จากการใช้ Prompting Agents สู่การทำ Loop Engineering

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

ด้านล่างนี้คุณสามารถอ่านความคิดบางส่วนของฉัน (เขียนด้วยความช่วยเหลือของ Claude) จากการทดลอง งานวิจัย และบทสนทนาที่ฉันมีกับ นักเรียน ของเรา, ผู้ก่อตั้งบริษัทเทคนิค, วิศวกร AI, และสตาร์ทอัพ

คุณอาจพบว่าเซสชันสดล่าสุดของเราเรื่อง "Autonomous Long-Running Coding Agents" เป็นจุดเริ่มต้นที่ดีสำหรับทั้งหมดนี้*

ที่มาของข้อกล่าวอ้าง

"คุณไม่ควรพรอมต์เอเจนต์เขียนโค้ดอีกต่อไป คุณควรออกแบบลูปที่พรอมต์เอเจนต์ของคุณ"Peter Steinberger (

@steipete ), 7 มิ.ย. 2026. 2.2 ล้านวิว

ทวีตต้นฉบับ

Boris Cherny ผู้สร้าง Claude Code ก็พูดในมุมเดียวกันจากอีกด้าน

"ผมไม่พรอมต์ Claude อีกต่อไปแล้ว ผมมีลูปที่กำลังทำงานอยู่ พวกมันต่างหากที่พรอมต์ Claude และหาว่าต้องทำอะไร หน้าที่ของผมคือเขียนลูป"Boris Cherny (

@bcherny ).

ทวีตต้นฉบับ

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

ลูปจริงๆ แล้วคืออะไร

ลูปคือโปรแกรมเล็กๆ ที่คุณเขียนขึ้นมา ซึ่งทำสี่สิ่ง:

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

คุณหยุดนั่งพิมพ์พรอมต์ภายในลูป คุณเขียนลูป และโมเดลกลายเป็นซับรูทีนที่ลูปเรียกใช้

รูปร่างจะเหมือนเดิมเสมอ: ตั้งเป้าหมาย ลงมือทำ ตรวจสอบ ป้อนข้อผิดพลาดกลับไป แล้วทำซ้ำจนกว่าการตรวจสอบจะผ่าน หรือลูปหยุดตัวเอง

"ลูป" หมายถึงอย่างน้อยห้าสิ่ง

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

• ReAct (2022). รูปแบบการวิจัยดั้งเดิม: คิดเหตุผล ลงมือ สังเกต ทำซ้ำ
• AutoGPT (2023). ลูปเป้าหมายที่พรอมต์ตัวเอง อื้อฉาวว่าไม่รู้ว่าจะหยุดเมื่อไหร่
• ralph loop. การรีเซ็ตบริบทอย่างจงใจระหว่างการวนซ้ำ เพื่อให้เอเจนต์ไม่จมอยู่กับประวัติของตัวเอง
• /loop และ /goal. จังหวะและเงื่อนไขการเสร็จสิ้นถูกสร้างไว้ในเอเจนต์ โดยส่งต่อสถานะข้ามรอบ
• orchestration. ผู้เขียนคนเดียวกระจายงานไปยังเอเจนต์หลายตัวที่อ่าน GitHub, Slack และแชทของคุณ และตัดสินใจว่าจะสร้างอะไรต่อไป

ส่วนประกอบที่คุณต้องต่อเข้าด้วยกันจริงๆ

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

• ตัวกระตุ้น (Trigger). สิ่งที่เริ่มต้นลูปโดยที่คุณไม่ต้องกดเริ่ม: ตารางเวลา, webhook, การเปลี่ยนแปลงไฟล์, ป้ายที่ติดบน PR นี่คือสิ่งที่แยกลูปจริงๆ ออกจากการรันครั้งเดียวที่คุณทำซ้ำด้วยมือ
• การแยก (Isolation). การเช็คเอาท์ส่วนตัวต่อเอเจนต์หนึ่งตัว โดยปกติคือ git worktree เพื่อให้เอเจนต์สองตัวที่ทำงานพร้อมกันไม่สามารถเขียนทับไฟล์ของกันและกันได้ เมื่อคุณรันมากกว่าหนึ่งตัว สิ่งนี้จะไม่เป็นทางเลือกอีกต่อไป
• บริบทที่เขียนไว้ (Written-down context). ข้อตกลง ขั้นตอน build และกฎเฉพาะโปรเจกต์จะถูกเก็บไว้ในที่ที่เอเจนต์อ่านได้ทุกครั้งที่รัน ข้ามขั้นตอนนี้ไป ลูปจะต้องตีความโปรเจกต์ของคุณใหม่ตั้งแต่ต้นในแต่ละรอบ และเดาช่องว่างที่ขาดหายไป
• การเชื่อมต่อกับเครื่องมือของคุณ (Reach into your tools). ตัวเชื่อมต่อไปยังระบบติดตามปัญหา, CI, ฐานข้อมูล และแชท เพื่อให้ลูปสามารถเปิด PR, เชื่อมโยง ticket และโพสต์ผลลัพธ์ แทนที่จะพิมพ์วิธีแก้ไขและรอให้คุณนำไปทำต่อ
• เอเจนต์ตัวที่สองตรวจสอบ (A second agent checks). ผู้ทำงานแยกต่างหากที่ให้คะแนนผลลัพธ์ จะถูกแยกออกจากผู้ที่สร้างมันขึ้นมา เพราะโมเดลที่ตรวจสอบงานของตัวเองมักจะผ่านเกือบทุกอย่าง
• สถานะบนดิสก์ (State on disk). ไฟล์ Markdown, กระดาน หรือคิว: อะไรก็ตามที่อยู่นอกบทสนทนาที่บันทึกว่าอะไรเสร็จแล้วและอะไรต้องทำต่อไป โมเดลลืมระหว่างรอบ; ไฟล์ไม่ลืม

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

ลูปที่เป็นรูปธรรม: PR babysitter

ตัวอย่างที่เป็นรูปธรรมที่คุณสามารถสร้างได้วันนี้:

• ตัวกระตุ้น. ทุก 15 นาที
• ขอบเขต. PR ที่เปิดอยู่ซึ่งติดป้าย agent-watch
• การดำเนินการ. ถ้า CI เป็นสีแดงด้วยเหตุผลที่กำหนดได้ ให้พยายามแก้ไขหนึ่งครั้ง ถ้า main branch ขยับ ให้ rebase หนึ่งครั้ง
• งบประมาณ. พยายามแก้ไขหนึ่งครั้งต่อ PR, ห้านาที, เปลี่ยนแปลงสิบไฟล์
• เงื่อนไขหยุด. CI เป็นสีเขียว หรืองบประมาณหมด จากนั้นหยุดและแจ้งมนุษย์

คุณจะกลับมาพบ PR ที่ถูกรวม แทนที่จะเป็นงานค้างของ build ที่พัง รูปแบบเดียวกันนี้ครอบคลุมงาน ops ส่วนใหญ่:

• สุขภาพ CI. ทุก 30 นาที ดึงการรันที่ล้มเหลวและจัดกลุ่มตามลายเซ็น เพื่อให้ PR สีแดงสิบตัวที่มีสาเหตุเดียวกันกลายเป็นสิ่งเดียวที่ต้องดู
• การตรวจสอบการ deploy. หลังจาก push ให้เรียกไปยัง endpoints ของคุณ ยืนยันว่าได้ 200 และเนื้อหาที่คาดหวัง และแจ้ง flag การถดถอยก่อนที่ผู้ใช้จะเจอ
• การจัดกลุ่มข้อเสนอแนะ. ทุก 30 นาที ดึงความคิดเห็นจากช่องทางของคุณ จัดกลุ่มเป็นหัวข้อ และแมปแต่ละกลุ่มไปยังไฟล์หรือเอกสารที่เป็นเจ้าของ

ลูป Claude Code ที่เป็นรูปธรรมด้วย /goal

PR babysitter คือลูปที่คุณต่อด้วยตัวเอง; การได้เห็นลูปที่ถูกส่งมาในตัวเอเจนต์ก็ช่วยได้เช่นกัน ใน Claude Code ลูปที่สมบูรณ์ที่สุดที่เล็กที่สุดคือ /goal: คุณส่งมอบสถานะสุดท้ายที่ตรวจสอบได้ให้มัน และมันจะวนซ้ำต่อไปจนกว่าสถานะนั้นจะเป็นจริง

