ClaudeFolio
Lessons

We stopped writing the code. Now we’re starting to stop checking it too

Edward Kwun··4 min read
We stopped writing the code. Now we’re starting to stop checking it too

See more of our writing in your Google results.

Key points

  • We delegated research, then coding, and recently the checking too
  • The first two cost knowledge, the third hides that cost
  • Two models share training data, so their reviews are correlated not independent
  • Searching built source judgment, writing code built your mental map
  • Checking built the flinch that tells you something is wrong
  • Read the diff anyway, since it is the only human step left

First we stopped actively searching and looking things up. Why open six tabs and work out which source is credible when you can ask an LLM and get an answer? Then we stopped writing the code. Why type it when you can describe it. And then, recently, quietly, we stopped checking the code, because you can hand it to a second model and ask that one whether the first one did a good job.

Each step humans are getting lazier, but the third one is different from the other two.

Every step was a reasonable trade

Research first. The old way was not time consuming but it was also fun at first. It was six tabs, four of them SEO sludge, a forum post from 2011, and twenty minutes to find a paragraph someone could have just told you. Getting the answer from an LLM is a genuine improvement for the most part, besides the fewer clicks to your website part of course.

Writing code, same thing. Most code is not interesting. It is the fourth CRUD endpoint this month, the form validation, the migration. Handing that over is how one person now ships what used to need three, and I have argued that full reliance is fine as long as you can tell when the output is wrong.

Which is where the third step is different.

Checking was the last thing holding it together

I wrote a post recommending you have one model review another model's code. I still think that advice is correct. Two models have different blind spots and the second one catches real things the first one missed.

It is also the last link in a chain that now runs end to end without a person involved. The AI writes the code. A different AI reviews the code. You read a summary that says it looks good and you click approve. At no point did anyone who will be responsible for that code actually look at the code.

The first two delegations cost you knowledge. This one costs you the ability to notice that the first two cost you anything. Verification was the checkpoint where a gap in your understanding used to become visible, because you would sit down to check the work and discover you could not follow it. Delegate the checking and that signal never fires. You feel fine right up until production disagrees.

And the failure mode is specific. Two models can also share a blind spot. They may have trained on overlapping data and they make correlated mistakes, so a confident review is not independent evidence in the way a second human would be. It reads like a second opinion and it is closer to the same opinion in a different font.

What we actually lose

Not intelligence, and not in some vague way. Three specific things, and they are all skills of judgment rather than recall.

Searching taught you to weigh sources. Sifting six results and deciding which one to trust is the entire skill, and it transfers to everything: reading a contract, evaluating a claim, sensing when a confident stranger is out of their depth. Asking one oracle and accepting the output does not build that muscle, because the sifting already happened somewhere you cannot see.

Writing code taught you the shape of your own system. Not syntax, which genuinely does not matter much anymore. The map. Knowing what talks to what and where the data goes is what lets you guess correctly at 2am about which service is lying to you, and you mostly build that map by having typed the thing.

Reviewing and checking taught you what wrong looks like. This is the one that only comes from reps. After enough bad code you develop a smell for it, a flinch at the function that is doing too much or the error handler that swallows everything. Catching a hallucination is a detection skill, and detection is built by exposure. Outsource the exposure and the flinch never develops.

The version of this I would actually defend

What I would keep is narrow. Read the diff before you approve it, even when a second model already blessed it, because that is thirty seconds and it is the only moment the chain touches a human. Understand the project even if you never understand every line, meaning what talks to what and where the data lives. And notice when you cannot follow something, then treat that as information rather than a thing to route around, since routing around it is precisely how the gap gets permanent.

The chain works fine while nothing goes wrong. The question is only ever what happens on the day something does, and whether the person responsible has any way in. There is research now on what this does to people over time, and it is not encouraging, though it does suggest the effect reverses when you re-engage.

I still let it write most of my code. I read the diffs.

Found this article useful?

Add ClaudeFolio as a preferred source on Google to see our articles first.

FAQ

Why is it risky to let AI review AI-generated code?
A second AI can catch real mistakes, but both models may share blind spots, so an AI review should supplement rather than completely replace human review.
Should you still read code if Claude Code or another AI wrote it?
Yes. At minimum, read the diff before approving changes so you understand what changed and have a chance to catch problems the AI reviewer missed.
Can two different AI models make the same coding mistake?
Yes. Different models can make correlated mistakes or share blind spots, so agreement between two models does not guarantee that the code is correct.

Related posts

Comments