Loop Engineering.
ผู้เขียนต้นฉบับ: Addy Osmani
แปลโดย: Peggy, BlockBeats

ผู้แก้ไข: วิธีการใช้งาน AI Coding Agent กำลังเปลี่ยนจาก “ผู้ใช้เขียน Prompt ด้วยตนเองและดำเนินงานทีละขั้นตอน” เป็น “ผู้ใช้ออกแบบวงจร เพื่อให้ระบบจัดการ Agent อย่างต่อเนื่อง” Loop Engineering ที่ Addy Osmani พูดถึง มีจุดประสงค์หลักคือการสร้างระบบที่สามารถค้นหางานอัตโนมัติ จัดสรรงาน ตรวจสอบผลลัพธ์ บันทึกความคืบหน้า และตัดสินใจขั้นตอนถัดไป

วงจรนี้ประกอบด้วยโมดูลหลักห้าส่วน: Automations (การค้นหาและคัดกรองงานตามเวลาที่กำหนด)、Worktrees (แยกสภาพแวดล้อมการพัฒนาแบบขนานหลายรายการ)、Skills (สะสมความรู้โครงการและประเพณีทีม)、Plugins/Connectors (เชื่อมต่อกับเครื่องมือจริงเช่น GitHub, Linear, Slack, ฐานข้อมูล)、Sub-agents (แยกผู้ดำเนินการและผู้ตรวจสอบ) พร้อมด้วยชั้นความจำภายนอก เช่น ไฟล์ Markdown หรือบอร์ด Linear ที่ใช้เก็บสถานะและความคืบหน้า

บทความเตือนว่า ความหมายของ Loop Engineering ไม่ใช่แค่ “ให้ AI รันหลายรอบ” แต่คือการนำการตัดสินใจของวิศวกรไปไว้ในขั้นตอนการออกแบบระบบตั้งแต่ต้น วงจรสามารถเพิ่มประสิทธิภาพการทำงานของนักพัฒนาได้อย่างมาก แต่ไม่สามารถแทนที่การตรวจสอบ การเข้าใจ และการตัดสินใจได้ ความเสี่ยงที่แท้จริงไม่ได้อยู่ที่การใช้วงจร แต่อยู่ที่การใช้วงจรเป็นข้ออ้างในการหลีกเลี่ยงการเข้าใจโค้ดและระบบ ทักษะสำคัญในการร่วมมือกับ AI ในการเขียนโปรแกรมในอนาคต อาจไม่ใช่แค่การเขียน Prompt ที่ดี แต่คือการออกแบบกระบวนการทำงานของ Agent ที่เชื่อถือได้ ตรวจสอบได้ และสามารถทำงานอย่างยั่งยืน

以下为原文：

Loop engineering (การหมุนเวียนทางวิศวกรรม) กำลังแทนที่บทบาทของคุณในฐานะ “ผู้เขียนคำสั่งสำหรับตัวแทนปัญญาประดิษฐ์” คุณต้องออกแบบระบบเพื่อให้ระบบดังกล่าวเป็นผู้สั่งงานตัวแทนปัญญาประดิษฐ์แทนคุณ คำว่า loop (การหมุนเวียน) นี้สามารถเข้าใจได้ว่าเป็นเป้าหมายแบบเรียกซ้ำ: คุณกำหนดจุดประสงค์ แล้ว AI จะดำเนินการวนซ้ำจนกว่าภารกิจจะเสร็จสิ้น โดยระบบดังกล่าวประกอบด้วยองค์ประกอบหลักห้าประการ และ Claude Code และ Codex ตอนนี้ได้มีองค์ประกอบทั้งห้าประการนี้แล้ว

ฉันเชื่อว่านี่อาจเป็นวิธีที่เราทำงานร่วมกับตัวแทนการเขียนโค้ดในอนาคต แต่ทั้งหมดนี้ยังอยู่ในระยะเริ่มต้น และฉันยังคงมีข้อสงสัย คุณจำเป็นต้องระมัดระวังอย่างมากเกี่ยวกับต้นทุน token เพราะต้นทุนอาจแตกต่างกันอย่างมากขึ้นอยู่กับรูปแบบการใช้งาน โดยเฉพาะอย่างยิ่งหากคุณเป็น “ผู้มี token มาก” หรือ “ผู้มี token จำกัด” คุณยังต้องมีกลไกบางอย่างเพื่อให้มั่นใจว่าคุณภาพจะไม่ลดลง ความกังวลเกี่ยวกับ “ผลลัพธ์ขยะของ AI” (slop) ก็มีเหตุผลเช่นกัน แต่ถึงอย่างนั้น เรามาดูกันว่าที่จริงแล้วมันคืออะไร

