High Desert Technologies

Writing

Caring About Code Is Becoming a Coping Mechanism

2026-07-18 — I've been a developer for 25 years. I haven't read a line of my own codebase in three months. It's going great, and that's the problem.

machine code compilers managed runtimes the cloud frameworks AI agents ?
The stack has been rising for seventy years. We keep moving up.

The confession

I've been a software developer for twenty-five years. I work as a consultant doing daily architecture/design and coding on several large, enterprise projects, and I also run a production SaaS with paying customers, real revenue, and regular deployments.

I haven't read a line of my own codebase in over three months. The code window is now reserved entirely for claude.

Claude plans the design, and agents write the implementation. No diff skimming, no spot-checks, no nothing. Instead, my time is now spent reviewing the evidence around each change: are there tests and did they pass, did the architecture rules pass, and most importantly, what happened after deployment, does the product work?

The product ships regularly, things work, revenue is growing, and customers are happy. I care deeply about the product. I've just stopped caring about the code itself.

Ten years ago, hell even 3 years ago, I'd have called that malpractice. Today, it's just a Tuesday. The gap between those two realities is why I wrote this - because I think most of our industry is still living in that first one.

Protecting the product or ourselves?

Watch what actually happens when a team reviews AI-written code. The scrutiny is unlike anything we apply to each other. Every line inspected. Every variable name debated. Every comment scrutinized. Every test case questioned. We say the word "quality" a lot while we do it.

When a senior engineer you trust ships a change, do you read every line? Nope. You read the shape of it — the tests, the interfaces, whether it touches anything scary. You extend trust because they've earned it, and reading every line would be an insult and a waste of an afternoon.

Something's now writing pretty decent code, 10x faster than you or I ever could, around the clock, without getting tired or bored or precious about it. That's an uncomfortable thing to sit with when code is how you've defined yourself for a career. So we respond the way you do with the smarter, faster new kid: you inspect their work the hardest. Of course, some of that is diligence, though I think a lot of it is more a coping mechanism — control as a way of staying necessary.

There's a simple way to tell which one you're doing. If the agent's defect rate on some class of change dropped below your team's, would you actually review those changes less? If no measurement would ever make you read less, that isn't quality control. That's ritual.

I get to say this because I did it too, I'm just further along in accepting where this is going.

An entire industry using a thing it won't trust

This isn't me theorizing about other people's psychology. The survey data from the last year shows an industry stuck in exactly this bind.

Stack Overflow's 2025 survey put AI tool use at 84% of developers, with 51% of professionals using them daily. Google's DORA report measured 90% of tech professionals using AI at work, at a median of two hours every day. Adoption is no longer the question.

Trust went the other direction. In that same Stack Overflow survey, 46% of developers distrust the accuracy of AI output versus 33% who trust it — and the share who "highly trust" it is 3.1%. DORA found the same contradiction and named it the trust paradox: 30% trust AI-generated code a little or not at all, over 80% say it made them more productive, and they use it anyway, daily. An entire profession is shipping with a tool it doesn't believe in.

The companies employing those developers moved faster than the trust did. Sundar Pichai told investors in April 2025 that well over 30% of Google's checked-in code comes from accepted AI suggestions; by February 2026 Google's CFO was saying about half their code is written by coding agents. Even at Google, AI-generated code is still described in terms of the engineers who review it. Review is still the psychological line separating assistance from autonomy.

METR ran a randomized controlled trial with experienced open-source developers working in their own mature codebases: with AI assistance they took 19% longer — while predicting a 24% speedup going in, and still believing in a 20% speedup after it was over. The tools have improved since early 2025, but that's not why the result matters. It matters because it shows we're pretty unreliable in describing our AI transition. Those developers felt faster while being slower. So when you feel certain that your line-by-line review of AI output is where your value lives, how much would you bet on that feeling?

How fast this flips

Last year, using AI almost cost me a job. The company I was interviewing with nearly rejected my coding project, (and me) because it looked too perfect. They (correctly) assumed I'd used AI — nothing in the exercise prohibited it — but at the time, heavy AI use read as evidence that I'd skipped the real work. The product worked perfectly.

Less than a year later, everyone there is using it, and the organization is now building its own internal library of shared Claude skills. That whole transition — suspicious, then tolerated, then normal, then official infrastructure — took about 8 months.

This isn't moving at the speed of a normal tooling transition. Capability is compounding fast enough that a practice considered irresponsible today can become standard operating procedure before the organization finishes writing a policy for it.

The part where the control crowd is right

The control crowd isn't wrong about everything. The skeptics are right when they say AI still produces bad code. Where I disagree is on the response to that — keeping code inspection at the center of engineering isn't it.

The quality worries aren't invented. GitClear analyzed 211 million changed lines and found copy/pasted code exceeding refactored code for the first time in their dataset's history — churn up, refactoring down, code clones up roughly 4x since 2020. The skeptics are seeing something real. The mess is real, and it's compounding.

I'm making a bet about that mess: capability compounds faster than the debt does. The same agents generating clone sprawl today will refactor it for pennies tomorrow — large-scale mechanical refactoring against a passing test suite is exactly the kind of well-specified work they're best at. If churn keeps climbing and that refactoring never shows up, I was wrong and the control crowd gets to say so.

Any team without guardrails gets wild. That's not an AI problem; that's a team problem. You don't give a new hire production access on day one, and you shouldn't give a language model production write authority on any day. Here's what that means concretely in my shop:

