Loop Engineering: สร้าง AI ที่เขียนโค้ดให้คุณในขณะที่คุณหลับ

เมื่อเดือนธันวาคมที่แล้ว Boris Cherny ส่ง pull request จำนวน 259 ครั้งในเดือนเดียว ทุกครั้งเขียนโดย Claude เขาบอกว่าเขาไม่ได้เปิด editor เลยตลอดทั้งเดือน

งานของเขาไม่ใช่การเขียนโค้ด แต่คือการเขียนสิ่งที่เขียนโค้ดอีกที Peter Steinberger สรุปเป็นสองบรรทัดที่มียอดเข้าชมกว่า 8 ล้านครั้ง: “คุณไม่ควร prompt coding agents ด้วยตัวเองอีกต่อไป คุณควรออกแบบ loops ที่คอย prompt agents ของคุณ”

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

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

มีคำถามเดียวที่ตัดสินว่าคุณสร้างลูปแบบไหน: มันลู่เข้าหาสิ่งที่เป็นจริง หรือมันเป็นแค่การเดินสุ่ม (random walk) ที่แพงลิบ?

1. ลูปคือหกชิ้นส่วนและหนึ่งคำถาม

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

คุณไม่ได้สร้างสิ่งเหล่านี้ด้วยมืออีกต่อไปแล้ว เมื่อปีที่แล้ว ลูปหมายถึงกอง shell script ที่คุณเป็นเจ้าของและต้องดูแลตลอดไป ตอนนี้ชิ้นส่วนต่างๆ ถูกบรรจุอยู่ในผลิตภัณฑ์ และหกส่วนเดียวกันนี้ก็สามารถนำไปใช้ได้ทั้งในแอป OpenAI Codex และ Claude Code เมื่อคุณเห็นสิ่งนี้ เครื่องมือก็ไม่ใช่ประเด็นอีกต่อไป และลูปก็กลายเป็นการออกแบบ

1ชิ้นส่วน          หน้าที่ในลูป                    CODEX                      CLAUDE CODE
2-------------  ------------------------  -------------------------  --------------------------
3State          จดจำข้ามรอบการทำงาน        markdown / Linear (MCP)    markdown / Routines + MCP
4Automations    ทำงานตามตารางเวลา          Automations tab + Triage   /loop (skill), Routines, /goal
5Worktrees      แยก agents แบบขนาน        Worktree ต่อ thread        --worktree, isolation: worktree
6Skills         บันทึกความตั้งใจของคุณ     ~/.agents/skills/SKILL.md   ~/.claude/skills/SKILL.md
7Connectors     เชื่อมต่อเครื่องมือจริง    MCP servers (config.toml)  MCP servers (.mcp.json)
8Sub-agents     แยกผู้สร้างออกจากผู้ตรวจ   TOML ใน .codex/agents/     .claude/agents/ + agent teams

2. State คือสิ่งเดียวที่รอบถัดไปจะสืบทอด

เริ่มจากด้านล่าง เพราะทุกอย่างอื่นขึ้นอยู่กับมัน

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

ในทางปฏิบัติ นั่นคือไฟล์เดียว STATUS.md ใน repo หรือบอร์ด Linear ที่เข้าถึงผ่าน connector ซึ่งเก็บสิ่งที่ทำเสร็จแล้ว สิ่งที่กำลังทำ สิ่งที่ต้องทำต่อไป และสิ่งสองสามอย่างที่ลูปต้องไม่แตะต้องเด็ดขาด

