ทำไมโรงงานซอฟต์แวร์ถึงล้มเหลว

หรือ: การใช้ harness อย่างเดียวยังไม่พอ

อัปเดต - เวอร์ชัน talk ของโพสต์นี้ได้เผยแพร่บน youtube แล้ว: https://www.youtube.com/watch?v=Ib5GBkD555M

ฉันว่าเรากำลังวนลูปกันแล้วแหละ

เราทุกคนกำลังแข่งกันนำ AI coding ไปใช้ในการผลิตจริง มีการพูดถึง loop engineering มากมาย และความเห็นที่แพร่หลายคือเราควรจะเขียน loops ให้มากขึ้น

StrongDM เขียนเกี่ยวกับ software factory แบบไร้คนของพวกเขา ที่ไม่มีมนุษย์อ่านโค้ดและไม่มีมนุษย์เขียนโค้ด

เรื่องราวดำเนินไปประมาณนี้:

1. คุณคือคอขวด
2. โมเดลต่างๆ ดีพอแล้ว
3. โค้ดนั้นฟรี
4. แค่ส่งของออกไปให้มากขึ้น

Ryan Lopopolo จาก OpenAI เขียนเกี่ยวกับเรื่องนี้ในเดือนกุมภาพันธ์ และ บรรยายในเดือนเมษายน เกี่ยวกับ software factory ของ OpenAI ที่ชื่อ Symphony

คนเหล่านี้ล้วนฉลาดมาก และผมให้ความเคารพพวกเขาอย่างมาก แต่การมองในแง่ร้ายที่สุดตรงนี้ก็คือเรียกมันว่าเป็นข้ออ้างอีกข้อในการสูบเงิน VC เพิ่มเข้าไปในเครื่องยิงของไร้คุณภาพ

มันคือ...เอ่อ...มันกำลังดำเนินไป

เพื่อนของเรา Mario ขึ้นเวทีที่ AI Engineer Europe และ ขอร้องให้เราช้าลง -- เพราะบริษัทที่ไม่ควรมีเหตุให้ต้องหยุดให้บริการจากความผิดพลาดของ coding agent กำลัง... มีเหตุให้ต้องหยุดให้บริการจากความผิดพลาดของ coding agent

อย่างที่ Matt Pocock กล่าวไว้ codebases กำลังพังทลายเร็วกว่าที่เคยเป็นมา

ผมยังไม่สามารถหาข้อมูล/ผลลัพธ์ที่ชัดเจนจาก StrongDM เกี่ยวกับว่า dark factory นั้นดำเนินไปอย่างไร weather-report มีการอัปเดตเป็นระยะๆ ระหว่างเดือนกุมภาพันธ์ถึงมิถุนายนของปีนี้ แก้ไข - มีการสนทนากับทีมงานบน hacker news เมื่อวันที่ 23 กรกฎาคม - ดูเหมือนว่าเราอาจได้รับการอัปเดตอย่างเป็นทางการเร็วๆ นี้!

ทีมงานที่ Faros AI เผยแพร่รายงาน: ตั้งแต่เรา2 ทุกคนเริ่มใช้เครื่องมือ AI coding เหล่านี้เมื่อเดือนมกราคมและกุมภาพันธ์ คุณภาพการตรวจสอบ pull request ลดลงอย่างมาก

• มีความคิดเห็นมากขึ้น ความคิดเห็นยาวขึ้น และ PR จำนวนมากถูกรวมโดยไม่มีการตรวจสอบใดๆ เลย
• เหตุการณ์ขัดข้องเพิ่มขึ้นอย่างมาก
• ข้อบกพร่องต่อนักพัฒนาเพิ่มขึ้นอย่างมาก

รายงานนี้เป็นสัญญาณของความสัมพันธ์มากกว่าหลักฐานยืนยันที่ชัดเจน (ใช่ ผมเลือกคำนั้นโดยตั้งใจ อย่าให้ผมเริ่มพูดถึงสำนวนของ claude เลย) และประเด็นทั้งหมดของโพสต์นี้คือให้ระวังข้อมูลที่ไร้คุณภาพ แต่มัน ให้ความรู้สึก ว่าถูกต้องในเชิงทิศทางจากสิ่งที่ผมเห็น

"คุณถือมันผิดวิธี" (คุณไม่ได้ผิด)

หลายคนจะบอกคุณว่านี่เป็นปัญหาเรื่องทักษะ -- ว่าถ้าคุณไม่ได้รับผลลัพธ์ที่ดี นั่นเป็นความผิดของคุณ

แต่ไม่ว่าคุณจะเลือก...เอ่อ...ถือมันแบบไหน ผมรับประกันว่าคุณจะถูกบอกว่าถ้า token-maxxing ไม่ได้ผลสำหรับคุณ นั่นเป็นปัญหาเรื่องทักษะ คุณแค่ต้องใช้ tokens ให้มากขึ้น ปล่อยวางการอ่านโค้ด และถ้าคุณเพิ่งเริ่มมาถึงจุดนี้ ผมสัญญาว่ามันเป็นส่วนหนึ่งของความก้าวหน้า ผมก็คิดแบบนี้เมื่อฤดูร้อนที่แล้วเหมือนกัน

