ทำไมโรงงานซอฟต์แวร์ถึงล้มเหลว: วิธีจุดไฟให้กระบวนการพัฒนาอีกครั้ง

นี่เป็นส่วนที่สองของ ทำไม Software Factory ถึงล้มเหลว

เวอร์ชันบรรยายของโพสต์นี้อยู่บน YouTube แล้ว: https://www.youtube.com/watch?v=Ib5GBkD555M

การเปิดไฟกลับมาอีกครั้ง

ใน ส่วนที่ 1 ฉันได้ลงลึกไปว่าทำไมโมเดลถึงไม่น่าเชื่อถือในการรักษาคุณภาพของโค้ดเบสเมื่อเวลาผ่านไป ทำไมการปรับแต่งฮาร์เนสหรือการเพิ่มโทเค็นให้มากที่สุดก็ไม่สามารถแก้ปัญหาเรื่องการฝึกโมเดลและ benchmarks ได้ และทำไม "การใช้โมเดลเป็นผู้ตัดสิน" สำหรับคุณภาพโค้ดถึงไม่ได้ผลดีอย่างที่บางคนอยากให้คุณเชื่อ

สำหรับตอนนี้ ผู้ตัดสินคือคุณ เพราะฉะนั้นเราจะนำการตรวจสอบโค้ดกลับมา

เราจะ embrace สิ่งที่เราทำมาตลอดตั้งแต่ก่อนยุค AI นั่นคือการ วางแผนล่วงหน้าสักเล็กน้อย เพื่อลดโอกาสที่จะต้องตรวจสอบที่ยาวนานและยากลำบาก

เราจะหา leverage และใช้ AI เพื่อช่วยในเรื่องนี้ ผ่าน 4 ระยะ:

• Product Requirements (ข้อกำหนดผลิตภัณฑ์)
• System Architecture (สถาปัตยกรรมระบบ)
• Program Design (การออกแบบโปรแกรม)
• Vertical Slices (ชิ้นงานแนวตั้ง)

Product Review (การตรวจสอบผลิตภัณฑ์)

ทุกอย่างเริ่มต้นด้วย product review: เอกสารสั้น ๆ ที่ระบุ สิ่ง ที่เรากำลังสร้างและ เหตุผล เป้าหมายคือการนำคำสองสามประโยคหรือข้อความเสียงยาว ๆ ที่พูดเรื่อยเปื่อย มาทำให้เป็นโครงสร้างกึ่งทางการ

ขั้นแรก เราตกลงกันเรื่อง ปัญหาที่ต้องแก้ไข -- ความเจ็บปวดที่แท้จริงของผู้ใช้ ในภาษาของผู้ใช้เอง ขั้นที่สอง ความสำเร็จมีหน้าตาเป็นอย่างไร -- เราสามารถอ่านอะไรได้บ้างหลังจากที่ปล่อยฟีเจอร์ เพื่อตัดสินใจว่าสิ่งที่สร้างขึ้นมานั้นคุ้มค่าหรือไม่ โดยอุดมคติแล้ว สิ่งนี้ควรเป็นผลลัพธ์ของผู้ใช้ เช่น "สามารถทำงาน XYZ ได้เร็วขึ้น" หรือ "ถึงเหตุการณ์สำคัญในการเริ่มต้นใช้งาน ABC ได้เร็วขึ้น" บางครั้งก็เป็นเรื่องระดับล่าง เช่น อัตราข้อผิดพลาดหรือค่า latency บางครั้งก็แค่ " tickets สนับสนุนเกี่ยวกับ X หยุดเข้ามา"

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

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

นี่คือตัวอย่างจริงที่กำลังทำอยู่ -- เอกสารระบุฟีเจอร์ด้วยโครงร่าง JSON จากนั้นก็เป็น HTML mockup คร่าว ๆ สองอันของหน้าจอจริง:

https://x.com/dexhorthy/status/2078592010852982977

