จ้าง agent 1,393 ตัวมารีแฟคเตอร์โค้ดล้านบรรทัดได้ แต่ถ้าไม่มีของอย่างนึงก่อน ก็แค่ได้ขยะเร็วขึ้น

Nous Research เพิ่ง merge PR ที่ลบโค้ดไปสามแสนกว่าบรรทัด 2,655 ไฟล์ 4,271 commit

ตัวเลขเต็ม ๆ คือ Python ที่ไม่ใช่เทสต์ 1,063,826 บรรทัด เหลือ 698,363 ลดไป 34.4%

gateway/run.py ไฟล์เดียว 34,847 บรรทัด เหลือ 5,512

ฟังก์ชันที่ยาวเกิน 300 บรรทัด มี 192 ตัว เหลือ 2 ตัว

if/elif ที่ยาวที่สุดในโปรเจกต์ 92 สาขา เหลือ 9

ทำโดย agent 1,393 ตัว รันพร้อมกันสูงสุด 218 ตัว ใช้เวลาประมาณ 19 ชั่วโมง ค่า token ประมาณ 19,300 ดอลลาร์

ทุกคนจะเล่าเรื่องนี้ด้วยเลข 1,393 แต่เลขนั้นไม่ใช่เหตุผลที่มันเวิร์ก

ของที่ทำให้มันเวิร์ก มาก่อนหน้านั้นหลายเดือน

teknium ใช้ Hermes ทำงานกับ Hermes ทุกวัน เวลาแก้บั๊กด้วยกันแล้วเขาแก้วิธีที่ agent ทำ agent จะจดไว้เอง ว่าอันนี้ทำแบบนี้ อันนั้นห้ามลัด เช็กแบบไหนถึงเรียกว่าผ่าน

พอกันไปเรื่อย ๆ มันกลายเป็น skill ชื่อ hermes-agent-dev เป็นไฟล์ markdown ธรรมดาที่ agent โหลดไปใช้ได้

ในนั้นมีบรรทัดแบบ

repro on origin/main HEAD in clean env to check whether it's pre-existing

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

ฟังดูพื้นมาก แต่ตอนมี worker 218 ตัวแก้โค้ดพร้อมกัน บรรทัดนี้คือสิ่งที่กันไม่ให้ทุกตัวไล่แก้ปัญหาที่ไม่ได้เกิดจากมัน

คำสั่งที่เขาพิมพ์จริง ๆ สั้นมาก ประมาณว่า "อยากให้ LOC ลดลงเยอะ ๆ อย่างน้อย 30% god file ต้องแตก helper ต้องรวม if ซ้อน ๆ ต้องหาย ทำให้หมด ไม่ต้องรอถาม"

สั่งสั้นแบบนี้ได้เพราะรายละเอียดถูกเขียนไว้ก่อนแล้ว ไม่ใช่เพราะโมเดลเก่งขึ้น

agent 1,393 ตัวที่ไม่มีของพวกนี้ = ได้งานห่วยเร็วขึ้น 1,393 เท่า

อีกอย่างที่คนไม่ค่อยพูดถึง มันรันบนคอมตั้งโต๊ะ

ไม่ใช่คลัสเตอร์ ไม่ใช่ k8s

i7 กับ RAM 64GB ตัวจัดคิวเป็น process เดียว worker แต่ละตัวใช้ git worktree แยก checkout กันไม่ให้เขียนทับกัน แตกลูกได้สามชั้น ตัวบนสุดไม่แตะโค้ดเลย ทำหน้าที่เขียนโจทย์ อ่านรายงาน รวม branch แล้วรันเช็ก

ส่วนโมเดลยิงไปข้างนอกตามปกติ

แล้วมันก็พัง

ไม่ได้ราบรื่น

ผ่านไปห้าสิบนาที token ของ provider หมดอายุ รันล่มทั้งกระบิ ที่รอดมาได้เพราะ worker commit ไว้ทุกขั้น เลยเปิด session ใหม่มาไล่ดูว่าเกิดอะไรขึ้น เขียนสรุปส่งต่อ แล้วให้ตัวที่รันใหม่ไปเก็บของที่ค้างไว้ต่อ

ตอนรีวิว คนในคอมมูนิตี้จับได้ว่า agent ลบชื่อ public function ที่ไม่มีใครในโปรเจกต์เรียก แต่ปลั๊กอินข้างนอกเรียกอยู่

แล้วก็มีการแก้ suppress() อัตโนมัติ ที่ไปเปลี่ยนพฤติกรรมการจัดการ error ประมาณ 65 จุด

ทั้งสองอันนี้เทสต์ไม่จับ คนจับ รีวิวสองรอบก่อน merge แล้วหลัง merge ยังมีแก้ตามอีก

ตรงนี้แหละที่น่าอ่านกว่าเลข 1,393

ของที่เอาไปใช้ได้จริง

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

สอง ให้ worker commit ทุกขั้นที่ verify แล้ว อันนี้คือสิ่งเดียวที่ทำให้ตอนรันล่มไม่เสียของ

สาม ล็อกสิ่งที่ห้ามเปลี่ยนไว้เป็นข้อ ๆ ก่อนเริ่ม ของเขาคือ JSON schema ของ tool ต้องเหมือนเดิมเป๊ะ output ของ --help ต้องเทียบทีละ byte ได้ ไม่ใช่บอกว่า "อย่าทำพัง"

สี่ เทสต์ผ่านไม่ได้แปลว่าไม่พัง ของที่หลุดมาสองอันคือของที่เทสต์ไม่ได้ครอบ

ก่อนจะอิจฉา ลองวัด repo ตัวเองก่อน

เทคนิคนี้มีค่าเพราะโค้ดมันล้านบรรทัดและมีไฟล์เกินห้าพันบรรทัดอยู่ 37 ไฟล์

ลองรันดูว่าของตัวเองเท่าไหร่

find . -name "*.py" | grep -v node_modules | xargs wc -l | tail -1

ของผมเองที่ใหญ่สุดอยู่แสนต้น ๆ ซึ่งแปลว่าไม่ต้องใช้ 1,393 ตัว session เดียวก็จบ

repo ส่วนใหญ่ที่คนอ่านโพสต์นี้มีอยู่ ก็น่าจะเหมือนกัน

เรื่องนี้ไม่ได้อ่านไว้ทำตาม อ่านไว้รู้ว่าถ้าวันนึงของมันใหญ่ถึงจุดนั้น อะไรคือของที่ต้องมีก่อน

แล้วของที่ต้องมีก่อน มันเริ่มสะสมได้ตั้งแต่วันนี้