Chapter 7: You Are Not Your Code

“The painter should not paint what they see, but what will be seen.”
— Paul Valéry

Most of my day now is spent writing specifications rather than code. I describe what I want built. AI builds it. I review what it produced, catch the misunderstandings, adjust the specs, and iterate. The actual typing of code, the thing I spent two decades getting good at, has become a smaller and smaller part of the work.

A few years ago, this would have felt like science fiction. Now it’s just Tuesday.

I’m telling you this because it would be dishonest to write a book about the Tao of software engineering without acknowledging that software engineering is being redefined while we speak. The ground has shifted. It’s still shifting.

The Shift

AI writes most of the code now. Not universally, not in every shop, but the trajectory is clear. The developers who once spent their days writing functions and debugging logic are increasingly spending their days reviewing AI-generated code, fixing hallucinations, and trying to understand systems that no human would have structured quite that way.

For many, this feels like loss. The craft they spent years mastering is being automated. The expertise that gave them identity and job security is becoming less valuable by the quarter. The thing they loved doing, the actual writing of code, is being taken from them.

I’m not going to tell you that feeling is wrong. It’s not. If you built your identity around writing code, and now something else writes code better and faster than you ever could, that’s a legitimate grief. You’re allowed to feel it.

And it’s not just grief. For some, it’s rage. The sense that something has been stolen. That the years spent learning to think in code, to see the elegant solution, to debug by intuition, all of it now feels like training for a job that’s disappearing. That’s brutal. I know engineers who are genuinely mourning, and I don’t think they’re being dramatic. Something real is ending, even if something else is beginning.

I want to offer a different frame. Not to minimize the grief, but because there might be something on the other side of it worth seeing.

The Producer

When an actor becomes a director, they don’t stop caring about performance. They start caring about it differently. They’re no longer the one in front of the camera, but they’re still shaping what appears on screen. The craft changes, but the art continues.

When a musician becomes a producer, they don’t stop caring about music. They start caring about it at a different level. They’re no longer playing every note, but they’re still responsible for what the listener hears. The instrument changes, but the song continues.

I didn’t grieve when AI started writing most of my code. What I felt was closer to recognition. The code was never the point. The code was the medium. What I actually cared about was building things: systems that solved problems, tools that helped people, structures that held together under pressure. The code was just the only way I knew how to build them.

Now there’s another way. The code is still there, but I’m not the one writing most of it. I’m the one deciding what gets built, and why, and how the pieces fit together. I’m defining specifications, reviewing implementations, catching the places where the machine misunderstood the intent. I’m still building. I’m just building differently.

Beginner’s Mind, Again

Chapter 1 talked about the developer who knows nothing, the courage of admitting ignorance, the freedom of beginner’s mind. That chapter was about returning to openness after expertise had calcified.

AI makes beginners of us all, constantly. The tools change every few months. The patterns that worked last year don’t work now. The expertise you built with one generation of models only partially transfers to the next. You are perpetually starting over.

This can feel exhausting. It can also feel like freedom. If everyone is a beginner, then being a beginner is no longer a mark of inadequacy. The senior engineers and the junior engineers are both figuring it out as they go. The hierarchy of expertise flattens, and what remains is adaptability, curiosity, willingness to learn.

The beginner’s mind isn’t just useful now. It’s mandatory. And that might be a gift.

Holding Tools Even More Lightly

Chapter 2 argued that you are not your stack, that attaching your identity to a language or framework makes you brittle when the industry shifts. The solution was to hold your tools lightly, to find your identity in something more durable than syntax.

The same logic applies, amplified. If you’re not your stack, you’re certainly not your code. The code is even more temporary than the tools that generate it. An entire codebase can be rewritten by AI in hours now. Features that took weeks can be prototyped in an afternoon. The code is ephemeral. It’s disposable. It’s the output, not the point.

This is disorienting if you thought the code was what mattered. It’s liberating if you always suspected that something else mattered more. The code was always just paint. The question was always: what are you painting?

Flow at a Different Level

Chapter 3 explored flow state: the experience of coding so naturally that time disappears and the work does itself. That flow was tied to the act of writing code, the fingers on keyboard, the logic unfolding, the solution emerging line by line.

Flow still exists, but it moves. I find it now in the architecture, in the system design, in the moment when I see how all the pieces will fit together before any code has been written. I find it in the specification, when the description of what I want becomes precise enough that I know the machine will understand. I find it in the review, when I recognize that what the AI produced is exactly right, or see immediately how to adjust it.

The flow isn’t in the typing anymore. It’s in the thinking that the typing used to represent.