น่าเสียดายสำหรับอีโก้ของผม สิ่งโง่ๆ ที่ผมตัดสินใจพูดเกี่ยวกับ "วิธีถือมันให้ดีขึ้น" ถูกบันทึกไว้ และตอนนี้มีผู้ชมรวมกันประมาณล้านครั้งบน YouTube ผมไม่ได้พยายามอวดตรงนี้ ผมแบ่งปันสิ่งนี้เพื่อแสดงให้เห็นว่าผมได้ลงลึกในวิธีที่ดีที่สุดในการใช้ coding agents มาเป็น เวลานาน แล้ว และได้ค้นพบบางสิ่งที่หลายคนพบว่า มีประโยชน์อย่างแท้จริง

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed -- Solving Hard Problems in Complex Codebases
• Everything We Got Wrong About RPI

อย่างไรก็ตาม คำสัญญา ของการพูดพร่ำเพ้อออนไลน์เกี่ยวกับ "แค่ใช้ token ให้หนักขึ้น" ที่เราถูกบังคับให้ทนฟังนั้น คือ: ด้วยวิศวกรรม harness ที่เพียงพอ เราจะได้สิ่งที่ดีที่สุดของทั้งสองโลก:

• เร็วขึ้น 10 ถึง 100 เท่า
• มีคุณภาพสูง และ
• ไม่มีใครต้องทำสิ่งที่เราทุกคนเกลียดนั่นคือการตรวจสอบโค้ดอีกต่อไป

สิ่งที่เราต้องทำคือกำหนดค่า linters ให้มากขึ้น และโปรยคำวิเศษเช่น "adversarial review" ลงบนบอทตรวจสอบ PR ให้มากพอ แล้วซอฟต์แวร์ของเราจะสร้างตัวเองอย่างมีความสุขโดยไม่มีเหตุขัดข้อง

นี่ไม่ใช่ปัญหาเรื่องทักษะ

สิ่งที่ผมจะพยายามโน้มน้าวคุณคือ ไม่มีปริมาณของวิศวกรรม harness หรือ loopsmaxxing ใดๆ ที่จะสามารถแก้ไขสิ่งที่โดยพื้นฐานแล้วเป็นปัญหาเรื่องการฝึกฝนโมเดล (model-training issue)

เพื่อที่จะจัดการกับสิ่งนี้ ผมต้องเจาะลึกว่าโมเดลการเขียนโค้ดได้รับการฝึกฝนและประเมินผลอย่างไร -- ทั้งในส่วนของ RLVR และด้าน benchmark

ในโพสต์นี้ผมจะกล่าวถึง:

1. Software factories มีมาตั้งแต่ปี 1968, พวกมันพัฒนาไปอย่างไร, และ AI เปลี่ยนแปลงพวกมันอย่างไร
2. เหตุใดโมเดลจึงสามารถสร้างภูเขาแห่งโค้ดไร้คุณภาพได้ทั้งที่ทำคะแนนใน benchmark ได้ดีเยี่ยม (แม้แต่ benchmark "frontier" ใหม่ล่าสุด)
3. ถึงกระนั้น คุณก็ยังสามารถทำงานได้ค่อนข้างเร็วโดยไม่ทำให้ codebase ของคุณลุกเป็นไฟ

ผมจะพยายามตัดผ่าน hype ของปลั๊กอินทักษะใหม่ๆ ที่เกิดขึ้นทุกวัน และโรคระบาดของคำแนะนำ ai-psychosis-tokenmaxxing และพูดในแง่ทั่วไปเกี่ยวกับ ประเภทของสิ่งที่ใช้ได้ผล โดยไม่อ้างอิงถึงทักษะหรือกรอบงานใดเป็นพิเศษ

วิดีโอเวอร์ชัน: โพสต์นี้มีพื้นฐานมาจาก (และขยายความจาก) คำปราศรัยสำคัญของผมที่ AI Engineer World's Fair 2026

ขอบคุณ @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, และ @jeffreyhuber สำหรับข้อเสนอแนะในโพสต์นี้

ข้อสังเกต: สิ่งนี้ไม่เกี่ยวกับ vibe coding

Addy Osmani ได้แยกแยะสิ่งที่ควรค่าแก่การเน้นย้ำ:

นักพัฒนาที่กำลัง vibe-coding โปรเจกต์ส่วนตัวที่มีคนใช้งานไม่เกินสิบคน กับทีมที่ต้องรักษาระบบองค์กรอายุสิบปีให้อยู่รอดไปอีกไตรมาส แทบไม่มีข้อจำกัดใดๆ ที่เหมือนกันให้เอ่ยถึง และคำแนะนำส่วนใหญ่ที่หมุนเวียนอยู่นั้น แท้จริงแล้วคือหนึ่งในสองคนนั้นบอกอีกคนว่าควรใช้ชีวิตยังไง

