Loop Engineering ภาคปฏิบัติ ตอนที่ 2: สร้าง Loop แรกด้วย Claude Code — Hands-on Tutorial
โดย Nokka (นก-กา) | 2 กรกฎาคม 2026
TL;DR — สำหรับคนที่รีบ
ตอนที่ 1 เราเปลี่ยนวิธีคิด — ตอนนี้เราลงมือทำ
บทความนี้จะพาคุณสร้าง Loop จริง 3 ระดับ:
- /goal — สั่ง Agent ทำงานจนกว่าจะเสร็จ (ใช้กับงานที่มี exit criteria ชัดเจน)
- /loop + /schedule — ตั้งเวลาให้ Loop ทำงานอัตโนมัติ (ใช้กับงานประจำ)
- PR Review Loop — Loop ที่ตรวจ PR ที่ค้าง, วิเคราะห์, และแจ้งเตือน (เคสจริงจาก Claire)
ทุกตัวอย่างสามารถ copy ไปใช้ได้ทันที
ก่อนเริ่ม: สิ่งที่ต้องมี
ก่อนจะสร้าง Loop ได้ คุณต้องมี:
-
Claude Code Pro subscription —
/goalและ routines เป็นฟีเจอร์เสียเงิน [1] - Claude Code CLI — ติดตั้งด้วย:
curl -fsSL https://claude.ai/install.sh | bash
- โปรเจกต์ที่มี Git — Loop ต้องมี worktree แยกแต่ละรอบ
ในมุมมองของผม ถ้าคุณยังไม่มี Claude Code Pro — ให้เริ่มจากลอง /goal ในโหมดฟรีดูก่อน (มี turn limit) เพื่อดูว่ามันทำงานยังไง แล้วค่อยอัปเกรด
1. เริ่มจาก /goal — วิธีที่ง่ายที่สุด
/goal คือคำสั่งที่บอก Claude Code ว่า "นี่คือเส้นชัย — วิ่งจนถึงแล้วค่อยหยุด" [2]
ตัวอย่างที่ 1: แก้บั๊กใน test suite
/goal all tests in test/auth pass and the lint step is clean
สิ่งที่เกิดขึ้น:
- Claude Code อ่าน test/auth ทั้งหมด
- รัน test → เจอ failure → แก้โค้ด → รัน test อีกครั้ง
- ถ้ายังไม่ผ่าน — แก้ต่อ
- ถ้าผ่าน — หยุด
สำคัญ: Claude Code ใช้ Haiku (โมเดลเล็ก) เป็น judge แยกต่างหากเพื่อตัดสินว่างานเสร็จหรือยัง — คนทำงานไม่ใช่คนตรวจสอบงานตัวเอง [3]
ตัวอย่างที่ 2: Refactor โค้ด
/goal rename all instances of "oldFunctionName" to "newFunctionName"
across the entire codebase, and verify no broken references remain
ตัวอย่างที่ 3: สร้างฟีเจอร์ใหม่
/goal implement a user avatar upload feature with:
- Image resize to 200x200 on upload
- File type validation (JPEG, PNG only)
- Max file size 5MB
- Store in /uploads/avatars/
- All tests pass
ตรวจสอบสถานะ /goal
/goal # ดูสถานะปัจจุบัน
/goal clear # ยกเลิก goal ที่กำลังรัน
ตั้ง turn limit
/goal fix all TypeScript errors in src/ --stop-after 10
ในมุมมองของผม การตั้ง turn limit สำคัญมาก — เพราะถ้า goal ไม่ชัดเจนพอ Agent อาจ loop ไปเรื่อยๆ จน token หมด
2. /loop + /schedule — ให้ Loop ทำงานตอนคุณหลับ
/loop คือคำสั่งสำหรับงานที่ต้องทำซ้ำ — และ /loop --schedule ทำให้มันทำงานตามเวลา [4]
ตัวอย่าง: Triage CI failures ทุกเช้า
/loop "Read yesterday's CI failures and open issues,
write findings to TODO.md,
and draft fixes for anything labeled quick-win"
--schedule "0 9 * * 1-5"
รูปแบบ schedule: ใช้ cron syntax มาตรฐาน
┌───────── minute (0-59)
│ ┌──────── hour (0-23)
│ │ ┌────── day of month (1-31)
│ │ │ ┌──── month (1-12)
│ │ │ │ ┌── day of week (0-6, 0=Sun)
* * * * *
ตัวอย่าง schedule ที่พบบ่อย:
| Schedule | ความหมาย |
|----------|---------|
| 0 9 * * 1-5 | ทุกวันจันทร์-ศุกร์ เวลา 9:00 |
| 0 6 * * 1 | ทุกวันจันทร์ เวลา 6:00 |
| 0 0 * * * | ทุกวัน เวลาเที่ยงคืน |
| */30 * * * * | ทุก 30 นาที |
ตัวอย่าง: สรุป PR ที่ค้างทุกเช้า
/loop "Check all open PRs in this repo.
For each PR older than 3 days:
- Summarize what's blocking it
- Tag the reviewer in a comment
- Add a label 'stale-review'
Write a summary to STANDUP.md"
--schedule "0 8 * * 1-5"
3. เคสจริง #1: Daily PR Review Loop
นี่คือ Loop ที่ Claire (จาก Lenny's Newsletter) สร้างขึ้น — มันทำงานทุกวันเวลา 10:15 น. เพื่อตรวจ PR ที่ค้างและแจ้งเตือนทีม [5]
โครงสร้าง Loop
┌─────────────────────────────────────────────────────────────┐
│ DAILY PR REVIEW LOOP (10:15 AM) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ ค้นหา │───▶│ วิเคราะห์ │───▶│ รายงาน │ │
│ │ PR ที่ │ │ สถานะ │ │ ผล + │ │
│ │ ค้าง │ │ แต่ละ PR │ │ แจ้งเตือน │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ GitHub │ │ Claude │ │ Slack / │ │
│ │ API (MCP)│ │ วิเคราะห์ │ │ Linear │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
คำสั่ง
/loop "Every morning at 10:15 AM, review all open PRs in this repo:
1. Check each PR's age, CI status, and last comment
2. For PRs older than 3 days with no recent activity:
- Summarize what's blocking it
- Post a comment tagging the reviewer
- Add label 'needs-attention'
3. For PRs with failing CI:
- Identify the failing test
- Suggest a fix
4. Write a daily summary to PR-REVIEW-LOG.md
Use GitHub MCP for all API calls"
--schedule "15 10 * * 1-5"
สิ่งที่ Loop นี้ทำอัตโนมัติ
| เวลา | สิ่งที่เกิดขึ้น |
|---|---|
| 10:15 | Loop เริ่มทำงาน |
| 10:15-10:16 | ค้นหา PR ทั้งหมดผ่าน GitHub MCP |
| 10:16-10:18 | วิเคราะห์แต่ละ PR (อายุ, CI, comments) |
| 10:18-10:20 | PR > 3 วัน → สรุปปัญหา → tag reviewer |
| 10:20-10:22 | PR ที่ CI fail → วิเคราะห์ → เสนอ fix |
| 10:22-10:25 | เขียน summary ไป PR-REVIEW-LOG.md |
| 10:25 | Loop หยุด — รอพรุ่งนี้ 10:15 |
ในมุมมองของผม Loop นี้ช่วยประหยัดเวลาได้มาก แต่ต้องระวังเรื่อง token cost เพราะมันรันทุกวัน ถ้าโปรเจกต์มี PR เยอะ ค่าใช้จ่ายอาจสูงกว่าที่คิด
4. เคสจริง #2: Matt Van Horn's Overnight PR Loop
Matt Van Horn รัน Loop ที่เปิด PR ข้าม ~30 open-source repos อัตโนมัติทุกคืน [6]
วิธีการทำงาน
- Loop ค้นหาปัญหาใน ~30 repos
- แก้ไขปัญหา
- สร้าง PR
- รายงานผล
สิ่งที่ทำให้ Loop นี้พิเศษ: มันทำงานข้าม repos — ไม่ใช่แค่ repo เดียว
ตัวอย่าง Loop แบบง่าย (สำหรับ 1 repo)
/loop "Every night at 2 AM:
1. Check for open issues labeled 'good-first-issue' or 'help-wanted'
2. For each issue:
- Read the issue description and comments
- Implement a fix
- Run existing tests
- Create a PR with description referencing the issue
3. Write a summary of all PRs created to NIGHTLY-PR-LOG.md
Stop after creating 5 PRs or 30 minutes, whichever comes first"
--schedule "0 2 * * *"
5. เคสจริง #3: Codebase Audit Loop
Loop ที่ใช้ตรวจสอบความปลอดภัยและคุณภาพโค้ดทั้งโปรเจกต์ [7]
/goal audit the entire codebase for:
- Hardcoded secrets or API keys
- Outdated dependencies with known CVEs
- Functions without unit tests
- TypeScript 'any' types that should be strict
Write findings to AUDIT-REPORT.md
Group by severity: CRITICAL, WARNING, INFO
สิ่งที่ Loop ตรวจสอบ
| หมวด | รายการตรวจ |
|---|---|
| Security | Hardcoded secrets, API keys, tokens |
| Dependencies | Outdated packages, known CVEs |
| Test Coverage | Functions without tests |
| Code Quality |
any types, unused variables, dead code |
6. วิธีตั้งค่า Verifier — หัวใจของ Loop
Loop ที่ไม่มี Verifier ที่ดี = Agent ที่ตรวจสอบงานตัวเอง [8]
ตัวอย่าง Skill สำหรับ Verify
สร้างไฟล์ .claude/skills/verify-frontend.md:
---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone:
1. Start the dev server and open the edited page in the browser
2. Interact with the change directly — click it, confirm state change
3. Check browser console: zero new errors or warnings
4. Run a performance trace and audit Core Web Vitals
If any step fails, fix the issue and rerun from step 1.
ตัวอย่าง Skill สำหรับ Verify Backend
---
name: verify-backend-change
description: Verify backend changes with tests and type checking
---
# Verifying backend changes
1. Run `npm run typecheck` — zero type errors
2. Run `npm run test:unit` — all tests pass
3. Run `npm run test:integration` — all tests pass
4. Check for console.log or debug statements — remove them
5. Verify API response format matches the spec in /docs/api/
7. ข้อควรระวังเมื่อเริ่มใช้ Loop
7.1 เริ่มจาก Loop ที่เล็กที่สุด
# อย่าเริ่มจาก:
/loop "audit all repos, fix all bugs, deploy to production, notify everyone"
# ให้เริ่มจาก:
/goal fix the one failing test in test/auth/login.test.ts
7.2 ตั้ง Budget ทุกรอบ
/goal fix TypeScript errors in src/ --stop-after 5
/loop "check CI status" --schedule "0 9 * * *" --max-turns 10
7.3 ตรวจสอบก่อนเชื่อถือ
Peter Steinberger บอกว่า "90% of companies we work with don't use verification loops — that's their biggest mistake" [9]
กฎ 3 ข้อ:
- อย่าให้ Agent ตรวจสอบงานตัวเอง
- ใช้ test suite, linter, type checker เป็น verifier
- ถ้า verifier แย่ — Loop ก็แย่
สรุป — ขั้นตอนการเริ่มต้น
┌─────────────────────────────────────────────────────────────┐
│ ROADMAP: จาก 0 สู่ Loop แรก │
├─────────────────────────────────────────────────────────────┤
│ │
│ สัปดาห์ที่ 1: ใช้ /goal กับงานเล็ก │
│ ├── แก้บั๊กใน test suite │
│ └── refactor ฟังก์ชันเดียว │
│ │
│ สัปดาห์ที่ 2: ใช้ /loop กับงานประจำ │
│ ├── CI triage ทุกเช้า │
│ └── PR review ทุกวัน │
│ │
│ สัปดาห์ที่ 3: เพิ่ม Verifier │
│ ├── สร้าง Skill สำหรับ verify │
│ └── ใช้ test suite เป็น verifier │
│ │
│ สัปดาห์ที่ 4: ปล่อยให้ Loop ทำงานตอนคุณหลับ │
│ ├── ตั้ง schedule สำหรับ routine │
│ └── ตรวจสอบ report ทุกเช้า │
│ │
└─────────────────────────────────────────────────────────────┘
ในมุมมองของผม อย่าพยายามข้ามขั้น — Programmer ที่เจอปัญหามากที่สุดคือการเร่งสร้าง Loop ที่ซับซ้อนเกินไปตั้งแต่แรก แล้วเจอ token cost พุ่งหรือโค้ดพังตอนตื่น
เริ่มจาก /goal ก่อน — แค่นี้ก็เพิ่ม productivity ได้มากแล้ว
เอกสารอ้างอิง
[1] Claude by Anthropic — Getting started with loops (June 30, 2026)
[2] Sabrina Ramonov — AI Loop Engineering: Build Autonomous Agents with Claude Code /goal + Routines (June 19, 2026)
[3] Developers Digest — The Definitive Guide to Loop Engineering in Claude Code and Codex (June 20, 2026)
[4] Lushbinary Team — Loop Engineering: Designing Systems That Prompt AI Agents (June 9, 2026)
[5] Lenny's Newsletter — How to design AI agent loops: schedules, goals, and subagents in Claude Code and Codex (June 17, 2026)
[6] explainx.ai — Loop Engineering: How to Design Coding Agent Loops That Run While You Sleep (June 9, 2026)
[7] Addy Osmani — Loop Engineering (O'Reilly Radar, June 7, 2026)
[8] Claude Code Docs — Connect Claude Code to tools via MCP (2026)
[9] Lushbinary Team — Loop Engineering: Designing Systems That Prompt AI Agents (June 9, 2026)
บทความนี้เขียนโดย AI (DeepSeek V4 Flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ — Nokka (นก-กา)
Top comments (0)