@steipete เพิ่งพูดไว้ว่า: "คุณไม่ควรเขียนพร้อมต์ให้กับตัวแทนการเขียนโค้ดอีกต่อไป คุณควรออกแบบวงจรบางอย่างที่จะเป็นผู้ให้พร้อมต์กับตัวแทนของคุณ" ในทำนองเดียวกัน @bcherny หัวหน้าทีม Claude Code ของ Anthropic ก็กล่าวว่า: "ตอนนี้ฉันไม่ได้ให้พร้อมต์กับ Claude อีกแล้ว ฉันมีวงจรหลายชุดที่ทำงานอยู่ ซึ่งจะเป็นผู้ให้พร้อมต์กับ Claude และตัดสินใจด้วยตัวเองว่าควรทำอะไรต่อไป งานของฉันคือการเขียนวงจรเหล่านั้น"

แล้วนี่หมายความว่าอะไรกันแน่?

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

ตอนนี้คุณกำลังสร้างระบบเล็กๆ ที่สามารถค้นพบงานด้วยตัวเอง จัดสรรงาน ตรวจสอบผลลัพธ์ บันทึกสถานะการเสร็จสิ้น และตัดสินใจว่าจะทำอะไรต่อไป กล่าวอีกนัยหนึ่ง คุณให้ระบบนี้ขับเคลื่อนเอเจนต์แทนที่จะต้องแจ้งคำสั่งให้มันทีละขั้นตอนด้วยตัวคุณเอง ฉันเคยเขียนเกี่ยวกับ “ญาติใกล้ชิด” ของมันมาก่อน — agent harness engineering (วิศวกรรมกรอบการทำงานของเอเจนต์) ซึ่งหมายถึงการสร้างสภาพแวดล้อมสำหรับเอเจนต์เดียว; และ factory model (แบบจำลองโรงงาน) ซึ่งหมายถึงระบบในการสร้างซอฟต์แวร์ ขณะที่ loop engineering อยู่เหนือระดับของ harness ระบบ nàyคล้ายกับ harness แต่จะทำงานตามเวลาที่ตั้งไว้ สร้างผู้ช่วยเล็กๆ และสามารถเลี้ยงตัวเองได้

สิ่งที่ทำให้ฉันประหลาดใจคือ ตอนนี้มันไม่ได้เป็นเพียงปัญหาในระดับ “เครื่องมือ” อีกต่อไป หนึ่งปีก่อน ถ้าคุณต้องการลูป คุณต้องเขียนสคริปต์ bash จำนวนมาก และต้องดูแลรักษาสคริปต์เหล่านั้นตลอดไป มันเป็นสิ่งของคุณเอง และเป็นของคุณเท่านั้น แต่ตอนนี้ คอมโพเนนต์เหล่านี้ถูกฝังไว้ในผลิตภัณฑ์โดยตรง ความสามารถที่ Steinberger ระบุไว้นั้นสามารถจับคู่ได้เกือบตรงกันกับแอป Codex และเกือบจะตรงกันกับ Claude Code เช่นกัน เมื่อคุณตระหนักว่ารูปแบบของพวกมันเหมือนกัน คุณจะไม่ยุ่งกับการเลือกว่าควรใช้เครื่องมือไหนอีกต่อไป แต่จะเริ่มออกแบบลูป: ไม่ว่าคุณจะนั่งอยู่ในเครื่องมือใด มันก็ยังคงทำงานต่อไป

ห้าส่วนประกอบ และคำอธิบายบางประการ

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

ประการแรก، Automations (งานอัตโนมัติ): ถูกกระตุ้นตามกำหนดเวลา และดำเนินการค้นพบและแยกประเภทอัตโนมัติ

ที่สอง Worktrees (งานต้นไม้): ทำให้ตัวแทนที่ทำงานพร้อมกันสองตัวไม่ทับซ้อนไฟล์ของกันและกัน