ถ้าคุณรัก vibe coding เชิญเลยครับ ไป vibe ต่อไป ผมยังคง vibe code หลายๆ อย่างอยู่ เพียงแต่ผม ยังคง ดูแลซอฟต์แวร์ในระบบ production จำนวนมาก (และผ่าน HumanLayer ช่วยวิศวกรอีกหลายพันคนทำเช่นเดียวกัน) ดังนั้นส่วนที่เหลือจึงมุ่งไปที่ผู้คนที่กำลังแก้ปัญหายากๆ ใน codebases ที่ซับซ้อน

ผมได้ยินคำว่า brownfield บ่อยครั้งเพื่อพูดถึงการแบ่งแยกนี้ ในอดีตมันหมายถึง Java เก่าๆ อายุสิบปี แต่ด้วยความเร็วที่เราสามารถส่งงานได้ในตอนนี้ รู้สึกว่า codebase ที่สร้างโดย agent จะเริ่มมีปัญหาหลังจากผ่านไปประมาณ สามถึงหกเดือน -- คุณเริ่มช้าลง และวิธีที่คุณเข้าใกล้การเพิ่มสิ่งใหม่ๆ ต้องเปลี่ยนไป

ประวัติโดยย่อของ software factory

ผมสร้างและศึกษา software factories มาตลอดอาชีพการงาน แต่เพิ่งได้เรียนรู้เมื่อไม่นานนี้: คำนี้สืบย้อนกลับไปถึง การประชุม NATO ในปี 1968 -- การประชุมเดียวกับที่ให้คำว่า "วิศวกรรมซอฟต์แวร์" แก่เรา

อีกสิ่งเดียวที่ผมคิดว่าน่าสนใจมากตั้งแต่นั้นมาคือ กระทรวงกลาโหมสหรัฐฯ เขียน PDF จำนวน 31 หน้าเกี่ยวกับว่ากระทรวงกลาโหมจำเป็นต้องเริ่มใช้ jenkins ให้ดีขึ้นหรืออะไรบางอย่าง

Software factory ปี 2022

มาทำความเข้าใจนิยาม "software factory" ของเรารอบๆ ปี 2022 ก่อนยุค AI กัน ใน software factory ทั่วไป:

• คนตัดสินใจว่าจะสร้างอะไร -- วิศวกร, PM, ผู้บริหารที่ขับเคลื่อนวิสัยทัศน์
• มันเข้าสู่ระบบติดตาม -- Linear, Jira, อะไรก็ได้: เครื่องจักรสถานะของสิ่งที่ต้องทำ
• มีคนหยิบ ticket มาสร้างมัน -- อาจจะทำการทดสอบด้วยตนเอง/อัตโนมัติในขณะเดียวกัน
• Pull request -- การตรวจสอบอัตโนมัติ, มีมนุษย์ตรวจสอบโค้ด, อาจมีคนดึงลงมาทดสอบ
• มีอะไรผิดพลาดไหม? ย้อนกลับ ไปที่ "มีคนสร้างสิ่งนั้น"
• ส่งไปยัง production -- และมันได้สัมผัสกับผู้ใช้
• เพิ่มการตรวจสอบ -- มีอุตสาหกรรมทั้งหมดที่สร้างขึ้นมาเพื่อแจ้งเตือนวิศวกรตอนตี 3 เมื่อมีอะไรพัง
• ผู้ใช้บ่น -- ขอสิ่งต่างๆ, เจอข้อบกพร่อง, ยื่นคำขอฟีเจอร์ → กลับไปที่ทีมเพื่อเพิ่มในระบบติดตาม

และต่อไปเรื่อยๆ เรายังไม่ถึง AI ด้วยซ้ำ และก็มีหลาย loops ในภาพนี้แล้ว

การจัดแนวล่วงหน้า (front-loading alignment)

มีสิ่งหนึ่งที่ทีมต่างๆ ค้นพบเมื่อหลายสิบปีก่อน: การสร้างใช้เวลาหลายชั่วโมงหรือหลายวัน และการตรวจสอบก็เช่นกัน

ดังนั้นเราจึงจัดงานล่วงหน้า -- การวางแผน, ข้อเสนอด้านสถาปัตยกรรม, การวางแผน sprint -- ร่วมกันเป็นทีม ซึ่งหมายความว่า:

• ทำงานซ้ำน้อยลง, เพราะเราจัดแนวกันก่อนที่ใครจะเขียนโค้ด
• ใช้เวลาตรวจสอบทุกบรรทัดน้อยลง, ถ้าคุณเคยอ่าน PR ที่ยาวแต่ทำได้ดี คุณจะรู้ว่าการตรวจสอบเร็วแค่ไหนเมื่อมันใกล้จะสมบูรณ์แบบ

เราจะกลับมาที่เรื่องนี้ทีหลัง -- มาดูกันว่าเกิดอะไรขึ้นเมื่อคุณนำ agentic coding เข้ามาในภาพ

Software factory แบบ agentic

ตอนนี้ทุกบริษัทและแม่ของพวกมัน --

• Ramp
• Stripe
• WorkOS
• Brex

