- แม้ว่าเครื่องมือเขียนโค้ดด้วย AI จะช่วยเพิ่มความเร็วในการพัฒนาได้ แต่คอขวดที่แท้จริงไม่ได้อยู่ที่การเขียนโค้ด แต่อยู่ที่กระบวนการที่ไม่มีประสิทธิภาพขององค์กร
- เมื่อเพิ่มปริมาณการผลิตโค้ด ปัญหาค้างในขั้นตอนที่ไม่ใช่การพัฒนา เช่น การรอรีวิว การดีพลอยล่าช้า และข้อกำหนดที่ไม่ชัดเจน จะยิ่งรุนแรงขึ้น และเวลา cycle time จริงกลับยิ่งเพิ่มขึ้น
- ตามทฤษฎีข้อจำกัด (Theory of Constraints) ของ Eli Goldratt หากไปปรับให้ขั้นตอนที่ไม่ใช่คอขวดเร็วขึ้น ระบบไม่ได้เร็วขึ้น แต่กลับแย่ลง
- ในสถานการณ์ที่แม้แต่คนที่ "เขียน" โค้ดจาก AI ก็ยังไม่เข้าใจโค้ดนั้นทั้งหมด จะเกิดความเสี่ยงเชิงโครงสร้างที่พื้นที่ผิวของการรับมือเหตุขัดข้องกว้างขึ้น แต่คนที่สามารถอธิบายและวิเคราะห์ระบบได้กลับน้อยลง
- ความได้เปรียบในการแข่งขันไม่ได้ตกเป็นของทีมที่เขียนโค้ดได้เร็วที่สุด แต่เป็นทีมที่รู้ว่าควรสร้างอะไร และส่งมอบสิ่งนั้นไปถึงมือผู้ใช้ได้
จุดเริ่มต้นของการปรับให้เหมาะสมผิดจุด
- เริ่มมีการประกาศว่าการนำ AI coding assistant มาใช้ทำให้ปริมาณโค้ดที่ผลิตได้เพิ่มขึ้น 40%
- แต่คำถามว่า “เร็วขึ้นไปเพื่ออะไร” กลับหายไป
- หากทุ่มทรัพยากรไปยังขั้นตอนที่เร็วอยู่แล้ว (การเขียนโค้ด) ทั้งระบบจะยิ่งช้าลง
- เมื่อเร่งส่วนที่ไม่ใช่คอขวด จะเกิดสต็อกโค้ดที่ยังไม่เสร็จสะสม และนำไปสู่คุณภาพที่ลดลงกับความสับสน
หากไปปรับจุดที่ไม่ใช่คอขวด ระบบจะยิ่งพัง
- แก่นของทฤษฎีข้อจำกัด (Theory of Constraints) ที่ Eli Goldratt เสนอไว้ในนิยาย The Goal เมื่อปี 1984 คือ ทุกระบบมีคอขวดอยู่เพียงหนึ่งจุด และ throughput ของทั้งระบบถูกกำหนดโดย throughput ของคอขวดนั้น
- หากไปปรับขั้นตอนที่ไม่ใช่คอขวดให้เร็วขึ้น ระบบจะไม่ได้เร็วขึ้น แต่จะมีเพียงงานที่ยังไม่เสร็จสะสมมากขึ้น จนนำไปสู่ lead time ที่ยาวขึ้น ความสับสน และคุณภาพที่ลดลง
- เปรียบเทียบง่าย ๆ คือ ต่อให้สถานี A ผลิต widget ได้เร็วขึ้น แต่ถ้าสถานี B ซึ่งเป็นคอขวดยังประมวลผลได้เร็วเท่าเดิม ก็ไม่ต่างจากการมีกอง widget ที่ยังไม่ได้ประมวลผลสะสมอยู่ระหว่าง A กับ B เท่านั้น
สิ่งที่จะเกิดขึ้นจริงเมื่อ "ปริมาณโค้ดเพิ่ม 3 เท่า"
- นักพัฒนาสร้าง PR ได้เร็วกว่าเดิมมาก แต่จำนวน reviewer เท่าเดิม ทำให้ PR ต้องค้างในคิวรีวิวเป็นวัน ๆ สองวัน หรือเป็นสัปดาห์
- คนเขียนเปลี่ยนบริบทไปทำฟีเจอร์ถัดไปที่มี AI ช่วยแล้ว พอถึงเวลาต้องตอบคอมเมนต์รีวิวของโค้ดที่เขียนไว้เมื่อ 8 วันก่อน ก็แทบจำโค้ดส่วนนั้นไม่ได้แล้ว
- เมื่อมีรีวิวมากเกินไป ก็จะเกิดการรีวิวแบบ rubber stamp ที่อนุมัติโดยแทบไม่ได้อ่านจริง
- CI ใช้เวลา 45 นาที แถมยังล้มเหลวจาก flaky test แล้วต้องรันใหม่ ส่วน deployment pipeline ก็ต้องรอการอนุมัติแบบแมนนวลจากผู้รับผิดชอบที่กำลังประชุมอยู่ ทำให้ฟีเจอร์ถูกทิ้งไว้ใน staging นาน 3 วัน
- นักพัฒนาเปิด PR เพิ่มไปอีก 2 อันแล้ว ทำให้WIP (Work In Progress) พุ่งสูง ทุกคนกำลังทำ 6 อย่างพร้อมกันจนสุดท้ายไม่มีอะไรเสร็จ
- ผลคือผลิตโค้ดได้มากขึ้น แต่ปล่อยซอฟต์แวร์ออกได้น้อยลง cycle time แย่ลง แต่แดชบอร์ดยังโชว์ว่าประสิทธิภาพเพิ่มขึ้น 40%
- ความเสี่ยงเพิ่มเติมของโค้ดที่ AI สร้างคือ คนที่บอกว่าเป็นผู้ "เขียน" จริง ๆ แล้วแค่พิมพ์พรอมต์แล้วไล่ดูผ่าน ๆ ดังนั้นเมื่อระบบ production ล่มตอนตี 2 ทั้งคน on-call และคนเขียนพรอมต์อาจอธิบายโค้ดส่วนนั้นไม่ได้
- โค้ดเพิ่มขึ้นแต่ความเข้าใจลดลง แบบนี้ไม่ใช่ productivity ที่ดีขึ้น แต่คือระเบิดเวลาที่มีแดชบอร์ดสวยกว่าเดิมติดอยู่
คอขวดที่แท้จริง 1: ไม่รู้ว่าควรสร้างอะไร
- PM ไม่ได้คุยกับผู้ใช้จริงมา 2 เดือน แล้ว requirement ก็ถูกส่งมาในรูปแบบJira ticket 3 บรรทัดกับลิงก์ Figma
- วิศวกรต้องตัดสินใจยิบย่อยวันละ 50 เรื่อง (พฤติกรรม, edge case, การจัดการ error) แบบเดาเอา เพราะไม่มีสเปกชัดเจน
- ทีมหนึ่งใช้เวลา6 สัปดาห์พัฒนาฟีเจอร์จากสิ่งที่เซลส์ส่งต่อใน Slack โดยอ้างอิงจากสิ่งที่ลูกค้าเป้าหมายอาจเคยพูดไว้ในการโทร แต่สุดท้ายลูกค้ารายนั้นไม่ซื้อ และฟีเจอร์ดังกล่าวมีคนใช้เพียง 11 คน (ในนั้น 9 คนเป็น QA ภายใน)
- การเขียนโค้ดให้เร็วขึ้น จึงแค่ทำให้เราสร้างสิ่งที่ผิดได้เร็วขึ้น เท่ากับเป็นการทำระบบอัตโนมัติให้กับการเดา
- คอขวดคือความเข้าใจปัญหา และมันแก้ไม่ได้ด้วยการพิมพ์ให้เร็วขึ้น
คอขวดที่แท้จริง 2: ทุกอย่างหลังจากโค้ด "เสร็จแล้ว"
- ในองค์กรส่วนใหญ่ การเขียนโค้ดคิดเป็นเพียงประมาณ20% ของการเดินทางทั้งหมด อีก 80% ที่เหลือคือเวลาที่โค้ดนอนรออยู่ในคิวต่าง ๆ
- มีกรณีที่ฟีเจอร์หนึ่งใช้เวลาแค่ช่วงบ่ายเดียวในการเขียนโค้ด แต่ต้องใช้เวลา2 เดือนกว่าจะขึ้น production
- มีทั้ง PR review, CI, staging, QA, security review, product approval, deployment window, canary rollout และชุดของการส่งต่องาน การรอ และคิวที่ยาวต่อเนื่องกัน
- ตลอดเวลาส่วนใหญ่ โค้ดไม่ได้เคลื่อนที่ไปไหนเลย แต่กำลังรอให้ใครสักคนเข้ามาดู รอให้ pipeline รัน หรือรอการอนุญาตให้มีตัวตน
- หากอยากปล่อยได้เร็วขึ้น ต้องหาว่างานไปค้างอยู่ตรงไหน และต้องวัดสัดส่วนระหว่างเวลาที่ทำงานจริงกับเวลาที่รอในคิว
คอขวดที่แท้จริง 3: วงจรอุบาทว์ของความไม่น่าเชื่อถือในการ deploy
- เมื่อ test flaky, observability แย่มาก และไม่มีใครเชื่อถือกระบวนการ canary ทีมต่าง ๆ ก็จะกลัวการ deploy
- เพราะความกลัว จึงรวมการเปลี่ยนแปลงให้เป็น release ก้อนใหญ่ขึ้น ซึ่งทำให้ความเสี่ยงสูงขึ้น ทำให้การ deploy ยิ่งน่ากลัว และวนกลับไปสู่การรวมก้อนให้ใหญ่ขึ้นอีก กลายเป็นวงจรอุบาทว์ของความกลัว
- ถ้ายิ่งเติมความเร็วในการผลิตโค้ดเข้าไปอีก: โค้ดจะมากขึ้น แต่ culture การ deploy ยังกลัวเหมือนเดิม ดังนั้นbatch จะใหญ่ขึ้นและความถี่ในการ release จะยิ่งลดลง
คอขวดที่แท้จริง 4: ไม่มี feedback หลังปล่อย
- หลังจากสร้างและปล่อยฟีเจอร์ไปแล้ว ก็ไม่มีทั้งการวิเคราะห์ที่เหมาะสม ไม่มีการสัมภาษณ์ผู้ใช้หลังปล่อย และไม่มีใครตรวจว่าฟีเจอร์นั้นแก้ปัญหาได้จริงหรือไม่
- ฟีเจอร์ถัดไปก็เดา อีกฟีเจอร์ก็เดา ทั้ง product roadmap กลายเป็นชุดของการเดาแบบไร้ feedback
- การผลิตโค้ดได้เร็วขึ้นจึงแค่ทำให้วงจร "สร้าง ปล่อย แล้วก็ยักไหล่" หมุนเร็วขึ้นเท่านั้น
คอขวดที่แท้จริง 5: ปฏิทินคือกำแพงรับน้ำหนักของระบบ
- บางครั้งคอขวดไม่ใช่เรื่องเทคนิค แต่เป็นการประชุมเพื่อการตัดสินใจ การตกลง API contract ระหว่าง 3 ทีมที่ไม่ได้คุยกันมาเป็นเดือน และbacklog ที่ค้างยาว 2 สัปดาห์ ของสถาปนิกที่เป็นจุดอนุมัติเพียงคนเดียวสำหรับงานออกแบบสำคัญทั้งหมด
- เพราะกระบวนการวางแผนรายไตรมาสกินเวลา 6 สัปดาห์ งานด่วนก็ยังต้องรอ 5 สัปดาห์ ถึงจะเริ่มได้
- ยังมีสถานการณ์จริงที่ฟีเจอร์ยังไม่ถูกปล่อยเพราะ "กำลังรอประชุมกับคนที่ลาพักร้อนอยู่"
- ทั้งหมดนี้คือปัญหาด้านการประสานงาน ปัญหาด้านคน และปัญหาทางการเมืองในองค์กร ซึ่งไม่เกี่ยวอะไรกับความเร็วในการเขียนโค้ด
สิ่งที่ควรทำแทน
- ทำ value stream mapping: ไล่ตามฟีเจอร์หนึ่งตั้งแต่ไอเดียจนถึง production แล้วบันทึกเวลาที่ใช้ในแต่ละขั้นและเวลารอระหว่างขั้น
- วัด cycle time: อย่าวัดจากจำนวนบรรทัดโค้ด จำนวน PR ที่ merge หรือ story point แต่ให้วัดเวลาตั้งแต่ commit จนผู้ใช้สามารถใช้งานใน production ได้จริง
- กำจัดสถานะรอ: ถ้า PR review ใช้เวลา 2 วัน ให้แก้ด้วย pair programming, PR ขนาดเล็ก, ช่วงเวลารีวิวโดยเฉพาะ หรือกติกาการรีวิวแบบ async ถ้าการ deploy ต้องรอแมนนวลอนุมัติ ก็ทำให้เป็นอัตโนมัติ หรืออย่างน้อยเปลี่ยนเป็นปุ่มใน Slack
- หยุดเริ่ม แล้วโฟกัสที่การทำให้เสร็จ: มีเหตุผลที่ต้องจำกัด WIP เพราะของที่เสร็จ 3 อย่าง ดีกว่าของที่กำลังทำ 10 อย่าง ทุกงานที่อยู่ระหว่างทำมีต้นทุนจาก context switching
- คุยกับคนที่ทำงานจริง: นักพัฒนารู้อยู่แล้วว่าคอขวดอยู่ตรงไหน พวกเขาบ่นเรื่องนี้ใน standup และทำมีมใน Slack กันมาหลายเดือนแล้ว เพียงแต่คิดว่าไม่มีใครฟัง
ข้อสรุปสำคัญ
- แทนที่ VP จะประกาศว่า "ปริมาณโค้ดเพิ่มขึ้น 40%" เขาควรพูดว่า "จากการวิเคราะห์ value stream เราพบว่าฟีเจอร์หนึ่งรอเฉลี่ย 9 วันระหว่างแต่ละขั้น และเราจะลดเวลานั้นลงครึ่งหนึ่ง"
- ความได้เปรียบในการแข่งขันไม่ได้เป็นของทีมที่เขียนโค้ดได้เร็วที่สุด แต่เป็นทีมที่รู้ว่าควรสร้างอะไร สร้างมันขึ้นมา และส่งมันไปถึงมือผู้ใช้ได้
- คอขวดไม่ใช่คีย์บอร์ด
4 ความคิดเห็น
> ลูกค้าที่มีแนวโน้มรายนั้นไม่ได้ซื้อ และมีผู้ใช้ฟีเจอร์นั้นเพียง 11 คน (ในนั้น 9 คนเป็น QA ภายใน)
ฮ่าๆ
ไปป์ไลน์ก็ยังเหมือนเดิม
ดูเหมือนว่านักพัฒนากลายเป็นคนไร้ความรับผิดชอบกันเองมากขึ้นเฉยๆ
อยากเป็นช่างฝีมือซอฟต์แวร์
ความคิดเห็นจาก Hacker News
ตอนที่ทีมของเราเริ่มนำ การพัฒนาแบบ agent-based มาใช้อย่างจริงจัง เรากังวลว่าความเร็วในการเขียนโค้ดจะเพิ่มขึ้น แต่เวลาที่ใช้รีวิวจะยาวขึ้นหรือไม่
ตอนนี้ยังไม่เห็นการเปลี่ยนแปลงที่ชัดเจน และทุกคนก็กำลังเรียนรู้เวิร์กโฟลว์ใหม่อยู่ จึงยังมีข้อมูลไม่มากพอ
แต่การเขียนโค้ดได้เร็วมีประโยชน์มากในบางกรณี — เช่น การทดลองไอเดีย, งานวนซ้ำที่ซับซ้อน, การทำสิ่งที่เรียบง่ายแต่ใช้แรงมาก, หรือการจัดการ edge case หลังจาก happy path แล้ว
โดยเฉพาะในกรณีที่ต่อยอดจาก branch หรือ PR เดิม agent ทำงานได้ดีมาก
การเพิ่มผลิตภาพที่ใหญ่ที่สุดคือ ระหว่างที่ agent เขียนโค้ด ฉันสามารถไปทำอย่างอื่นได้ เช่น ไปรีวิว PR แล้วกลับมาก็มีผลลัพธ์รออยู่แล้ว
ตอนแรกฉันค่อนข้างสงสัย แต่ตอนนี้เริ่มมองในแง่ดีอย่างระมัดระวัง แม้จะไม่ถึง 10 เท่า แต่ถ้าได้ ดีขึ้น 2 เท่า ก็ถือว่ายอดเยี่ยมแล้ว
วิธีนี้พอใช้ได้เฉพาะตอนที่ต้นทุนของความผิดพลาดต่ำ หรือขอบเขตการเปลี่ยนแปลงเล็กเท่านั้น ไม่อย่างนั้นทั้งคุณภาพและความพึงพอใจก็ลดลง แถมตารางเวลาก็ยิ่งถูกบีบ
สุดท้ายแล้วมันไม่ใช่การได้เวลากลับคืนมาแบบขนานจริง ๆ แค่เป็นการผัดวันประกันพรุ่งให้น้อยลงนิดหน่อยเท่านั้น
เพียงแต่การไปทำอย่างอื่นระหว่างที่ agent เขียนโค้ดให้ มันให้ความรู้สึก เหนื่อยล้าแบบแปลก ๆ
AI มีประสิทธิผลก็จริง แต่เป็นแรงงานคนละแบบกับการเขียนโค้ดในฐานะงานช่างฝีมือของมนุษย์โดยสิ้นเชิง
รีแฟกเตอร์ที่ถ้าทำเองคงตัดใจทิ้งยาก แต่ถ้า AI เป็นคนทำ เราจะตัดสินได้ง่ายกว่าว่า “อันนี้ไม่ค่อยดี”
ถ้าต้องมัลติทาสก์ตลอดจะ หมดไฟ ได้เร็ว เสียดายที่การถกเถียงนี้ไม่ค่อยพูดถึงปัจจัยความเป็นมนุษย์
ฉันไม่ได้อยากทำงานในสภาพ ‘ถูก optimize’ ตลอดเวลา
มีคนบอกว่า “คอขวดคือการทำความเข้าใจปัญหา” แต่ฉันอยากถามว่า ทำไม การพิมพ์ให้เร็วขึ้น ถึงจะช่วยให้เข้าใจปัญหาไม่ได้ล่ะ
ถ้าเราสร้างของที่ผิดได้เร็วขึ้น ก็อาจช่วยให้เจอทิศทางที่ถูกได้เร็วขึ้นไม่ใช่หรือ?
ฉันมักจะรู้ว่าตัวเองต้องการอะไรจริง ๆ ก็ตอนลงมือสร้างอะไรบางอย่างขึ้นมา ยิ่งการทำต้นแบบถูกลง แนวโน้มนี้ก็ยิ่งชัด
แน่นอนว่าสุดท้ายก็มักจะจบลงด้วยการย้อนมองว่า “เราควรคุยกับผู้ใช้ให้มากกว่านี้” แต่นั่นก็เป็นอีกปัญหาหนึ่ง
ที่อย่างธนาคาร บางทีก็ทดลองได้อย่างมากแค่สัปดาห์ละครั้ง
แต่ซอฟต์แวร์ส่วนใหญ่ไม่ใช่แบบนั้น การเขียนโค้ดเป็นแค่ส่วนหนึ่งของงานทั้งหมด
เหมือนศัลยแพทย์ไม่ได้มีหน้าที่แค่ ‘ผ่า’ อย่างเดียว วิศวกรเองก็ไม่ได้มีหน้าที่แค่เขียนโค้ดเท่านั้น
ถ้านั่งเกลาโค้ดอยู่คนเดียว มันก็แค่สร้างความสับสนที่ใหญ่ขึ้นเท่านั้น
บางครั้งคุยกับ PM หรือลูกค้าสักหนึ่งชั่วโมงยังดีกว่าเยอะ
กระแส LLM บูม ตอนนี้ให้ความรู้สึกเหมือนมีโซลูชันออกมาก่อนปัญหา
ถ้าจะเพิ่มความเร็วจริง ๆ ต้องถามก่อนว่า “คอขวดอยู่ตรงไหน?”
ที่ผู้บริหารดูพรีเซนเทชัน AI แล้วเชื่อว่า “ใช้สิ่งนี้แล้วจะเร็วขึ้น” นั้น ก็เป็นแค่ การบริหารตามบรรยากาศ (vibe management) เท่านั้น
การเขียนโค้ดคือส่วนที่ ใช้แรงงานมากและทำให้เป็นอัตโนมัติได้มากที่สุด ในทั้งหมดนี้
LLM สามารถช่วยลดภาระส่วนนี้ได้มาก โดยเฉพาะการเขียนเทสต์โค้ดที่ AI ทำได้ดี
นักพัฒนาที่เป็นมนุษย์ยังคงปล่อยวาง ความยึดติดกับโค้ด ไม่ได้
จริง ๆ แล้วโค้ดก็เป็นเพียงตัวแทนระดับกลาง (IR) ของคำตอบเท่านั้น
เหมือนที่ GCC แปลงเป็นแอสเซมบลีโดยเราไม่ต้องไปสนใจการ optimize ภายใน ถ้า agent สร้างโค้ดขึ้นมา เราก็ควรดูแค่ความถูกต้องของผลลัพธ์
ถ้ามีสเปกที่ชัดเจนและกระบวนการตรวจทานซ้ำอย่างต่อเนื่อง ไม่ว่าจะเป็นมนุษย์หรือ agent ก็ควรให้ implementation เดียวกันได้
LLM ไม่ได้เป็นแบบนั้น มันอาจตีความผิดหรือเกิด ภาพหลอน (hallucination) ได้
เพราะงั้นมนุษย์ก็ยังต้องรีวิวอยู่ดี
บ่อยครั้ง agent เลือกรูปแบบที่ผิด หรือสร้าง หนี้ทางเทคนิค เพิ่ม
สักวันหนึ่งเราอาจเลิกใช้ภาษาโปรแกรมไปเลยก็ได้ แต่ตอนนี้ยังอีกไกล
ความหมายอาจถูกขยาย ถูกบีบอัด หรือแม้แต่หายไปเลยก็ได้
หลายบริษัทไม่ได้ต้องการ โค้ดที่ดี จริง ๆ
การประเมินภายในดูจากว่า “ปล่อยของได้มากแค่ไหน” และถ้าชี้ปัญหาก็มักจะถูกบอกว่า “ละเอียดเกินไป”
สุดท้ายแล้วผู้มีส่วนได้ส่วนเสียภายในแค่อยากได้เหตุผลไปบอกว่า ‘มันสำเร็จแล้ว’
คนเทคนิคมีหน้าที่ต้องอธิบายความเสี่ยงนั้น
หลังจากนำ AI มาใช้ ก็เริ่มเห็น คุณภาพลดลง เกิดขึ้นจริง
บริษัทของฉันอนุมัติ PR กันแบบลวก ๆ, CI ใช้เวลา 45 นาที, deployment ล่าช้าเป็นวัน ๆ
แถมยังห้ามใช้ AI ด้วย ถึงจะบอกว่าส่วนใหญ่เป็นโค้ดที่มนุษย์เขียน แต่ก็ชวนให้สงสัย
สิ่งที่บทความนี้พลาดไปมีสองอย่าง — (A) การใช้ agent กับการ optimize กระบวนการสามารถอยู่ร่วมกันได้, (B) บาง ticket นั้นคอขวดคือโค้ดจริง ๆ
ท้ายที่สุดแล้วสิ่งสำคัญไม่ใช่ว่าใช้ AI หรือไม่ แต่คือ การปรับปรุงกระบวนการเพื่อลดคอขวด
ฉันเป็น นักพัฒนาคนเดียว ความเร็วในการเขียนโค้ดเป็นปัญหาจริง เพราะมันแย่งเวลาจากงานอย่างอื่น
วันนี้เพิ่งตั้งค่า Claude Code ไป ตอนนี้เลยเสียเวลากับการค้น Google หรือการเขียนเทสต์น้อยลง
มันอาจไม่ได้เพิ่มผลิตภาพ 10 เท่า แต่ในฐานะ เทคโนโลยีประหยัดแรงงาน มันมีคุณค่ามากพอ เหมือนเครื่องล้างจาน
ตอนนี้ AI เขียนเทสต์ให้ด้วย แถมยังเตือน edge case ให้
มันไม่สมบูรณ์แบบ แต่ ความเร็วในการออกฟีเจอร์ใหม่ เพิ่มขึ้น และฉันก็มีเวลามากขึ้น
คำพูดที่ว่า “เชื่อ AI ไม่ได้” ฟังดูเหมือนกับคำว่า “เชื่อคอมไพเลอร์ไม่ได้”
สุดท้ายแล้วมันคือกระบวนการที่มนุษย์กำหนดทิศทาง ปรับปรุงพรอมป์ต์ และเติบโตไปด้วยกัน
ในสตาร์ตอัปหรือสภาพแวดล้อมแบบ VC สิ่งสำคัญคือ การแก้ปัญหาทางธุรกิจ มากกว่าการเขียนโค้ด
ต่อให้ปริมาณโค้ดเพิ่มขึ้น ก็ไม่ได้มีหลักประกันว่าผลลัพธ์ของทั้งระบบจะดีขึ้น
มันช่วยให้เร็วขึ้นเหมือน template หรือ code generator แต่ถ้าการ เก็บ requirement ไม่ได้เร็วขึ้น 10 เท่า ก็ไม่มีทางได้ผลิตภาพเพิ่ม 10 เท่า
ถ้าใช้เป็นอุปมา ก็อาจไม่ค่อยเหมาะนัก
จะทำอย่างไรให้ AI ไม่ก่อ ความผิดพลาดแบบที่คนมักไม่ทำ?
มนุษย์ตรวจโค้ดอย่างมีเหตุมีผลทีละขั้น แต่ AI ไม่ได้เป็นแบบนั้น
ต่อให้มีวิศวกรอาวุโสแบบที่ Amazon ใช้มารีวิว การรีวิวก็ไม่ได้เป็นกระบวนการที่ออกแบบมาเพื่อจับบั๊กทุกตัว
ยิ่งเป็นระดับ senior ก็ยิ่งมีประชุมเยอะ จนไม่ค่อยรู้บริบทของโค้ด รีวิวแบบนี้จะมีประสิทธิภาพแค่ไหนกัน?
การคิดว่ามนุษย์สมบูรณ์แบบเป็นความเข้าใจผิด
เรากำลังตั้งมาตรฐานกับ AI สูงกว่าที่ตั้งกับมนุษย์
สุดท้ายสิ่งสำคัญคือ การเสริมกระบวนการ QA อย่าให้การทดสอบเป็นหน้าที่ของนักพัฒนาเพียงอย่างเดียว
ทำให้นึกถึงหนังสือเก่าที่เคยอ่านชื่อ 《The Goal》 พอทำให้ขั้นตอนหนึ่งของกระบวนการเป็นอัตโนมัติ ขั้นตอนถัดไปก็กลายเป็นคอขวดแทน
ซอฟต์แวร์ก็เหมือนกัน ถึงการสร้างโค้ดจะเร็วขึ้น แต่ถ้ากระบวนการทั้งระบบตามไม่ทันก็ไม่มีความหมาย
ท้ายที่สุดแล้ว ทุกอย่างขึ้นกับเป้าหมายเรื่อง การสร้างกำไร และคุณภาพของโค้ดก็เป็นเพียงแนวคิดย่อยภายใต้เป้าหมายนั้น
ความเร็วในการเขียนโค้ด ไม่ใช่คอขวดในสถานการณ์ที่มีความเสี่ยงสูง
บางครั้งการวางแผนอย่างช้า ๆ และใคร่ครวญผลลัพธ์ให้รอบคอบกลับดีกว่า
ตัวอย่างเช่น ถ้าสร้างระบบขนาดมหาศาลเร็วเกินไปอย่างในอุตสาหกรรม AI ก็อาจก่อ ความเสี่ยงระดับอารยธรรม ไปในทิศทางที่ผิดได้
แต่ถ้าเป็นเกมเล็ก ๆ ที่ทำคนเดียวในวันหยุดสุดสัปดาห์ก็ไม่เป็นไร สุดท้ายแล้ว ขนาดของความเสี่ยง ต่างหากที่เป็นตัวกำหนดความเร็ว