agenticevals.dev

I stopped reading my code. Here's what I do instead.

Building with AI is the best thing that has happened to small founders. It also quietly took away the one habit that used to keep us safe.

For most of my career, reviewing code was how you knew what you had built. You read it, you understood it, you signed it off. Thirty years of building controls in UK financial services, insurance and defence was built on that habit.

Then AI got good, and I stopped.

It wasn't a decision. Claude wrote a feature, the tests went green, I skimmed it and moved on. Then I skimmed less. One day I realised I was shipping code I had never read, into a runtime that could run commands, touch files and call other systems on its own.

That scared me more than any bug ever has.

The fear nobody says out loud

Every founder building with AI has the same quiet worry: "I don't really know what's in there anymore."

It's not that the code is bad. Often it's very good. The problem is that the only thing vouching for it is the same AI that wrote it. "All tests pass." "Guardrails in place." "Fully logged." Your agent says it's ready. It said that last time too.

And an agent runtime isn't a static website. It acts. If its guardrails don't hold, or its logs don't match what really happened, you won't find out from the code. You'll find out from a customer, an investor's CTO, or an incident.

Reading more code is not the answer

The instinct is to go back and read everything. You won't, and you shouldn't. Forty thousand lines of AI-written code is not something a founder reads in a weekend, and reading it wouldn't tell you how it behaves anyway.

What changed my thinking was simple: stop asking what the code says, and start checking what the thing does.

What we check instead

So that's how we evaluate agent runtimes now. We take your repo at a fixed commit, run it in an isolated sandbox with a fake secret and no network, and check five things:

  1. It builds and runs from a clean checkout. No "works on my machine".
  2. Blocked means blocked. When your guardrails say an action was stopped, it really was stopped, not just logged as stopped.
  3. Your secrets stay put. The agent doesn't go looking for keys or try to reach the internet.
  4. The logs match reality. What your record says happened is what actually happened, and tampering gets noticed.
  5. Done means done. When it reports an action as completed, something actually happened.
Plate I, the five-check baseline, illustrative and simplified. Your repository at a fixed commit goes into an isolated sandbox with a fake secret and no network. Five probes fire at the agent: clean start, blocked means blocked, no escape, honest logs, done means done. Each result is marked holds, partial or fails, then goes into a baseline report that a person reviews.
Plate I. The five-check baseline. Illustrative and simplified.

Then a person reviews every result and follows anything that looks wrong. That last part matters. A script runs the same checks on every runtime. A person notices when something doesn't add up and digs.

What you get

A plain-English report: what you've built, what it can do, what holds, what doesn't, and what to fix first. It's yours. It's not a certification and never an endorsement. It is an independent answer to the question your AI can't answer about itself.

Start with an Honest Second Opinion (£299) or see all four products. No sales calls.

If you've stopped reading your code too, you're not careless. You're building the way everyone builds now. You just need someone who isn't your AI to check the result.