การบีบอัดจาก 655 เป็น 14: สิ่งที่เกิดขึ้นจริงเมื่อ AI แทนที่ทีมพัฒนา

TL;DR:เราทำการสร้างระบบองค์กรมาตรฐาน 655 คน-วัน — สองปีครึ่งของผลผลิตมนุษย์ทั่วไป — และส่งมอบใน 14 วันด้วยวิศวกรคนเดียว ไม่ใช่เพราะเราเจอคำสั่งมหัศจรรย์ แต่เพราะเราได้ปฏิบัติต่อ AI เหมือนเป็นแรงงาน ไม่ใช่พ่อมด สูตรคือ:เอกสารสเปค 220 หน้า → การเอกสารย้อนกลับแบบสปรินต์ → การทดสอบการรวมระบบที่เข้มงวดทุก 3 สปรินต์ → สภาหลายโมเดลพร้อมการตรวจสอบที่เป็นปฏิปักษ์.หยุดปฏิบัติต่อ AI เหมือนการเติมข้อความอัตโนมัติ เริ่มปฏิบัติต่อมันเหมือนทีมก่อสร้างที่ต้องการแผนผัง, หัวหน้างาน, และการควบคุมคุณภาพ.

เจมส์ที่นี่, CEO ของ Mercury Technology Solutions.

จากสำนักงานของฉันในหว่านไจ, ฮ่องกง — กรกฎาคม 2026

เมื่อไม่กี่สัปดาห์ที่ผ่านมา, ฉันบอกสถาปนิกหลักของเราให้ทำสิ่งที่ทำให้ฉันถูกหัวเราะในห้องประชุมส่วนใหญ่:นำโครงการที่กำหนดไว้ที่ 655 คน-วันและส่งมอบในสองสัปดาห์.

ไม่ใช่ต้นแบบ ไม่ใช่ MVP แต่เป็นระบบองค์กรเต็มรูปแบบ — โครงสร้างฐานข้อมูล, การโต้ตอบขนาดเล็ก, ชั้นความปลอดภัย, API การรวมระบบ, ทุกอย่าง.

การตอบสนองจากผู้จัดการวิศวกรรมแบบดั้งเดิมนั้นคาดเดาได้"คุณไม่สามารถบีบอัดการพัฒนาซอฟต์แวร์แบบนั้นได้" "คุณภาพจะต้องประสบปัญหา" "ใครบางคนจะต้องทำการปรับโครงสร้างทั้งหมด"

นี่คือสิ่งที่พวกเขาไม่เข้าใจ: ข้อจำกัดไม่เคยอยู่ที่ความเร็วในการพิมพ์ ข้อจำกัดอยู่ที่การตัดสินใจ

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

นี่ไม่ใช่เรื่องราวเกี่ยวกับกลเม็ดการกระตุ้น นี่คือเรื่องราวเกี่ยวกับ วิศวกรรมระบบในยุค AI。

กับดักหยาง เหวิน-ลี่ (หรือ: ทำไมโครงการ AI ส่วนใหญ่จึงล้มเหลว)

แฟน ๆ ของตำนานวีรบุรุษกาแล็กซี่รู้จักประโยคที่มีชื่อเสียงของหยาง: "วิธีที่มีประสิทธิภาพที่สุดในการชนะคือการทำให้ศัตรูสูญเสียความตั้งใจที่จะต่อสู้."

โครงการพัฒนา AI ส่วนใหญ่ตายด้วยวิธีเดียวกัน — ไม่ใช่จากความล้มเหลวทางเทคนิค แต่จาก การสูญเสียความตั้งใจ. ทีมเริ่มต้นได้ดี สร้างโค้ด 10,000 บรรทัดในช่วงสุดสัปดาห์ จากนั้นค้นพบว่า AI ได้เบี่ยงเบน สถาปัตยกรรมไม่สอดคล้องกัน และไม่มีใครสามารถบอกได้ว่าอะไรทำงานได้บ้างกับอะไรที่เป็นภาพหลอน.

พวกเขาสูญเสียความตั้งใจที่จะต่อสู้.

เหตุผลนั้นง่ายมาก: พวกเขาปฏิบัติต่อ AI เหมือนผู้ช่วยเขียนโค้ดแทนที่จะเป็นระบบการผลิต.

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

