กลไกความซับซ้อนของ AI Agent: ทำไมการครอบคลุมของ Test Coverage ถึง 90% จึงเป็นสิ่งจำเป็น

ฉันเขียนโค้ดกับ AI มาทั้งปี ไม่ใช่แค่การสั่งงาน -- แต่สร้างซอฟต์แวร์จริงๆ โปรเจกต์โอเพนซอร์สสองตัว: GStack ที่ทำให้ AI coding agents ดีขึ้น และ GBrain ที่เปลี่ยนทุกสิ่งที่คุณอ่านและเขียนให้เป็นฐานความรู้ที่ค้นหาได้ซึ่ง AI ของคุณสามารถใช้ได้ รวมกันแล้วประมาณ 970,000 บรรทัดโค้ดและไฟล์ทดสอบ 665 ไฟล์ ส่วนใหญ่เขียนโดย Claude Code และ Codex ตามคำสั่งของฉัน (ส่วนใหญ่ใช้ 15 เซสชัน Conductor พร้อมกัน)

สัปดาห์ที่แล้วฉัน รวม pull requests สิบสี่ตัวใน 72 ชั่วโมง โค้ดใหม่เกือบ 29,000 บรรทัด แต่ละรีลีสมีการทดสอบที่ดีกว่าตัวก่อนหน้า

นั่นควรจะเป็นไปไม่ได้ ความเร็วและคุณภาพควรจะต้องแลกกัน ส่งเร็ว ทำพัง เคลื่อนช้า ส่งถูกต้อง เลือกอย่างใดอย่างหนึ่ง

คุณไม่ต้องเลือกอีกแล้ว กุญแจสำคัญคือการครอบคลุมการทดสอบ 90% -- และ AI agents ทำให้การไปถึงจุดนั้นเป็นเรื่องฟรี เป็นเวลาห้าสิบปี การตรวจสอบในระดับนั้นต้องใช้กำลังใจของมนุษย์มากเกินไปที่จะรักษาไว้ ตอนนี้ agent เขียนการทดสอบควบคู่ไปกับโค้ด ผลลัพธ์คือสิ่งที่ฉันเรียกว่ากลไกเฟืองท้ายความซับซ้อน (complexity ratchet): ระบบที่สามารถดีขึ้นเท่านั้น ไม่เคยแย่ลง

