Your Code Is the Least Interesting Thing You Produce

I've been writing code since 1985. Forty-one years. Somewhere around year thirty I realized the code was never the point.

Think about the last genuinely hard problem you solved. Not a CRUD endpoint; something where you had to actually think. The solution that shipped probably took an afternoon to write. But the thinking that produced it? Weeks. A conversation with a user who described their workflow in a way that reframed your entire data model. A dead-end prototype that taught you where the real constraints were. That 2am moment when you realized consistency and latency were in direct tension and you finally understood which one your users actually needed.

All of that reasoning is gone now. It lives in a Slack thread nobody will search, a Notion doc that's already stale, and the heads of people who might leave next quarter. The code stays. The reasoning dies inside it. What's left is coral; the calcium skeleton of something that was once alive. Structurally sound. You can build on it. But the organism that knew why it grew this way is gone.

We've Always Lost This

This is the oldest pattern in the industry.

Engineer builds something. The code works. The reasoning that made it correct for this specific context; the trade-offs, constraints, rejected alternatives, domain knowledge; none of that gets captured in a way that survives the engineer's departure.

Your senior engineer spent six months understanding the municipal code. She encoded that understanding into the handlers she wrote. She left. The handlers work, but nobody knows which parts of the municipal code they implement. When the code changes, nobody knows which handlers are affected.

You chose PostgreSQL over DynamoDB because the audit trail requirements made strong consistency non-negotiable. That reasoning lives in a Slack thread from eight months ago. The new tech lead is proposing a DynamoDB migration because "it scales better." He's right about scaling. He doesn't know about the audit requirement.

You tried three approaches to the scheduling algorithm. Two failed. Those failures taught you things about the problem space that shaped the solution. None of that is recorded. A year from now, someone will try one of the failed approaches and spend a week rediscovering why it doesn't work.

New engineer arrives. Reads the code. Understands what it does. Has no idea why. Makes a reasonable change that violates an invisible constraint. Something breaks in production three weeks later.

I wrote a book about this. About engineering teams that consume their people and can't figure out why everything is always on fire. The soil metaphor: you can extract from soil or you can cultivate it. Most teams extract. They mine their people for output and throw away the root system. The coral piles up. The organisms die off. The reef looks impressive from the outside and it's dead on the inside.

The Bandwidth Explosion

At Los Alamos, before the digital computers, there were human computers. Women, mostly, doing calculations by hand. The project was compartmentalized; many of them didn't know what the numbers meant. They were handed calculating sheets with specific operations and cranked through them. One of von Neumann's human computers said he didn't understand the purpose of the equations. He just punched keys and translated outputs into curves on paper.

They were already doing what we do now. Executing without the why.

The why lived in a small number of heads: Oppenheimer, Teller, Feynman, a few dozen others. When digital computers replaced the human ones, bandwidth exploded by orders of magnitude. The work didn't shrink. It grew so fast that the bottleneck shifted. The valuable thing stopped being "can you execute this calculation" and became "can you formulate the right question."

But the why was never captured. It stayed in those few heads, in hallway conversations, in classified memos that aged into obscurity. We've never had good infrastructure for the why. The bandwidth explosion just made the gap between production capacity and reasoning capture wider. Nobody noticed; everyone was amazed at the throughput.

That split between doing and understanding isn't unique to Los Alamos. Immanuel Kant identified it two hundred years earlier. He drew a line between pure logic and applied logic. Pure logic is the necessary laws of thought; what reasoning does by itself. Applied logic is how you actually think under real-world constraints, dealing with the mess of practice. Kant was almost dismissive of applied logic. He said it wasn't really logic at all; just psychology.

We built an entire industry around logic, applied. Git, CI/CD, linters, test frameworks, package managers, deployment pipelines. Forty years of increasingly sophisticated tooling for the practical work of writing and shipping code. World-class infrastructure for the derivative. Almost nothing for the foundation it derives from.

And it worked, because humans were still the ones typing. Every line of code had a person behind it who understood why that line existed. The reasoning wasn't captured, but it didn't need to be; it lived in the same head as the output.

AI broke that connection. The person with the reasoning is no longer the one producing the output.

Watch any developer use Cursor, Copilot, Claude Code:

That prompt captured intent; why this code should exist in this shape for this situation. Gone. Next quarter the model improves. The code doesn't. It's coral. Frozen snapshot of a dead prompt.

This isn't a story about losing something. We never had it.

The bottleneck didn't disappear; it shifted. At Los Alamos it shifted from "can you execute this calculation" to "can you formulate the right question." Now it's shifting from "can you write this code" to "do you know what to write and why."

Intent is the bottleneck. And we have nothing for it.

Before you say "Jira": no. Jira captures work assignments, not reasoning. "As a user I want to..." is a template for task delegation. There's no provenance. No connection to the source material that informed the decision. You can't traverse from a deployed handler back through a Jira ticket to the user interview that shaped the requirement. The ticket closes and the reasoning dies with it, same as a deleted prompt. Same with Linear. Notion. Basecamp. All of them. They track what needs to be done and who's doing it. None of them track why it should exist or where that reasoning came from.

They're to-do lists masquerading as knowledge systems.

A Confession

After forty-one years of writing code, I'm not sure I'm a software engineer anymore. I'm not sure what to call what I do now. The closest word I have is philosopher, and that feels so alien.

But the work is reasoning about what should exist and why, and letting machines handle the rest. Capturing the intent; claims, sources, constraints, trade-offs, rejected alternatives; in a structure that survives me. Building something where the organism stays alive, not just the coral.

Philosopher. It's always been the job.