Building for Bob
The form of a user
It is one in the morning. The feature is almost done. Bob has built features like this before. He knows how to do it by hand. But hands are slow, so tonight he is working with an agent inside a coding harness.
Extend the feature, he writes.
Done, it says.
He checks. It is good. Really good. For a moment, Bob forgets he was ever going to do this by hand.
Now tweak this part.
On it.
He checks again. Something is broken.
That broke it.
You’re right. Fixed.
Still broken.
You’re right to push back — and that matters, it says. Still wrong.
Bob has stopped reading the replies. The thought arrives on its own, quiet and final:
I don’t trust you.
He does not close the agent. He keeps it open. He just stops taking it at its word.
From here on out, the agent is still useful. It just no longer gets to say what counts as done. Its output can still help him work. But it can no longer tell him when the work is done. Every answer has to be checked by hand.
That is the disorder, and it is easy to miss because nothing crashed. The work got faster. The trust did not keep up. Bob now has more output than he can stand behind and the same single pair of eyes he had before.
The session was full of completion.
Done.
Fixed.
You’re right, and that matters.
Each reply looked like an answer. None gave Bob anything to stand on.
That failure was almost merciful: the code was broken, and broken code announces itself. Bob saw it, named it, worked around it. The coding harness made the loop quick; the agent was steered. Broken code is not the hard problem.
The hard problem is the change that looks right.
The tests pass. The diff reads cleanly. The agent is confident. Bob ships it because “it looks right and the tests pass” is often all a tired developer has.
Nothing explodes. That is why it is dangerous.
A shipped change is not only new behavior. It is a set of claims the codebase now carries: this path is covered, this retry is safe, this edge case cannot happen, this refactor preserved behavior.
If Bob does not name those claims when he accepts the change, they do not disappear. They settle into the repository as assumptions.
Months later, another change builds on them. A guard is removed. A test is narrowed. A retry path is reused somewhere it was never meant to run. The old claim is still there, but its grounds were never recorded.
That is how AI-assisted work bites late: not only by breaking code now, but by leaving unexamined claims for the future to inherit.
A passing test is real. A fluent summary is useful. A confident reply feels like progress. Each can resemble a finished, trustworthy thing without becoming one.
Fast machines are excellent at resemblance.
An agent does not only write code. It makes claims about the code.
The feature works.
This is safe to ship.
The tests cover it.
The edge case is handled.
The refactor preserves behavior.
Every agent session leaves behind a small pile of claims. Some are explicit. Some are implied by the diff. Some are hidden inside the words done and fixed.
Bob answers for all of them.
That is the whole of it, in one sentence:
The agent changed the code; Bob inherited the claims.
Every claim asks for acceptance. Acceptance creates responsibility.
An agent can produce a week of work in an afternoon, and the afternoon’s work still has to be accepted by someone before it ships. That someone is not the agent. The agent can help generate, inspect, summarize, and repair. It can even gather evidence. But it does not carry responsibility for the change.
Bob does.
And Bob does not need more reassurance. He needs grounds for acceptance.
He needs to know, for the one change he is about to ship: what is being claimed, what the claim rests on, what evidence stands behind it, who or what is allowed to count that evidence, and what is still missing.
None of the confident answers told him that.
There is an older name for what went wrong. A thing can resemble trustworthy software without participating in what makes software trustworthy. The plausible diff imitates the careful one. The fluent summary imitates review. The passing test imitates coverage. Imitation is cheap and convincing. Participation is harder.
Resemblance is not grounds.
Back in the repository, this stops being philosophy.
A change is not just a patch. It is a set of claims made against a particular state of the codebase. To trust the change, Bob needs to inspect those claims.
The usual instruments help, and none of them finishes the work.
A test proves what it was written to prove, which may not be the thing Bob cares about.
A summary orients, but it is not authority.
A command log records what happened, but it does not say what the result is allowed to mean.
A dashboard can organize facts, but it can also ask Bob to scan a hundred things when judgment needs one.
A score answers too quickly. It trades the question Bob actually has — what makes this safe to ship? — for a number that has forgotten the question.
The question Bob has is narrower than a dashboard and harder than a score:
What makes this claim acceptable?
This is where Arch begins.
Not as an oracle.
As a compiler underneath, and a workbench at the surface.
Underneath, Arch compiles the materials of acceptance — the claim, the repository state, the contract, the evidence, and the unresolved gaps — into inspectable records.
At the surface, Bob does one small thing: inspect one AI-assisted claim in one guarded local repository.
Take a claim from Bob’s session:
The tests cover this behavior.
Arch makes that claim visible. Then it places the grounds beside it.
The source basis: not “the repo,” but the files, symbols, and commit the claim depends on.
The evidence: not “tests passed,” but the run, the test cases, and the assertions that exercise the behavior.
The authority: not the agent’s confidence, but the rule or source that allows that evidence to count. Maybe a project policy. Maybe a CI requirement. Maybe a maintainer-approved convention. Maybe an architectural decision record. Maybe a local rule checked into the repository.
The audit trail: what happened, by whom or by what, against which repository state.
And the gap: the branch nobody exercised, the invariant nobody checked, the edge case still resting on belief.
A grounded review record might look less like a verdict and more like this:
Claim: the tests cover the retry behavior.
Basis: MessageSender, RetryPolicy, commit abc123.
Evidence: test run 42, including timeout retry and max-attempt assertions.
Authority: repository rule requiring changed delivery behavior to have integration coverage.
Gap: no test exercises partial delivery before retry.
That last line is the point.
Arch should not tell Bob the tests are enough. It should not pretend to prove the empirical truth of the claim. It should not turn uncertainty into a green check because green checks feel good at one in the morning.
Arch does something smaller and more useful: it makes the contract around the claim visible.
The contract says what the claim depends on, what evidence may count, what rule admits that evidence, which repository state is being judged, and what remains unresolved.
Where the support is missing, Arch should show the gap instead of filling it with a confident guess.
When a next action is allowed, that action should stay bounded: gather the missing evidence, or record why the gap remains.
The agent is confident.
Arch is honest.
That distinction matters because Bob is tired. Any tool that offers him certainty when he is tired is selling the same fluency that got him here.
Arch cannot read the agent’s reasoning and rule it sound. It cannot promise the feature is bug-free. It cannot make responsibility disappear.
Sometimes, after everything is laid out, the honest result is:
Not proven yet.
That is not the tool failing. A gap shown plainly is worth more than a green check that hides one.
Take Bob back to the same diff and the same tired eyes. Nothing has made the work certain. But now he can name the claim he is about to ship. He can see what stands behind it. He can see what does not. He can decide with the grounds in front of him instead of the agent’s confidence ringing in his ears.
He might ship it.
He might hold it.
Either way, he can say why.
You do not regain trust in a codebase all at once. You regain it claim by claim.
Bob is the developer after the agent leaves.
Bob is still responsible.