The obvious hole in all of this: tests prove the behavior you expected is there. They say nothing about behavior you never thought to look for. A subtle tenancy leak sails through all 966 tests if none of them were written to catch it, and line-by-line reading is genuinely the best tool for that kind of defect. I know. I'm accepting that risk with my eyes open, the same way I accepted it for twenty years as the sole reviewer of my own code at 11 PM, tired, and biased toward shipping. The bounded write path and the cold-read release reviewer cover most of it. Not all of it. If you're holding payment credentials or health records, you might have different concerns and still read your fair share of code.

None of those controls make the code elegant. That's not what they're for. They make the product safer to operate and they make failures visible.

So yes: constraints, boxes, hard limits. I'm not anti-control. I'm asking a different question — where should the control live, and for how long?

What I actually care about

I didn't stop reading code because I found a better way to admire its quality. I stopped because code quality isn't the outcome I care about.

I care about the product. Does it do what it's supposed to do? Is it secure? Is it reliable? Can I change it quickly when the product needs to change? Can the system that built it keep maintaining it? Those are the outcomes I care about. I don't care whether the implementation is elegant, whether it follows the architecture I'd have picked, or whether another developer would enjoy reading it. I really don't care what the code looks like.

The machine can use conventions I dislike. It can produce code I'd call ugly. Eventually it may build an architecture I'd never have designed. As long as it can understand that system tomorrow, modify it safely, prove the behavior still works, and keep it secure, the internal shape of the code doesn't matter to me. Human-readable code mattered because humans had to maintain it. If machines become the primary maintainers, optimizing the codebase for human comprehension stops paying for itself. I don't need the code to be good by human standards. I need the product to be good by measurable standards.

We're not there yet. Current models still lose context, make bad tradeoffs, introduce security risks, and sometimes build complexity they can't unwind. That's why the controls in the last section exist. I still define the intent, set the constraints, limit the blast radius, and decide what evidence is enough to ship. Sometimes I still have to look lower in the stack because the controls can't tell me enough. Less often than it used to, though.

This still goes wrong. Agents misunderstand requirements, make changes broader than necessary, and occasionally create a mess. I redirect them, improve the tests, or tighten the constraints. I'm not claiming the process is autonomous. I'm saying that reading every line has stopped being the most useful place for me to intervene.

Control didn't disappear from my process. It moved up a level. I review at the boundaries now — contracts, tests, the shape of the change. The mental model I keep in my head is the system's structure, not its implementation. It's closer to how you own a codebase with six human contributors than one you typed yourself.

And yes, everything in that process — the tests worth writing, the constraints worth encoding, the sense of what evidence is enough — comes from twenty-five years of reading and writing code. Nobody coming up now will build it that way, and I don't think it matters. I never learned to read compiler output either. The generation before me was sure that skill was load-bearing. It wasn't — I just spent those years a level up. The next generation will learn how not to code: how to state intent, cap blast radius, and judge machine output at the system level, from day one. They'll get their scar tissue from owning things that break, same as I did. Just higher in the stack.

The ratchet only turns one way

typing the keystrokes gone — nobody grieved reviewing every line dead for anyone shipping at speed policing code structure ← the industry is fighting here guiding the architecture ← me, today stating the intent next, whether we like it or not the ratchet
Every level on this list looked permanent to the people standing on it.

Developers used to inspect compiler output because generated instructions couldn't be trusted. Most stopped when the abstraction became consistently better than the value of inspecting it. Manual memory management went the same way. I think reading code is heading to the same place.

So here's where I actually am.

Line-by-line review of AI code is already dead anywhere work ships at real speed. Structure — the thing we're all writing linters and standards documents and angry blog posts about right now — is dying the same death, and the fight over it is mostly grief. The guardrails that matter are moving up: contracts, tests, blast radius, budgets. Not "did it name the variable well" but "can it hurt me, and would I know."

We're between stages. AI can write far more of the implementation than it can safely own. I still define the boundaries and sometimes the architecture. I still decide what evidence is enough. But I spend less time inside the code every month and more time judging the system around it.

Here's how it's gone for me. At first AI wrote functions and I reviewed every line. Then it implemented features and I reviewed the changes. Now I mostly review contracts, tests, constraints, release evidence, and product behavior.

Writing the code → reviewing the code → reviewing the change → reviewing the evidence → reviewing the product outcome.

We still need humans. We just need them much less at the level of the code and much more at the level of the product. This won't happen at the same speed everywhere. Some code will need eyes on inspection for a while yet — if a regulator or an auditor reads your source, human comprehension is a requirement imposed from outside, and no amount of capability removes it. But the general movement is up, and I don't expect it to reverse.

My prediction — and I mean for it to be aggressive: within about two years, developers working on most modern application software won't routinely inspect generated code at all. Argue with the timeline if you want. I don't think you can argue with the direction.

Today I still guide the architecture, because current agents aren't consistently good at the system-level tradeoffs. It's where I add the most value and I enjoy the work. I'm not attached to keeping it. I also don't need the machine to preserve my design. I care whether the architecture stays understandable and maintainable to the system operating it, not whether it looks like something I'd have drawn. If agents eventually prove they can design, secure, and evolve a system better than I can, I'll stop caring about that layer too. The level where humans add value is not a fixed address. It keeps moving up.

I let my agents do a lot without a ton of oversight. The product is good. I don't care about the dirty details anymore, and no customer has ever asked me to.

The job was never the typing

After twenty-five years of writing software, here's where I land: this is awesome! I didn't get into this field to type. I got into it to solve problems and build things that work for people, and I've never in my career shipped more, better, or faster than I do right now — without reading a line of it. And yes, after everything I just said about METR, I know what that sentence is worth: a developer's feeling about his own speed. So don't take my word for it. I'm running four projects across three machines right now, alone, no employees. Count that however you want — it wasn't a thing I could ever have done before.

The code was never the point. It was always the tax we paid to get the product. The tax rate just dropped.

Sources

← All writing