ใช้เวลาช่วงที่ผ่านมาของปีนี้ในการอธิบายว่าพวกเขาสร้าง agent factory ที่ส่งมอบโค้ดได้ประมาณ 75% ได้อย่างไร

agentic factory ส่วนใหญ่มีลักษณะเหมือนการสลับ "มีคนสร้างสิ่งนั้น" → "agent สร้างสิ่งนั้น" -- มีบางอย่างตรงนี้เช่น orchestration, harness, sandbox, model, computer use, ฯลฯ ผมจะไม่ลงรายละเอียดพวกนั้นเพราะพูดตามตรงผมเบื่อที่จะอ่านเกี่ยวกับมันแล้ว และผมแน่ใจว่าคุณก็เหมือนกัน

เมื่อ agent สร้างสิ่งนั้น:

• การสร้างลดลงจากหลายชั่วโมงหรือหลายวันเหลือเป็นนาทีหรือชั่วโมง
• การตรวจสอบยังคงใช้เวลาหลายชั่วโมงหรือหลายวัน มนุษย์ยังคงต้องอ่านโค้ดและทดสอบการเปลี่ยนแปลง ดังนั้นการตรวจสอบจึงเป็นคอขวดแล้ว

ดังนั้นคุณก็เร่งการตรวจสอบเช่นกัน:

• การตรวจสอบโค้ดแบบ agentic, เพื่อจับสไตล์, ข้อบกพร่อง, ความปลอดภัย
• การทดสอบการถดถอยแบบ agentic, เพื่อทดสอบจากภายนอกด้วยเบราว์เซอร์และ computer use และอาจส่งวิดีโอน่ารักๆ ให้คุณเมื่อเสร็จ

ตอนนี้การตรวจสอบเร็วขึ้นแล้ว แต่มันก็อาจยังคงเป็นคอขวด แต่เราสามารถทำ loops ได้มากขึ้น

ต่อไปคุณอาจจะส่งต่อเหตุการณ์ขัดข้องเข้าไปใน factory แทนที่จะแจ้งเตือนใครสักคนตอนตี 3 พวกเขาตื่นขึ้นมาเจอ PR ที่อาจแก้ไขมันได้แล้ว

เรายังสามารถส่งต่อความคิดเห็นของผู้ใช้เข้าไปใน factory ได้อีกด้วย ผู้คนขอสิ่งต่างๆ มันก็ถูกสร้างขึ้น

ถึงจุดนี้งานก็เหลือแค่สองคำถาม: คุณสามารถยัดอะไรเข้าไปในคิวได้มากแค่ไหน และคุณสามารถตรวจสอบและทดสอบสิ่งที่ออกมาได้เร็วแค่ไหน?

ซึ่งนำเรามาสู่ software factory แบบไร้คน

Software factory แบบไร้คน (lights-off software factory)

Dan Shapiro บัญญัติศัพท์นี้ และ Simon Willison เขียนเกี่ยวกับการนำไปใช้ของ StrongDM -- ที่ซึ่งเราไม่ต้องอ่านโค้ดอีกต่อไป

คุณมองดู software factory ที่สวยงามของคุณ มันถูกทำลายโดยขั้นตอนการตรวจสอบโค้ดที่น่ารำคาญนั้น และคุณก็พูดว่า: คุณรู้ไหม สิ่งที่มนุษย์ต้องอ่านทุกการเปลี่ยนแปลงนั้น? ไม่เอาล่ะ

ดังนั้นคุณจึงทิ้งมันไป และคุณทุ่มเทความพยายามไปที่อื่น:

• ลงทุนในการทดสอบและปล่อยให้ agent ทดสอบงานของตัวเอง
• ลงทุนใน sandboxes และ orchestration
• ลงทุนในการตรวจสอบอัตโนมัติ
• ลงทุนในการตรวจสอบ (monitoring)
• ลงทุนในการเผยแพร่ (rollout)
• ลงทุนในการรวบรวมสัญญาณ feedback จากผู้ใช้

และตอนนี้งานก็เหลือเพียงคำถามเดียว: เราสามารถขอให้ agent สร้างอะไรได้มากแค่ไหน? เราต้องการ ต้มมหาสมุทร มากแค่ไหน?

นี่จะต้องไปได้สวยแน่ๆ (มันไม่)

ผมจะเสนอสิ่งที่อาจเป็นที่ถกเถียง: โรงงานแบบไร้คนใช้ไม่ได้ผล

มาดูกันว่าเหตุใด software factories จึงล้มเหลว

เราลองสิ่งนี้แล้ว

ในเดือนกรกฎาคม 2025 เราใช้ระบบไร้คนเต็มรูปแบบ อ่านแค่สเปกและ tickets, ใช้ background agents สำหรับงานเล็ก/งานกลางทั้งหมด ทุกอย่าง

ถ้าคุณลองทำจริงจังสักสองสามเดือน คุณก็รู้แล้วว่ามันจบลงอย่างไร คุณจะเจอปัญหาอย่างน้อยหนึ่งข้อที่ยากพอที่ agent จะแก้ไม่ได้ -- แม้จะใช้ prompt และ workflow ที่ทันสมัยที่สุดของคุณก็ตาม

