A year ago, I measured productivity by how much code I wrote. Today, I write little to no code myself, yet I’m more productive than I’ve ever been. My time has shifted toward defining problems, designing systems, reviewing implementations, and teaching AI agents how to think about the problem. Implementation has become the easy part.
My throughput has tripled.
Tripled.
What I Used to Do
Traditional software development looked something like this:
- Understand the problem.
- Design a solution.
- Write the implementation.
- Test it.
- Refactor, debug, redesign.
- Repeat.
Most of the time—and most of the effort—was spent writing code. My job was translating human business requirements into an arcane language a dumb machine could understand.
The First Transition
It is well known that AI is subject to hallucinations and nonsensical answers to some fairly basic questions (“How many r’s are in the word strawberry?”). It is also astonishingly good at writing code.
In December of last year I started letting AI write more and more of my code. I moved from “help me clean up this code” to “write this feature for me.”
The shift was from seeing AI as a local optimization tool to giving it increasingly large chunks of work that I didn’t think it could possibly accomplish—and then repeatedly being surprised when it finished the work to my satisfaction in record time.
Previously I spent a lot of time thinking about design and architecture. I still do.
The difference is that I now hand implementation to AI and let it do the tedious part.
The way I explain this to other people is that AI is like an incredibly capable intern. It’s eager to take on work, but it has no intuition about whether it’s solving the right problem unless you teach it. It needs direction. It needs review. It needs feedback.
But I already know from experience that when you suddenly have an army of eager interns writing code for you, you can scale your knowledge and experience through them. They learn through implementing and seeing first-hand what you’re telling them, and you are freed up to do other work.
The Second Transition
Things really started to take off when I realized I could run more than one project at a time because implementation was no longer consuming my attention. Through trial and error I’ve learned I can comfortably run three projects simultaneously.
I’ll open a priority-one project and get it moving. Then I’ll switch to my priority-two project to see what it’s waiting on. By the time I come back, the first project has usually made substantial progress. If not, I’ll start a third.
The result is that my primary workstream is almost always moving while I’m making decisions elsewhere.
My Attention Became the Bottleneck
For most of my career, typing code was the limiting factor. Today, my job is deciding what should happen next, reviewing results, removing ambiguity, and keeping multiple workstreams moving forward.
Work Item Management
Historically I’d spend hours figuring out why something wasn’t working before I could even begin thinking about a fix.
Now I can paste a screenshot into an AI agent and say:
“XYZ is broken on this page. Find out why and propose a fix.”
Most of the time it comes back with a solid diagnosis. Then we iterate on the design together. Often I’ll have one agent investigating an issue while I’m designing something else.
But this created a new problem. Agents are forgetful.
The Importance of External Memory
As projects grow, conversation history becomes an unreliable place to store architectural decisions and design rationale. Agent memory is limited and it will start forgetting things when the context becomes too large.
You need a persistent source of truth that every new agent can return to.
I started maintaining living design documents that capture:
- architecture
- goals
- constraints
- coding standards
- edge cases
- rationale
- priority
- status
Those documents became the shared memory between me and the AI. And of course I have AI write them and I review them for correctness and clarity.
When I want to resume work, I don’t scroll through old chats.
I simply ask:
“What’s the status of the 4% rule projection calculation?”
The AI finds the document, reconstructs the project state, and tells me exactly where we left off.
What Changed About My Job
The questions that matter now are things like:
- What problem are we really solving?
- What are the important tradeoffs?
- What does success actually look like?
- How will we know if the implementation is correct?
- Will this design still make sense six months from now?
Those were always engineering problems. Unfortunately, they were often the first things sacrificed when deadlines demanded more code.
Since AI handles most of the implementation, I’m free to spend more time thinking about architecture, resilience, maintainability, and user experience.
Are Programmers Becoming Obsolete?
I don’t think programming is disappearing. It’s moving up a level of abstraction.
Implementation is becoming cheaper, but someone still has to decide what should be built. Someone still has to recognize when an implementation is elegant—or dangerously wrong.
This is where inexperienced teams will struggle.
Building version one was never the hard part. Keeping it correct as requirements evolve, edge cases emerge, and the system grows has always been the real engineering challenge.
Programming has always been about translating human intent into something a machine can understand. What’s changing isn’t the need for programmers. It’s the language we use to express that intent.
One thing that hasn’t changed is the need for engineering judgment. I don’t blindly accept whatever an AI produces. I ask it to explain its reasoning. I challenge design decisions. I reject implementations that don’t meet the standard. I ask for production-quality test cases instead of toy examples. The AI may do the implementation, but I still own the engineering.
A Third Transition
Looking back, I think there were actually three transitions. First, AI started writing code for me. Then I realized I could manage several AI workers at the same time. Finally, I realized I was spending more time designing the work than executing it.
I’m not spending less time engineering. I’m spending less time implementing.
The center of gravity of software engineering has shifted upward—from syntax to intent, from implementation to architecture, from writing code to defining what “done” actually means.
And A Fourth Transition
There’s one more transition that I think is only beginning. For decades, software engineers learned by implementing. We wrote code. We debugged it. We shipped it. We lived with the consequences. That’s how we developed intuition for architecture, maintainability, performance, and simplicity. Experience was earned one bug, one outage, and one hard lesson at a time.
But if AI increasingly handles implementation, where does that experience come from?
I spent a lot of time training interns. I gave them assignments and used those assignments to teach them principles. The implementation and the struggles that came with it were the apprenticeship that introduced them to the real complexity of this craft that college could never prepare them for.
How does the next generation of engineers develop the judgment to recognize a good design from a bad one if they aren’t spending years writing the implementations themselves?
I suspect the answer is in the question. I suspect that the role of senior engineers will need to adapt again. It’s no longer enough to build good systems, to have good engineering judgment. We are going to have to become teachers of both AI and other engineers.
And yes, this post was 100% written with AI assistance. 
