Five years ago, I was the MacGyver on a development team.
You know the type. Backend breaks? I'm in there. Frontend needs a component? I've got it. Server configuration, database optimization, API design — I could touch any part of the stack and make it work. Thirty years of building software had made me the Swiss Army knife that every team keeps around for the problems nobody else wants to touch.
That role doesn't exist anymore. Not because the skills became irrelevant — they became the foundation for something nobody saw coming.
I'm now a solo operator running six to eight concurrent projects on any given day. Some days it's twelve. I build AI-powered SaaS applications. I run an MSP. I manage client infrastructure. I write, I ship, I maintain. I do this with AI agents, CLI tools, multi-agent orchestration systems, and a development philosophy that would have sounded insane to me in 2021.
And I have never been more exhausted in my life.
The Paradox Nobody Talks About
The AI productivity conversation is dominated by two camps. The first says AI will replace developers. The second says AI makes everything easy. Both are wrong, and both are telling you something useful by being wrong in the exact way they are.
AI didn't replace me. It promoted me. I went from being a developer to being a development operation. I don't write every line of code anymore — I architect systems, direct agents, review output, make judgment calls, and maintain quality across a portfolio of work that would have required a team of ten five years ago.
Here's what nobody warns you about: when you can do the work of ten people, you will do the work of ten people. Not because someone forces you to. Because you can see it. You can see the product that should exist. You can see the automation that would save your client forty hours a week. You can see the gap in the market that you could fill in a weekend. And now you actually have the capacity to act on all of it.
So you do. All of it. Simultaneously.
The output is staggering. I ship more working software in a month than I used to ship in a year. The quality is higher because I have AI reviewing my architecture decisions, catching edge cases I'd miss at 2 AM, and generating test coverage I never would have written manually. My GitHub has over 170 repositories. I have products live, products in beta, products being sold.
The cost is that I haven't had a slow week in two years.
The Moment It Clicked
I didn't plan to become an operator. There was no strategic pivot, no whiteboard session where I mapped out the transformation. It happened, and then one day I noticed.
I was several days into a stretch of work — directing AI agents, reviewing pull requests, writing specifications, architecting integrations — and I realized I hadn't personally written a line of code in days. Not a function. Not a component. Not even a quick script.
Holy crap. My world had changed.
I wasn't coding. I was orchestrating. I was the one deciding what got built, how it got built, what the architecture looked like, what the edge cases were. But the actual typing-code-into-an-editor part — the thing I'd done every working day for three decades — wasn't mine anymore. It belonged to the agents. My job had become making sure they had the right context, the right specifications, and the right constraints to do their work.
That was the moment I understood: the title hadn't changed, but the job had.
What Actually Changed
The shift happened in layers, and I didn't fully understand it until I was already deep in the new reality.
Layer 1: AI as a fast typist. This is where everyone starts. You use Copilot or ChatGPT to write boilerplate faster. You save maybe 20% of your time. You feel clever. This phase lasted about three months for me in 2022.
Layer 2: AI as a junior developer. You start giving it larger tasks. Write this component. Build this API endpoint. Generate the migration. You review everything, but the throughput doubles. You start taking on more work because you can.
Layer 3: AI as a development team. This is where it gets dangerous — and where I live now. You're not prompting a chatbot. You're running Claude Code from the CLI with autonomous capabilities. You're orchestrating multiple agent sessions in tmux panes, each working on different parts of the same system. You've built spec-driven workflows where the AI reads the specification, generates the code, runs the tests, and opens the PR. Your job shifts from writing code to writing specifications, reviewing output, and making architectural decisions.
At Layer 3, you stop being a developer. You become an operator.
Layer 4: AI as infrastructure. This is what I'm building toward. Systems that don't just help you build — they run autonomously. They monitor your production applications, triage issues, fix bugs, and only surface what requires human judgment. The development team that never sleeps, never forgets, and never gets frustrated that you changed the requirements at 4 PM on a Friday.
The jump from Layer 1 to Layer 3 took me about eighteen months. Each layer didn't just increase productivity — it increased the scope of what I was willing to attempt. And that's the trap.
What Layer 4 Actually Looks Like
I'll make it concrete. One of my production platforms — a case management system for personal injury law firms — has an automation Mac that runs Claude Code on a 30-minute cycle. Here's what it does without me:
It checks the production site health. It pulls new GitHub issues. It classifies each one as a bug or a feature request. If it's a bug, it creates a branch, writes the fix, runs the build, pushes it through CI, and waits for the automated code review bot to clear it. If everything passes, it creates a pull request and emails me. If it's a feature request, it escalates to me and the client for approval before touching anything.
I built the system that builds the fixes. The system that monitors the system. The system that decides what it's allowed to fix and what requires a human.
That's not development. That's operations.
And here's the part that keeps me up at night — sometimes literally. I'm now looking at a Mac Studio that's been sitting on a shelf and thinking about it the way a DevOps engineer thinks about a build server. Not "what should I code on this?" but "what should this machine run autonomously while I sleep?" I'm evaluating terminal emulators not for font rendering or color schemes, but for memory efficiency under sustained AI workloads. I'm researching memory leaks in my CLI tools the way I used to research database query optimization.
The stack changed. The developer didn't go away — the developer evolved into something that manages machines that do the developing.
The MacGyver Problem
Being a generalist was always my superpower. Full-stack, infrastructure, networking, security — I could solve problems that specialists couldn't because I could see across boundaries. I wasn't the best at any one thing. I was the best at connecting things.
AI turned that superpower into a liability.
When you can connect anything, and AI can build anything, every connection becomes a potential project. Every integration becomes a product idea. Every client problem becomes a SaaS opportunity.
I went from "I could build that" to "I am building that" across a dozen domains simultaneously. Personal injury litigation software. Time tracking platforms. Sales call analysis tools. AI-native communication systems. A precious metals intelligence platform. Browser automation. And underneath all of it, the AI operating system that ties everything together.
This isn't a humble brag. This is a warning.
The same trait that made me valuable on a team — the ability to see the whole board and move across it — is the trait that AI amplifies most aggressively. If you were a specialist, AI made you faster at your specialty. If you were a generalist, AI removed every constraint that used to keep your scope manageable.
The specialists got faster. The generalists got wider. And width without boundaries is just a different word for overload.
The Cost Nobody Talks About
It's 10:37 on Easter Sunday night. I'm writing this article. I have Claude Code running in another terminal window working on a client project. Tomorrow is Monday, and I'll pick up where I left off without a break because there wasn't one.
I got up at 4 AM on Saturday and coded until 7. Friday — Good Friday — I got off work at 3, got home at 5, settled for an hour, and then picked up coding until 3 in the morning.
I'm not telling you this because I think it's admirable. I'm telling you because it's the part of the AI productivity story that nobody writes about, and I think it's the most important part.
The productivity gains are real. I am genuinely getting a hundred times more done than I was five years ago. But the productivity doesn't create leisure. It creates more surface area. More projects that need attention. More systems that need monitoring. More clients who can see the output and want more of it. More ideas that you now have the capacity to act on.
And if you're the kind of person who became a developer in the first place — the kind who sees a problem and can't not try to solve it — that capacity is a trap. You don't use the extra throughput to work less. You use it to attempt more. And "more" has no natural stopping point.
I talk to other senior developers who are going through the same thing. We compare notes. We all tell the same story with different specifics. The output is incredible. The hours are worse than they've ever been. The line between work and life isn't blurred — it's gone.
What I've Learned the Hard Way
Your development methodology matters more than your code. I don't start projects by coding anymore. I start with a specification. A detailed document that describes what the system does, how it's structured, what the data models look like, and what the user experience should feel like. The spec is the product. The code is just the spec rendered in a language machines can execute. Without this discipline, AI-assisted development produces a lot of working software that doesn't cohere into a product.
Context management is the new core skill. The limiting factor in AI-assisted development isn't the AI's capability. It's your ability to maintain context across a dozen active projects, each with its own architecture, its own deployment pipeline, its own client expectations, and its own set of decisions you made three weeks ago at midnight. I've built memory systems, specification repositories, and project documentation habits specifically to solve this problem. The developer who can hold the most context — or build systems that hold context for them — wins.
The "AI will handle it" trap is real. There's a seductive moment where you think: I'll just spin up another agent session and let it handle this while I focus on that. And it works. Until it doesn't. Until the agent makes an architectural decision that conflicts with a decision you made in a different project. Until it generates code that passes tests but violates a design principle you haven't documented. Until you realize you're reviewing output from six different AI sessions and you've lost track of which project each one is changing.
You need to say no more than you ever have. This is the hardest lesson. When AI removes the execution constraint, the only constraint left is your attention. And attention is not scalable. I can run twelve projects. I cannot think deeply about twelve projects simultaneously. The ones that suffer are the ones where deep thought was the thing that mattered most.
Physical infrastructure becomes a bottleneck you didn't expect. I have a MacBook Pro, a Mac Studio, a Dell server in a data center rack, and dedicated AI hardware. When you're running always-on AI automation, your development machines aren't just tools — they're production infrastructure. Memory leaks in your CLI tools at 3 AM aren't a minor annoyance. They're operational failures that take down your autonomous pipeline. You start thinking about your own hardware the way you used to think about client servers.
The Identity Shift
This is the part nobody writes about because it's uncomfortable.
I was a developer for thirty years. I identified as a developer. I took pride in elegant code, in solving hard problems with clean solutions, in that moment when you trace a bug through four layers of abstraction and find the one line that's wrong.
I still do that. But less. Now I spend more time writing specifications than writing code. More time reviewing AI output than producing my own. More time thinking about project orchestration than about algorithm design. More time managing infrastructure than building features.
I went days without writing code and didn't notice until I noticed. That's not a workflow change. That's an identity shift.
I'm not complaining. The work I do now has more impact. The systems I ship solve real problems for real businesses. The output is genuinely 100x what it was five years ago. I wouldn't go back.
But there's a grief in it that nobody talks about. The craft of sitting down with a blank file and building something from nothing, line by line, with your own hands — that experience is becoming rare in my workflow. Not gone. Rare. And when it happens, it feels different. It feels almost nostalgic. Like handwriting a letter in an age of email.
What I'd Tell the 2021 Version of Me
Start building systems to manage your own capacity before you need them. By the time you feel overwhelmed, you're already six months behind on the infrastructure you need to manage the overwhelm.
Document everything. Not for compliance, not for your team — you don't have a team anymore. Document it for yourself at 2 AM when you can't remember why you architected the auth system that way three projects ago.
Build the spec-driven workflow first. Before you write a line of product code, build the process that turns ideas into specifications and specifications into working software. That process is your actual product. Everything else is output.
Set boundaries that aren't based on willpower. Willpower doesn't work when you can see exactly how to solve the problem and the only thing between you and the solution is deciding to stop for the night. Build systems. Timers. Rules. Hard stops. Whatever works. Because the work will always be there, and it will always feel urgent, and you will always be able to do just a little more.
And for the love of everything — learn to say no. AI removed the "I can't build that" excuse. It didn't remove the "I shouldn't build that right now" reality. The hardest skill in the AI era isn't prompting. It's prioritization.
The Uncomfortable Truth
I am more productive than I have ever been. I am more capable than I have ever been. I am building things I could not have imagined building five years ago, at a pace that would have seemed impossible.
I am also more tired, more scattered, and more at risk of burnout than at any point in my thirty-year career.
These two things are not contradictory. They are the same thing.
AI didn't make the work easier. It made more work possible. And for people like me — the builders, the MacGyvers, the ones who see a problem and can't not try to solve it — "more possible" is the most dangerous phrase in the English language.
The developers who thrive in this era won't be the ones who adopt AI the fastest. They'll be the ones who learn to govern their own capacity. Who build systems not just to produce more, but to decide what's worth producing. Who understand that the bottleneck was never their typing speed. It was never the code.
It was always the human.
Jason Brashear has been building software since 1994 and is a partner at Titanium Computing in Austin, TX. He currently runs multiple AI-powered SaaS products and writes about the operational reality of AI-native development in the Frontier Operations Series.
Top comments (0)