นี่คือตัวอย่างการใช้ /goal เป็นคำสั่งภายในเซสชันใน Claude Code คุณเปิดเซสชัน จากนั้นตั้งเป้าหมายภายในเซสชัน:

1$ claude  # เปิด Claude Code
2$ /goal tests in test/auth pass   # ตั้งเป้าหมายภายในเซสชัน

มันเป็นรูปเดียวกัน: ลงมือ, ตรวจสอบ, ทำซ้ำ จากที่กล่าวมาก่อนหน้านี้ โดยมีตัวตรวจสอบในตัว

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

• ตั้งเงื่อนไข. พิมพ์ /goal ตามด้วยสถานะสุดท้ายที่ตรวจสอบได้ เช่น /goal tests in test/auth pass รอบแรกจะเริ่มทันที
• เอเจนต์ทำงานหนึ่งรอบ. มันแก้ไข, รันทดสอบ, และแสดงผลลัพธ์ในเซสชัน
• ผู้ประเมินตรวจสอบ. โมเดลที่เร็วอ่านทรานสคริปต์และตัดสินใจว่าตรงตามเงื่อนไขหรือไม่ตรง เพื่อให้เอเจนต์ไม่ได้ให้คะแนนงานของตัวเอง
• วนซ้ำหรือจบ. ไม่ตรงหมายถึงอีกรอบพร้อมคำแนะนำ; ตรงหมายถึงเป้าหมายเคลียร์ตัวเองและการรันหยุด

สถานะถูกส่งต่อข้ามรอบ ดังนั้นมันจะไม่เลิกก่อนเวลาหรือทิ้งข้อจำกัดกลางทาง มีการควบคุมบางอย่างที่ช่วยให้มันเชื่อถือได้:

• ทำให้การตรวจสอบวัดผลได้. ผลลัพธ์ของ test, รหัสออก, จำนวนไฟล์, หรือคิวที่ว่าง npm test exits 0 คือเป้าหมาย; "ทำให้ดีขึ้น" ไม่ใช่
• กำหนดขอบเขตการรัน. ต่อท้ายบางอย่างเช่น "หรือหยุดหลังจาก 20 รอบ" เพื่อให้ลูปที่ติดขัดหยุดแทนที่จะเผารอบ
• จับคู่กับโหมด auto เพื่อให้รอบทำงานโดยไม่มีคนดูแล และใช้ /goal clear เพื่อยกเลิกมันก่อนเวลา

ขั้นตอนผู้ประเมินซ่อนความละเอียดอ่อนที่มีประโยชน์: ตัวตรวจสอบไม่จำเป็นต้องเป็นโมเดลเดียวกันกับผู้เขียนโค้ด เมื่อลูปมีบทบาทที่แตกต่างกัน (ผู้วางแผน, ผู้ดำเนินการ, ผู้ประเมิน, ผู้ตรวจสอบภาพ) แต่ละบทบาทสามารถรันบนโมเดลที่แตกต่างกัน และการเลือกว่าโมเดลใดเติมบทบาทใดกลายเป็นการตัดสินใจทางสถาปัตยกรรม แทนที่จะเป็นการเดิมพันครั้งเดียวกับเอเจนต์เขียนโค้ดที่ "ดีที่สุด" ตัวเดียว โมเดลบางตัววางแผนได้ดีกว่า, บางตัวทำงานได้ถูกกว่า, บางตัวตัดสินภาพหน้าจอได้แม่นยำกว่า และ orchestrator ที่ดีจะให้คุณสลับตามบทบาทแทนที่จะรอให้ผู้ขายรายเดียวชนะทุกหมวดหมู่