แน่นอนว่าไม่ใช่ทุกอย่างที่จะต้องมี product review การปรับแก้ข้อความ copy, สคริปต์ครั้งเดียว, บั๊กที่มีวิธีการจำลองชัดเจน -- เรายังคงส่งตรงถึง agent ได้เลย วิธีนี้ใช้สำหรับการเปลี่ยนแปลงที่ agent เข้าใจเจตนาของเราผิดพลาดแล้วมีค่าใช้จ่ายสูง

สำหรับเอกสารนี้และทุกเอกสารในชุดนี้ เราจะทำ author-opt-in reviews ถ้าคุณต้องการประหยัดเวลาในช่วงรีวิว ให้เลือกคนที่จะรีวิว PR และทำ product/tech specs ผ่านกับพวกเขา ไม่ว่าจะแบบ async ผ่านความคิดเห็นในเอกสาร (เราใช้ humanlayer dogfood สำหรับเรื่องนี้ แต่คุณสามารถทำใน GitHub/Notion/Plannotator ฯลฯ ได้เช่นกัน)

System Architecture (สถาปัตยกรรมระบบ)

เมื่อ product review เรียบร้อยแล้ว เราจะทำ system architecture ส่วนนี้ไม่ได้แปลกใหม่เป็นพิเศษ และเป็นสิ่งที่แม้แต่ vibe coders ก็เริ่มสาบานว่าจะใช้

ถ้าต้องการประหยัดเวลาในช่วงรีวิว ให้เลือกคนที่จะรีวิว PR และทำ product/tech specs ผ่านกับพวกเขาก่อนที่จะถึงขั้นตอนการเขียนโค้ด

ในระยะนี้ เราจะตกลงกันว่า services, endpoints, schemas, queues, และ stores จะสื่อสารกันอย่างไร โดยไม่ต้องลงรายละเอียดของ program design เพื่อเพิ่มประสิทธิภาพแบนด์วิธการสื่อสารระหว่างมนุษย์กับ agent เราจะใช้ visualization อย่างหนัก เช่น sequence diagrams:

รูปร่างของ Contract / Endpoint:

Data models และการแปลงข้อมูล:

Mermaid ใช้ได้ในที่นี้ แต่บางครั้งก็อาจมากเกินไป และบางครั้งก็อาจล่อลวงให้คุณรู้สึกว่าคุณเข้าใจตรงกันแล้ว Architecture เป็นเรื่องที่มี leverage สูง และมีแนวโน้มผิดพลาดของโมเดลที่อาจไม่ดีมากมายที่คุณสามารถป้องกันได้ในช่วงนี้ แต่มันยังไม่เพียงพอที่จะสร้างโค้ดคุณภาพสูง สำหรับสิ่งนั้น เราจำเป็นต้องมี program design

Program Design (การออกแบบโปรแกรม)

หลังจากสถาปัตยกรรม เราจะทำสิ่งที่ฉันคิดว่าถูกมองข้ามอย่างมากใน agentic coding: program design

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

แต่สิ่งที่ฉันเห็นว่าได้ผลดีคือ ก่อนที่ใครก็ตาม (มนุษย์หรือ agent) จะเขียนโค้ดจริง เราจะลงไปอีกระดับจากสถาปัตยกรรมสู่ รูปร่างของโค้ด: ชนิดข้อมูล, ลายเซ็นเมธอด, การจัดวางโปรแกรม, และ call stacks

เวอร์ชันแรกของ skill program design ของเราแย่มาก อ่านยาก ทำให้เหนื่อย เราลองใช้ Mermaid ซึ่งมีประโยชน์ในบางที่ แต่สิ่งที่เรา ชอบจริง ๆ คือ visualization แบบเบา ๆ ใน pseudocode:

Call-stack trees สำหรับการเปลี่ยนแปลง orchestration หรือ control-flow ใด ๆ ใช้ diff syntax เมื่อส่วนที่น่าสนใจคือสิ่งที่กำลังเปลี่ยนแปลง:

Dillon Mulroy พูดถึงการใช้ call graphs เป็นส่วนหนึ่งของกระบวนการวางแผนของเขา และฉันคิดว่ามันถูกต้องทีเดียว