(นี่คือตอนที่เจ็ดในซีรีส์เกี่ยวกับการสร้างด้วย AI: 1 2 3 4 5 6

ซอฟต์แวร์เคยเปราะบาง

เป็นเวลาห้าสิบปี วินัยทั้งหมดของวิศวกรรมซอฟต์แวร์ถูกจัดระเบียบรอบแนวคิดเดียว: ป้องกันข้อผิดพลาด เพราะข้อผิดพลาดเป็นหายนะ

คุณต้องทำให้โค้ดถูกต้องตั้งแต่ครั้งแรก พลาด edge case เดียวก็พังในโปรดักชัน ส่ง database migration ที่ไม่ดีก็สูญเสียข้อมูลลูกค้า เขียนฟังก์ชันที่ทำอะไรบางอย่างที่ซับซ้อน และเมื่อคนเดียวที่เข้าใจมันลาออก ก็ไม่มีใครรู้ว่าทำไมมันถึงทำงาน ทั้งระบบขึ้นอยู่กับมนุษย์ที่ต้องระมัดระวัง และมนุษย์ไม่ได้ระมัดระวัง ดังนั้นเราจึงสร้างกระบวนการที่ซับซ้อน -- การตรวจสอบโค้ด, สภาพแวดล้อม staging, ทีม QA, รถไฟรีลีส -- ทั้งหมดออกแบบมาเพื่อจับข้อผิดพลาดก่อนที่จะถึงผู้ใช้

มันใช้ได้ในระดับหนึ่ง แต่มันช้า และมันหมายความว่าความซับซ้อนของระบบซอฟต์แวร์ใดๆ มีเพดานที่แข็ง: จำนวนสิ่งที่ทีมเดียวสามารถเก็บไว้ในหัวพร้อมกันได้

ตอนนี้ซอฟต์แวร์ยืดหยุ่นได้

ฉันไม่ได้หมายถึงเลอะเทอะ ฉันหมายถึงมีความยืดหยุ่นในแบบที่ไม่เคยเป็นไปได้มาก่อน

เมื่อฉันพูดว่า "โมเดลมาถึงแล้ว" ฉันหมายถึง AI coding agents -- Claude, GPT, Codex และระบบนิเวศที่เติบโตรอบๆ พวกมัน -- ตอนนี้สามารถอ่านโค้ด เข้าใจบริบท วินิจฉัยข้อผิดพลาด และเขียนแก้ไขได้ ไม่สมบูรณ์แบบ แต่ดีพอที่โมเดลข้อผิดพลาดสำหรับซอฟต์แวร์เปลี่ยนไป

การ migration พัง? Agent อ่านข้อความแสดงข้อผิดพลาด เข้าใจประวัติ schema ของฐานข้อมูลตลอด 45 เวอร์ชัน เขียนการแก้ไข เขียนการทดสอบ การซิงค์ไฟล์ค้างที่ symlinks จำนวนล้าน? Agent วินิจฉัย parser timeout จำกัดไว้ที่ 30 วินาที ส่งการแก้ไขพร้อมการทดสอบ pipeline การแยกข้อมูลมีบั๊กเรื่องการระบุแหล่งที่มา? การประเมินข้ามโมเดลจับมันได้ prompt ถูกปรับปรุง การบังคับใช้ถูกเพิ่มที่เลเยอร์ฐานข้อมูล

สำหรับข้อผิดพลาดระดับโค้ดส่วนใหญ่ -- บั๊กทางตรรกะ, ความล้มเหลวในการแยกวิเคราะห์, edge cases ที่พัง -- agents สามารถวินิจฉัยและแก้ไขได้ในเทิร์นถัดไป นั่นเป็นสิ่งใหม่จริงๆ ข้อผิดพลาดที่ยังคงเป็นหายนะคือข้อผิดพลาดที่ทำลายสถานะ: การ migration ที่ไม่ดีบนข้อมูลโปรดักชัน, ช่องโหว่ด้านความปลอดภัยที่ถูกใช้ประโยชน์ก่อนการตรวจจับ, การรั่วไหลของความเป็นส่วนตัวที่ไม่สามารถยกเลิกได้ กลไกเฟืองท้ายช่วยได้ที่นี่เช่นกัน (การทดสอบที่ดีจับสิ่งเหล่านี้ได้ส่วนใหญ่ก่อนโปรดักชัน) แต่การเปลี่ยนแปลงที่แท้จริงคือข้อผิดพลาดส่วนใหญ่ใน codebase เป็นประเภทที่แก้ไขได้

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

กลไกเฟืองท้ายความซับซ้อนของ Agent

กลไกเฟืองท้าย (ratchet) คือกลไกที่ยอมให้เคลื่อนที่ไปในทิศทางเดียวเท่านั้น ประแจกระบอกหมุนโบลต์ไปข้างหน้าและป้องกันไม่ให้หมุนกลับ นั่นคืออุปมาอุปไมย

ในซอฟต์แวร์ที่เขียนโค้ดโดย agent ทุกเซสชันการเขียนโค้ดกับ AI agent จะเพิ่มสามสิ่งให้กับ codebase:

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

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

พื้นคุณภาพสูงขึ้นทุกเทิร์น การเคลื่อนที่ไปข้างหน้าเท่านั้น นั่นคือกลไกเฟืองท้าย

สิ่งนี้มีลักษณะอย่างไรในทางปฏิบัติ

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

หนึ่งในคุณสมบัติของมันคือการแยกข้อมูลทางญาณวิทยา (epistemological extraction): มันอ่านผ่านหน้าหลายพันหน้าและแยกว่าใครเชื่ออะไร ด้วยความมั่นใจเท่าไหร่ เมื่อเวลาผ่านไป "แกรี่คิดว่า Bitcoin จะถึง $300K (ความมั่นใจ: 0.45)" "จาเร็ดคิดว่าสตาร์ทอัพนี้มีการรักษาลูกค้าที่แข็งแกร่ง (ความมั่นใจ: 0.80)" ประมาณนั้น แต่ครอบคลุม 28,000 หน้า

การรันการแยกข้อมูลครั้งแรกดึงข้อมูล 100,720 ข้อความอ้างสิทธิ์ ฉันใช้การประเมินข้ามโมเดลเพื่อให้คะแนนคุณภาพ -- ให้ GPT-5.5 และ Claude ให้คะแนนผลลัพธ์อย่างอิสระ โดยรวม: 6.8 จาก 10

ปัญหาที่ใหญ่ที่สุด? สิ่งที่ฉันเรียกว่าความสับสนของผู้ถือ (holder confusion) ยกตัวอย่างข้อความอ้างสิทธิ์ "AI จะแทนที่วิศวกรซอฟต์แวร์ 80% ภายในปี 2027" ใครเป็นผู้ถือความเชื่อนั้น? เป็นคนที่เขียนมัน? เป็นคนที่พวกเขาอ้างถึง? หรือเป็นเครื่องมือวิเคราะห์ของระบบ ซึ่งอนุมานมาจากพอดแคสต์ทรานสคริปต์? เวอร์ชัน 1 แยกแยะความแตกต่างนี้ผิด 35% ของเวลา นั่นสำคัญ -- ถ้าคุณกำลังสร้างระบบที่ติดตามสิ่งที่ผู้คนเชื่อ คุณต้องรู้ว่าใครเป็นผู้เชื่อ

ดังนั้นผลการประเมินจึงถูกบันทึกไว้ รูปแบบความล้มเหลวเฉพาะหกรูปแบบถูกระบุ prompt เวอร์ชัน 2 จัดการทั้งหกรูปแบบ การปัดเศษน้ำหนัก (คะแนนความมั่นใจ) ถูกบังคับใช้ที่เลเยอร์ฐานข้อมูล -- ไม่มีความแม่นยำเท็จอีกต่อไปเช่น 0.74 เมื่อ 0.75 คือคำตอบที่ซื่อสัตย์ การทดสอบสิบเจ็ดตัวล็อกสัญญาไว้

ตอนนี้ไม่มีเวอร์ชันในอนาคตของการแยกข้อมูลใดที่สามารถส่งได้หากไม่ผ่านการทดสอบสิบเจ็ดตัวนั้น ไม่มีใครต้องจำว่าทำไมการปัดเศษน้ำหนักถึงสำคัญหรือความสับสนของผู้持有人คืออะไร การทดสอบจำได้

พื้นคุณภาพสูงขึ้นอย่างถาวร นั่นคือหนึ่งเทิร์นของกลไกเฟืองท้าย

ทำไมโปรเจกต์ vibecoded ส่วนใหญ่ถึงตาย

"Vibecoding" คือคำของ Andrej Karpathy สำหรับการเขียนโค้ดกับ AI โดยการอธิบายสิ่งที่คุณต้องการในภาษาธรรมชาติและปล่อยให้โมเดลสร้างโค้ด มันทรงพลังและเป็นวิธีที่ฉันสร้าง แต่จากสิ่งที่ฉันเห็นในใบสมัคร YC และ repos โอเพนซอร์ส โปรเจกต์ vibecoded ส่วนใหญ่ที่ข้ามการทดสอบเริ่มพังเมื่อถึงความซับซ้อนปานกลาง -- สองสามพันบรรทัด, ฟีเจอร์ที่โต้ตอบกันสองสามตัว

พวกเขาข้ามกลไกเฟืองท้าย ไม่มีการทดสอบ ไม่มีเอกสาร ไม่มีการประเมิน Agent เพิ่มความซับซ้อน แต่ไม่มีอะไรป้องกันการถดถอย ทุกฟีเจอร์ใหม่มีโอกาสทำลายฟีเจอร์เก่า และหากไม่มีการทดสอบ คุณจะไม่รู้จนกว่าผู้ใช้จะรายงาน เมื่อถึงเวอร์ชัน 0.5 codebase ก็กลายเป็นบ้านผีสิงที่ทุกการเปลี่ยนแปลงทำลายบางสิ่งที่ไม่คาดคิด จากนั้นนักพัฒนาก็เขียนบล็อกโพสต์เกี่ยวกับว่า AI coding ไม่ทำงาน

AI coding ทำงานได้ดี พวกเขาแค่ไม่ได้สร้างกลไกเฟืองท้าย

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

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

การทดสอบเป็นความจำของสถาบัน

ในบริษัทซอฟต์แวร์แบบดั้งเดิม ความจำของสถาบันอยู่ในมนุษย์ วิศวกรอาวุโสที่รู้ว่าทำไมเลเยอร์แคชถึงมีอยู่ สถาปนิกที่จำการ migration ที่เกือบทำลายฐานข้อมูล หัวหน้าทีมเทคนิคที่สามารถอธิบาย edge case แปลกๆ ในระบบการเรียกเก็บเงิน

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

context window ของ agent ไม่ลาออก มันไม่ถูกแย่งตัว มันไม่ลืม เมื่อชุดทดสอบเข้ารหัสว่า "การปัดเศษน้ำหนักต้องใช้ส่วนเพิ่ม 0.05" และเอกสารประกอบอธิบายว่า "เพราะการประเมินข้ามโมเดลแสดงให้เห็นว่าความแม่นยำเท็จลดความไว้วางใจในคะแนนความมั่นใจ" ความรู้นั้นคงทน agent ใดๆ โมเดลใดๆ เวลาใดๆ ก็สามารถโหลด context นั้นและเข้าใจข้อจำกัดได้

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

ทุกสิ่งที่สามารถควบคุมได้คือสิ่งที่ทดสอบได้

กลไกเฟืองท้ายไม่เพียงทำงานสำหรับโค้ดแบบดั้งเดิม มันทำงานสำหรับทุกสิ่งที่คอมพิวเตอร์สามารถสังเกตได้

คิดถึงเลเยอร์ของระบบสมัยใหม่ OS ให้ process trees, สถานะระบบไฟล์, network sockets, ตาราง cron เทอร์มินัลให้ทุกการกดแป้นพิมพ์ ทุกบรรทัดของผลลัพธ์ ทุก prompt แบบโต้ตอบ เบราว์เซอร์ให้หน้าเว็บที่เรนเดอร์ สถานะปุ่ม เหตุการณ์การนำทาง API ให้การตอบสนองที่มีโครงสร้างที่คุณสามารถแยกวิเคราะห์และตรวจสอบได้ และ AI agents ให้พฤติกรรมที่สังเกตได้ -- สิ่งที่พวกเขาพูด เครื่องมือที่พวกเขาเรียกใช้ ลำดับที่พวกเขาทำสิ่งต่างๆ ไม่ว่าพวกเขาจะถามก่อนลงมือทำ

ทั้งหมดนี้ควบคุมได้ และถ้าคุณควบคุมได้ คุณก็สังเกตได้ ถ้าคุณสังเกตได้ คุณก็ยืนยันได้ ถ้าคุณยืนยันได้ คุณก็ใช้กลไกเฟืองท้ายได้

นี่คือพื้นที่ผิวที่ใหญ่กว่าการทดสอบหน่วยแบบดั้งเดิมมาก ให้ฉันแสดงให้คุณดู

GStack คือเฟรมเวิร์ก coding agent โอเพนซอร์สของฉัน -- 93,000 ดาว GitHub, โค้ด 701,000 บรรทัด, 46 ทักษะ หนึ่งในคุณสมบัติหลักของมันคือการตรวจสอบแผนแบบโต้ตอบ (interactive plan review): คุณขอให้มันตรวจสอบสถาปัตยกรรมของคุณ และมันจะเดินผ่านแผนทีละส่วน ถามคำถาม ตรวจสอบ edge cases ท้าทายสมมติฐานของคุณ เหมือนมีผู้จัดการวิศวกรรมที่อ่านโค้ดจริงๆ

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

คุณจะทดสอบสิ่งนั้นได้อย่างไร? คุณไม่สามารถทดสอบหน่วยว่า "AI มีบทสนทนาหรือไม่" ไม่มีเฟรมเวิร์กการทดสอบแบบดั้งเดิมใดครอบคลุมสิ่งนี้

ดังนั้นฉันจึงใช้ฟังก์ชัน TTY ของ Bun เพื่อ สร้าง test harness (PR #1354) ที่ spawn Claude Code ภายใน pseudo-terminal ป้อนสถานการณ์ repo ที่เฉพาะเจาะจง เรียกใช้ทักษะการตรวจสอบ และดูผลลัพธ์เทอร์มินัลแบบเรียลไทม์ การทดสอบสังเกตว่า agent ยิงคำถามแบบโต้ตอบก่อนที่จะเสร็จหรือไม่ ถ้ามันทิ้งข้อค้นพบและออกโดยไม่ถามอะไร การทดสอบล้มเหลว

นั่นไม่ใช่การทดสอบโค้ด นั่นคือการทดสอบว่า AI agent ปฏิบัติตามสัญญาพฤติกรรมหรือไม่ ที่ระดับ TTY โดยการดูมันทำงานจริงๆ

การตอบสนองของกลไกเฟืองท้ายมีสามเลเยอร์:

ประตู STOP ในคำแนะนำทักษะ -- กฎที่ชัดเจนที่บอกว่า "คุณต้องถามผู้ใช้ก่อนดำเนินการต่อในส่วนถัดไป" พร้อมข้อต่อต้านการใช้เหตุผลที่ระบุรูปแบบความล้มเหลวเฉพาะเพื่อให้โมเดลไม่สามารถพูดโน้มน้าวตัวเองให้ข้ามได้
ข้อต่อต้านทางลัด -- "ไฟล์แผนคือ OUTPUT ของการตรวจสอบแบบโต้ตอบ ไม่ใช่สิ่งทดแทน" หนึ่งประโยคที่ปิดช่องโหว่ที่แน่นอนที่โมเดลใช้ประโยชน์ซ้ำแล้วซ้ำเล่า
การทดสอบพื้นระดับประตู -- การทดสอบ TTY harness ที่ spawn Claude Code ในสถานการณ์ที่ควบคุมและล้มเหลวถ้า agent ไม่ถามคำถามแบบโต้ตอบอย่างน้อยหนึ่งคำถาม

ตอนนี้เมื่อ Anthropic ส่งเวอร์ชันโมเดลใหม่ หรือเมื่อฉันเปลี่ยน prompt ทักษะ ชุดทดสอบจะจับการถดถอยใดๆ ในสัญญาแบบโต้ตอบ Agent ไม่สามารถหยุดถามคำถามอย่างเงียบๆ ได้ การทดสอบดูเทอร์มินัลและตรวจสอบ

หรือดู PR #880 ซึ่งส่งปลั๊กอิน OpenClaw ใหม่ การทดสอบไม่เพียงตรวจสอบว่าโค้ดคอมไพล์ มันสร้างปลั๊กอินจากซอร์สโค้ด spawn อินสแตนซ์ OpenClaw จริงในโปรไฟล์ที่แยก ติดตั้งปลั๊กอินผ่าน CLI รัน plugins inspect เพื่อตรวจสอบว่า runtime โหลดมัน ตั้งค่าช่อง config ตรวจสอบ config และรัน plugins doctor เพื่อยืนยันว่าไม่มี diagnostics การเดินทางครบวงจรแบบ end-to-end ข้ามสองโปรแกรมแยกกัน โค้ดทดสอบ 359 บรรทัด การทดสอบประเภทที่มนุษย์แทบจะไม่เคยเขียนด้วยมือเพราะการตั้งค่าลำบากเกินไป Claude เขียนมันในเวลาประมาณห้านาที นั่นคือกำแพงความพยายามที่หายไปในแบบเรียลไทม์

หลักการนี้ใช้ทั่วไป คุณสามารถทดสอบที่ระดับ OS: การ migration สร้างตารางที่ถูกต้องหรือไม่ cron job ทำงานหรือไม่ process ยังมีชีวิตอยู่หรือไม่ ที่ระดับเบราว์เซอร์: หน้าเว็บเรนเดอร์หรือไม่ agent กรอกแบบฟอร์มถูกต้องหรือไม่ ที่ระดับ API: โมเดลส่งคืน JSON ที่ถูกต้องด้วย schema ที่ถูกต้องหรือไม่ ที่ระดับพฤติกรรม: agent ปฏิบัติตามโปรโตคอลหรือไม่ มันถามก่อนลบหรือไม่ มันหยุดเมื่อถูกบอกให้หยุดหรือไม่

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

ตัวเลข 90%

แล้วการครอบคลุมการทดสอบ 90% ซื้ออะไรให้คุณจริงๆ?

Capers Jones ศึกษาโปรเจกต์ซอฟต์แวร์กว่า 10,000 โปรเจกต์และวัดประสิทธิภาพการกำจัดข้อบกพร่อง (DRE) -- เปอร์เซ็นต์ของบั๊กที่ถูกจับก่อนถึงผู้ใช้ ข้อมูลของเขาจาก Applied Software Measurement แสดงเส้นโค้งที่ไม่เป็นเชิงเส้น: ต่ำกว่า 70% การครอบคลุม DRE อยู่ที่ประมาณ 65-75% ที่ 85-95% การครอบคลุม DRE กระโดดไปที่ 92-97% ความสัมพันธ์ไม่เป็นเชิงเส้น มีจุดศอกในเส้นโค้งประมาณ 85% ที่ข้อบกพร่องที่หลุดรอดลดลงอย่างรวดเร็ว

อุตสาหกรรมอากาศยานค้นพบสิ่งนี้เมื่อหลายสิบปีก่อน DO-178C มาตรฐาน FAA สำหรับซอฟต์แวร์ที่สำคัญต่อการบิน กำหนดให้มีการครอบคลุมการตัดสินใจ/เงื่อนไขที่แก้ไข (MC/DC) สำหรับระบบระดับ A -- ระบบที่บั๊กหมายถึงเครื่องบินตก การครอบคลุมสาขาเพียงอย่างเดียวพลาดข้อบกพร่อง 10-20% MC/DC ซึ่งเข้มงวดกว่าการครอบคลุมบรรทัด บรรลุ DRE >99% พวกเขาไม่ได้บังคับใช้เพราะข้าราชการชอบเอกสาร พวกเขาบังคับใช้เพราะข้อมูลแสดงให้เห็นว่าต่ำกว่าเกณฑ์การครอบคลุมที่แน่นอน ข้อบกพร่องร้ายแรงหลุดรอดในอัตราที่เข้ากันไม่ได้กับการไม่ทำให้คนตาย

ความคล้ายคลึงกับวิศวกรรมความน่าเชื่อถือนั้นชัดเจน โรงงานใช้ระบบที่เรียกว่า Six Sigma เพื่อวัดคุณภาพ แนวคิด: นับจำนวนข้อบกพร่องที่คุณได้รับต่อล้านหน่วยที่ผลิต จากนั้นแสดงเป็น "ระดับซิกม่า" -- ซิกม่าที่สูงขึ้นหมายถึงข้อบกพร่องน้อยลง กระบวนการ 3-ซิกม่าผลิตข้อบกพร่องประมาณ 67,000 ต่อล้าน (ค่อนข้างแย่) กระบวนการ 4-ซิกม่าผลิตประมาณ 6,200 (ดีกว่าสิบเท่า) กระบวนการ 5-ซิกม่าผลิต 233 (ดีขึ้นอีก 27 เท่า) การกระโดดจาก 4 เป็น 5 ซิกม่าไม่ใช่การปรับปรุงทีละน้อย มันคือการเปลี่ยนเฟส

การครอบคลุมการทดสอบเป็นไปตามเส้นโค้งเดียวกัน การไปจาก 70% เป็น 90% การครอบคลุมไม่ใช่ดีขึ้น 30% มันคือข้อบกพร่องที่หลุดรอดน้อยลงหนึ่งลำดับความสำคัญ ข้อบกพร่องที่หลุดรอดที่ 70% ซ่อนอยู่ใน 30% ของโค้ดที่ไม่ได้ทดสอบ ที่ 90% ที่ซ่อนลดลงเหลือ 10% และเส้นทางอันตรายส่วนใหญ่ถูกล็อก

ตอนนี้ ฉันควรจะซื่อสัตย์เกี่ยวกับสิ่งที่งานวิจัยยังแสดงด้วย Mockus, Nagappan, และ Dinh-Trong ศึกษา Windows Vista และพบว่าในขณะที่การครอบคลุมสัมพันธ์กับข้อบกพร่องหลังรีลีสที่น้อยลง ความพยายามในการไปถึง 90%+ เพิ่มขึ้นอย่างรวดเร็ว 20% สุดท้ายของการครอบคลุมใช้ความพยายามมากกว่า 70% แรกอย่างไม่สมส่วน สิ่งนี้เป็นจริงมานานหลายทศวรรษ มันเป็นสาเหตุที่ทีมส่วนใหญ่หยุดที่ 70-80% และบอกว่าดีพอแล้ว

แต่มีบางอย่างเปลี่ยนไป: AI coding agents ไม่รู้สึกถึงความพยายาม

พวกเขาไม่เบื่อที่จะเขียนการทดสอบ edge case ที่สิบสี่ พวกเขาไม่ตัดมุมตอน 5 โมงเย็นวันศุกร์ พวกเขาไม่ดูการทดสอบบูรณาการที่ยุ่งยากและคิดว่า "ฉันจะกลับมาทำทีหลัง" เส้นโค้งความพยายามที่หยุดทีมมนุษย์ที่ 70% ไม่ใช้กับ agents คุณสามารถขอให้ Claude เขียนการทดสอบสำหรับทุก edge case ในโมดูล และมันจะทำอย่างร่าเริง ละเอียดถี่ถ้วน ตอนตีสอง โดยไม่บ่น 20% สุดท้ายที่โหดร้ายซึ่งทำให้การครอบคลุม 90% ไม่สามารถทำได้สำหรับทีมมนุษย์ คือประเภทของงานที่ AI agents ถนัดที่สุด

นี่คือกุญแจสำคัญที่แท้จริง ไม่ใช่แค่ AI ให้คุณเขียนโค้ดเร็วขึ้น หลายคนสังเกตเห็นแล้ว มันคือ AI ให้คุณ ตรวจสอบ ในระดับที่ก่อนหน้านี้แพงเกินไปที่จะรักษาไว้ เกณฑ์ 90% ที่ข้อมูลบอกว่ามหัศจรรย์? มันเคยใช้กำลังใจของมนุษย์มากเกินไปที่จะไปถึง ตอนนี้มันฟรี

นั่นคือความแตกต่างที่สำคัญ กลไกเฟืองท้ายไม่เกี่ยวกับการครอบคลุมบรรทัดเป็นเมตริกความไร้สาระ มันเกี่ยวกับการทดสอบที่เข้ารหัสสัญญาพฤติกรรม -- การทดสอบความสับสนของผู้ถือ การทดสอบการปัดเศษน้ำหนัก ประตูการตรวจสอบแบบโต้ตอบ แต่ละการทดสอบล็อกบทเรียนเฉพาะที่เรียนรู้ การครอบคลุมคือตัวแทนที่บอกคุณว่าพฤติกรรมของระบบอยู่ภายใต้สัญญามากแค่ไหน ที่ 90% เกือบทุกการเปลี่ยนแปลงพฤติกรรมจะกระตุ้นสัญญาณการทดสอบ Agent ผ่าน (ปลอดภัยที่จะส่ง) หรือทำการทดสอบพัง (ถูกจับทันที)

10% ที่เหลือคือจุดบูรณาการ ท่อประปาโครงสร้างพื้นฐาน และ edge cases ที่ทดสอบยากจริงๆ ไม่เป็นไร 90% คือสิ่งที่เปลี่ยนความโกลาหลให้เป็นกลไกเฟืองท้าย

การไปถึง 90% เคยเป็นความพยายามที่กล้าหาญ ตอนนี้มันเป็นวันอังคาร นั่นคือการเปลี่ยนแปลงของเกม

การพิสูจน์แนวคิด

ฉันเริ่มทั้งสองโปรเจกต์คนเดียว พวกมันไม่ใช่คนเดียวอีกต่อไป

GStack ตอนนี้มีผู้มีส่วนร่วม 37 คน v1.30 รวม PR จากชุมชน 21 ตัวในรีลีสเดียว GBrain มีผู้มีส่วนร่วม 25 คน v0.31.1.1 ส่งการแก้ไขจากชุมชน 22 รายการใน PR เดียว -- การไหลของการตรวจสอบสิทธิ์ การบูตสแตรป schema การซิงค์ ความเป็นส่วนตัว

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

รีลีส GBrain สัปดาห์ที่แล้วบอกเล่าเรื่องราว:

v0.31.0: ตารางข้อเท็จจริงใหม่สำหรับความจำแบบเรียลไทม์ บวกกับเฟสการรวมความฝันที่เลื่อนความจำระยะสั้นเป็นความรู้ระยะยาว
v0.31.1: แก้ไขคำสั่ง CLI 25 คำสั่งที่กำลังส่งไปยังฐานข้อมูลท้องถิ่นที่ว่างเปล่าอย่างเงียบๆ แทนที่จะเป็นสมองจริงของผู้ใช้
v0.31.1.1: การแก้ไขที่รายงานโดยชุมชนยี่สิบสองรายการใน PR เดียว
v0.31.2: แก้ไขการซิงค์โค้ดที่ค้างตลอดไปใน repos ขนาดใหญ่ที่มี symlinks โดยเพิ่ม timeout 30 วินาที

แต่ละรีลีสส่งมาพร้อมกับการทดสอบมากกว่าตัวก่อนหน้า Agent เขียนการทดสอบควบคู่ไปกับโค้ด การครอบคลุมไม่ลดลงเพราะความพยายามในการรักษามันไม่ใช่ภาระของมนุษย์อีกต่อไป

เพดานความซับซ้อนใหม่

เพดานความซับซ้อนสำหรับซอฟต์แวร์เพิ่งสูงขึ้นมาก

มันเคยถูกจำกัดด้วยความสามารถของทีมเดียวในการเก็บระบบไว้ในหัว ตอนนี้มันถูกจำกัดด้วยคนคนเดียวบวกกับ agents ที่สามารถโหลด codebase ทั้งหมด ประวัติ schema ชุดทดสอบ และเอกสารประกอบเข้าสู่ context

นั่นคือจำนวนที่ใหญ่กว่ามาก และมันยังคงเติบโตเมื่อ context windows ใหญ่ขึ้นและโมเดลดีขึ้นในการใช้เหตุผลเกี่ยวกับโค้ด

ทุกบริษัทซอฟต์แวร์ที่ไม่นำโมเดลนี้มาใช้ -- agents บวกรสนิยมบวกชุดทดสอบที่เพิ่มขึ้นเท่านั้น -- กำลังส่งช้ากว่าและมีคุณภาพน้อยกว่าคนคนเดียวที่มีเครื่องมือเหล่านี้

เครื่องมืออยู่ที่นี่ โค้ดเปิดอยู่ การทดสอบคือกลไกเฟืองท้าย การครอบคลุม 90% ทุก PR ไม่มีข้อยกเว้น

เป็นเวลาห้าสิบปี การครอบคลุม 90% เป็นสิ่งฟุ่มเฟือยที่สงวนไว้สำหรับอากาศยานและอุปกรณ์ทางการแพทย์ -- ทีมที่มีงบประมาณที่จะทุ่มชั่วโมงมนุษย์ไปที่กำแพงความพยายาม AI agents ทำลายกำแพงนั้น เกณฑ์การครอบคลุมที่ทำให้ซอฟต์แวร์เชื่อถือได้ไม่แพงอีกต่อไป มันเป็นแค่การตั้งค่า คำถามไม่ใช่คุณสามารถจ่าย 90% ได้หรือไม่ มันคือคุณสามารถจ่ายที่จะไม่ทำได้หรือไม่

กลไกเฟืองท้าย ทักษะ และระบบความรู้ทั้งหมดเป็นโอเพนซอร์สและฟรีบน GitHub ไปสร้างกัน

โปรเจกต์โอเพนซอร์สที่ได้รับอนุญาต MIT ของฉัน: