How we run coding agents on a real board

Most writing about coding agents is about a single agent in a single chat window. That is not how the interesting work happens. Here is how a full day of shipping actually ran: one human, one task board, an orchestrator, and a handful of agent lanes working in parallel.

The shape

There is a board, and the board is the truth. Every piece of work is a task with acceptance criteria written down before anyone starts. The human owns the board; agents never invent work and never mark anything done.

An orchestrator sits in the middle. It does not write the code. It reads the board, picks what matters, writes a brief for each piece, hands that brief to a lane, and then verifies what comes back. Each lane is a separate agent with its own context, its own task, and one job.

A lane finishes a task the same way a person would: it claims the task, implements, proves the work, and moves it to review. The examples below are all from one session, mistakes included.

Rules that make parallel agents safe

Running several agents at once is not hard. Running them without corrupting each other's work is the actual engineering problem.

One writer per file. Two lanes never edit the same file, and never the same repository checkout. When two tasks genuinely touch the same area, they run in sequence or as one lane — not in parallel with a hope. The orchestrator assigns disjoint file sets and says so in every brief.

The unit of work is a task, not a conversation. A lane cannot "kind of" finish. A task either has evidence or it is not done. Ambiguity gets resolved before the lane starts, because a lane that guesses produces confident, wrong work.

Cap the parallelism. Three heavy lanes at once, not thirty. Browsers, container builds and test suites compete for the same machine; the fourth thing you start makes the first three slower.

Evidence, not adjectives

The single most useful rule: a claim needs proof attached.

"It works" is not evidence. Evidence means you reproduced the failure before you fixed it, measured the thing you claim to have improved, and compared artifacts rather than impressions. A few real examples from the day:

• A build broke. The lane proved the root cause by building the failing stage before and after the change, and showed the error count going to zero — not a local type-check that would have passed either way.
• A layout change shipped with measurements: prose width, code width, and characters per line at two screen sizes. The last number mattered, because it was wider than comfortable reading — worth knowing before deciding, not after.
• An artifact was verified by checksum: the file that landed in the task store was compared byte-for-byte with the source. "Uploaded successfully" is a claim; matching hashes are evidence.
• A deployment was verified by fetching the deployed address from outside and comparing before and after, because the same script can exit zero while nothing on the host changed.

The verification pass is the part people skip

Delegation is easy and verification is slow, which is exactly why verification is where the value is.

That day a page was retired. On the fresh deployment it was gone — requesting it returned a 404 — while the live address still returned a 200, serving a stale copy with a seven-day cache lifetime. Only a request that bypassed the cache showed what readers were actually getting. The deployment was correct; the reader was not.

The same shape turned up twice more. A build had been failing for days behind an unrelated error, so the thing everyone assumed was fine had never actually been built — a masked failure is not a passing build. And a test that had been green for as long as anyone remembered turned out to be incapable of failing: its assertion compared a substring, so it passed whatever the code did. A passing test is not evidence until you have watched it fail.

That is the whole discipline in one sentence: a change nobody verified is not a fix — it is only different.

Process bugs are bugs

Most of the day's interesting defects were not in the product. They were in how the work was done:

• The task system's own commit step captured the task record but not the code. A ticket could point at a change that existed only in a working tree. Fixed by verifying what each commit actually contained.
• Generated files must be fixed in their generator. A hand-fix to generated output is undone by the next build, and nobody remembers why it came back.
• A lane that cannot verify something must say so, in writing, rather than rounding up. One lane reported that it could not prove an end-to-end build and named exactly what it could not prove — which turned out to be the most valuable sentence in its report.
• When a requirement changes mid-flight, the change must reach the lane before it finishes, or the ticket gets reopened. Ours did: a late clarification arrived after a lane had stopped, so the work was reopened rather than accepted.

What still needs a human

Agents handled implementation, tests, deployment mechanics and verification. Four things stayed with the human, and should:

1. The final verdict. Everything an agent finishes lands in review, not done.
2. Anything irreversible. Deleting, publishing, rotating credentials, spending money.
3. Credentials. They stay on the human's side of the line, always.
4. Taste. Whether a page reads well, whether a post is worth publishing, whether the number is acceptable. Agents can produce the measurement and the options; the judgement is not theirs to make.

The point

The thing that made the difference was not a better prompt. It was organising the work as tasks and putting something in the middle of them.

1. Let the orchestrator write the tasks, and review them as concepts. It brainstorms with you, then writes each task up front in plain English — short, high level, readable in one pass. You approve the shape. Nobody has time to read a wall of generated detail, and you do not need to: the gaps get filled by the agent, not by your attention.
2. Let it own the detail. The orchestrator picks the agent best suited to each task and writes that agent's brief — acceptance criteria, the file list it may not exceed, the evidence required, the boundaries. That detail belongs to the agent, not to your reading list.
3. Verify the results yourself. Not the agent's summary of the results — the artifact.
4. Then confirm. When a task is claimed as done, it is most probably done, because someone checked before handing it back.

That loop is what stops the ping-pong. Without it you go back and forth with an agent — still broken, try again, nearly there — because nothing was verified before it was handed back. With it, review becomes a confirmation step instead of the beginning of the work.

And it is the honest route to more autonomy: the more of your verification you can turn into evidence a machine produces, the more you can hand over, and the more you can delegate without watching.

• All posts — the blog index, newest first
• How to use Vibeflow — the three-step workflow in ten minutes
• vibeflow tasks — every flag of the claiming command