The next evolution of software developers: from implementation to intent, orchestration, and ownership.
Over the last few months, I've read countless articles debating whether AI will replace software developers. Some predict the end of programming as we know it, while others argue that nothing significant will change.
Personally, I think both perspectives miss the point.
The real transformation isn't that AI can write code. We already know it can. The interesting question is what happens to our profession when writing code is no longer the hardest part of building software.
When I look back at the history of software engineering, I notice a recurring pattern. Every major innovation has raised the level of abstraction.
We moved from Assembly to high-level languages. We stopped managing memory manually. Frameworks abstracted away repetitive boilerplate. Cloud platforms removed much of the operational complexity that once required dedicated teams.
Every step made developers more productive by allowing them to focus less on implementation and more on solving problems.
AI feels like the next step in that same evolution.
Instead of replacing software developers, AI is moving us one level higher in the abstraction stack.
The shift isn't from developers to AI. It's from writing code to defining intent, orchestrating systems, and owning outcomes.
AI isn't the disruption. Abstraction is.
When I started my career, software development revolved around the IDE. A typical day meant creating classes, implementing functions, fixing bugs, and gradually evolving a codebase one commit at a time.
The code was the way we expressed our intentions to computers.
As software systems became larger, something interesting happened. Understanding existing code became just as valuable as writing new code.
Entire consulting projects revolved around taking ownership of legacy applications, understanding how they worked, fixing bugs without introducing regressions, and safely adding new functionality.
Reading code became a highly valuable skill because understanding the system was ultimately more important than producing another hundred lines of PHP or Java.
Today, I believe we're witnessing another transition.
The abstraction layer is moving again.
Every major evolution in software engineering has raised the level of abstraction. AI is simply the next step.
Developers are moving up the abstraction stack
More and more of my time is spent understanding problems before thinking about implementation.
I define requirements, clarify constraints, evaluate trade-offs, design architectures, connect existing platforms, review AI-generated code, and decide where deterministic software is sufficient and where AI reasoning genuinely creates value.
Writing code is still part of my work, but it is no longer necessarily the activity that creates the most value.
This is why I don't believe software developers are disappearing. I believe we're moving to another layer of the stack.
The skills and technical knowledge accumulated over years don't suddenly become irrelevant. Quite the opposite. They allow us to operate at this higher level because we can understand what is happening underneath the abstractions we use.
The role becomes less about translating every decision manually into code and more about making those decisions in the first place.
Developers aren't becoming less technical. They're applying their technical skills at a higher level of abstraction.
The IDE is no longer the center of our work
For decades, the IDE was our primary interface for creating software.
Increasingly, that interface is changing.
We can describe what we want to build, provide context, define requirements and constraints, and let systems produce part of the implementation for us. Whether those systems are Codex, Claude Code, Gemini CLI, or tools that don't even exist yet is almost secondary.
The interesting part is the shift in our interaction with software development.
The IDE doesn't disappear. I still expect to open files, inspect code, debug problems, review implementations, and occasionally write code directly.
But its role changes.
Instead of being the place where every line of software originates, it increasingly becomes one of the places where generated implementations are inspected, understood, validated, and evolved.
Our primary interface is gradually shifting from implementation toward intent.
The IDE used to be where software was created. Increasingly, it's becoming where software is reviewed.
The economics of software are changing
This transition also changes the economics of software development.
Yes, AI has a cost. Tokens aren't free.
But if you compare the cost of generating, reviewing, and iterating on code with the cost of performing the same work entirely manually, it's difficult to ignore where the industry is heading.
Implementation is becoming dramatically cheaper than it has ever been.
I don't think that means software becomes less valuable. If anything, it means we'll build significantly more software.
Ideas that were previously too expensive to implement suddenly become viable. Small businesses can automate processes that never justified custom software before. Freelancers can build products that previously required entire engineering teams. Startups can experiment faster because the cost of implementation continues to decrease.
And all this new software still needs somewhere to live.
It needs reliable infrastructure, deployment platforms, observability, authentication, content management, payments, monitoring, storage, databases, integrations, and security.
Platforms such as Laravel Cloud, Vercel, Netlify, Storyblok, Supabase, Stripe, and many others don't become less relevant because AI can generate code. They provide the building blocks that allow increasingly more ideas to become real products.
Software creation becomes cheaper, but operating, evolving, and taking responsibility for that software doesn't magically disappear.
And that leads to what I believe is one of the most important changes in our profession.
Implementation is becoming cheaper. Ownership is becoming more valuable.
Ownership is the new differentiator
Let's imagine a future where AI generates every single line of code in a project.
Who owns that software?
Not the AI.
Someone still owns the architecture. Someone decides how services communicate. Someone is responsible for security, scalability, reliability, compliance, performance, cost, and long-term maintainability.
Someone decides which trade-offs are acceptable, which technical debt can wait, and which technical debt has become dangerous.
Someone needs to understand why a particular architectural decision was made and whether that decision still makes sense six months later.
Someone is ultimately accountable when production fails at two o'clock in the morning.
And that someone will rarely be an individual in a significant software product. It will be people and teams taking ownership of different parts of the system.
Generating code doesn't mean owning a product.
Those are two very different responsibilities.
In fact, I believe the cheaper the implementation becomes, the more valuable ownership becomes. As AI removes friction from producing software, the quality of architectural, functional, and non-functional decisions becomes a stronger differentiator.
Making software has never been just about producing code. It's about making decisions and accepting responsibility for their consequences.
Code can be generated. Responsibility cannot.
Modern software is becoming probabilistic
There's another fascinating change happening inside the applications themselves.
For decades, most business logic was deterministic. Given the same input and the same state, we expected the same output every single time.
AI introduces something different.
Applications can now reason at runtime, interpret natural language, classify information, summarize documents, generate content, select tools, and make decisions based on context.
Parts of our systems are becoming probabilistic rather than purely deterministic.
This creates an entirely new category of engineering decisions.
Where should we use an LLM, and where is a traditional function the better solution? How do we test something whose output can legitimately change? How do we evaluate its quality? How do we monitor it in production? How much variability is acceptable? What happens when the model produces an unexpected result?
The more intelligence we introduce at runtime, the more important these questions become.
AI doesn't eliminate engineering decisions by providing an intelligent component.
It creates new ones.
AI doesn't remove engineering decisions. It creates new ones.
The biggest opportunity for software developers
This is the part of this evolution that makes me optimistic.
For years, many freelancers and consultants essentially sold implementation.
A client needed a feature, we estimated the work, implemented it, and charged for the time required to produce it.
When implementation becomes cheaper, that model obviously changes.
But I don't necessarily see that as a problem.
I see an opportunity.
A single experienced developer can increasingly combine AI capabilities, cloud infrastructure, authentication providers, payment platforms, headless CMSs, deployment services, databases, and specialized APIs to build products that only a few years ago would have required an entire team.
The differentiator is no longer simply the ability to implement every component.
It's knowing which components to use, how to combine them, what should be custom, what shouldn't be built at all, and most importantly, which problem is actually worth solving.
That moves developers much closer to the product.
Instead of selling only implementation, we can sell solutions. Instead of receiving specifications and translating them into code, we can participate in defining what should be built and take ownership of the result.
That's why I like the word builder.
A builder isn't defined by how much code they personally write.
A builder understands the problem, designs the solution, chooses the right tools, orchestrates the pieces, evaluates the result, and owns what happens next.
Looking at our profession from this perspective, I don't think the future software developer creates less value.
I think we create value differently.
Less implementation, more intent.
Less typing, more decision-making.
More orchestration.
More ownership.
Every major shift in our industry has raised the level of abstraction without removing the need for great engineers. AI is doing the same thing, but perhaps at a scale and speed we haven't experienced before.
It's not asking us to become less technical. It's giving us the opportunity to apply our technical knowledge at a higher level, where understanding systems, making good decisions, and taking ownership matter even more.
That's not the end of software development.
It's the next evolution of software developers.