• คุณทำการวิจัยที่คำนึงถึงบริบทอย่างลึกซึ้ง รวบรวมส่วนที่ถูกต้องทั้งหมดไว้ในโซนอัจฉริยะเพื่อให้โมเดลวิเคราะห์
• คุณให้ agent ลองทำซ้ำใน 10 วิธีที่แตกต่างกัน

ในที่สุดคุณต้องทำใจและลงไปขุดคุ้ย codebase ที่คุณหยุดอ่านเมื่อสามเดือนก่อน พยายามหาว่าอะไรพัง

และในขณะเดียวกัน:

• เว็บไซต์ของคุณล่ม
• ผู้ใช้ของคุณโกรธ
• และคุณ ถ้าคุณเป็นเหมือนผม ก็คงทุกข์ทรมาน -- อ่านโค้ดไร้คุณภาพทั้งหมดที่คุณปล่อยให้เล็ดลอดเข้าสู่ระบบของคุณ

ครั้งแรกที่สิ่งนี้เกิดขึ้นกับเรา ผมสลัดมันทิ้งไป แม้ว่าผมเพิ่งใช้เวลาเกือบสองสัปดาห์ขุดคุ้ยเส้นสปาเก็ตตี้ของ claude "ความเสี่ยงด้านลบนั้นคุ้มค่ากับความเร็ว" พอถึงครั้งที่ ~สามในเดือนพฤศจิกายน เราตัดสินใจว่าการเขียนใหม่ตั้งแต่ต้นคงจะง่ายกว่า และผู้ร่วมก่อตั้งของผมใช้เวลา สองสัปดาห์เต็ม ใน VS Code (ไม่ใช่ cursor ด้วยซ้ำ) เพื่อวางโครงสร้างรูปแบบทั้งหมดด้วยมือ

โมเดลทำให้คุณภาพ codebase ลดลงเมื่อเวลาผ่านไป

สิ่งที่ผมอยากจะพูดถึงคือ: โมเดลมีข้อบกพร่อง พวกมันไม่สามารถรักษาและปรับปรุงคุณภาพ codebase เมื่อเวลาผ่านไปได้ -- ถ้าไม่มีการชี้นำจากมนุษย์ในปริมาณที่พอสมควร4

เมื่อผมพูดถึงความสามารถในการบำรุงรักษา (maintainability) ผมหมายถึงสิ่งเฉพาะที่มันกลายเป็นเรื่องยากมากที่จะเปลี่ยนส่วนหนึ่งของ codebase โดยไม่ทำให้อีกส่วนพัง นี่คือ shotgun surgery ของ Martin Fowler

ผมจะไม่พูดถึงความสามารถในการบำรุงรักษามากไปกว่านี้ มีหนังสือหลายเล่มที่คุณสามารถไปอ่านเกี่ยวกับมันได้

• A Philosophy of Software Design ของ John Ousterhout
• Clean Code ของ Robert C. Martin
• Refactoring ของ Martin Fowler

แล้วทำไมโมเดล ถึงทำ ความสามารถในการบำรุงรักษาซอฟต์แวร์ไม่ได้ล่ะ?

"แต่แน่นอนว่าโมเดลดีขึ้นมากตั้งแต่นั้นมา"

ถึงจุดนี้คุณอาจอยากจะพูดว่า: แต่ Dex แน่นอนว่าโมเดลดีขึ้นมากตั้งแต่เดือนกรกฎาคม

พวกมันดีขึ้น -- ในบางด้าน ในด้านอื่นๆ พวกมันก็เหมือนเดิม

• การแก้ปัญหาที่เกิดขึ้นครั้งเดียว หรือการ vibe-coding เว็บไซต์การตลาดใหม่? ใช่ ดีขึ้นมาก
• การปรับปรุงคุณภาพ codebase เมื่อเวลาผ่านไป? ไม่ได้ดีขึ้นมาก เท่าที่ผมบอกได้

ผมพิสูจน์สิ่งนี้ไม่ได้ คุณก็พิสูจน์ไม่ได้เช่นกัน ไม่มี benchmark ที่ดีสำหรับความสามารถของโมเดลในการรักษาคุณภาพ codebase (เพิ่มเติมเกี่ยวกับว่าสิ่งนั้นกำลังจะไปทางไหนในภายหลัง)

ไม่มี benchmark ที่ดี สำหรับความสามารถของโมเดลในการรักษาคุณภาพ codebase

แต่ถ้าคุณทำงานกับ coding agents มาระยะหนึ่ง -- และมีคนจำนวนมากโพสต์เกี่ยวกับสิ่งนี้พอดี -- คุณคงมีความรู้สึกนั้นอยู่แล้ว: พวกมันมีแนวโน้มที่จะทำให้สิ่งต่างๆ แย่ลงเมื่อเวลาผ่านไป และทำให้ codebase ทำงานได้ยากขึ้น