มันทำงานได้ดีสำหรับการย้าย API (ย้ายทุกจุดเรียกใช้จนกระทั่งคอมไพล์และ test ผ่าน), การรีแฟกเตอร์ (แบ่งไฟล์จนกว่าแต่ละโมดูลอยู่ในงบประมาณ), งานค้างของอีสชู (ทำงานตามคิวที่ติดป้ายจนกว่าจะว่าง), และลูปประเมินผล (ปรับแต่งพรอมต์จนกว่าคะแนนจะถึงเกณฑ์) /loop เป็นคู่หูสำหรับงานที่ไม่มีเส้นชัยเดียว: แทนที่จะเป็นเงื่อนไขการเสร็จสิ้น มันจะพรอมต์ซ้ำตามตารางเวลา ซึ่งเป็นวิธีที่ลูปอย่าง PR babysitter ทำงานต่อไป

การรันหลายลูปโดยไม่มีคนดูแล

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

1. อนุมัติสิทธิ์อัตโนมัติ เพื่อให้เอเจนต์ไม่หยุดถามในการเรียกใช้เครื่องมือทุกครั้ง
2. ใช้เวิร์กโฟลว์แบบไดนามิก (ใส่ Ultracode ลงในพรอมต์) เพื่อกระจายงานไปยังเอเจนต์หลายตัวแทนที่จะเป็นเธรดเดี่ยวแบบอนุกรม
3. ใช้ /goal หรือ /loop เพื่อให้มันทำงานต่อไป /goal ตั้งเงื่อนไขการเสร็จสิ้น, /loop พรอมต์ซ้ำตามตารางเวลา และทั้งคู่ส่งต่อสถานะ ดังนั้นมันจะไม่เลิกก่อนเวลา
4. รันในคลาวด์ (แอปเดสก์ท็อปหรือมือถือ) เพื่อให้เซสชันคงอยู่เมื่อคุณปิดแล็ปท็อป
5. ให้วิธีการตรวจสอบตัวเองแบบ end-to-end Claude ใน Chrome สำหรับเว็บ, simulator MCP สำหรับมือถือ, และเซิร์ฟเวอร์สดสำหรับแบ็กเอนด์ นี่คือขั้นตอนที่ทำให้สี่ขั้นตอนอื่นๆ ปลอดภัย

ลำดับเต็ม:

1claude --permission-mode auto                          # 1 · ไม่ต้องอนุมัติ
2ultracode  orchestrate sub-agents เพื่อส่งมอบฟีเจอร์   # 2 · กระจายงาน
3/goal all tests pass and the demo loads clean          # 3 · ทำงานต่อไป
4→ cloud / desktop app                                  # 4 · ปิดแล็ปท็อป
5→ chrome ext · sim MCP · live server                   # 5 · ตรวจสอบตัวเองแล้วหยุด

crabfleet: orchestration ในรูปแบบผลิตภัณฑ์

Orchestration จะจินตนาการได้ง่ายขึ้นเมื่อมีเครื่องมือที่เป็นรูปธรรม crabfleet ของ Peter Steinberger โปรเจกต์ OpenClaw ที่โฆษณาว่าเป็น "ศูนย์ควบคุมสำหรับการรันเอเจนต์" คือลูปที่บรรจุเป็นผลิตภัณฑ์ และรูปร่างของมันสอดคล้องกับทุกอย่างที่กล่าวมา

• งานเป็น card บนกระดาน. งานถูกป้อนเป็น card ที่สร้างจากพรอมต์, GitHub issue หรือ PR จากนั้นเคลื่อนผ่าน todo, running, human review และ done กระดานนั้นคือคิวของลูปและขั้นตอนหยุดและรายงาน ที่ทำให้มองเห็นได้
• การรันที่คงทน ไม่ใช่ยิงแล้วลืม. แต่ละรันคือความพยายามที่ถูกติดตามด้วย heartbeats ดังนั้นมันจะทำงานต่อไปเมื่อคุณมองไปทางอื่น และคงอยู่เมื่อปิดแล็ปท็อป คุณจะเข้ามาคุมก็ต่อเมื่อ runtime โฆษณาว่ารองรับการส่งต่อ
• เอเจนต์ที่สร้างเอเจนต์. การรันสามารถเริ่มเซสชันลูก, ส่งข้อความ, อ่านทรานสคริปต์, และอัปเดตสรุปของตัวเองจากภายใน sandbox: หน่วยความจำบนดิสก์และการกระจายงานในที่เดียว ผู้เขียนหนึ่งคนและเอเจนต์หลายตัว

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