File-tree diffs - เพื่อให้คุณติดตาม layout ของโค้ดเบสและตำแหน่งที่อยู่ของสิ่งต่าง ๆ

Types และ method signatures สำหรับฟังก์ชันใหม่ที่สำคัญ -- สิ่งที่อยู่ภายในเกินไปสำหรับเอกสารสถาปัตยกรรม แต่ agent อาจยังทำผิดได้

ไม่มีสิ่งไหนใช้เวลานานในการผลิต (โมเดลร่างให้ คุณโต้แย้งกับมัน) และทุกอย่างคือการตัดสินใจที่คุณจะต้องทำโดยปริยายระหว่างการตรวจสอบโค้ด -- ในช่วงเวลาที่มีค่าใช้จ่ายสูงที่สุดในการเปลี่ยนใจ

Vertical Slices (ชิ้นงานแนวตั้ง)

ต่อไป เราชอบสิ่งที่เรียกว่า "vertical slices" - Matt Pocock และฉันมี

บทสนทนาเกี่ยวกับ vertical slices หรือ "tracer bullets" ใน live stream เมื่อเดือนมกราคม 2026 - สิ่งนี้ยังถูกเรียกว่า - tracer bullets

โมเดลชอบสิ่งที่ฉันเรียกว่า "horizontal plans" - การทำสิ่งต่าง ๆ ตามลำดับชั้น:

1. ฐานข้อมูล Migration
2. Service Layer
3. API
4. Frontend

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

ก่อนยุค AI เป็นเรื่องยากที่ใครจะเขียนโค้ด 2000+ บรรทัด หรือแม้แต่ 500 บรรทัด โดยไม่ตรวจสอบ บางสิ่ง ระหว่างทาง

ฉันใช้เวลาพอสมควรกว่าจะสังเกตเห็นความแตกต่างจากสิ่งที่ฉันคุ้นเคย - เมื่อฉันเขียนโค้ดก่อนยุค AI ฉันจะเริ่มจากตรงกลางแล้วขยายออกไป ประมาณว่า:

1. สร้าง API contract และ serve mock data, ทดสอบด้วย curl
2. สร้าง frontend เพื่อ consume mock data, ปรับแต่ง + ขัดเกลาในเบราว์เซอร์
3. เชื่อมต่อ API กับ services layer (services serve mock data/behavior)
4. เพิ่ม database migrations, เชื่อมต่อ services กับฐานข้อมูล
5. เพิ่ม business logic จำนวนมาก
6. เพิ่ม error handling จำนวนมาก

และฉันจะทดสอบ/ปรับปรุง/ขัดเกลาในแต่ละขั้นตอน

ถ้าฉันใส่ใจโค้ดมาก หรือไม่แน่ใจในความสามารถของโมเดลในการทำงานส่วนนี้ของโค้ดเบส ฉันจะตรวจสอบโค้ดในแต่ละขั้นตอนด้วย การตรวจสอบ 100-200 บรรทัดและปรับทิศทางใหม่นั้นถูกกว่ามาก

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

การวางแผน 30 นาทีช่วยประหยัดเวลาตรวจสอบเป็นชั่วโมง

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

1. การออกแบบผลิตภัณฑ์
2. สถาปัตยกรรมระบบ
3. การออกแบบโปรแกรม
4. ชิ้นงานแนวตั้ง

แน่นอนว่าเราไม่ได้ทำกระบวนการทั้งหมดนี้สำหรับทุกสิ่งที่เราส่ง (ดู sidequest ด้านล่าง) ฉันเดาว่าการกระจายตัวประมาณนี้:

• ~40% ของงานได้ oneshot หรือ oneshot พร้อม feedback เล็กน้อย 1-2 รอบ
• สำหรับงานขนาดกลาง เราทำ product/system design ในเอกสารแผนเดียว และไม่ต้องแยกงานเป็นระยะ
• สำหรับงานขนาดใหญ่ เราทำทุกขั้นตอน เราจะข้ามส่วน product สำหรับสิ่งที่มันไม่สมเหตุสมผล เช่น การ refactor ครั้งใหญ่