ดังนั้นเพื่อหาคำตอบ ว่าทำไม สิ่งนี้ถึงเกิดขึ้น ผมอยากจะซูมออกไปยัง coding agent ตัวแรกที่ยอดเยี่ยม

Claude Code ชนะเพราะ Reinforcement Learning ภายใน harness

Claude Code ไปจากศูนย์ถึง ~$4B -- ตอนนี้ประมาณ ~$9B -- ในรายได้ภายในเวลาไม่ถึงปี

ซึ่งค่อนข้างแปลก เพราะมี CLI agents ที่ยอดเยี่ยมอยู่แล้ว aider, cline, codebuff -- ทั้งหมดมาก่อน Claude Code, ทั้งหมดมีวิศวกรรมบริบทที่ยอดเยี่ยมในตัว, ทั้งหมดมีชุดเครื่องมือเดียวกับที่คุณอาจยกให้ claude code: read, write, edit, grep, bash ผมใช้พวกมัน มันดี แต่ในขณะเดียวกัน การใช้เครื่องมือก็... บางครั้งล้มเหลว -- คุณดูมันกระดิกหางกับการแก้ไขเดียวกันสามครั้งแล้วเปิดโปรแกรมแก้ไขของคุณกลับมาเพื่อทำเอง

บทความ SWE-Agent จากปี 2024 อธิบายว่าการเปลี่ยนแปลงเล็กน้อยในรูปร่างของเครื่องมือทำให้เกิดความแตกต่างที่สังเกตได้ เช่น การรวมหมายเลขบรรทัดในผลลัพธ์ ReadFile หรือการเปลี่ยนเครื่องมือ Edit จาก find/replace เป็นการแก้ไขตามช่วงบรรทัด

จากนั้น Claude Code ก็เปิดตัวและพุ่งขึ้นในแนวตั้งอย่างรวดเร็ว คุณสามารถปัดสิ่งนี้ว่าเป็นการกระจาย แต่คำอธิบายที่ยอมรับกันโดยทั่วไปคือ claude code ชนะเพราะมันดีกว่า และมันดีกว่าเพราะ Anthropic ทำ RL กับโมเดล ภายใน harness -- เป็นครั้งแรกที่ห้องปฏิบัติการฝึกโมเดลกับเครื่องมือที่แน่นอนที่พวกเขาจะจัดส่งไปด้วย และมันก็ เก่งมาก ในการเรียกใช้เครื่องมือเหล่านั้นใน loop แบบ agentic

สิ่งหนึ่งคือการปรับแต่งนิยามเครื่องมือและการประเมินผลจนกว่าคุณจะพบรูปร่างที่โมเดลชอบมากที่สุด -- ผมใช้เวลาหลายสัปดาห์ในการทำสิ่งนี้สำหรับกรณีการใช้งานต่างๆ มันเป็นเกมที่แตกต่างออกไปเมื่อคุณเป็นเจ้าของ weights และสามารถ ปรับเปลี่ยนโมเดลเอง ให้ดีขึ้นกับชุดเครื่องมือเฉพาะได้

ทีม OpenAI บรรยายในเดือนพฤศจิกายน ซึ่งกล่าวไว้ค่อนข้างดี: ถ้าคุณสร้าง harness แต่คุณไม่ได้เป็นเจ้าของ weights และไม่สามารถทำ RL กับโมเดลภายในมันได้ คุณจะเสียเปรียบทีมที่เป็นเจ้าของทั้งสองอย่างเสมอ

Coding Agent RL ใน 60 วินาที

ผมค้นคว้าเกี่ยวกับหัวข้อนี้มากมาย และสร้างภาพประกอบมากมายเพื่อพยายามอธิบายส่วนที่สำคัญ แต่ผมพบว่า Calvin French-Owen (MTS ในทีม codex, ผู้ก่อตั้ง Segment) ได้บรรยายที่ AI Council ซึ่งทำได้ดีกว่าและสะอาดกว่ามาก ดังนั้นผมจะวางแอนิเมชั่นนี้ที่ได้รับแรงบันดาลใจจากสไลด์ของเขา:

เพื่อทำให้โมเดลเขียนโค้ดได้ดีขึ้น คุณจะต้อง:

1. สร้าง traces ของ coding agent เพื่อแก้ปัญหา (เช่น แก้ไขการทดสอบของฉัน)
2. ให้คะแนน traces ตามเกณฑ์บางอย่าง (verifier)
3. อัปเดตน้ำหนักโมเดลเพื่อทำให้ traces ที่ดีมีโอกาสมากขึ้น และ traces ที่แย่มีโอกาสน้อยลง

แล้วคุณก็ทำสิ่งนี้หลายล้านครั้งในช่วงหลายสัปดาห์หรือหลายเดือน

ส่วน "การให้คะแนน" ของสิ่งเหล่านี้มักจะมีแนวโน้มที่จะเป็นมิติเดียวอย่างน่าขบขัน

ไม่มีบทลงโทษสำหรับการออกแบบที่ไม่ดี

