ตัวอย่างบทเรียน

feature_list.json for AI Agents: WIP=1, Feature Status and verify.sh Verification

How to limit an AI coding agent to one task at a time (WIP=1): feature_list.json with feature states, task granularity, scripts/verify.sh as the only gate for passing status, strict vs weak verification.

WIP=1 task granularity feature_list. feature finite state machine gatekeeper

คุณจะเรียนรู้อะไรในบทเรียนนี้

Implement WIP=1 and watch the number of unfinished parallel changes fall.
Set up feature_list. with an honest finite state machine, instead of the agent marking its own homework.
Write verify.sh as the sole authority permitted to set a status to passing.

จุดเริ่มต้นของบทเรียน

Twelve files, eight hundred lines, zero finished features

There was just one request: 'add sign-up'
Along the way, the agent 'helpfully' wired in email verification, bcrypt and a middleware refactor
The resulting code is tightly coupled, yet no scenario passes end-to-end
The next session opens this tangle from scratch

The request was exactly one thing — build sign-up. Here's how, in practice, it sprawled into six directions: the agent models the user, then decides email verification is needed, wires up a mail service, remembers password hashing still needs doing, pulls in a separate library, spots inconsistent error handling and refactors the middleware, and tidies up the test structure along the way. Six directions, each half-done, all tightly coupled together — and not a single end-to-end run. The next session opens this code with no idea where to begin.

Arithmetic, not metaphor

C — the agent's usable context capacity
k — the number of simultaneously active tasks
Each task gets roughly C/k of the reasoning resource
As soon as C/k drops below the minimum, no task gets seen through to completion

This isn't a metaphor, it's arithmetic. Call the agent's usable context capacity C, and the number of simultaneously active tasks k. Each task gets roughly C divided by k of the reasoning resource. As soon as that value falls below the minimum needed to carry a single task through to completion, nothing gets completed. The more tasks the agent juggles at once, the lower the chance that any one of them genuinely gets finished.

The trap: one request turns into six projects

❌ The agent treats 'fixing things while we're at it' as a free action, and often does exactly that: pulling in an email service, bcrypt, a middleware refactor, test reorganisation — all within a single task
✅ One request = one branch of work; anything noticed along the way goes into BACKLOG.md, not into the current scope

'I'll fix that while I'm at it' is the most expensive phrase in an agent's vocabulary. You ask for sign-up, and the agent — since it's already deep in the code anyway — fixes error handling while it's at it, adds email verification while it's at it, tidies up the tests while it's at it. Each of these 'while I'm at it' moves seems almost free to the agent. This is a trap people fall into constantly: scope creep costs the agent almost zero tokens, but the cost to the project is real. The right move is different: one request, one branch of work, and everything else noticed along the way gets recorded separately and left well alone.

บทเรียนฉบับเต็มใช้ได้เมื่อสมัครสมาชิก

ฉบับเต็มมีสไลด์เพิ่มอีก 23 สไลด์

วิดีโอ สไลด์ทั้งหมด โน้ต แบบทดสอบ AI ติวเตอร์ และการสัมภาษณ์จะเปิดหลังเข้าสู่ระบบและสมัครสมาชิก

เข้าสู่ระบบหรือลงทะเบียน สมัครสมาชิก

เนื้อหาบทเรียน

Twelve files, eight hundred lines, zero finished features
Arithmetic, not metaphor
The trap: one request turns into six projects
Myth: more code means more progress
An agent has no brakes
BACKLOG.md — a release valve for the 'while we're at it' impulse
BACKLOG.md — a release valve for the 'while we're at it' impulse
Scope lives outside — in a file
Scope lives outside — in a file
VCR: the metric that keeps the agent on a short leash
WIP=1 is set. But who remembers what's already done?
💡 Not too wide, not too narrow: the right size for a feature
Feature = session = commit = scenario: the size check
WIP=1 is set. But who remembers what's already done?
📖 'The basket's nearly done, but there are bugs' — nearly done for whom?
The feature list is the harness’s spine, not a memo
Three fields without which a feature entry is just words
A feature has exactly four states — and not one extra transition
The passing gate: the agent can request it, but not declare it
The feature list rules live in AGENTS.md too
Two levels of checking: first the whole, then the part
Two levels of checking: first the whole, then the part
“The function exists” doesn’t mean it works
A feature's journey from queue to passing: three places it can get stuck
Step 4 of the end-to-end project: feature_list. for the payment backend
The harness applies the brakes, not the agent