I Stopped Reading the Code

Deep Thought ran for seven and a half million years and produced 42. By the time the answer arrived, nobody on the team remembered what they had asked.

I’ve been writing code for 41 years. I started on a Commodore 64, I’ve logged somewhere north of 90,000 hours at a keyboard, and Claude writes syntax faster and more fluently than I do. It remembers idioms I stopped caching a decade ago. It produces working implementations in languages I’ve never opened. I work with it every day. If you’re honest with yourself and you’ve been doing this for any meaningful length of time, you already know what I’m describing.

The thing I keep catching myself thinking is that the bottleneck has moved. I’m not certain, because the ground keeps shifting underneath me. What I can tell you is where I’m standing today and how I got here from where I was a year ago.

The workflow that used to work

A year ago I reviewed every line of AI-generated code. I treated the model like a very fast junior developer whose output required careful supervision. I’d read the diff, check the edge cases, verify the imports, make sure the error handling matched our conventions. I found real problems. The process worked.

Six months ago I noticed I was mostly skimming. The diffs were getting larger and the problems I found were getting rarer. I was spending thirty minutes reviewing a feature and flagging one minor stylistic issue. My time was clearly going to the wrong thing.

Three months ago I stopped opening the diffs on entire features. I started reading the architecture instead: the interfaces, the data flow, the boundaries between components, the shape of the solution. I asked whether the thing being built was the right thing. Line-by-line correctness stopped being my question.

Last month I ran my first adversarial agent against a module I had never read. The agent was specifically configured to look for exploits, injection points, auth bypasses, and broken invariants. It found three issues. I fixed two of them, negotiated the third with the team, and shipped. I have no idea what the code looked like. I still don’t.

What I’m trying to figure out

The easy read of this workflow is that I’ve stopped doing quality control. That read is wrong, and it’s the first thing I want to say clearly, because I suspect half the engineers reading this have already reached for it.

Quality control moved up a level of abstraction. I verify architecture because architecture is where category errors live, and category errors are what ship to production disguised as features. I delegate security review to models specifically trained for that work. I run adversarial agents because they are more thorough and more patient than I am at probing for exploits. The quality bar is arguably higher than it was when I was eyeballing diffs on my fourth code review of the day.

What I’m still working out is what this actually means about the job. My current working theory goes something like this: syntax fluency used to be scarce and expensive, which made it disproportionately valuable. It isn’t scarce anymore. What remains scarce is judgment about what to build, knowledge of the domain the software operates in, and the ability to recognize when an answer from a model is wrong in a way no syntax check will catch.

A model can write me a beautiful settlement function. It cannot tell me that the settlement window for this particular clearing house closes at 3:47pm Eastern and any race condition involving that boundary will cost us actual money. A model can write a clinically correct dosing algorithm. It cannot tell me that pediatric dosing for this class of drug diverges from adult dosing in ways that aren’t in the standard literature. I’ve watched both kinds of failure land on teams with syntactically perfect code.

The skill that’s left when syntax goes free is knowing the thing the software is about.

The confession that used to feel like a confession

I used to think I should be embarrassed that I’ve forgotten C# syntax I had cached for years. I thought it meant I was slipping. Somewhere in the last six months I stopped feeling that way. My productivity went up when I stopped trying to hold syntax in my head. What went up with it was the amount of time I spend thinking about the problem itself, the domain, the failure modes, the architectural implications.

There’s a version of me from ten years ago who would read this post and accuse me of dressing up a decline as a promotion. I want to acknowledge him directly. He’s right that the framing is convenient for someone in my position. Convenience doesn’t make the observation false. I watched it happen before I knew what to do with it.

The question I don’t have an answer to

How do juniors learn this way? I genuinely don’t know. A junior developer can’t evaluate model output they don’t understand. If you hand someone a working implementation and they can’t read it, they can’t learn from it.

My suspicion is that the learning path has to change rather than disappear. I think the new curriculum probably involves domain immersion from day one. The old sequence, three years of syntax drills with domain layered on later, was built for a world where syntax was the scarce resource. That world is gone. I think the new path involves reading model output as a primary teaching text, with a human explaining why the choices were made and where they could have gone wrong. I don’t know this for certain. I’m watching the first cohort of developers who learned this way move through their first jobs right now, and I’ll have better answers in two years.

If you’re running a team with junior engineers and you’ve figured out a version of this that works, I want to hear it. That’s a genuine request, not a rhetorical close. I’m actively trying to build an answer.

Where I am right now

I’m six months into a working life that looks significantly different from the one I had a year ago, and I suspect the one I’ll have a year from now will look different again. I’m not at a destination. I’m not even sure the destination is stable enough to be called one.

What I can say with confidence is that the skills I invested in for decades have been revalued. Syntax fluency, idiom recall, speed of raw production: commodity now. Judgment, domain intuition, taste, knowing which question is the one worth asking: the entire job.

Deep Thought’s team got an answer they couldn’t use because they’d forgotten the question. I spend most of my days now trying to make sure that doesn’t happen to me.

Don’t panic. Don’t assume the map you have is the one you’ll need. I’m redrawing mine while I walk it, and I suspect you are too.

First published April 17, 2026 on 42 Insights.