ยกตัวอย่าง SWE-bench Multilingual งานต่างๆ มีขนาดเล็ก -- ประมาณสิบห้านาทีต่อชิ้น -- ถูกขูดออกจาก repos โอเพนซอร์สเช่น Redis, jq, และ Django รางวัลเป็นหนึ่งหรือศูนย์โดยขึ้นอยู่กับ:

• FAIL_TO_PASS - คุณแก้ไขสิ่งที่คุณถูกขอให้แก้ไขหรือไม่?
• PASS_TO_PASS - คุณทำโดยไม่ทำให้อย่างอื่นพังหรือไม่?

นี่คือตัวอย่างจริง fastlane__fastlane-19304 จาก fastlane -- โปรเจกต์ Ruby action zip ของมันดึงพารามิเตอร์เสริมสองตัวแล้วเรียก .empty? กับพวกมันทันที ดังนั้นทันทีที่คุณละทิ้ง include และ exclude มันก็จะล้ม:

การแก้ไขโดยมนุษย์ที่ปิด issue นี้คือสองบรรทัด (ตั้งค่า nils เริ่มต้นเป็นอาร์เรย์ว่าง):

ในระหว่างการประเมิน โมเดล

1. เริ่มต้นจาก base commit -- repo ที่ checkout ไปยังช่วงเวลาก่อนที่จะมีการแก้ไขนั้น
2. รายงานข้อบกพร่อง - ในกรณีนี้คือ 'zip_command': undefined method 'empty?' for nil:NilClass

agent ทำงานและเขียนโค้ดบางส่วนตาม issue มันไม่เห็น golden patch หรือ test patch ที่ทำหน้าที่เป็นผู้ให้คะแนน:

จากนั้น:

1. เราจะเก็บ patch ใดก็ตามที่มันสร้างไว้ แล้ว
2. ทิ้งการแก้ไขใดๆ ที่มันทำกับไฟล์ทดสอบ (เราจับได้แล้วว่าโมเดลแอบคอมเมนต์การทดสอบที่ล้มเหลว หรือต่อ mock ที่ทำให้การทดสอบไร้ประโยชน์)
3. ใช้ test patch ของ benchmark ด้านบน แล้ว
4. รันชุดทดสอบทั้งหมด: การทดสอบ zip ที่มีอยู่ (PASS_TO_PASS) บวกกับอันใหม่ (FAIL_TO_PASS) เพื่อดูว่าทั้งคู่ผ่านหรือไม่

ข้อสังเกต - Benchmarks ไม่ใช่ verifiers - อันที่จริงแล้วพวกมันต้องถูกแยกออกจากกัน (อย่าฝึกบน test, ฯลฯ) - ผมหมายถึงสิ่งนี้เพื่อสื่อถึงรูปร่างของ "การตัดสินคุณภาพของ trace coding agent" และข้อจำกัดของมัน

วิธีที่โมเดลได้คำตอบที่ถูกต้องนั้นไม่สำคัญ ถ้าการทดสอบผ่าน เราก็ชนะ แต่ ไม่มีบทลงโทษ สำหรับการกัดกร่อนความสามารถในการบำรุงรักษา codebase

ไม่มีบทลงโทษสำหรับการกัดกร่อนความสามารถในการบำรุงรักษา codebase

นั่นคือวิธีที่คุณได้ try catch ครอบคลุมทุกอย่าง:

การตรวจสอบคุณภาพนั้นยากกว่าการ "ตรวจสอบว่าการทดสอบผ่านหรือไม่" เป็นอย่างมาก

การรันการทดสอบจะได้ผลลัพธ์ผ่านหรือไม่ผ่านที่ชัดเจนภายใน ~วินาที นั่นคือสาเหตุที่ RL สามารถรันลูปนับล้านเพื่อปรับแต่งโมเดลแต่ละรุ่นได้

แต่ฟังก์ชันต้นทุนของสถาปัตยกรรมที่ไม่ดีนั้นวัดกันเป็นสัปดาห์ เดือน หรืออาจเป็นปี มันเกิดขึ้นครั้งแรกที่มีคนเปิดไฟล์นั้นเพื่อแก้ไขบรรทัดเดียว และตระหนักว่าพวกเขาไม่สามารถทำได้ในบรรทัดเดียว -- มีคน vibe สิ่งนี้หนักเกินไปหน่อย และตอนนี้เราต้องแก้ไขเดียวกันในสิบเอ็ดแห่ง และหวังว่าจะไม่มีอะไรพังสามไฟล์โดยไม่รู้ตัว

การทดสอบให้ feedback ภายในไม่กี่วินาที แต่ฟังก์ชันต้นทุนของสถาปัตยกรรมที่ไม่ดีนั้นวัดกันเป็นสัปดาห์ เดือน หรืออาจเป็นปี

การออกแบบที่ไม่ดีเป็นสิ่งเดียวที่ benchmarks ในปัจจุบันไม่สามารถประเมินได้ และผมรู้ ผมรู้ RL != Benchmarks แต่ถ้าสิ่งนี้ได้รับการแก้ไขใน RL ผมค่อนข้างแน่ใจว่ามันจะเริ่มปรากฏให้เห็นในวิธีการออกแบบ benchmarks ของเราเช่นกัน

