Today I was working on a project that was completely vibe-coded. Not one line was written by me or by any other developer. Every file, every function, every commit came from a single AI coding agent: Claude Code. That raises a question every business shipping AI-generated code now has to answer: who actually verifies it?

Then a critical bug showed up. The kind of bug that makes you stop and stare at the screen. So I asked the agent a simple question: how could anyone in their right mind write this code?

The answer was honest, and a little funny. It agreed with me completely. This code was wrong.

The Investigation

Curious, I asked it to dig deeper. Was there a reason behind this? Who wrote it, and why?

It went through the git history and came back with a confident verdict: the commit was under my name. So, according to the evidence, I was the one who wrote that code.

I told it that the only developer who has ever worked on this project is you. It didn't accept that. The git log said otherwise.

And I sat there, genuinely amused. Because I have seen this exact scene many times before, with humans.

The Oldest Ritual in Software Teams

I've been building for the web since 2008, and in every dev team I've worked with, the blunder always belongs to someone else. Production breaks. Everyone opens the file. Everyone agrees the code is terrible. And then, slowly, every finger points somewhere else: the developer who left last year, the freelancer, the "quick fix" from another team.

Nobody wrote the bad code. It just appeared.

I didn't expect to see that ritual reproduced by a coding agent. But here we are.

Why the AI Coding Agent Actually "Blamed" Me

To be fair to the machine, it wasn't lying. It was doing exactly what a new developer on the team would do: trusting the evidence in front of it.

Here is what really happens in an agent-driven project:

• The agent writes code and commits it using your git identity, because it runs on your machine with your config.
• Each new session starts with little or no memory of what previous sessions did.
• So when it runs git blame, it sees your name, and it has no way to recognise its own past work.

In other words, the authorship trail is broken by design. That is a funny story. It is also a serious problem.

So Who Verifies AI-Generated Code?

This is the real question, and it matters for every business now shipping vibe-coded products.

If an AI writes the code, the same AI reviews the code, and the same AI investigates the bug, then nobody has actually verified anything. You have one system grading its own homework, and forgetting it did the homework in the first place.

The agent was quick to agree the code was wrong once I pointed at it. It did not catch the problem when it wrote it. That gap, between writing code and knowing what good code looks like, is exactly where experience lives.

Verification needs someone who:

• Can read the code and understand why it is wrong, not just that a test failed.
• Knows the business context the AI never had.
• Takes responsibility when it breaks, instead of pointing at git blame.

That person is not optional. AI has made writing code cheap. It has not made judgement cheap.

Leave Notes for Your Memento Developer

A coding agent is like the man in Memento: brilliant, fast, and unable to remember yesterday. Without notes, he investigates his own crime and concludes someone else did it. That is exactly what happened to me.

So the first half of the fix is simple: every piece of AI-written code must be traceable, and its reasoning must be written down.

• Mark AI authorship in git. Use co-author trailers or a clear commit convention, so history tells the truth about who (or what) wrote each change. git blame should never point at a human for code a human never touched.
• Document the why, not just the what. Ask the agent to record why it chose this approach, what alternatives it rejected and what assumptions it made, in the commit message, the pull request or a decision log. Code shows what was done. Only the reasoning shows what it was thinking.
• Keep a project memory file. Architecture decisions, business rules and known pitfalls live in the repo, and every new agent session reads it first. Every session is the agent's first day on the job, so give it an onboarding document.

Now when a bug appears, you can open the notes and say: you wrote this, on this date, for this reason. And you can see exactly where the reasoning went wrong.

But Notes Are Not Verification

Here is the trap. If the AI writes the code and writes the explanation, the explanation can be just as wrong as the code. An AI can produce a confident, well-formatted justification for a bad decision. Documentation only records what the AI believed. It does not tell you whether it was right.

That is the second half of the fix, and it is the part no tool replaces:

• Human review on critical paths. Payments, authentication, data handling and anything customer-facing get read by an experienced engineer before merge, with the AI's reasoning right next to the code.
• Tests written from requirements, not from the code. If the AI writes both the code and the tests from the same misunderstanding, both will pass together.
• One accountable owner. Not "the AI". A person.

If you're planning how AI fits into your development process, this is exactly the kind of setup we work through in our AI consultation sessions.

The Blame Game Doesn't Change. Accountability Has To.

I will keep using coding agents. They are incredibly productive, and I've written about why real engineers shouldn't be loyal to any single model in Real AI Engineers Aren't Married to One Model.

But this small moment taught me something. Whether the developer is a person or an agent, the code will eventually break, and someone will look for someone else to blame.

AI will keep writing more of our code, and it will keep forgetting that it did. So leave it notes: traceable commits, documented reasoning, a project memory it reads every session. But notes only tell you what the AI thought. Someone who has been doing this for years still has to decide whether it was right.