ثالثly, Skills (ทักษะ): จดบันทึกความรู้เกี่ยวกับโครงการ เพื่อหลีกเลี่ยงการที่ตัวแทนต้องเดาทุกครั้ง

สี่ ปลั๊กอินและตัวเชื่อมต่อ: ให้ตัวแทนสามารถเชื่อมต่อกับเครื่องมือที่คุณกำลังใช้อยู่แล้ว

ห้า ซับ-เอเจนต์ (sub-agents): ตัวหนึ่งรับผิดชอบการเสนอแนวทาง อีกตัวหนึ่งรับผิดชอบการตรวจสอบแนวทาง

จากนั้นคือสิ่งที่หก: memory (ความจำ) มันสามารถเป็นไฟล์ Markdown หรือบอร์ด Linear หรือที่ใดก็ตามที่แยกออกมาจากบทสนทนาครั้งเดียวและสามารถบันทึกสิ่งที่ "เสร็จแล้ว" และ "ขั้นตอนถัดไป" ดูเหมือนเรื่องง่ายๆ ที่ไม่น่าจะสำคัญ แต่นี่คือเทคนิคเดียวกันที่ตัวแทนที่ทำงานระยะยาวทุกตัวพึ่งพา ฉันได้เขียนไว้อย่างละเอียดใน long-running agents: โมเดลจะลืมทุกครั้งระหว่างการรัน ดังนั้นความจำต้องถูกเก็บไว้บนดิสก์ ไม่ใช่ในบริบท ตัวแทนอาจลืม แต่คลังรหัสไม่ลืม

ตอนนี้ ผลิตภัณฑ์ทั้งสองมีส่วนประกอบทั้งห้านี้แล้ว

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

Automations คือสิ่งที่ทำให้ loop กลายเป็น loop ที่แท้จริง ไม่ใช่แค่งานที่คุณรันด้วยมือเพียงครั้งเดียว ในแอป Codex คุณสามารถสร้างงานอัตโนมัติได้ในแท็บ Automations โดยเลือกโปรเจกต์ คำสั่งที่จะรัน ความถี่ในการรัน และว่าจะรันใน local checkout ของคุณหรือใน worktree พื้นหลัง ผลลัพธ์ที่พบปัญหาจะถูกส่งไปยัง Triage inbox ส่วนผลลัพธ์ที่ไม่มีปัญหาจะถูกจัดเก็บอัตโนมัติ ซึ่งเป็นเรื่องที่ดี OpenAI ใช้มันเองเพื่องานที่น่าเบื่อแต่จำเป็น เช่น การแยกปัญหาประจำวัน การสรุปสาเหตุการล้มเหลวของ CI การเขียนรายงาน commit และติดตามบั๊กที่ใครบางคนเพิ่มเข้ามาในสัปดาห์ที่แล้ว งานอัตโนมัติยังสามารถเรียกใช้ skill ได้ ดังนั้นคุณสามารถรักษาความสามารถในการดูแลรักษาของงานที่ต้องรันซ้ำๆ: กระตุ้น $skill-name แทนการวางข้อความคำสั่งยาวๆ ไว้ในงานที่วางแผนไว้แล้วแต่ไม่มีใครอัปเดตอีก

Claude Code ก็สามารถทำให้เกิดผลลัพธ์เดียวกันได้ เพียงแต่ใช้วิธีที่ต่างกัน: มันใช้การจัดตารางและ hooks คุณสามารถใช้ /loop เพื่อรันคำสั่งหรือพรอมต์ที่ระยะเวลากำหนดไว้ หรือตั้งค่า cron job หรือใช้ hooks ที่จุดต่างๆ ในวงจรชีวิตของตัวแทนเพื่อกระตุ้นคำสั่ง shell หากคุณต้องการให้มันทำงานต่อไปหลังจากปิดแล็ปท็อป คุณสามารถนำทั้งชุดนี้ไปใส่ไว้บน GitHub Actions ได้ แนวคิดนั้นเหมือนกันทั้งหมด: คุณกำหนดงานอัตโนมัติ กำหนดจังหวะให้มัน และปล่อยให้ผลลัพธ์มาหาคุณ แทนที่จะต้องไปตรวจสอบเองทุกที่

