สิ่งที่ผมได้เรียนรู้จากการสร้าง AI Dev Harness

ผมใช้เวลาหลายเดือนในการสร้างระบบ harness ที่ไม่ขึ้นกับโมเดลใดโมเดลหนึ่งโดยเฉพาะ เพื่อทำงานซอฟต์แวร์จริงกับ coding agents สุดท้ายแล้ว ฟีเจอร์ต่างๆ กลับมีความสำคัญน้อยกว่าที่ผมคิดไว้มาก สิ่งที่สำคัญจริงๆ กลับเป็นแนวคิดไม่กี่อย่างที่เปลี่ยนวิธีคิดของผมเกี่ยวกับการสร้าง ร่วมกับ agents แทนที่จะแค่ป้อนคำสั่ง (prompting) พวกมัน

นี่คือแนวคิดที่ทรงพลังที่สุด สามข้อแรกเปลี่ยนกรอบความคิด (mental model) ของผมไปเลย ที่เหลือเป็นเรื่องเชิงปฏิบัติที่คุณสามารถนำไปใช้ได้แทบจะทันที

1. กำหนดเกณฑ์การยอมรับ (Acceptance Criteria) ให้ตายตัว ก่อนที่ agent จะเริ่มทำงาน

และเก็บไว้ในที่ที่มันแก้ไขไม่ได้

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

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

นั่นไม่ใช่ปัญหาของการป้อนคำสั่ง (prompting) แต่มันเป็นปัญหาเชิงโครงสร้าง ดังนั้นวิธีแก้ก็ต้องเป็นเชิงโครงสร้างด้วย

เขียนเกณฑ์การยอมรับก่อน เก็บไว้ภายนอกพื้นที่ทำงานที่แก้ไขได้ (editable workspace) และปิดกั้นความพยายามใดๆ ที่จะแก้ไขมันโดยอัตโนมัติ ตอนนี้ agent กำลังทำงานตามสัญญาที่มันไม่สามารถเจรจาต่อรองได้อีกต่อไป งานจะเสร็จก็ต่อเมื่อมันเป็นไปตามสัญญาฉบับเดิม ไม่ใช่เพราะ agent บอกว่าเสร็จ

2. ไม่มีใครควรเป็นคนตรวจงานของตัวเอง

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

ดังนั้น จงแยกหน้าที่กัน

ให้สคริปต์ที่กำหนดตายตัว (deterministic scripts) ตรวจสอบทุกอย่างที่เป็นกลไก สคริปต์ไม่สามารถสร้างรหัสสำเร็จ (exit code) ปลอมขึ้นมาได้ ให้ปฏิบัติต่อโมเดลเขียนโค้ดในฐานะวิศวกร ไม่ใช่ในฐานะผู้ตรวจสอบ จากนั้นส่งผลลัพธ์ให้ ผู้ตรวจสอบที่มีบริบทใหม่ (fresh-context reviewer) ซึ่งไม่เคยเห็นกระบวนการเขียนโค้ดมาก่อน เป็นคนตัดสินการออกแบบ เจตนา และคุณภาพโดยรวม

การแยกหน้าที่ง่ายๆ นี้สามารถตรวจจับปัญหาได้มากกว่าที่ผมคิดไว้มาก และที่น่าแปลกคือมันทำได้ถูกและง่ายด้วย

3. การบังคับใช้เป็นเรื่องง่าย การปรับเทียบ (Calibration) ต่างหากที่ยาก

ความเข้าใจนี้เปลี่ยนวิธีคิดของผมที่มีต่อระบบ harness ทั้งหมด

ระบบ agent ส่วนใหญ่ รวมถึงเวอร์ชันก่อนหน้าของผมด้วย จะปฏิบัติต่องานทุกประเภทเหมือนๆ กัน การแก้ไขพิมพ์ผิดบรรทัดเดียวก็ต้องผ่านกระบวนการเดียวกับการออกแบบสถาปัตยกรรมครั้งใหญ่ ซึ่งอาจจะเสียเวลาเปล่าหรือไม่ก็เสี่ยงเกินไป

กุญแจสำคัญคือความพยายามที่ได้สัดส่วนกัน

ขั้นแรก จำแนกประเภทงาน มันเป็นการเปลี่ยนแปลงเล็กน้อยที่ไม่มีอะไรต้องพึ่งพา หรือเป็นโครงสร้างพื้นฐาน (core infrastructure) ที่ทุกอย่างต้องพึ่งพา? มันเป็นตรรกะทางธุรกิจ (business logic) หรือโค้ดอเนกประสงค์ (generic utility code)?

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

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

ชั้นเชิงปฏิบัติ (The Practical Layer)

เมื่อแนวคิดใหญ่ๆ เหล่านั้นเข้าที่แล้ว แนวปฏิบัติเล็กๆ ไม่กี่อย่างก็ให้ผลลัพธ์ทันที

• ใส่กฎของคุณไว้ใน harness ไม่ใช่ใน prompt. Prompt ที่บอกว่า "อย่าแก้ไขใน repo หลัก" เป็นแค่คำแนะนำ กฎเดียวกันนี้ถ้าบังคับใช้โดยการปิดกั้นการเรียกใช้เครื่องมือ (tool call) จะกลายเป็นสิ่งที่มองข้ามไม่ได้ กฎสำคัญไม่ควรพึ่งพาการตัดสินใจของโมเดลว่าจะทำตามหรือไม่
• เก็บสถานะ (state) ไว้นอกบทสนทนา และใช้ worker ใหม่สำหรับทุกงาน เก็บบันทึกงานไว้ภายนอก ใช้ worktrees แบบแยกส่วน และประมวลผลการเปลี่ยนแปลงผ่าน merge queue เมื่อสถานะอยู่ภายนอกแชท ข้อจำกัดด้านบริบท (context limits) ก็จะไม่ใช่ข้อจำกัดที่ใหญ่ที่สุดของคุณอีกต่อไป งานต่างๆ จะทำแบบขนาน (parallel), เรียกกลับมาทำต่อได้ (resumable), และเข้าใจได้ง่ายขึ้นมาก
• การตรวจสอบข้ามผู้ให้บริการ (Cross-provider review) ดีกว่าการตรวจสอบภายในผู้ให้บริการเดียวกัน โมเดลอาจจะผ่อนปรนกับงานของตัวเองมากกว่างานของคนอื่น การใช้โมเดลจากผู้ให้บริการต่างกัน เป็นวิธีที่ง่ายและได้ผลในการลดอคตินั้น

ทำไมหลักการเหล่านี้ถึงใช้ได้ผล

ไม่มีแนวคิดใดในนี้ที่ต้องพึ่งพาโมเดลใดโมเดลหนึ่งโดยเฉพาะ พวกมันเกี่ยวกับวิศวกรรมของ harness (harness engineering) ตั้งแต่โปรโตคอล การตรวจสอบ ท่อส่งงานตรวจสอบ (review pipelines) และการแยกหน้าที่

โมเดลที่อยู่บนสุดของมาตรวัด (benchmarks) จะเปลี่ยนแปลงไปเรื่อยๆ

แต่หลักการเหล่านี้น่าจะไม่เปลี่ยนแปลง

คุณค่าที่ยั่งยืนไม่ได้อยู่ที่โมเดล และไม่ได้อยู่ที่ฟีเจอร์ แต่อยู่ที่โครงสร้างรองรับ (scaffolding) ที่คุณสร้างขึ้นรอบๆ สิ่งเหล่านั้น