เราทำในสิ่งที่ตรงกันข้าม เราใช้ วินัยวิศวกรรมระบบ กับแรงงาน AI และผลลัพธ์นั้นไร้สาระ

ขั้นตอนที่ 1: แผนผัง 220 หน้า (สถาปัตยกรรมแบบ Spec-First)

ก่อนที่โค้ดบรรทัดแรกจะถูกสร้างขึ้น สถาปนิกของเราใช้เวลา 1 สัปดาห์ในการเขียน เอกสารข้อกำหนด 220 หน้า.

ไม่ใช่เรื่องราวของผู้ใช้ ไม่ใช่ wireframes เป็น แบบแปลนสถาปัตยกรรมที่สมบูรณ์ครอบคลุม:

• โครงสร้างฐานข้อมูลและความสัมพันธ์ทุกอย่าง

• จุดสิ้นสุด API ทุกจุด รูปแบบคำขอ/การตอบกลับ และกรณีข้อผิดพลาดทุกกรณี

• การโต้ตอบขนาดเล็กและการเปลี่ยนสถานะทุกอย่าง

• ขอบเขตความปลอดภัยและแมทริกซ์การควบคุมการเข้าถึงทุกอย่าง

• ผลลัพธ์ของสปรินต์ทุกอย่างพร้อมเกณฑ์การยอมรับ

ข้อโต้แย้งแบบดั้งเดิม: "แต่นั่นคือการไหลของน้ำ! มันช้า!"

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

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

**สมการ 655 ต่อ 14:** ความเร็วในการดำเนินการของ AI (~50x) × ความชัดเจนของสเปค (~0.95) × การตรวจสอบของมนุษย์ (~0.3) = ~14x การบีบอัดปฏิทิน

มนุษย์ทำหน้าที่เป็น สถาปนิกหลัก. AI เป็นทีมงานก่อสร้าง แผนผังต้องไม่มีที่ติ เพราะทีมงานไม่ตั้งคำถาม — มันแค่สร้างขึ้นมา

ขั้นตอนที่ 2: วงจรการบันทึกย้อนกลับ (บังคับให้รับผิดชอบ)

นี่คือจุดที่โครงการ AI ส่วนใหญ่ผิดพลาด: AI เขียนโค้ด และไม่มีใครตรวจสอบสิ่งที่มันสร้างขึ้นจริงๆ

เราแก้ปัญหานี้ด้วยกระบวนการที่ฉันเรียกว่า เอกสารย้อนกลับ.

หลังจากแต่ละสปรินต์ เราได้ป้อนโค้ดดิบกลับเข้าไปใน LLM แยกต่างหากด้วยคำสั่งเดียว: "เอกสารสิ่งที่โค้ดนี้ทำจริงๆ".

จากนั้นเราก็เปรียบเทียบเอกสารที่ย้อนกลับกับสเปค 220 หน้า ของเรา.

ถ้าตรงกัน? สปรินต์ได้รับการอนุมัติ, ย้ายไปยังถัดไป.

ถ้าต่างกัน? เราจับการหลอกลวง ก่อนที่มันจะซับซ้อนขึ้น. AI เข้าใจผิดในความต้องการ, ใช้ทางลัด, หรือแนะนำตรรกะที่ละเมิดสถาปัตยกรรม เราแก้ไขมันทันที

นี่ไม่ใช่การทดสอบ นี่คือ การตรวจสอบการจัดเรียงที่ความเร็วของเครื่อง. AI เขียน AI เอกสาร มนุษย์เปรียบเทียบ ล้าง, ทำซ้ำ

ใน 14 วัน เราได้ทำซ้ำลูปนี้ประมาณ 40 ครั้ง. ลองทำแบบนั้นกับวิศวกรมนุษย์ดูสิ

ขั้นตอนที่ 3: การกำจัดการเบี่ยงเบนของ AI (การบูรณาการเป็นสิ่งที่ไม่สามารถเจรจาได้)

โหมดการล้มเหลวที่อันตรายที่สุดในพัฒนา AI ไม่ใช่ข้อบกพร่องที่ชัดเจน มันคือ การเบี่ยงเบน.

LLMs สูญเสียบริบทในระหว่างการสนทนายาว พวกเขาลืมข้อจำกัดจากสปรินต์ 2 เมื่อพวกเขากำลังเขียนสปรินต์ 12 ช้าๆ อย่างไม่รู้ตัว สถาปัตยกรรมเสื่อมสภาพ — จนกระทั่งคุณมีการดำเนินการยืนยันตัวตนที่แตกต่างกันหกแบบ รูปแบบการเชื่อมต่อฐานข้อมูลสามแบบ และส่วนหน้าที่คิดว่ากำลังพูดคุยกับ API ที่ไม่มีอยู่แล้ว

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

เราทำการ ทดสอบการรวมและความปลอดภัยอย่างเข้มงวดทุก 3 สปรินต์. ไม่ใช่การตรวจสอบแบบอ่อน การทดสอบทั้งหมด:

• การตรวจสอบสัญญา API

• การตรวจสอบความสมบูรณ์ของฐานข้อมูล

• การทดสอบขอบเขตความปลอดภัย (การตรวจสอบสิทธิ์, การอนุญาต, การฉีด)

• การตรวจสอบการทำงานแบบครบวงจร

หากการทดสอบล้มเหลว เราหยุด เราแก้ไข เราตรวจสอบ จากนั้นเราก็ดำเนินการต่อ

**กฎการป้องกันการเบี่ยงเบน:** ทดสอบก่อนที่การเบี่ยงเบนจะเกิดขึ้น ที่ความเร็วของเครื่องหนี้ทางเทคนิคจะเพิ่มขึ้นอย่างทวีคูณ — ไม่ใช่เชิงเส้น

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

ขั้นตอนที่ 4: สภาหลายโมเดล (การควบคุมคุณภาพแบบขัดแย้ง)

ความผิดพลาดที่ใหญ่ที่สุดในการพัฒนา AI? การใช้โมเดลเดียวสำหรับทุกอย่าง

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

เราใช้ สามโมเดลที่แตกต่างกัน โดยแต่ละโมเดลมีมอบหมายเฉพาะ:

| โมเดล | บทบาท | งาน | |-------|------|------| | โมเดล 1 (โค้ด) | ผู้สร้าง | สร้างโค้ดการดำเนินการจากสเปค | | โมเดล 2 (ทีมแดง) | ผู้ทำลาย | เขียนการทดสอบการรวม/ความปลอดภัยที่ออกแบบมาเพื่อทำลายโค้ดของโมเดล 1 | | โมเดล 3 (Scribe) | ผู้แปล | อ่านโค้ดเบส, สร้างเอกสารที่อ่านได้สำหรับมนุษย์ |

นี่ไม่ใช่แค่การประมวลผลขนาน มันคือ การควบคุมคุณภาพที่เป็นปฏิปักษ์.

งานทั้งหมดของโมเดล 2 คือการหาว่าโมเดล 1 ทำผิดที่ไหน งานของโมเดล 3 คือการนำเสนอความซับซ้อนที่มนุษย์จำเป็นต้องเข้าใจ สถาปนิกมนุษย์เป็นผู้จัดการ, ตัดสิน, และตัดสินใจ.

คิดว่ามันเป็น วงจร OODA ที่ความเร็วของเครื่อง: สังเกต (โมเดล 3), ปรับทิศ (มนุษย์), ตัดสินใจ (มนุษย์), ลงมือ (โมเดล 1) — โดยมีโมเดล 2 ทดสอบความเครียดในวงจรอย่างต่อเนื่อง.

ไม่มีจุดล้มเหลวเพียงจุดเดียว. ไม่มีภาพหลอนของโมเดลใดที่ไม่ได้รับการท้าทาย.สภาตรวจสอบตัวเองเพื่อให้มนุษย์ไม่ต้องจับทุกอย่าง.

รูปแบบ: จากนักพัฒนาไปยังวิศวกรระบบ

นี่คือสิ่งที่ไม่มีใครอยากได้ยิน: ยุคของนักพัฒนาบริสุทธิ์กำลังจะสิ้นสุด.

ไม่ใช่เพราะ AI เขียนโค้ดได้ดีกว่า — แม้ว่าจะเป็นเช่นนั้น. เพราะ AI ทำให้การดำเนินการ ฟรี, และการดำเนินการฟรีเปลี่ยนสิ่งที่มนุษย์ต้องเก่งที่.

เมื่อคอนกรีตมีราคาแพง ช่างก่อสร้างจึงมีค่า เมื่อคอนกรีตกลายเป็นราคาถูก สถาปนิกจึงมีค่า การเปลี่ยนแปลงเดียวกันนี้กำลังเกิดขึ้นในซอฟต์แวร์.

**ลำดับชั้นคุณค่าใหม่:** 1. **การกำหนดปัญหา** (สเปค) 2. **การรวมระบบ** (ทำให้ชิ้นส่วนทำงานร่วมกัน) 3. **การจัดการความเสี่ยง** (จับการเบี่ยงเบน ความปลอดภัย กรณีขอบ) 4. **การดำเนินการ** (โค้ด — ตอนนี้กลายเป็นสินค้าโภคภัณฑ์)

วิศวกรที่ใช้เวลาทั้งวันเขียน CRUD endpoints กำลังถูกทำให้เป็นอัตโนมัติ วิศวกรที่ออกแบบระบบ ดูแลแรงงาน AI และตรวจสอบการรวมระบบกำลังกลายเป็นสิ่งที่ไม่สามารถแทนที่ได้.

หยุดจัดการไวยากรณ์ เริ่มจัดการระบบ.

สิ่งนี้หมายถึงอะไรสำหรับองค์กรของคุณ

หากคุณเป็น CTO, VP ของวิศวกรรม, หรือผู้ก่อตั้งที่คิดเกี่ยวกับการพัฒนา AI นี่คือคู่มือของคุณ:

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

หยุด:ปล่อยให้นักพัฒนาทำโค้ดตามอารมณ์ของพวกเขาผ่านสถาปัตยกรรม.เริ่ม:ต้องการสเปคที่ละเอียดก่อนที่โค้ดที่สร้างโดย AI จะเข้าสู่ repo ของคุณ.

หยุด:การทดสอบที่สิ้นสุดโครงการเริ่ม:การรันการทดสอบการรวมที่เข้มข้นทุก 2-3 สปรินต์ อย่างน้อย

หยุด:การใช้โมเดล AI ตัวเดียวสำหรับทุกอย่างเริ่ม:การสร้างสภาหลายโมเดลพร้อมการตรวจสอบที่เป็นปฏิปักษ์

หยุด:จ้างนักเขียนโค้ดที่พิมพ์เร็วเริ่ม:จ้างวิศวกรระบบที่คิดในด้านสถาปัตยกรรม การรวมระบบ และความเสี่ยง

การบีบอัด 655-to-14 ไม่ใช่เรื่องตลก มันคือ การแสดงตัวอย่างปกติ.

องค์กรที่เชี่ยวชาญในการออกแบบสเปคก่อน โมเดลหลายแบบ และวิศวกรรม AI ที่เป็นศัตรู จะสามารถส่งมอบในไม่กี่สัปดาห์ในสิ่งที่คู่แข่งใช้เวลาหลายปีในการส่งมอบ องค์กรที่ไม่ทำเช่นนั้นจะใช้เวลาในปี 2027 อธิบายให้คณะกรรมการของตนฟังว่าทำไมโครงการ AI ของพวกเขา "ไม่เป็นไปตามที่คาดหวัง"

ข้อสรุป

เราไม่ได้บรรลุการบีบอัด 47 เท่าเพราะเราเป็นอัจฉริยะ แต่เราได้มันมาเพราะเราได้ปฏิบัติต่อ AI เหมือนกับสิ่งที่มันเป็นจริงๆ: แรงงานที่ต้องการการบริหารจัดการ ไม่ใช่ไม้กายสิทธิ์ที่ต้องการคำสั่งที่ดีกว่า.

เอกสารสเปค 220 หน้าคือส่วนที่ยาก ส่วนการย้อนเอกสารคือวินัย ส่วนสภาหลายโมเดลคือระบบความปลอดภัย ส่วนการส่งมอบภายใน 14 วันคือสิ่งที่เกิดขึ้นเมื่อคุณทำระบบให้ถูกต้อง.

อนาคตเป็นของวิศวกรระบบ ไม่ใช่ผู้พิมพ์ไวยากรณ์ คำถามคือคุณจะเป็นหนึ่งในนั้นหรือไม่.

Mercury Technology Solutions: เร่งความเป็นดิจิทัล.