How Do You Trust AI-Generated Code? The Same Way You Always Did.
A junior developer recently asked me how I can trust code that AI generated. It's a fair question. My answer surprised both of us: I've been doing this for 20 years. The only thing that changed is who wrote the code.
The question
Someone more junior asked me this recently. She's starting to use AI for parts of her work and wanted to know: how can you trust code you didn't write yourself?
It's a good question. It's also the wrong framing.
Because I haven't written all my own code in decades. As a Lead Developer at DirectorInsight, I reviewed code from a team of developers building a corporate governance platform. As a Project Manager at TNO and Atos Origin, I was responsible for code produced by teams I couldn't personally audit line by line. At Zintouch, I inherited an entire codebase that someone else had written over five years, with no version control, no tests, no documentation.
In none of these situations did I read every line of code. That's not how software engineering works at scale.
What I actually did
What I did, in every role, was focus on the parts that matter most.
Architecture and structure. Does the code follow the patterns we agreed on? Is it organised in a way that will survive the next six months of changes? Are responsibilities separated cleanly?
Risk areas. Security-sensitive code gets extra scrutiny. Payment processing, authentication, data access. Anything where a bug means money, data, or trust is lost.
Fundamentals. Are SOLID principles applied sensibly? Is there unnecessary duplication? Are there magic numbers or hardcoded values that should be constants?
Integration points. Where systems connect is where things break. API boundaries, database queries, external service calls. These get careful attention.
I never reviewed code by reading every line top to bottom. I reviewed it by knowing where to look and what to look for.
AI code is no different
When Claude Code generates code for me today, I apply exactly the same judgment.
I don't read every line it produces. I look at the architecture. I check the risk areas. I verify that the patterns I've specified are followed. I pay extra attention to security boundaries, error handling, and data integrity.
The difference is that I now have better tooling to enforce my standards before the code is even written.
From code review to code specification
Here's what actually changed. When I reviewed code from human developers, my influence was reactive. I could catch problems after they were written. I could suggest improvements. But the initial decisions, the architecture, the patterns, the error handling strategy, those were made by the developer.
With AI-augmented development, my influence is proactive. I specify the standards upfront, and the AI follows them during generation.
My Claude Code Toolkit is essentially a codified version of everything I used to put in a code review checklist. It has rules for error handling that enforce RFC 9457 Problem Details and proper error propagation. Rules for data integrity that require transactions, database constraints, and idempotent operations. Rules for API design that mandate correct HTTP status codes and cursor-based pagination.
These aren't suggestions. They're loaded into every conversation. The AI reads them before writing a single line.
rules/
error-handling.md -- never swallow errors, translate at boundaries
api-design.md -- standard HTTP codes, RFC 9457, rate limiting
data-integrity.md -- transactions, constraints, idempotency
structured-logging.md -- structured fields, severity levels, no secrets
code-review.md -- verify before implementing, push back when wrong
testing.md -- real behaviour over mocks, realistic fixtures
When a human developer writes code, they might forget a database constraint or skip proper error context. When Claude writes code with these rules loaded, it doesn't forget. It might occasionally deviate, but the baseline is higher and more consistent than what I got from most junior and mid-level developers.
The honest comparison
I'll say something that might be uncomfortable: I trust AI-generated code more than code from some junior developers I've managed.
Not because AI is smarter. It isn't. It makes mistakes that no human would make. It hallucinates function signatures. It sometimes ignores instructions in favour of its training data habits.
But it's consistent. It doesn't have bad days. It doesn't cut corners because a deadline is approaching. It doesn't skip tests because "it's a simple change". And when I correct it, the correction applies to the entire session.
A junior developer who skips error handling in one place will likely skip it in three other places too. An AI agent with an error handling rule will apply it everywhere, every time.
That's not a criticism of junior developers. Everyone starts somewhere. The point is that the trust model is the same: you verify what matters, you enforce standards through process, and you accept that you can't check everything.
What you still need
None of this works without experience. The reason I can review AI code efficiently is the same reason I could review human code efficiently: I know where bugs hide. I know which patterns lead to problems at scale. I know what "this looks fine" means versus "this will break in production".
If you're a junior developer, you can't shortcut this. Using AI to generate code you don't understand is not AI-augmented development. It's outsourcing to a colleague you can't evaluate.
The path is: build your own understanding first, then use AI to amplify it. The trust comes from your ability to judge, not from the AI's ability to generate.
The toolkit as a trust system
My toolkit has three layers that mirror how I built trust in human teams:
Prevention (rules and CLAUDE.md). Standards that are enforced before code is written. Like onboarding documentation and coding guidelines for a new team member, except the AI actually reads them.
Detection (review and test skills). /review runs structural analysis on changes. /test scopes tests to affected code. /pre-merge orchestrates all checks before code reaches the main branch. Like a CI pipeline combined with a code review, automated.
Safety nets (hooks). hook-block-destructive.sh prevents force pushes, rm -rf, and DROP TABLE. hook-auto-approve-bash.sh streamlines safe operations. Like branch protection rules and deployment gates, but at the development level.
This is not revolutionary. It's the same layered trust model that every mature engineering team uses. The difference is that it's codified in a way that works with an AI agent instead of a human team.
The real answer
How do you trust AI-generated code?
The same way you trust code from any developer you manage: you set clear standards, you focus your review on what matters, you build systems that catch mistakes, and you accept that perfection is not the goal. Reliability is.
The question "how do you trust AI code?" is really the question "how do you trust code you didn't write yourself?" And if you've been a Lead Developer, a Tech Lead, or a Project Manager, you already know the answer.
You've been doing it for years.
Kort samengevat: een junior developer vroeg me hoe ik AI-gegenereerde code kan vertrouwen. Mijn antwoord: op precies dezelfde manier als hoe ik 20 jaar lang code van mijn teams beoordeelde. Niet door elke regel te lezen, maar door te weten waar je moet kijken, standaarden vooraf vast te leggen, en systemen te bouwen die fouten opvangen. Met mijn Claude Code Toolkit zijn die standaarden nu vastgelegd als regels die in elke AI-sessie worden geladen. Het resultaat: consistentere output dan wat ik van de meeste junior developers kreeg, met dezelfde review-aanpak die ik altijd al gebruikte.
Jan Keijzer is a senior software engineer with 30 years of experience building mission-critical systems. He uses AI-augmented development to deliver software with the reliability standards of enterprise environments. His Claude Code Toolkit is open source.