1# STATUS.md  (ลูปอ่านไฟล์นี้ก่อน เขียนทีหลัง)
2## เสร็จแล้ว
3- [x] auth: ย้ายไปใช้ tokens v2 แล้ว, tests ผ่านหมด
4## กำลังทำ
5- [ ] billing: refactor webhook (PR #214, CI สีแดง)
6## ถัดไป
7- [ ] dashboard: test ที่ไม่เสถียรใน test/charts
8## ห้ามแตะ
9- ห้ามแก้ไข infra/ โดยไม่มีมนุษย์

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

3. Automations คือความแตกต่างระหว่างลูปกับสิ่งที่คุณรันครั้งเดียว

ลูปจะสมควรได้ชื่อนี้ก็ต่อเมื่อมันทำงานได้เอง

ในแอป Codex คุณสร้างมันในแท็บ Automations: repo, prompt, ความถี่ การรันที่เจออะไรบางอย่างจะไปที่ Triage inbox; การรันที่ไม่เจออะไรจะเก็บถาวรตัวเอง OpenAI ใช้สิ่งนี้สำหรับงานพื้นฐานที่ไม่สวยหรูของ codebase: การคัดกรอง issue รายวัน, สรุป CI-failure, จับบั๊กที่ใครบางคนแอบใส่เมื่อสัปดาห์ที่แล้ว

Claude Code เข้าถึงสิ่งนี้ผ่าน primitives สองสามอย่าง และบทความยอดนิยมมักให้รายละเอียดผิด ดังนั้นจึงควรบอกให้ชัดเจน /loop คือ skill ไม่ใช่คำสั่งในตัว และมันจะรัน prompt ซ้ำตามความถี่ในขณะที่เซสชันของคุณเปิดอยู่ งาน cloud ที่เกิดซ้ำคือ Routines ตั้งค่าด้วย /schedule โดยมีขั้นต่ำหนึ่งชั่วโมง และมันจะทำงานต่อไปแม้ปิดแล็ปท็อปแล้ว ไม่มี local crontab

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

1# Claude Code: รันจนกว่าจะเสร็จจริงๆ ไม่ใช่แค่รู้สึกว่าเสร็จ
2/goal tests ทั้งหมดใน test/auth ผ่าน และขั้นตอน lint สะอาด
3
4# Claude Code: งาน cloud ที่เกิดซ้ำ (ขั้นต่ำ 1 ชั่วโมง)
5/schedule triage PR รายวันเวลา 9 น.
6
7# Codex: พรอมต์สำหรับ automation (ตั้งค่าความถี่ในฟอร์ม)
8"วันจันทร์-ศุกร์ 9 น.: สแกน PR ที่เปิดอยู่, ทำเครื่องหมาย CI ล้มเหลวหรือไม่มีผู้ตรวจสอบ, โพสต์ไปที่ Triage"

เขียนเงื่อนไขหยุดเหมือนสัญญา "Tests ทั้งหมดใน test/auth ผ่าน" คือสัญญา "ทำให้ดีขึ้น" คือวิธีที่ลูปทำงานจนถึงวันจ่ายเงินเดือน

4. Worktrees ทำให้ agents แบบขนานไม่ก้าวก่ายกัน

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

git worktree คือกำแพงกั้นระหว่างพวกมัน: ไดเรกทอรีทำงานแยกต่างหากบน branch ของตัวเอง แชร์ประวัติ repo ดังนั้นการแก้ไขของ agent หนึ่งจะไม่ไปถึง checkout ของอีกตัว

1# Claude Code: checkout ที่แยกสำหรับแต่ละ agent
2claude --worktree feature-auth
3
4# หรือใน sub-agent, ใน frontmatter ของ .claude/agents/<name>.md:
5#   isolation: worktree
6
7# Codex: เลือก "Worktree" เมื่อคุณเปิด thread (แต่ละ thread มี detached HEAD)

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

5. Skills คือความตั้งใจของคุณ เขียนครั้งเดียว ไว้ข้างนอก

Agent เริ่มต้นทุกรอบการทำงานอย่างเย็นชา และเติมเต็มช่องว่างในความตั้งใจของคุณด้วยการเดาที่มั่นใจ Skill คือความตั้งใจนั้นที่เขียนไว้ที่โมเดลอ่านทุกครั้ง เพื่อให้มันหยุดเดา

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

1# .claude/skills/triage/SKILL.md   (Codex: ~/.agents/skills/triage/SKILL.md)
2---
3name: triage
4description: อ่าน CI failures ของเมื่อวาน, issues ที่เปิดอยู่, และ commits
5  ล่าสุด; เขียนแต่ละสิ่งที่พบลงใน STATUS.md เป็นงาน
6---
71. ดึง CI ที่ล้มเหลวและจัดกลุ่มตามสาเหตุที่แท้จริง
82. จับคู่แต่ละรายการกับ issue ที่เปิดอยู่หรือ commit ที่เป็นสาเหตุ
93. เขียน STATUS.md หนึ่งงานต่อสิ่งที่พบจริง ข้ามสิ่งที่ไม่สำคัญ

หากไม่มี skills ทุกรอบจะต้องเรียนรู้โปรเจกต์ของคุณใหม่จากศูนย์ เมื่อมี skills ลูปจะคมชัดขึ้นเล็กน้อยในทุกเช้า

6. Connectors ให้ลูปลงมือทำ ไม่ใช่แค่พูด

ลูปที่มองเห็นแต่ filesystem คือของเล่น Connectors ซึ่งสร้างขึ้นบนมาตรฐาน MCP ที่ใช้ร่วมกัน ช่วยให้ agent อ่าน issue tracker ของคุณ ตี API staging สืบค้นฐานข้อมูล โพสต์ไปยังช่องทางต่างๆ

1# Claude Code
2claude mcp add --transport http linear https://mcp.linear.app/mcp
3
4# Codex
5codex mcp add linear --url https://mcp.linear.app/mcp

นี่คือเส้นแบ่งระหว่าง agent ที่บอกว่า "นี่คือวิธีแก้ไข" กับลูปที่เปิด pull request เชื่อมโยง ticket และรายงานว่าสีเขียวด้วยตัวเอง เนื่องจากเครื่องมือทั้งสองใช้ MCP เดียวกัน connector ที่คุณต่อสำหรับเครื่องมือหนึ่งจึงมักจะใช้กับอีกเครื่องมือหนึ่งได้

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

การเคลื่อนไหวที่มีมูลค่าสูงที่สุดในลูปใดๆ คือการแยก agent ที่เขียนออกจาก agent ที่ตรวจสอบ

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

1# Codex: .codex/agents/reviewer.toml
2name = "reviewer"
3description = "ผู้ตรวจสอบ PR แบบไม่ไว้หน้า: ความถูกต้อง, ความปลอดภัย, tests ที่ขาดหายไป"
4developer_instructions = "ตรวจสอบเหมือนเจ้าของ ให้ถือว่าผู้เขียนผิด
5  จนกว่า diff จะพิสูจน์เป็นอื่น"
6model_reasoning_effort = "high"
7
8# Claude Code: frontmatter ของ .claude/agents/reviewer.md
9#   name: reviewer
10#   description: ผู้ตรวจสอบแบบไม่ไว้หน้า ใช้หลังการเปลี่ยนแปลงโค้ดใดๆ
11#   model: opus

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

8. ลูปหนึ่งตัวมีหน้าตาอย่างไร

นำหกส่วนมารวมกัน และ thread เดียวก็จะกลายเป็นเครื่องจักรขนาดเล็ก

automation ที่ตั้งเวลาไว้จะทำงานทุกเช้าบน repo มันเรียก skill triage ของคุณ ซึ่งอ่าน CI failures ข้ามคืน issues ที่เปิดอยู่ และ commits ล่าสุด แล้วเขียนแต่ละสิ่งที่พบจริงลงใน STATUS.md สำหรับทุกสิ่งที่คุ้มค่าที่จะทำ ลูปจะเปิด worktree ที่แยกออกมา ส่ง sub-agent หนึ่งตัวไปร่างการแก้ไข และตัวที่สองไปตรวจสอบกับ skills และ tests ของคุณ Connectors เปิด PR และอัปเดต ticket สิ่งที่จัดการไม่ได้จะรออยู่ใน triage inbox ของคุณ STATUS.md จะจดจำสิ่งที่ผ่านและสิ่งที่ยังเปิดอยู่ ดังนั้นพรุ่งนี้จะเริ่มต้นจากจุดที่วันนี้หยุด

สิ่งที่คุณตื่นขึ้นมาเจอคือการส่งมอบงานสั้นๆ ไม่ใช่กำแพงของ log:

1# 9:00 น. — การส่งมอบข้ามคืนของลูป (Triage inbox ของคุณ)
2พร้อมรวม
3  PR #218  แก้ test ที่ไม่เสถียรใน test/charts          CI เขียว
4  PR #219  ลอง webhook ใหม่เมื่อเจอ 429, เพิ่ม backoff test  CI เขียว
5ต้องการคุณ
6  auth/session.ts  มีสองวิธีที่ปลอดภัยในการแก้ไขนี้; ฉันไม่ได้เลือกทั้งสอง, คุณเป็นคนตัดสิน
7เงียบ
8  7 การรันตามกำหนดไม่พบอะไรและเก็บถาวรตัวเอง

คุณออกแบบมันครั้งเดียว คุณไม่ได้ prompt มันเลย

9. สร้างเบรกก่อนที่คุณจะเดินออกไป

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

บิล 47,000 ดอลลาร์นั้นไม่ใช่โมเดลอัจฉริยะที่กลายเป็นปีศาจ มันคือ agent สองตัว ตัววิเคราะห์และตัวตรวจสอบ แต่ละตัวถามหางานเพิ่มจากอีกตัวอย่างสุภาพ โดยไม่มีการจำกัดขั้นตอน ไม่มีเพดานงบประมาณ และไม่มีเงื่อนไขหยุด มันทำงานสิบเอ็ดวัน การจำกัดเพียงครั้งเดียวก็จะหยุดมันได้ตั้งแต่แรก

ติดตั้งเบรกก่อนเพิ่มแรงม้า อย่าส่งเครื่องยนต์จนกว่าคุณจะส่งแป้นเบรก

1# ติดตั้งสิ่งเหล่านี้ ก่อนที่คุณจะเดินออกไป:
2- ขีดจำกัดขั้นตอน:  --max-turns 50            (หยุดเด็ดขาด, ไม่มีข้อยกเว้น)
3- เพดานงบประมาณ:  claude -p --max-budget-usd 10   (โหมดพิมพ์; ต่อเฟส)
4- รัศมีการระเบิด:  หนึ่ง worktree, หนึ่ง branch, อ่านอย่างเดียวภายนอก src/
5- เซอร์กิตเบรกเกอร์: เครื่องมือเดียวกัน + อาร์กิวเมนต์เดียวกัน 3 ครั้งติด = หยุด
6- การตรวจสอบสัญญาณชีวิต: เขียน heartbeat ไปยัง STATUS.md ทุกรอบ; ความเงียบจะแจ้งเตือนคุณ

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

และตั้งราคาตามจริง ฝูง agent ร้อยตัวของ Steinberger มีอยู่จริง และมันมีค่าใช้จ่ายประมาณ 1.3 ล้านดอลลาร์ต่อเดือน มันได้ผลเพราะ OpenAI จ้างเขาตอนนี้และจ่ายบิล กรณีสุดขั้วได้รับการสนับสนุน กรณีของคุณไม่ใช่ ในแผนราคา 20 ถึง 200 ดอลลาร์ ลูปที่คุ้มค่าคือลูปขนาดเล็ก มีขีดจำกัด และมุ่งไปที่งานที่น่าเบื่องานเดียว ไม่ใช่ฝูงชน

1การกระจายต้นทุน (ทั้งหมดจริง, ทั้งหมดจากหกเดือนที่ผ่านมา)
2-----------------------------------------------------------------
3259 PRs ใน 30 วัน    วิศวกรหนึ่งคน, 100% เขียนโดย Claude
447,000 ดอลลาร์ใน 11 วัน    ลูปที่หนีออกนอกทางโดยไม่มีขีดจำกัด, ไม่มีใครดู
5~1.3 ล้านดอลลาร์ต่อเดือน       ฝูง 100 ตัว (บิลได้รับการสนับสนุน)
6-----------------------------------------------------------------
7เทคโนโลยีเดียวกัน ความแตกต่างอยู่ที่เบรก

10. ลูปตายอย่างไร

ลูปทุกตัวที่ล้มเหลวตายด้วยหนึ่งในสี่สาเหตุ เรียนรู้ชื่อตอนนี้เพื่อให้คุณสังเกตเห็นตอนตีสาม

การเรียกซ้ำที่หนีไม่พ้น (Runaway recursion) Agent สองตัวป้อนกันและกันตลอดไป วิธีรักษาคือการจำกัดขั้นตอนและเพดานงบประมาณด้านบน ไม่มีอะไรที่ฉลาดกว่านี้

การตายอย่างเงียบ ๆ (Silent death) การรันข้ามคืนของนักพัฒนาคนหนึ่งเจอ context window เต็ม หยุด แล้วพยายามเริ่มใหม่ที่กำแพงเดิมต่อไปในขณะที่ยังดูเหมือนทำงานอยู่ ลูปของคุณอาจตายเป็นชั่วโมงและยังคงรายงานความคืบหน้า วิธีรักษาคือ heartbeat และ context ใหม่ต่อเฟส ไม่ใช่การรันที่ไม่สิ้นสุดครั้งเดียว

การเดินสุ่ม (The random walk) หากไม่มีเงื่อนไขหยุดที่ตรวจสอบได้ ลูปจะลอยห่างจากเป้าหมายแทนที่จะเข้าใกล้ ชุด test ที่ผ่านคือจุดตรึง (fixpoint) ที่มันเข้าถึงได้ "ดูเหมือนเสร็จ" ไม่ใช่

หนี้ความเข้าใจ (Comprehension debt) ยิ่งลูปส่งโค้ดที่คุณไม่ได้เขียนได้เร็วเท่าไหร่ ช่องว่างระหว่างสิ่งที่ repo ของคุณทำกับสิ่งที่คุณเข้าใจก็ยิ่งกว้างขึ้น ปล่อยให้มันทำงานโดยไม่ได้อ่านนานพอ และคุณจะหยุดเป็นวิศวกรและกลายเป็นตรายาง วิธีรักษาคือประตูที่มนุษย์ต้องตรวจสอบ ซึ่งลูปไม่ได้รับอนุญาตให้ข้าม

11. สร้างลูป คงสถานะวิศวกร

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

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

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

ไม่มีใครที่ส่ง pull request 200 ครั้งต่อเดือนเริ่มต้นด้วย agent ร้อยตัว พวกเขาเริ่มต้นด้วยลูปหนึ่งตัวที่ไว้ใจได้ และพวกเขายังคงเป็นวิศวกรตลอดทาง สร้างลูปตัวนั้น