ต้นทุนตอนนี้ไปอยู่ที่ไหน

เป็นเวลาสองปี คำถามเรื่องต้นทุนในการเขียนโค้ดด้วย AI นั้นง่าย: โมเดลไหน, และใช้กี่โทเค็น ภายในลูป สัญชาตญาณนั้นชี้ไปยังชั้นที่ผิด ค่าใช้จ่ายไม่ใช่การเรียกครั้งเดียวอีกต่อไป แต่คือจำนวนครั้งที่ลูปวนซ้ำ ดังนั้นลูปที่ลองใหม่หกครั้งก่อนจะลู่เข้า จะมีค่าใช้จ่ายหกเท่าของลูปที่สำเร็จในครั้งแรก บนโมเดลเดียวกัน

นั่นเปลี่ยนสิ่งที่คุ้มค่าที่จะปรับให้เหมาะสม:

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

เมื่อก่อนคุณปรับแต่งพรอมต์; ตอนนี้คุณปรับแต่งลูป เพราะนั่นคือที่ที่ต้นทุนสะสม

เมื่อไหร่ที่ไม่ควรใช้ลูป

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

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

อะไรที่อาจผิดพลาดได้

ลูปที่ทำงานในขณะที่คุณหลับ ก็ทำผิดพลาดในขณะที่คุณหลับเช่นกัน และรูปแบบความล้มเหลวนั้นคาดเดาได้

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

ไม่มีอะไรในนี้เป็นข้อโต้แย้งต่อลูป; มันคือสาเหตุที่วิศวกรที่ออกแบบลูปมีความสำคัญมากขึ้น ไม่ใช่น้อยลง

วิธีสร้างลูปของคุณเอง

1. เลือกงานที่ทำซ้ำได้หนึ่งอย่าง การดูแล PR, แก้ไข CI, ตรวจสอบการ deploy: เริ่มจากงานประจำ
2. กำหนดขอบเขตให้แคบ "แก้ไขการตรวจสอบความถูกต้องของ billing webhook, สัมผัสเฉพาะ app/api/billing และ lib/billing" ดีกว่า "แก้บั๊ก" ลูปที่หลวมจะเร่ร่อน
3. ให้งบประมาณและเงื่อนไขหยุด จำนวนครั้งสูงสุด, เวลาทำงานสูงสุด, ไฟล์สูงสุด, ค่าใช้จ่ายสูงสุด, ความล้มเหลวติดต่อกันสูงสุด ลูปที่ทำงานโดยไม่มีคนดูแลก็คือลูปที่ทำผิดพลาดโดยไม่มีคนดูแลเช่นกัน
4. เพิ่มตัวตรวจสอบอิสระ เอเจนต์ย่อยแยกต่างหากให้คะแนนงาน เพราะเอเจนต์ที่เขียนโค้ดเป็นผู้ตัดสินที่แย่ที่สุดว่างานเสร็จหรือไม่
5. รันตามจังหวะ /loop สำหรับช่วงเวลา, cron สำหรับตารางเวลา, hooks ที่จุดต่างๆ ในวงจร หรือ GitHub Actions เพื่อให้มันคงอยู่เมื่อปิดแล็ปท็อป
6. เก็บหน่วยความจำไว้บนดิสก์ โมเดลลืมระหว่างรอบ ดังนั้นสถานะจะอยู่ใน markdown หรือกระดาน ไม่ใช่ในหน้าต่างบริบท

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

ถ้าคุณเห็นข้อผิดพลาดหรือสิ่งที่ต้องการคำชี้แจงเพิ่มเติม อย่าลังเลที่จะติดต่อมา

เอกสารอ้างอิงที่เป็นประโยชน์อื่นๆ

• Addy Osmani (@addyosmani), เกี่ยวกับลูปการเขียนโค้ดที่ใช้ AI ช่วย
• Matt Van Horn (@mvanhorn), "WTF Is a Loop?"
• Peter Steinberger (@steipete), เกี่ยวกับการออกแบบลูป
• Boris Cherny (@bcherny), เกี่ยวกับการรันเอเจนต์อย่างอัตโนมัติ