มีอีกหนึ่งพริมิทีฟภายในเซสชันที่ใกล้เคียงกับหัวใจหลักที่บทความนี้พูดถึง /loop จะทำงานซ้ำตามจังหวะ; /goal จะทำงานต่อเนื่องจนกว่าเงื่อนไขที่คุณระบุจะเป็นจริง หลังจากแต่ละรอบ จะมีโมเดลเล็กตัวแยกต่างหากมาประเมินว่าภารกิจเสร็จสิ้นหรือไม่ ดังนั้นเอเจนต์ที่เขียนโค้ดจึงไม่ใช่ผู้ให้คะแนนตัวเอง คุณสามารถระบุเงื่อนไข เช่น “การทดสอบทั้งหมดใน test/auth ผ่านและ lint สะอาด” แล้วจากไป Codex ก็มีความสามารถเดียวกัน ซึ่งเรียกว่า /goal เช่นกัน มันจะทำงานข้ามรอบจนกว่าเงื่อนไขการหยุดที่สามารถตรวจสอบได้จะเกิดขึ้น และรองรับการหยุดชั่วคราว การฟื้นฟู และการล้าง พริมิทีฟเดียวกันนี้มีอยู่ในเครื่องมือทั้งสองตัว นี่คือรูปแบบที่ปรากฏซ้ำๆ ในบทความนี้

ดังนั้น Automations จึงรับผิดชอบในการทำให้งานปรากฏขึ้น ส่วนส่วนที่เหลือของ loop จะรับผิดชอบในการจัดการงานเหล่านั้น

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

Codex มีการรองรับ worktree แบบฝังตัวไว้แล้ว ดังนั้นหลายเธรดสามารถประมวลผลรีโพสิทอรีเดียวกันพร้อมกันโดยไม่เกิดการชนกัน Claude Code ก็สามารถใช้ git worktree เพื่อให้ได้การแยกกันเช่นเดียวกัน: คุณสามารถใช้ flag --worktree เพื่อเปิดเซสชันใน checkout ที่แยกจากกัน หรือตั้งค่า isolation: worktree บน subagent เพื่อให้ตัวช่วยแต่ละตัวได้รับ checkout ใหม่ทั้งหมด และล้างอัตโนมัติหลังเสร็จสิ้น ผมเคยเขียนเรื่องนี้ในมุมมองของมนุษย์ใน the orchestration tax: worktrees สามารถขจัดความขัดแย้งในระดับกลไกได้ แต่คุณยังคงเป็นขีดจำกัดอยู่ จริงๆ แล้วสิ่งที่กำหนดว่าคุณสามารถรันตัวแทนได้กี่ตัวพร้อมกัน ไม่ใช่เครื่องมือ แต่คือ bandwidth การทบทวนของคุณ

ทักษะคือกลไกที่ช่วยให้คุณไม่ต้องอธิบายบริบทของรายการเดียวกันซ้ำแล้วซ้ำเล่าในแต่ละเซสชันเหมือนปลาทอง สองเครื่องมือใช้รูปแบบเดียวกัน: โฟลเดอร์ที่มีไฟล์ SKILL.md ซึ่งบันทึกคำอธิบายและข้อมูลเมตา; นอกจากนี้ยังสามารถมีสคริปต์ แหล่งอ้างอิง และไฟล์ทรัพยากรเพิ่มเติมได้ Codex จะรันทักษะเมื่อคุณเรียกใช้ด้วย $ หรือ /skills และยังสามารถรันอัตโนมัติเมื่อภารกิจของคุณตรงกับคำอธิบายของทักษะนั้น นี่คือเหตุผลที่คำอธิบายที่กระชับและเรียบง่ายมักจะดีกว่าคำอธิบายที่ฉลาดหรือซับซ้อนเกินไป Claude Code ก็ใช้วิธีเดียวกัน ฉันเคยเขียนรูปแบบนี้ไว้ใน agent skills

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

มีจุดหนึ่งที่ต้องแยกให้ชัด: skill เป็นรูปแบบการเขียนโค้ด ส่วน plugin เป็นวิธีการจัดส่ง เมื่อคุณต้องการแชร์ skill หนึ่งไปยังหลายที่เก็บโค้ด หรือแพ็กเกจ skill หลายตัวเข้าด้วยกัน คุณจะห่อพวกมันให้เป็น plugin เช่นเดียวกับ Codex และ Claude Code