This is a loss for those who loved the typing, the tactile satisfaction of building something character by character. I understand that. But the flow was never really in the keystrokes. It was in the clarity that the keystrokes expressed. The clarity can still be yours. It just expresses itself differently now.

Cleverness Reconsidered

Chapter 4 warned against cleverness, the temptation to write impressive code that obscures rather than clarifies. The solution was simplicity: write for the reader, not for your ego.

AI complicates this. AI-generated code is often clever in ways no human would be: dense, optimized, structured according to patterns the model learned from millions of repositories. It works, but it can be hard to read. You find yourself debugging code that feels alien because it is alien. No human wrote it. No human would have written it that way.

The response isn’t to reject AI code. It’s to apply the same standard: does this code communicate its intent? If the AI produced something clever but obscure, you refactor it, or you ask for something clearer, or you add the comments that make it legible to the next reader.

Cleverness is still a trap. It’s just that now the trap can be set by your tools, not just by your ego. The discipline is the same: clarity over impressiveness. The only difference is that you’re now the editor, not just the author.

Silence Before the Prompt

Chapter 5 argued for pausing before you start typing, letting the problem settle before you try to solve it. The pressure to look busy makes this hard. The instinct to act makes it uncomfortable. But the pause is where clarity comes from.

This applies even more urgently now. The temptation with AI is to prompt immediately. The tool is right there. It responds in seconds. Why wouldn’t you just ask it and see what comes back?

But prompting without clarity produces garbage. If you don’t know what you want, the AI will happily give you something, and that something will be confidently wrong in ways you might not notice until much later. The silence before the syntax becomes the silence before the prompt. The discipline of knowing what you’re trying to build before you start building is more important than ever.

I’ve learned this the hard way. The iterations I save by pausing, by writing the specification carefully, by thinking through the edge cases before I ask the machine: those iterations dwarf the time the pause takes. Rushing to prompt is just as dangerous as rushing to type. The silence is still where the work begins.

Burnout in the New World

Chapter 6 described burnout as recursion without a base case: the loop that never terminates, the stack that grows until it overflows. The solution was recognizing the pattern before the collapse, building in the exit condition, taking care of the system that produces the output.

AI introduces new ways to burn out. The volume of code to review is higher than ever. The hallucinations and bugs require constant vigilance. The pace of change means your skills feel obsolete the moment you acquire them. The productivity metrics look great while the exhaustion deepens.

But the pattern is the same. If you’re pushing toward a finish line that keeps receding, the loop is broken. If you’re reviewing AI output faster than you can understand it, the stack is growing. If you’re measuring productivity in commits while your capacity to care erodes, you’re optimizing for the wrong thing.

The base case still matters. Rest still matters. The system, you, still needs maintenance. AI doesn’t change that. It just adds new ways to ignore it.

What Remains

So what’s left? If AI writes the code, and the code was never the point, what is the point?

Here’s what I’ve found: specification, vision, judgment.

Specification is the ability to describe what you want precisely enough that it can be built. This is harder than it sounds. It requires understanding the problem deeply, anticipating edge cases, knowing what questions to ask. AI can help you explore the problem space, but it can’t tell you what’s worth building.

Vision is the ability to see the whole. How the pieces fit together. What the system should feel like when it’s done. What matters and what doesn’t. AI can generate components, but it can’t see the architecture. That’s still yours.

Judgment is the ability to evaluate. This solution works, but is it right? This code is clever, but is it clear? This feature is possible, but is it wise? AI has no judgment. It has pattern matching. The judgment is still yours.

These are the things that remain when the typing is automated. They’re also, if you look closely, the things that always mattered most. The code was just how we expressed them.

The Painting

I don’t miss writing every line of code. I thought I would, but I don’t. What I miss, occasionally, is the simplicity. When it was just me and the editor, the problem and the solution, the keystrokes and the logic. That was clean. That was pure. I understand why people grieve it.

But the purity was always an illusion. The code was always a means to an end. The end was building something that worked, that helped, that mattered. The code was the paint. The building was the painting.

I’m still painting. The brush is different now. Some days it feels like I’m holding several brushes at once, each moving on its own, and my job is to guide them toward something coherent. That takes a different skill. It’s harder to romanticize. But the painting is still mine.

If you’re grieving the craft, I’m not here to tell you to stop. Grieve it. It was real, and it mattered, and something has been lost. But when you’re ready, look up. The canvas is still there. The work is still waiting.

You were never your code. You were always the one who knew what to build, and why.

That part, they can’t automate.