หัวข้อต้นฉบับ: Loop Engineering.
ผู้เขียนต้นฉบับ: Addy Osmani
เรียบเรียง: Peggy, BlockBeats

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

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

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

ต่อไปนี้คือเนื้อหาต้นฉบับ:

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

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

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

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

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

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

ที่ทำให้ผมประหลาดใจคือ ตอนนี้มันไม่ใช่แค่ปัญหา "ระดับเครื่องมือ" อีกต่อไปแล้ว เมื่อปีที่แล้ว ถ้าคุณอยากได้ loop คุณต้องเขียน bash script เป็นชุด แล้วก็ต้องดูแลมันตลอดไป นั่นเป็นของของคุณเอง และเป็นของคุณคนเดียว ตอนนี้ ส่วนประกอบเหล่านี้ถูก built-in ไว้ในผลิตภัณฑ์โดยตรงแล้ว ความสามารถที่ Steinberger ระบุไว้แทบจะจับคู่กับแอป Codex ได้ทีละอย่าง และก็แทบจะจับคู่กับ Claude Code ได้เช่นกัน เมื่อคุณรู้ว่ารูปแบบของมันเหมือนกัน คุณจะไม่กังวลอีกต่อไปว่าจะใช้เครื่องมือไหน แต่จะออกแบบ loop: ไม่ว่าคุณจะนั่งอยู่ในเครื่องมือไหน มันก็จะทำงานต่อไป

ห้าส่วนประกอบ พร้อมคำอธิบาย

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

หนึ่ง Automations (งานอัตโนมัติ): ทำงานตามกำหนดเวลา ค้นหาและจัดสรรงานโดยอัตโนมัติ

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

ประการที่สาม Skills (ทักษะ): จดบันทึกความรู้เกี่ยวกับโปรเจกต์ไว้ เพื่อป้องกันไม่ให้เอเจนต์ต้องเดาทุกครั้ง

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

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

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

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

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

Automations: นี่คือหัวใจของลูป

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

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

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

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

Worktrees: ทำให้การทำงานแบบขนานไม่กลายเป็นความวุ่นวาย

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

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

ทักษะ (Skills): ทำให้คุณไม่ต้องอธิบายโปรเจกต์ซ้ำทุกครั้ง

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

ทักษะยังเป็นที่ที่เจตนา (intent) ไม่ต้องถูกใช้ซ้ำแล้วซ้ำเล่า ผมเคยพูดถึง intent debt ว่าเอเจนต์จะเริ่มต้นแบบเย็น (cold start) ทุกครั้งที่เซสชันเริ่มต้น และตราบใดที่เจตนาของคุณมีช่องว่าง มันจะเติมเต็มช่องว่างนั้นด้วยการเดาที่มั่นใจ ทักษะคือการเขียนเจตนาเหล่านี้ไว้ภายนอก: ข้อตกลงของโปรเจกต์ ขั้นตอนการสร้าง "เราไม่ทำแบบนี้เพราะเคยเกิดเหตุการณ์นั้นมาก่อน" ฯลฯ ทั้งหมดเขียนไว้ในที่เดียวที่เอเจนต์จะอ่านทุกครั้งที่รัน หากไม่มีทักษะ loop จะต้องอนุมานโปรเจกต์ทั้งหมดของคุณจากศูนย์ในทุกๆ รอบ แต่ถ้ามีทักษะ มันจะเหมือนกับการทบต้น (compounding)

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

ปลั๊กอินและคอนเนกเตอร์ (Plugins and Connectors): ให้ loop เข้าถึงเครื่องมือจริงของคุณ

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

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

Sub-agents：แยกผู้สร้างออกจากผู้ตรวจสอบ

ในลูป (loop) การออกแบบโครงสร้างที่มีประโยชน์ที่สุดคือการแยก "ผู้เขียน" และ "ผู้ตรวจสอบ" ออกจากกัน โมเดลที่เขียนโค้ดมักจะใจดีเกินไปเมื่อต้องให้คะแนนงานของตัวเอง เอเจนต์ (agent) อีกตัวที่มีคำสั่งต่างกัน หรือบางครั้งใช้โมเดลต่างกัน จะสามารถจับปัญหาที่เอเจนต์ตัวแรกมองข้ามหลังจากโน้มน้าวตัวเองได้

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

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

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

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

ทุกเช้า ระบบอัตโนมัติ (automation) จะทำงานบน repository โค้ด พรอมต์ (prompt) ของมันจะเรียกใช้ triage skill อ่านความล้มเหลวของ CI เมื่อวานนี้ issues ที่เปิดอยู่ คอมมิต (commits) ล่าสุด และเขียนสิ่งที่พบลงในไฟล์ Markdown หรือบอร์ด Linear สำหรับทุกปัญหาที่ควรจัดการ เธรดจะเปิด worktree ที่แยกออกมา ส่ง sub-agent หนึ่งร่างแนวทางแก้ไข และส่ง sub-agent ที่สองตรวจสอบแนวทางนั้นตาม project skills และการทดสอบที่มีอยู่

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

สังเกตสิ่งที่คุณทำจริงๆ คุณแค่ออกแบบครั้งเดียว ขั้นตอนเหล่านั้นไม่ได้ถูกคุณสั่งทีละบรรทัดด้วยตัวเอง นี่คือเวอร์ชันจริงของคำพูดของ 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 ของตัวเองได้ แต่อย่าลืมว่าการสั่งงาน agent โดยตรงก็ยังมีประสิทธิภาพอยู่ กุญแจสำคัญคือการหาสมดุลที่เหมาะสม

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

นี่คือเหตุผลที่ loop design (การออกแบบลูป) ยากกว่า prompt engineering (วิศวกรรมคำสั่ง) ไม่ใช่เรื่องง่ายกว่า สิ่งที่ Cherny หมายถึงไม่ใช่ว่างานจะเบาลง แต่เป็นจุดศูนย์ถ่วงที่เปลี่ยนไป

สร้าง loop แต่จงสร้างมันในแบบที่ยังคงตั้งใจเป็นวิศวกร ไม่ใช่แค่คนที่กดปุ่ม "เริ่มต้น"

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

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia