How a run is proved, before you keep a line of it

The hardest problem with an agent that writes code is not getting it to write code. It is knowing whether what came back is any good — and “done ✓” at the bottom of a transcript is not knowing. It is the model grading its own homework, in prose, with no penalty for being wrong.

So 8code does not ask. After every code run it puts the result through four checks that the model has no hand in. They are the same four for every agent you drive: a run from a free HTTP model gets exactly the scrutiny an Opus run gets. Nothing merges into your working tree until you have looked at them and said so.

1. The diff — what actually changed

   Code runs happen in an isolated git worktree: a private copy of your repository on its own branch. Your checkout is not touched, at any point, until you decide it should be. That is not a safety wrapper bolted on afterwards — it is where the agent lives for the whole run, which is why it can be allowed to run commands at all.

   When it finishes you review the change as a change: the full diff, per file, or per hunk. Keep applies exactly what you selected and nothing else, left unstaged so the commit is still yours to write. Discard deletes the lot, and your repository is where it was.

   What you get: a reviewable diff you chose to accept, hunk by hunk — never a surprise commit.

2. Tests — does the logic still hold

   Once the agent is done, 8code runs your project's own verify command inside that worktree — npm test, then the build, then make test, whichever your repository actually has. Not a test harness we invented, and not one the model wrote to make itself look good.

   The result comes back as an independent pass / fail card with the tail of the real output attached, sitting beside the diff. If the suite goes red, you see it red.

   The model's “done ✓” is a claim. This is evidence.

   What you get: a pass or a fail from the suite you already trust, run by something other than the author of the change.

3. Diagnostics — did it introduce new problems

   A green suite is not the same as a clean change. So the project's own checkers run too — tsc, eslint, ruff, whatever the repository configures. 8code never installs a linter of its own; if your project has no checker, this gate is silent rather than opinionated.

   The important part is that they run twice: once on the change, and once on the untouched baseline. Only the problems the change introduced are shown to you. A repository with four hundred pre-existing warnings does not drown the one warning that is new, and errors that merely shifted to a different line number never nag.

   What you get: the delta, not the backlog — new problems attributable to this run.

4. Pixels — does it actually render

   For web work, passing tests can still ship a blank page. Verify opens the result in the built-in Preview browser, screenshots the real rendered page, and sends that screenshot back to the same model in one bounded follow-up: fix what is visibly broken, or certify that it is not. One pass, not an open-ended loop.

   It is off by default and lives in Settings, for an honest reason: it costs a model run, and you should be the one deciding to spend it.

   What you get: an image of the page as a browser drew it, and one model turn spent on what it shows.

Then it is yours to ship

The gates advise; they never merge. Once you have read them there are three ways out of a run, and all three keep the decision on your side of the line.

Three rules the gates are built on

• Advisory, never blocking. A red card does not stop you keeping the diff. It is there to inform the decision, not to take it — an agent tool that refuses to hand over your own code has misunderstood whose repository it is.
• Uniform. The same four gates for every vendor's model. When you are mixing five agents in one window, the only referee worth having is the one with no stake in which of them wins.
• Local. All four checks execute on your machine, against your repository, with your tools. Nothing about the checking leaves the box.

Why four and not one

Each gate catches a failure the others cannot see. Tests miss a change that is correct and unreviewable. The diff misses a change that reads beautifully and breaks the build. Diagnostics miss a page that compiles and renders blank. Pixels miss the regression three modules away. Four cheap independent checks beat one clever one, and they are cheap precisely because they are not ours — they are the repository's own verify command and the repository's own linters, pointed at a copy of the repository.

There is a longer-run reason too. A run that passed four checks and one that failed on diagnostics are not the same event, and recording which is which is the beginning of measuring whether an agent is any good at your work — the thing the rest of 8code is being built toward.