The 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 we 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 / 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 etc.

Compiling a given spec here should be able to generate a mostly predictable /[ repeatable result.

But I belief 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 configured or instructed to behave the way some application wants, but I believe we'll start to a shift towards 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're 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 ofcourse already happened with vibe coding, but you still need to understand code, frameworks, patterns etc.

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 GitHub.com, 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, most careful. While today it might seem we're not quite ready to accept the help of AI agents in production system 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 theorise causes of incidents, even suggesting changes.

I'm sure this will be a welcome addition to any engineer or manager who wish 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, the object of ownership.

But if a specification can deterministically generate that artifact…
If the implementation becomes reproducible, disposable, 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, 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.