Published: 2026-03-04 03:04
Every day I ship code. I review PRs, I architect systems, I make decisions about what gets built and how. But I haven't personally written a line of code in over two months.
I'm a senior engineer and unofficial team lead on the AI team at my company. The reason I haven't written code isn't because I'm slacking — it's because my job changed and I leaned into it instead of fighting it.
Nate Jones wrote something recently that nailed what I've been living: "The tool changes the workflow, but the workflow hasn't been redesigned around the tool."
That's the gap most teams are sitting in right now. They bolted AI coding agents onto their existing processes and wondered why things felt off. The standup still happens. The sprint planning still happens. The code review still happens. But the human isn't writing the code anymore — so why are we running the same playbook?
Here's what I figured out: all those ceremonies exist because humans need coordination structures. Stand-ups exist for daily sync. Sprint planning exists because we can only hold so many tasks in working memory. Code review exists because we make mistakes other people can catch. Every one of these is a response to a human limitation.
When AI writes the code, those limitations don't disappear — they shift. The bottleneck isn't "can we write this fast enough" anymore. It's "are we building the right thing" and "does this actually work beyond passing the tests."
Here's something that doesn't get talked about enough: AI coding agents optimize for passing tests. That's their default behavior. You give them a test suite and they will find a way to make it green. Whether the code is good, maintainable, or even correct in a broader sense — that's not their problem.
Charles Goodhart said it decades ago: "When a measure becomes the target, it ceases to be a good measure." We built test suites to measure code quality. Now AI treats them as the target. Unless you architect around that, you're going to ship code that passes every test and misses the point.
This is where the job shifted for me. I stopped writing code and started spending my time on architecture, problem decomposition, and making sure the AI has the right constraints. The code gets written fast. The question is whether it gets written right.
Michael Gerber wrote The E-Myth decades ago about small business owners. His argument was simple: knowing how to do the technical work doesn't mean you understand the business. A baker who opens a bakery isn't running a business — they just created a job for themselves where they bake.
He broke every business owner into three roles: the entrepreneur (vision and direction), the manager (systems and process), and the technician (the one doing the work). His whole point was that the technician should not be in charge. When the technician runs the show, you get someone who's great at baking bread but terrible at running a bakery.
I didn't read that book thinking about software engineering. But the parallel hit me one morning when I realized I hadn't opened my editor in weeks and nothing had slowed down.
For most of my career, I was all three roles mashed together. I'd think about what to build, figure out how to organize the work, and then write the code myself. AI didn't add a new role — it separated the ones I was already playing. The technician work got automated. What's left is the entrepreneur and manager work: deciding what to build, designing the systems, making sure the constraints are right.
Gerber also said something that stuck with me: "Systems run the business. People run the systems." Swap "business" for "codebase" and you've got the new engineering reality. AI writes the code. I design the systems the AI works within. If those systems are bad — if the architecture is wrong, if the problem decomposition is sloppy — the AI will cheerfully produce bad code that technically works.
The technician era of software engineering is ending. The engineers who thrive will be the ones who figured out they were always supposed to be building the bakery, not just baking the bread.
This is the part that makes some developers uncomfortable: mediocre is no longer a viable career position. LLMs do "adequate" faster than any human can. If your value was cranking out average code at a steady pace — that value just got automated.
The developers who are getting slower with AI are the ones who didn't have much beyond code output to offer. They could write a function, but they couldn't tell you why that function should exist or how it fits into the system. AI exposed the gap between "can write code" and "can engineer software."
The ones getting faster? They already thought in systems. They already cared about architecture, about feedback loops, about whether the thing they're building actually solves the problem. AI just took the grunt work off their plate so they could focus on the stuff that matters.
There's a trap here that I want to name because I've watched teams fall into it in real time.
Ryder Carroll made an observation in The Bullet Journal Method that I think about a lot: technology hasn't made us more productive, just more busy. That was written about notifications and apps, but it applies perfectly to AI-assisted development.
When AI can generate code fast, the natural response is to generate more code. More PRs. More features. More tickets closed per sprint. The dashboard looks incredible. Leadership sees the throughput numbers and thinks the team is crushing it.
But throughput isn't progress. Shipping ten features that nobody needed isn't better than shipping one that changes everything. I've seen teams triple their output with AI and somehow end up further behind because they built a bunch of stuff without stopping to ask whether any of it was the right thing to build.
This is where the job gets harder, not easier. When the bottleneck was writing code, you had a natural speed limit that forced you to prioritize. You couldn't build everything, so you had to choose. AI removes that constraint. Now you can build everything, which means the discipline of choosing what not to build becomes the most important skill on the team.
If your team adopted AI tools and the main thing that changed is you ship more stuff — but you didn't change how you decide what to ship — you're not faster. You're just busier.
My days look different than they did six months ago. I spend most of my time on:
Gerber was obsessed with documenting every process in a business so that anyone — even someone with no experience — could step in and run it. He called these Operation Manuals.
That's what I do now when I set up architecture docs, constraint files, and system specifications that the AI works from. The AI is the novice employee Gerber talked about. It can do the work, but only if the manual is clear. If I hand it a vague description and hope for the best, I get vague output. If I hand it tight constraints, clear interfaces, and well-decomposed problems, I get code that actually solves what I needed it to solve.
The irony is that engineers have always been terrible at documentation. We'd rather write code than write about code. But now the documentation is the work. The quality of what you write before the code gets generated determines the quality of everything that comes after.
I'm not writing code, but I'm engineering more than ever.
If you're reading this and your team still runs the same ceremonies it did two years ago, I'm not saying burn it all down tomorrow. That's a recipe for chaos. Adapt incrementally. Look at each process and ask: does this exist because of a human limitation that AI just removed? If yes, it's friction. Cut it or reshape it.
The teams that figure this out first are going to move at a pace that makes everyone else look like they're standing still. And the engineers who figure out that their value isn't in the code they type but in the decisions they make — they're the ones who'll still have careers when the dust settles.
I haven't written a line of code in two months. I've never been more productive.
Happy coding, J.R.