การลูปที่สามารถดูได้เฉพาะระบบไฟล์ เป็นลูปขนาดเล็กมาก Connectors ที่สร้างจาก MCP ช่วยให้ตัวแทนสามารถอ่าน issue tracker ของคุณ สอบถามฐานข้อมูล เรียกใช้ API ของ staging หรือส่งข้อความใน Slack Codex และ Claude Code รองรับ MCP ดังนั้น connector ที่คุณเขียนสำหรับตัวใดตัวหนึ่ง มักจะสามารถใช้งานได้กับอีกตัวหนึ่งด้วย Plugins จะรวม connectors และ skills เข้าด้วยกัน เพื่อให้เพื่อนร่วมทีมของคุณติดตั้งการตั้งค่าทั้งชุดในครั้งเดียว แทนที่จะต้องจำและสร้างใหม่ทั้งหมด

นี่คือความแตกต่างระหว่าง “ตัวแทนอัจฉริยะบอกคุณว่า ‘นี่คือวิธีแก้ไข’” กับ “ลูปเปิด PR เอง ผูกกับ Linear ticket และแจ้งช่องทางเมื่อ CI ผ่าน” Connectors มีความสำคัญเพราะทำให้ลูปสามารถดำเนินการในสภาพแวดล้อมจริงของคุณ ไม่ใช่แค่บอกคุณว่า “ถ้าฉันทำได้ ฉันจะทำ”

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

Codex จะสร้าง subagents เฉพาะเมื่อคุณร้องขอ โดย subagents เหล่านี้จะทำงานแบบขนาน แล้วรวมผลลัพธ์กลับเป็นคำตอบเดียว คุณสามารถกำหนด agent ของตนเองในไฟล์ TOML ที่ .codex/agents/ โดยแต่ละ agent จะมีชื่อ คำอธิบาย คำสั่ง และโมเดลและระดับการให้เหตุผลที่เลือกได้ ดังนั้น ผู้ตรวจสอบความปลอดภัยของคุณสามารถเป็นโมเดลที่มีการให้เหตุผลระดับสูง ในขณะที่ผู้สำรวจของคุณสามารถเป็นโมเดลเบาและอ่านอย่างเดียวที่เร็ว Claude Code ก็มีความสามารถคล้ายกันผ่าน subagents และทีม agent ใน .claude/agents/ ซึ่งทำให้ agent หลายตัวสามารถส่งงานให้กันได้ การแบ่งงานที่พบบ่อยที่สุดบนทั้งสองแพลตฟอร์มคือ: agent หนึ่งสำรวจ, agent หนึ่งดำเนินการ, และ agent หนึ่งตรวจสอบตามข้อกำหนด

ฉันได้อธิบายมุมมองนี้แล้วสองครั้ง: หนึ่งครั้งใน code agent orchestra และอีกครั้งใน adversarial code review มันมีความสำคัญเป็นพิเศษใน loop เพราะ loop จะทำงานขณะที่คุณไม่ได้จับตาดู ดังนั้น verifier (ผู้ตรวจสอบ) ที่คุณไว้วางใจอย่างแท้จริง จึงเป็นเหตุผลเดียวที่คุณจะกล้าจากไป Subagents ใช้ token เพิ่มขึ้นจริงๆ เพราะแต่ละ agent ต้องเรียกใช้โมเดลและเครื่องมือของตนเอง ดังนั้นคุณควรใช้พวกมันในสถานการณ์ที่ “ความเห็นที่สองคุ้มค่ากับการจ่ายเงิน” ซึ่งก็คือสิ่งที่ /goal ของ Claude Code ทำในระดับพื้นฐานนั่นคือ ให้โมเดลใหม่ตัดสินว่า loop จบแล้วหรือยัง แทนที่จะให้โมเดลที่ทำงานเสร็จมาเป็นผู้ตัดสินเอง กล่าวอีกนัยหนึ่ง มันนำหลักการแยก “ผู้สร้าง” และ “ผู้ตรวจสอบ” มาใช้กับเงื่อนไขการหยุดเอง

ลูปมีหน้าตาเป็นอย่างไร

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

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

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

