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 not a new framework or a bootcamp. It was agentic AI. And the honest version of that story is not “I got faster.” It is that I had to let go of something I had 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
Our entire profession trained us to own code. We were hired because we could produce it. We were promoted because we produced more of it, or better of it, or led others who did. Performance reviews, interviews, our own sense of being good at the job, all of it points at one thing: the code you write.
So when a tool offers to write it for you, the resistance you feel is not laziness or fear of change. It is deeper than that. You are being asked to loosen your grip on the exact thing that made you valuable. That is not a small ask. It is a genuine identity shift, and I think we have been too glib about it.
I see this in senior engineers who are, on paper, the most capable people to work with AI, and who are often the most resistant. Not because they cannot. Because they have the most invested in the old contract. 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 own style so it would feel like mine. That instinct is the whole problem in miniature.
The old SDLC assumed a human at the keyboard
Here is why 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 and a human needs to check them. Estimation is based on how long it takes someone to write and debug. Ownership is tied to authorship. Our whole delivery pipeline is a set of controls wrapped around the act of a person producing code, one pull request at a time.
Agentic AI breaks that assumption in two ways. First, the volume and speed of change stop matching a human typing pace, so line-by-line everything does not scale. Second, and more importantly, these tools are non-deterministic. Ask the same thing twice and you can 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, and it is the subject of the next post: how you wrap predictability around a non-deterministic builder. But you cannot even start on that until you have made 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 your ownership shows up as defining what “done and correct” actually means, and then verifying it rigorously, regardless of who or what produced the implementation.
A framework I keep coming back to, and share with my teams and peers, is Surabhi Gupta’s four levels of AI-driven engineering (worth reading in full). In short: at Level 1, AI accelerates your individual tasks and you are still the author. At Level 2, you delegate real pieces but stay in the loop on every change, reviewing line by line, shipping one PR at a time, carrying the same cognitive load as before. At Level 3, your role changes: you define intent, constraints, and context up front, agents generate the implementation, and you stay accountable for correctness at merge. Level 4 stretches this to whole cross-system builds.
The interesting thing is where people get stuck. Most individuals and teams plateau at Level 2, because Level 2 is comfortable. You get some speedup without giving up any control. It feels like progress. But you are still doing the same amount of human work, just with a faster autocomplete.
The jump from Level 2 to Level 3 is the hard one, and it is hard for exactly the reason this whole post is about. It is not a tooling gap. As one reader put it on Surabhi’s article, the hardest part of Level 3 “is not the technology, it’s getting engineers comfortable being accountable for code they didn’t fully write.” That is the identity shift, stated plainly. 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 are someone who climbed into management, maybe not entirely by choice, and you miss building, this is a golden opportunity to come back. For years, getting hands-on again meant carving out time you did not have to relearn a stack that had moved on without you. That barrier is largely gone. You can describe intent, direct an agent, and build real things again, with far less ramp-up than before.
I am living proof, and I will be honest about the shape of it rather than throw vanity numbers around. Across 2024 to now, my own contribution activity grew several times over. More telling than the volume is the mix: my early activity was mostly reviewing other people’s code, and today the majority of it is building, with AI doing the execution while I direct and verify. On top of the day job, I have built personal projects I would never have attempted before, and I have genuinely enjoyed it.
The clearest proof for me was not at work. I am a data, backend, and DevOps person. I had never built a mobile app in my life. With AI, I built a fully working Expo app for iOS and Android, a travel companion my wife had been asking me for so we could plan trips as a family. It runs. The only thing holding up a launch is that I am still waiting on her to write the content, which she somehow cannot find time for. That is the one bug AI has not fixed for me yet.
I am not sharing that to say “look how productive.” I am sharing it because I want other leaders to know the door is open. You do not have to choose between leading and building anymore. That is a gift, and I am glad it is happening while I am still in the game.
Where this is going
None of this means code stops mattering, or that engineers become prompt typists. Technical depth matters more than ever. It just moves. It moves from writing the implementation to defining the problem crisply, setting the guardrails, and verifying the result. That is a more senior act, not a lesser one. You are becoming the architect and the reviewer of outcomes, not the typist.
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. So the next post is about the practical half: what “readiness” actually means, and how you make an unpredictable builder produce predictable, trustworthy outcomes.
For now, I would leave you with one uncomfortable question. When you resist letting AI write the code, are you protecting quality, or are you protecting your grip on the thing that used to make you valuable? Be honest. I had to be.
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.