ในกรณีใดๆ ก็ตาม โดยส่วนตัวแล้วผมไม่เชื่อถือการปรับปรุงใดๆ บน benchmarks ในปัจจุบันว่าเป็นตัวบ่งชี้ว่าโมเดลดีขึ้นอย่างกะทันหันในการไม่ทำให้ codebase ของคุณรก

Frontier กำลังดีขึ้น แต่ช้า

แน่นอนว่าคนฉลาดจำนวนมากกำลังทำงานเกี่ยวกับเรื่องนี้ ประเด็นของผมไม่ใช่ว่ามันทำไม่ได้ แต่เป็นว่า hype กำลังวิ่งนำหน้าวินัย

มีความพยายามสองสามอย่างที่ผมคิดว่าชี้ไปในทิศทางที่ถูกต้อง:

• SWE-Marathon (Abundant AI): งานที่ใช้เวลาประมาณ ~400 ชั่วโมงเช่น "โคลน Excel ทั้งหมด, ทุกฟีเจอร์" -- พร้อมช่องทางรางวัลแบบผสมแทนที่จะเป็น bit ผ่าน/ไม่ผ่านเดี่ยว
• DeepSWE (Datacurve): งานใหญ่บน repos OSS ที่ไม่เคยถูกสร้างในโลกจริงมาก่อน ดังนั้นโดยโครงสร้างแล้วพวกมันไม่สามารถอยู่ในชุดฝึกได้อยู่แล้ว (แก้ปัญหาการปนเปื้อน แต่ไม่ใช่คุณภาพ)
• Frontier Code (Cognition): งานหลาย PR, และการเคลื่อนไหวที่ชาญฉลาดที่ประเมินคุณภาพในเชิงกำหนด -- มันลงโทษโมเดลสำหรับการเขียนการทดสอบที่ไม่ล้มเหลวบนโค้ดก่อน patch (ถ้าคุณไม่เคยได้ยินเกี่ยวกับ mutation testing คุณกำลังจะได้พบกับการเดินทางที่สนุก5) มันยัง รันโมเดลผู้พิพากษาเหนือ diff ที่ตรวจสอบกฎคุณภาพโค้ด ด้วย

แต่โมเดลที่ตัดสินคุณภาพนั้นไปได้แค่ระดับหนึ่งเท่านั้น

จริงๆ แล้ว ก็ไม่ยากที่จะจินตนาการว่า ถ้าโมเดลสามารถแยกแยะโค้ดดีและโค้ดแย่ได้อย่างน่าเชื่อถือ มันก็น่าจะเขียนเวอร์ชันที่ดีออกมาได้ตั้งแต่แรก RL ต้องการ oracle ที่รวดเร็วและเชื่อถือได้ แต่เรายังไม่มีสำหรับเรื่องความสามารถในการบำรุงรักษา

ถ้าโมเดลสามารถแยกโค้ดดีและโค้ดแย่ได้อย่างน่าเชื่อถือ มันก็น่าจะเขียนเวอร์ชันที่ดีออกมาได้ตั้งแต่แรก แต่ความสามารถในการบำรุงรักษาไม่มี oracle ที่รวดเร็ว ดังนั้นเราจึงไม่สามารถให้รางวัลกับมันระหว่าง RL ได้

แน่นอนว่า การมี review agents มากขึ้นและ tokens มากขึ้นก็ช่วยได้ — มันยกระดับพื้นฐานขึ้นมา จับข้อผิดพลาดเล็กๆ น้อยๆ ได้

แต่มันไม่ได้ขยับเพดาน เพราะเพดานคือสิ่งที่เราสามารถสอนโมเดลใน RL ได้ และการออกแบบที่ดีคือสิ่งที่เรายังไม่รู้ว่าจะสอนมันได้อย่างไร

ดังนั้นฉันยังไม่กล้าเดิมพันโค้ดเบสของฉันกับสิ่งเหล่านี้ แต่มันเป็น evals ครั้งแรกที่ฉันเห็นว่าพยายามให้คะแนนความสามารถในการบำรุงรักษาแทนที่จะหยุดแค่ผ่าน/ไม่ผ่าน

หมายเหตุ บางทีโมเดลในอนาคตอาจเข้าใจเรื่องนี้และเราก็หยุดได้ ถ้าคุณอยากสุ่ม prompts ไปจนกว่า GPT-7 จะเปิดตัวและดูผลลัพธ์ ก็เชิญตามสบาย — แต่ bitter lesson ช่างหัวมัน เรามีปัญหาที่ต้องแก้ไขตอนนี้ และฉันจะอธิบายว่าเราทำอย่างไร

เปิดไฟกลับมา

วันนี้ฉันได้เรียนรู้ว่า Twitter Articles มี "ข้อจำกัดด้านสื่อ" ซึ่งหมายความว่าส่วนที่เหลือจะอยู่ในโพสต์ตอนที่ 2 — โปรดติดตาม