โปรดสังเกตว่าคุณได้ทำอะไรไปจริงๆ คุณแค่ออกแบบครั้งเดียวเท่านั้น ขั้นตอนเหล่านั้นไม่ได้ถูกคุณกระตุ้นทีละขั้นตอนด้วยตัวเอง นี่คือเวอร์ชันจริงของคำพูดของ Steinberger และ loop เดียวกันนี้สามารถทำงานได้ทั้งบน Codex และ Claude Code เพราะชิ้นส่วนที่ใช้นั้นเป็นชิ้นส่วนเดียวกัน

Loop ยังคงไม่ได้ทำอะไรให้คุณ

Loop เปลี่ยนวิธีการทำงาน แต่ไม่ได้ลบคุณออกจากการทำงาน ที่จริงแล้ว เมื่อ loop แข็งแกร่งขึ้น ปัญหาสามข้อจะยิ่งทวีความรุนแรงขึ้น ไม่ใช่กลายเป็นง่ายขึ้น

การตรวจสอบยังคงขึ้นอยู่กับคุณ การรัน loop โดยไม่มีผู้ดูแลอาจกำลังทำผิดพลาดโดยไม่มีใครรู้ คุณแยก verifier sub-agent และ maker ออกกันเพื่อให้คำว่า “เสร็จสิ้น” ของ loop มีความหมายบางอย่าง แม้กระนั้น “เสร็จสิ้น” ก็ยังคงเป็นข้ออ้าง ไม่ใช่หลักฐาน ฉันได้ย้ำคำเดียวกันนี้ใน code review in the age of AI อยู่เสมอ: หน้าที่ของคุณคือส่งมอบโค้ดที่คุณยืนยันแล้วว่าใช้งานได้

ถ้าคุณปล่อยไว้โดยไม่จัดการ ความเข้าใจของคุณเองจะยังคงเน่าเปื่อยไปเรื่อยๆ ยิ่ง Loop ส่งโค้ดที่คุณไม่ได้เขียนด้วยตัวเองให้คุณเร็วเท่าใด ช่องว่างระหว่างสิ่งที่คุณเข้าใจจริงกับสิ่งที่มีอยู่จริงในระบบก็ยิ่งกว้างขึ้นเท่านั้น นี่คือความหนี้ความเข้าใจ (comprehension debt) หากคุณไม่อ่านสิ่งที่ Loop สร้างขึ้น การทำงานของ Loop ที่ลื่นไหลจะทำให้หนี้นี้เพิ่มขึ้นเร็วยิ่งขึ้น

และใช่ ท่าทางที่สบายที่สุดมักจะเป็นท่าทางที่อันตรายที่สุด เมื่อ loop สามารถทำงานเองได้ คุณอาจหยุดการสร้างการตัดสินใจของตัวเอง และแค่ยอมรับสิ่งใดๆ ที่มันส่งกลับมา ฉันเรียกสิ่งนี้ว่า cognitive surrender (การยอมจำนนทางปัญญา) หากคุณออกแบบ loop ด้วยการใช้การตัดสินใจ มันจะเป็นยาแก้; แต่ถ้าคุณออกแบบ loop เพื่อหลีกเลี่ยงการคิด มันจะเป็นตัวเร่งปฏิกิริยา การกระทำเดียวกันนี้สามารถนำไปสู่ผลลัพธ์ที่ตรงข้ามกันอย่างสิ้นเชิง

สร้าง loop แต่ยังคงเป็นวิศวกร

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

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

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

นี่คือเหตุผลที่ loop design ยากกว่า prompt engineering ไม่ใช่ง่ายกว่า ความหมายของ Cherny ไม่ได้หมายถึงงานง่ายขึ้น แต่หมายถึงจุดที่ใช้แรงผลักดันเปลี่ยนไป

สร้าง loop แต่ให้สร้างมันเหมือนคนที่ยังคงตั้งใจจะเป็นวิศวกร ไม่ใช่เหมือนคนที่แค่รับผิดชอบการกดปุ่ม「เริ่มต้น」

[ลิงก์ต้นฉบับ]

คลิกเพื่อเรียนรู้เกี่ยวกับตำแหน่งที่律动BlockBeats กำลังรับสมัคร

ยินดีเข้าร่วมชุมชนอย่างเป็นทางการของ律动 BlockBeats:

กลุ่มสมัครรับข้อมูลบน Telegram: https://t.me/theblockbeats

กลุ่ม Telegram: https://t.me/BlockBeats_App

บัญชี Twitter อย่างเป็นทางการ：https://twitter.com/BlockBeatsAsia