และในกรณีส่วนใหญ่ ฉันจะส่งโมเดลไปทำ 1-3 slices ต่อครั้ง และตรวจสอบโค้ดไปเรื่อย ๆ มันง่ายกว่ามากที่จะปรับทิศทางตั้งแต่เนิ่น ๆ ไม่ว่าจะเป็นเรื่องภายในหรือฟังก์ชันการทำงานจริง มากกว่าที่จะจบลงที่อีกด้านของโค้ด 2,000+ บรรทัด โดยไม่รู้ว่าอะไรพัง

คุณคงรู้สึกว่าคุณมี Pull Request มากเกินไป

คุณไม่ได้มี PR มากเกินไป คุณมี PR ที่แย่มากเกินไป

เราทุกคนเคยรีวิว PR มากมายที่ต้องแก้ไขใหม่ ตั้งแต่ก่อนยุค AI

แต่ PR ที่ดีคือความสุขในการรีวิว คุณเลื่อนดูทุกไฟล์ โค้ดสะอาด ปฏิบัติตามการตัดสินใจ/การหารือ/ความคิดเห็นที่ได้มาอย่างยากลำบากทั้งหมดของคุณเกี่ยวกับวิธีการเขียนซอฟต์แวร์

ในทางกลับกัน ถ้า Pull Request ต้องการการแก้ไขใหม่แม้เพียง 20% (และนั่นก็ใจดีแล้ว ฉันว่า PR oneshot ของ AI ส่วนใหญ่มีแนวโน้มที่จะอยู่ที่ 50%) นั่นก็เป็นทั้ง ภาระทางปัญญา และ ภาระทางอารมณ์ สำหรับทั้งผู้ส่ง และ ผู้ตรวจสอบ (แม้ว่าผู้ส่งจะเป็น AI ก็มีคนเริ่มงานนี้หรือปรับแต่งผลลัพธ์ AI หรืออย่างน้อยก็ใส่ใจกับผลลัพธ์)

เพื่อประหยัดเวลาของคุณ (เราใกล้จะจบแล้ว) ฉันพูดถึงเรื่องนี้เพิ่มเติมใน side quest:

"เวลาไปไหน"

ทฤษฎีข้อจำกัด (ฉบับปี 2026)

มันง่ายที่จะรู้สึกหดหู่กับแก่น thesis ตรงนี้: "ตอนนี้เราติดอยู่กับการอ่านโค้ด"

ฉันค่อนข้างตื่นเต้นกับโลกที่เราสามารถขอสิ่งต่าง ๆ และปล่อยให้โมเดลทำงาน และไม่อ่านโค้ด และได้ซอฟต์แวร์ production ที่สวยงามซึ่งพัฒนาไปตามกาลเวลาและไม่แย่ลง

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

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

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

คำแนะนำสรุปของฉันคือ:

1. เรียนรู้ข้อจำกัดให้ดี พัฒนาสัญชาตญาณโดยการทำงานกับโมเดลบ่อย ๆ
2. ปรับระบบให้เหมาะสมภายในขอบเขตของข้อจำกัดเหล่านี้
3. แสวงหา leverage
4. อ่านโค้ดให้จง

แค่นั้น ถ้าคุณอยากอยู่ฟังการขายต่อ ก็เลื่อนลงไปเรื่อย ๆ ฉันหวังว่าสิ่งนี้จะช่วยให้คุณหลีกเลี่ยงหายนะ หรืออย่างน้อยคุณก็สนุกกับการดูแอนิเมชั่นน่ารัก ๆ

ขอบคุณที่อ่าน

-dex

PS เรา obsessed กับเรื่องนี้

เรากำลังสร้าง humanlayer.com ซึ่งเป็น agentic IDE และแพลตฟอร์มการทำงานร่วมกัน เพื่อช่วยให้คุณเคลื่อนที่เร็วขึ้น 2-3 เท่า ในขณะที่ยังคงรักษาคุณภาพโค้ดในระดับมนุษย์ (หรือใกล้เคียงมนุษย์มาก)

