Staying in control of a coding agent, without watching it all the time

Delegating is not abandoning

Two extremes threaten anyone working with a coding agent. Approving every one of its commands means doing its job for it. Letting it do everything alone means discovering the result too late. In between, there are a handful of moments where your opinion truly changes what happens next: what you want, the plan, the result and the delivery.

Treelab places your decisions at those moments, and only there. The home page publishes the minimum number of actions counted on a demonstration project; the rest, plans, code, tests, review and next sessions, the agent handles.

The moments where you decide

Scoping: you answer grill-me’s questions and confirm the summary. This is where everything is decided, because a well-scoped task avoids most corrections later.

The plan: before each lot, the agent proposes its plan, with the objective and the completion criteria; you approve or correct it. Nothing is coded before your approval.

The trial: after the last lot, you try the result yourself. This is the acceptance trial: lab acceptance records your approval, tied to the revision you tried; if the code changes afterwards, the trial must be repeated.

The closing: lab close delivers and removes the worktree only after your explicit confirmation, which names the worktree. A command typed too fast is not enough to remove everything.

$lab next project-1 feature-3LANE_PHASE=in acceptancelab: Work finished — to try together. The lane feature-3 stays open.$lab acceptance project-1 feature-3 --accept --evidence 'dark mode tried on every page'ACCEPTANCE=validPUSH=ok

What protects the work in between

Between your decisions, the agent runs commands. Before each one, a hook reads what it is about to do. Common destructive operations are refused by default: git reset --hard, git clean -f, a forced push to a protected branch, rm -rf outside the worktree, a commit on the main branch from the main checkout, a raw deployment.

The refusal is not a wall: the hook names the safe alternative, and the agent carries on that way. You are not disturbed for an operation it should not have run.

It is a closed list of common operations, not a sandbox: your agent’s permissions remain yours, and its own permission requests continue according to your settings. The security page details this scope.

Require evidence, not promises

“Done” is not enough. Each lot ends with evidence: the command run, its exit code, the result and, for a fix, the test seen failing before it turned green. It is written in the lot document and in its proof report, readable weeks later.

A review by an agent that did not write the code reads the diff against the document. It does not judge style: it looks for what is wrong or out of scope. Its findings are fixed, each with its test, before delivery. And when a criterion cannot be met, the agent says so in the log, with the reason, instead of hiding it.

Screens count too: when a lot touches an interface, it is checked in a real browser, at the sizes the document lists, and not only by automated tests.

Follow without watching

You do not need to watch the agent work. lab plan shows the progress of all your worktrees; lab status details a branch, a lot, a session or a pull request. Both are recomputed from the documents at each display. Neither changes anything: they only read the documents and the repository, so you can run them as often as you like, from any tab.

When a session stops, nothing is lost: the handoff says where to resume, and lab next relaunches the agent at the right place, in the same tab.

When something goes wrong, lab doctor checks the installation and the context, and says what to fix. lab doctor --report prepares an anonymised diagnostic without sending anything: you choose to share it.

Building trust step by step

Trust is built lot after lot. On a first task, read the documents, look at the log, reread the review: you will see what the agent proves and what it leaves aside. After that, you can stick to the decision points and the evidence.

When evidence is missing or a result surprises you, say so at the trial: a refusal records your feedback, and the next correction lot starts from there, with its own document and its own completion criteria.

The most direct lever remains scoping: what is made precise at the start does not have to be corrected at the end, nor explained again at each new session.

What the method does not do

It does not replace your judgement: a badly chosen completion criterion will be proven all the same. It does not guarantee defect-free code: the checks depend on what your repository tests. And it does not provide the agent: you need access to Claude Code or Codex, chosen per worktree, with no affiliation between Treelab and either.

What it does is make every decision explicit and every delivery verifiable. For splitting work into lots, read the guide to the lot method; for working on several tasks at once, the one on worktrees; for the vocabulary, the glossary.