You were paid to write code. That's the problem now.

In 2024, I barely wrote any code.

I am a Director of Engineering. Somewhere on the way up, like a lot of people in my seat, I had traded building for reviewing, planning, and unblocking other people. That is the job, and I was fine with it. What I did not expect was how much I missed the craft, or what it would take to get it back.

What brought me back was agentic AI. But the story is not “I got faster.” I had to let go of something I spent my whole career being rewarded for: control over the code itself.

If you have ever looked at an AI tool and thought “I could just write this faster myself,” this post is about what is really behind that thought. It is not about speed. It is about identity.

Why we all clutch the keyboard

We were hired because we could write code. We were promoted because we wrote more of it, or better, or led others who did. Reviews, interviews, our own sense of being good at the job - all of it points at one thing: code you wrote.

When a tool offers to write it for you, the resistance is not laziness or fear of change. You are being asked to let go of the thing that made you valuable. That is not a small ask.

Senior engineers are, on paper, the best equipped to work with AI. They are often the most resistant. Not because they cannot. Because they have the most invested in the old deal. The better you got at writing code, the harder it is to stop treating code as the point.

I felt it myself. The first time an agent produced a working change I had only described, my instinct was to rewrite it in my style so it felt like mine. That instinct is the whole problem in miniature.

The old SDLC assumed a human at the keyboard

This matters beyond feelings. Almost everything about how we build software assumes a person is typing each line.

Code review is line by line because a human wrote those lines. Estimation is based on how long someone takes to write and debug. Ownership is tied to authorship. The whole delivery pipeline is controls wrapped around one person producing code, one PR at a time.

Agentic AI breaks that in two ways. First, the volume of change stops matching a human pace. When an agent rewrites a module in seconds or minutes, reviewing every line the old way becomes the bottleneck, not the safeguard.

Second, these tools are non-deterministic. Ask the same thing twice and you get two different implementations. The old SDLC was built for a predictable author. We now have a capable but unpredictable one.

That is the real work ahead: how you wrap predictability around a non-deterministic builder. But you cannot start on that until you make the mental shift underneath it.

From controlling code to controlling outcomes

The shift is simple to say and hard to live: stop controlling the code, start controlling the outcome.

Controlling code means your ownership shows up as writing it and gatekeeping every line. Controlling outcomes means defining what “done and correct” looks like, then verifying it, regardless of who or what produced the implementation.

Surabhi Gupta describes four levels of AI-driven engineering that map this well:

Level 1: AI accelerates your tasks. You are still the author.
Level 2: You delegate pieces but review every change line by line, one PR at a time. Same cognitive load, faster autocomplete.
Level 3: You define intent, constraints, and context up front. Agents implement. You stay accountable for correctness at merge.
Level 4: This stretches to whole cross-system builds.

Most people plateau at Level 2 because it is comfortable. You get some speedup without giving up control. It feels like progress. But you are still doing the same amount of human work.

The jump to Level 3 is hard for exactly the reason this post is about. It is not a tooling gap. As one reader put it on Surabhi’s article: the hardest part “is not the technology, it’s getting engineers comfortable being accountable for code they didn’t fully write.”

There is an irony here. Every engineer already depends on frameworks and libraries - thousands of lines of code they never saw. We trust those because someone else vetted them. The shift is the same shape: learn to vet for outcomes, not lines of code. The tools are ready. We are the bottleneck.

The part nobody tells the managers

There is a version of this story that is almost never told, and it is the one I am most excited about.

If you climbed into management, maybe not entirely by choice, and you miss building, this is a real chance to come back. For years, getting hands-on meant carving out time you did not have to relearn a stack that moved on without you. That barrier is largely gone. You can describe intent, direct an agent, and build real things again.

My own shift shows in my commit history. In early 2024, most of my activity was reviewing other people’s code. Today the majority is building - AI does the execution while I direct and verify.

The clearest proof was not at work. I am a data, backend, and DevOps person. I had never built a mobile app. With AI, I built a working Expo app for iOS and Android - a travel companion my wife wanted so we could plan trips as a family. It runs. The only holdup is she still has not written the content. That is the one bug AI has not fixed yet.

I am sharing this because I want other leaders to know: you do not have to choose between leading and building anymore.

Where this is going

Code does not stop mattering. Technical depth matters more than ever. It just moves - from writing the implementation to defining the problem clearly, setting guardrails, and verifying the result. That is a more senior act, not a lesser one.

But wanting the shift is not enough. If you hand real work to a non-deterministic tool without rebuilding the process around it, you do not get Level 3. You get a mess you are still accountable for.

The next post is about that practical half: what “readiness” actually means, and how you make an unpredictable builder produce predictable outcomes.

I’ll leave you with the question I had to ask myself. When you resist letting AI write the code, are you protecting quality, or are you holding on to the thing that used to define your value? I had to answer that question myself before I could move forward.

I am sharing this as I go, from my own experience rather than a finished playbook. If it is useful and there is interest, I will keep writing about what comes next. I would genuinely like to hear where you are on this, and where you are getting stuck.