เราสร้างเพื่อสองแนวคิด: "building blocks สำหรับ software factory ของคุณ" และ "better verifiers สำหรับการบำรุงรักษาซอฟต์แวร์" (บางทีอาจเป็นโมเดลที่ดีกว่าด้วย)

HumanLayer ฟรีสำหรับทีมเล็กสูงสุด 3 คน และถ้าคุณต้องการความช่วยเหลือในการเริ่มต้น คุณสามารถเข้ามาที่ discord ของเรา หรือส่งอีเมลถึงเราที่ founders@humanlayer.dev

ขอขอบคุณ @calvinfo สำหรับแรงบันดาลใจ, ผู้ร่วมก่อตั้งของฉัน @0xBlacklight, @swyx และทีมงานที่ @aiDotEngineer ที่ให้พื้นที่ฉันได้สำรวจแนวคิดเหล่านี้ และขอบคุณลูกค้า นักลงทุน เพื่อน และครอบครัวที่น่าทึ่งทุกคนที่ให้กำลังใจเรา

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

PPS แหล่งข้อมูลอื่น ๆ

พอดแคสต์และบทความ:

• Dex และ Gergely พูดถึง context engineering และ software factories ใน The Pragmatic Engineer - กรกฎาคม 2026
• Dex และ Matt Pocock พูดถึงคำแนะนำ AI coding ที่เป็นอมตะ (และ ralph loops) - มกราคม 2026

ตอนของ AI That Works:

• Benchmarks พิสูจน์อะไรไม่ได้
• Product Specs สำหรับ AI Coding
• Learning Tests สำหรับ backpressure ที่ดีขึ้น
• การใช้หลักการ 12-factor agents กับ AI coding

ลิงก์จากโพสต์นี้:

• Why Software Factories Fail keynote — AI Engineer World's Fair 2026
• StrongDM's lights-off software factory
• OpenAI: Harness Engineering (ก.พ. 2026)
• Ryan Lopopolo on Symphony (บรรยาย, เม.ย. 2026)
• Mario at AI Engineer Europe: "Building pi in a world of slop"
• FT: Amazon outages จากข้อผิดพลาดของ coding-agent
• Matt Pocock: codebases กำลังพังทลาย
• Faros AI: รายงาน AI acceleration whiplash
• Advanced Context Engineering for Coding Agents (บรรยาย 8/25)
• No Vibes Allowed (บรรยาย 11/25)
• Everything We Got Wrong About RPI (บรรยาย 3/26)
• Awesome-RLVR - แหล่งข้อมูล Reinforcement Learning
• Advanced Context Engineering for Coding Agents (บทความ)
• 12-Factor Agents
• Addy Osmani เกี่ยวกับ vibe-coding vs. การบำรุงรักษา
• NATO Software Engineering Conference, 1968
• DoD DevSecOps Reference Design (PDF)
• แพลตฟอร์ม coding-agent ของ Ramp
• Stripe: Minions, coding agents แบบ one-shot ครบวงจร
• WorkOS: Project Horizon
• Brex (Latent Space)
• Dan Shapiro: ห้าระดับสู่ software factory
• Simon Willison เกี่ยวกับ StrongDM's software factory
• "Boil the ocean"
• Shotgun surgery (refactoring.guru)
• John Ousterhout — A Philosophy of Software Design
• Robert C. Martin — Clean Code
• Martin Fowler — Refactoring
• aider
• cline
• codebuff
• SWE-Agent paper (2024)
• OpenAI Codex talk (พ.ย.)
• Calvin French-Owen — AI Council talk
• SWE-bench Multilingual (dataset)
• AIE Worlds Fair 2026 - The Great Loops Debate (" hype กำลังวิ่งนำวินัย")
• SWE-Marathon (Abundant AI)
• DeepSWE (Datacurve)
• Frontier Code (Cognition)
• Mutation testing (Wikipedia)
• Dillon Mulroy เกี่ยวกับ call graphs ในการวางแผน
• Dex × Matt Pocock: vertical slices / tracer bullets (livestream, ม.ค. 2026)
• "งานหนักของการคิดไม่สามารถ outsource ได้" (Jake Nations)