How I keep coding agents honest.

Why this matters

The danger with AI-generated code is not that it is always bad. The danger is that it can look finished before it has earned trust. A clean explanation, a big diff, and a confident summary can create the feeling of progress even when the actual change is too broad, under-tested, or based on the wrong assumption.

So I try to treat agent-written code the same way I would treat a pull request from another engineer: useful, but not automatically correct.

The pattern: separate creation from validation

The most useful pattern in my skills repo is simple: the agent that creates the artifact should not be the only agent that validates it.

For example, my plan-work skill writes a durable plan, then sends only the absolute plan path and repo root to a fresh plan-validator subagent. No chat history. No hints. No summary of what the first agent meant. The validator reads the plan cold and cross-checks its claims against the actual codebase.

The same pattern exists for explanations. The explain-code skill drafts a markdown explanation, then an explain-verifier fact-checks every concrete claim: file paths, functions, behaviors, data shapes, library versions, and even Mermaid diagram arrows.

Validate the plan at <ABSOLUTE_PATH_TO_PLAN_MD>.
Repo root: <ABSOLUTE_PATH_TO_REPO_ROOT>.

Read the plan cold. Cross-reference against the codebase.
Return your structured findings report.

That cold-read constraint matters. If the validator inherits the same conversation, it inherits the same blind spots. Keeping it separate is how I make agents disagree productively.

My review checklist

1. 01

   Scope. Did the change solve the request, or did it wander into cleanup, refactoring, or speculative improvements?

2. 02

   Simplicity. Is this the smallest reasonable solution, or did the agent introduce a new abstraction because it could?

3. 03

   Assumptions. What did the agent assume about the data, API, user flow, framework, or project conventions?

4. 04

   Verification. Is there a test, build, screenshot, reproduction, manual check, or independent validator report that proves the change works?

5. 05

   Ownership. Would I be happy to maintain this code later without explaining that an agent wrote it?

Things I distrust

A big diff is not automatically wrong, but it needs to justify itself. The more files an agent touches, the more careful I become. I especially distrust changes that make the code look more impressive while making the actual behavior harder to reason about.

The same goes for explanations. I want the explanation to point to evidence: files read, tests run, errors reproduced, edge cases checked. Confidence without evidence is just decoration.

What good agent work feels like

Good agent work usually feels boring. The agent reads the relevant files, names its assumptions, changes a small number of lines, removes anything it made unused, and tells me exactly how it verified the result.

A good final answer includes:
- what changed
- why it changed
- what was intentionally not changed
- what command or manual check verified it
- any remaining risk or tradeoff

That kind of output makes review easier because it separates facts from vibes. It also makes it easier to reject the work. If the verification is weak or the tradeoff is wrong, I can send the agent back with a specific correction instead of starting over.

The loop I want

1. 01

   Ask for the smallest plan. Before implementation, make the agent explain the narrowest safe path.

2. 02

   Validate the plan cold. For non-trivial work, send the written plan to a fresh validator subagent that has to read the repo and cite evidence.

3. 03

   Let it implement. Use the agent for the mechanical parts, but keep the scope fixed.

4. 04

   Review the diff. Check correctness, security, TypeScript quality, naming, patterns, and whether changed files match the surrounding code.

5. 05

   Tighten or reject. If the diff is too broad, make it smaller. If the assumption is wrong, throw it away.

The professional standard

Using coding agents does not lower the bar. If anything, it raises the bar for review. More code can be produced in less time, which means taste, restraint, and verification matter more.

The standard I want is simple: if the code ships under my name, it should feel like code I chose. Not code I passively accepted because the agent was fast.