Future of Software Engineering
Our computers can now understand our natural language specification for how we want our software to work, and build it accordingly.
This is where it all begins: the revolution set to change the future of software engineering forever.
Now that this is the case, how is our industry going to change? Fundamentally, is the best guess. The better question is probably: how will it not?
Right now we're at the point where everyone is starting to adopt engineering with AI, but we're still playing the same game, still working with the same code. We're trying to figure out how to avoid AI slop, know where we need to step in, and how we can best use AI.
While our coding has shifted up a level to natural language, we've yet to see how fundamentally AI will change how we work.
Below are a few observations and predictions for the next year or decade.
One Language To Bind Them All
Gone are the days where we cling to our favorite language with a hardcore grip. AI has made it easy to step into new programming languages and frameworks much more easily.
Today, there is one real language to rule them all: your native language.
Spec Driven Development
Now that we are programming in English, the specs we get fed as engineers will become a first-class citizen in the code. They will be used by our AI assistants to generate the implementation, and stay updated as the system changes.
We're not as close to this as it might seem. Right now we can prompt AI to make a change, but we're not prompting AI to notice a change in the spec and rebuild or update the code.
Which brings me to...
Deterministically Generated AI Code
I can see a future where the spec becomes our code, and AI compiles this down into a programming language, with frameworks, patterns, architecture, and more.
Compiling a given spec should be able to generate a mostly predictable, repeatable result.
But I believe for that to be possible, we need to abstract away some of the code we're used to controlling.
Enter...
Engine Driven Applications
We've seen a lot of no-code tools which you might consider having "engines" that are configured or instructed to behave the way an application wants, but I believe we'll start to shift toward human-made engines that abstract away implementation details and execute the output of our AI generators.
Engineers place so much attention and energy into what framework they are going to use. That is going to shift up a layer into what we might see as engines rather than frameworks.
Programming for the Masses
There's little doubt now that it's possible for anyone to become a programmer, just as was predicted two decades ago. But it probably won't look anything like what we thought it would.
Rather than the ordinary person learning to code, our systems will continue to evolve until the ordinary person has very little left to learn. This has of course already happened with vibe coding, but you still need to understand code, frameworks, patterns, and more.
I suspect in future we'll have a much more powerful layer of abstraction for people to review the output of AI code generation tools.
Equality Between Agents and Engineers
We've already seen the introduction of AI coding agents who you can assign tasks to on platforms like GitHub, but we're for the most part still operating in our IDEs with an agent that is limited in what it can do.
Eventually these agents will have as much control over our mouse and keyboard as we do, narrowing the gap between what we can do and what it can do.
Production Fire Fighting Agents
It's an unspoken fact that the worst or hardest part of software engineering is those days you're on call for product support. This is when we are expected to be most responsible and most careful.
While today it might seem we're not quite ready to accept the help of AI agents in production systems, given their unpredictability, there is already research underway for systems like this.
Production support and incident debugging is a high-stakes, high-pressure game where every minute matters. Agents will be much better designed to inspect dozens of services and theorize causes of incidents, even suggesting changes.
I'm sure this will be a welcome addition to any engineer or manager who wishes to maintain greater uptime and stability.
Conclusion
Soon we may have to redefine what we consider code and, with it, what we consider software engineering.
For decades, code has meant the implementation. The files. The repository. The thing the machine executes. That artifact has been the source of truth, the proof of skill, and the object of ownership.
But if a specification can deterministically generate that artifact, if the implementation becomes reproducible, disposable, and rebuildable at will, then what is the real code?
Is it the output, or is it the input?
Will our specs become the true source of truth: the thing we version, reason about, and refine, while everything beneath them is simply compiled consequence?
And if that's the case, what happens to the definition of "software engineer"? Will any technically literate person be able to build systems?
I suspect the answer is yes, and that's not a threat. It's empowering.
The leverage shifts upward toward abstraction, constraint design, and system boundaries. Toward building engines instead of stitching implementations together. Toward defining the shape of possibility rather than filling in its details.
And I suspect many engineers will quietly welcome that.
There is something deeply satisfying about saying less and getting more. About designing the machine that builds the machine. About thinking at a higher layer where elegance compounds.
We're still early. Right now we're using AI to accelerate the old game. But the deeper shift begins when we stop treating implementation as the center of gravity and start treating intent as executable.
When the spec is the code. When engines execute intent. When agents operate with parity. When production systems debug themselves.
Software engineering won't disappear.
But software itself may stop being handwritten artifacts and start becoming simple intent.
And if natural language is the interface, then clarity of thought becomes the ultimate programming skill.
That may be the most empowering shift of all.