Just a year ago, it was still easy to dismiss AI coding as a shaky and inaccurate auto-complete. Now it’s clear to most software professionals that AI is not merely here to stay. It is fundamentally changing how we build software.
After more than 30 years as a programmer, I no longer code manually. Sometime in October 2025 I went 100% agentic, and I’m not planning on going back.
My agentic shift came after decades spent learning various programming languages, tools, and ecosystems. That’s a massive investment in skills that are now, at least partly, automated.
So what happens next? Will there even be such a thing as a software developer in a few years? Or will our profession go the way of the lamplighters and horse carriages?
Agentic workflows have moved us way past mere prompting and into something closer to delegation and orchestration. And that gives us a view of what lies ahead.
In the short term, two forces are pulling in opposite directions:
Automation reduces the need for manual coding, suggesting fewer software people.
Yet expanding system complexity increases the need for more builders.
My bet is on the second force exerting the strongest pull. There has yet to be a technological revolution that did not expand the scope of what we build. AI will not shrink software. The future will see more software than ever, as there’s an infinite — and growing — amount of tasks to automate via code.
The difference compared to earlier seismic shifts is the pace. The industrial revolution took roughly 80 years (1760-1840), giving society time to adapt. This time, we don’t get generations. We get months.
You probably see this in your LinkedIn and X feeds. They are filled with stories like building a Linux clone in Visual Basic by chatting to a Claude Code cluster over voice. While taking a bath. No prior coding experience. No deep technical background. Just a prompt and a generous supply of tokens.
Now, here’s the reality: Building the first prototype of a product or feature was always the easy part.
Roughly 95% of the cost of a software product occurs after the initial version is released. Turning a prototype into a stable, reliable, and evolvable system is where the real work starts. Shipping is optional. Maintaining is not.
Once you have users, you get pressure:
new features,
bug fixes,
scaling concerns,
integration challenges,
and a constant need to evolve the system without breaking it.
AI does not remove that complexity. Building successful production software has never been easy, and it won’t suddenly become trivial. Design, architecture, and what to build — the hardest parts — cannot be automated.
But wait: did I really say that not everything will be automatable? I did. And that usually gets the same response:
AI is improving rapidly. Soon it will be able to build and maintain complex systems on its own.
Usually stated in a flat, matter-of-fact voice, as if that settles it.
It’s an appealing idea. I also believe it’s flawed—for at least three reasons:
If we had stuck to the problems of the 1970s, programming would already be trivial. We didn’t. Instead, we created better tools, languages, and abstractions to take on bigger and more complex problems. AI will likely do the same.
Tomorrow’s systems will be even more ambitious.
Most real-world systems simply aren’t ready for autonomous agents. Long-lived legacy systems are shaped by years of implicit assumptions and accumulated technical debt while still being business critical.
For an agent to perform well, data quality is key. And in software, code is the data. Most production codebases are inconsistent, under-tested, and full of edge cases that even humans struggle to reason about. Sure, AI is useful on legacy systems, but fully autonomous development remains a pipe dream at best.
You just shouldn’t bet your career on the hopes and promises of “soon”. Even if full autonomy eventually becomes possible, the real question is: When?
We’ve been hearing that “AGI is around the corner” for years. Maybe it is. Most likely it isn’t. (Coincidentally, the AGI narrative is pushed by people who happen to sell language models...and rely on external funding for them).
Personally, I’m not waiting. I’m preparing for a world where the developer role changes. I’d rather be early than obsolete.
Agents are automating the act of writing code. It’s easy to feel threatened. Uncertainty about one’s professional future is a big drain.
But here’s the good news: Code has no intrinsic value. It never had. (We just built our careers pretending it did.)
Code is a means to an end. What matters is what the code enables—the system, the behavior, the product. And this is where the human developer comes in. Because that human role does not disappear. It shifts.
I see two emerging and complementary developer roles:
First we have the expert generalist builder. In an AI-first workflow, the expert generalist is responsible for:
deciding what to build
deciding how to build it (at the system level)
breaking work into meaningful increments that can be delegated to agents
These responsibilities are not new. They have traditionally been split across:
product managers
software architects
technical leads
What’s changing is that these three specialist roles are collapsing into a single generalist role. No, it won’t be an easy job. Each one of those used to pay well in the past. Now one individual has to master them all. But for one salary.
Alongside that, I also see a second role emerging: the enabler.
The enabler is responsible for the meta-layer of development. The work that makes agentic development effective by:
optimizing build and deployment pipelines
capturing constraints and patterns in machine-friendly formats (think: present day SKILLs)
improving testability and optimizing coverage
refactoring legacy systems to make them AI-friendly
This role is not about shipping features. It is about enabling agents to build features well. As such, the enabler is a vital support role for the expert generalist.
All your prior knowledge will serve you well in the AI age. Rather, the challenge is to keep on learning. Continuously.
To be an expert generalist, our learning and purpose needs to shift. Details aren’t as important as the larger picture. For example, it might be more important to know the type of problems and systems that are a good fit for the Rust language rather than mastering the borrow checker syntax. The former is a strategic tool, the latter a now automatable task.
Unfortunately, and these are the bad news, the future of development will probably not be for everyone. I met great programmers who code because they love to code. And now those days are gone, with no obvious financial incentive for bringing them back.
But another group of developers are likely to thrive. As much as I loved to code by hand, I enjoy agentic coding even more. To me, code was always about what I could make it do, not syntax, not craft, definitely not the typing. Agents get me there faster.
My main worries early on were around just problem solving: When machines carry out our execution, how can we still stay in the loop to maintain effective mental models of the problem we’re working on? You see, problem solving is not a one-way street. It’s a constant iteration between observing, expressing, and reflecting.
Surprisingly, I’ve found that agents can support and strengthen that flow. In the past, I could easily get sidetracked by secondary tasks. Like restructuring the emerging code. I had an idea in my head, but now I wasn’t working on it; I was working on supportive and related tasks, but not the core. With agents taking over the details, I find it much, much easier to maintain the high-level thought and iterate on it.
That said, there’s a flip side to it.
Software development is definitely more mentally effortful with agents.
Maintaining a constant focus is draining, and I find that I can usually only sustain that intense high pace for a couple of hours before needing a break. (Thankfully, I can let a long-running agent make progress while I sip coffee).
With AI, the developer’s role shifts from writing code to designing systems that can evolve safely, with agents doing the grunt work. But agents won’t replace human taste when it comes to deciding what to build.
Taste is a human quality. And building the right system is going to be key. Faster coding? Not so much. It’s already a commodity.
Even if code no longer serves as a moat or job security, strong engineering remains a competitive advantage. Teams that succeed in this shift to agentic development will iterate faster and build better systems. This is where systems thinking and domain expertise come in. Knowing what to build and how to build it matters more than execution.
Throughout my decades in various software companies, I’ve seen plenty of promising products fail. Not due to any flawed product ideas, but rather due to buggy, sub-par code preventing organizations to ship when the opportunity was rife.
If there’s one truly good thing coming out of the agentic revolution then it’s this: for many, bad code might become a distant memory of times less enlightened. But mark my words: an AI won’t set you up for that success on its own. Developers who fail to adopt are likely to ship the same sub-par code, only faster. Because the future of software development will not be less engineering. It’s more engineering at a higher level of abstraction.