The Future of Software Isn’t Code. It’s Intent.

Inspired by a series of posts starting with https://www.linkedin.com/posts/philspilsbury_what-if-ai-takes-us-back-to-assembly-language-share-7480255128013307904-BqM3/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAACq0Bxz3cJvZujzZMFOxVsWmiIStHfXI by Phil Spilsbury, Esq., about the future of computer languages and whether the next language would be a machine representation,

I asked ChatGPT for its opinion. Here it is, uncut. But first, when I asked ChatGPT for a title and told it that I was crediting it, it replied:

If I were writing this under my own name, I’d probably open with something like this:

For seventy years we’ve argued about programming languages.

AI may finally be making that the wrong argument.

The important question isn’t whether AI will generate Python, C#, or some machine-first intermediate language. The important question is what becomes the source of truth when implementation is no longer scarce.

My answer is simple: not code, but intent.

Here’s the original response to the article:

I really enjoyed reading these because they’re asking a systems question rather than a tooling question. They’re also consistent: each post builds on the previous one instead of just escalating the claim.

That said, I think the central thesis is simultaneously insightful and slightly misdirected.

I think the key insight is this:

AI shifts the locus of abstraction.

I don’t think the destination is a machine-first language. I think that’s where I’d challenge the series.

The historical pattern isn’t actually “languages became more human.”

It’s that we kept moving the boundary between specification and implementation.

Assembly wasn’t about readability.

FORTRAN wasn’t about readability.

SQL wasn’t about readability.

They were about allowing humans to specify intent while hiding implementation.

The same happened with:

• operating systems
• virtual memory
• databases
• Kubernetes
• Terraform
• serverless
• React

Every generation lets us specify what while hiding more of how.

AI is simply another move in that direction.

Where I think Part 1 is weakest is the assumption that the implementation remains the interesting artifact.

I don’t think it does.

If AI is producing implementations that nobody reads, why preserve any implementation?

The implementation becomes a cache.

The specification becomes the source of truth.

That feels like a much more profound shift.

I suspect future repositories look more like

Vision.md

Architecture.md

Protocols/

Policies/

Domain Model/

Tests/

Constraints/

Performance Goals/

Security Requirements/

Compliance/

Examples/

instead of

src/

The source becomes the intent.

Code is merely one compiled view.

That also changes version control.

Today we version code.

Tomorrow we may version intent.

Imagine git commits like

Increase throughput by 30%

Reduce memory ceiling to 2GB

Support offline mode

Comply with PCI 5.0 

Those become first-class engineering artifacts.

This is where your “Engineering Judgment is Scarce” axiom intersects beautifully.

If implementation is essentially free…

then judgment becomes the expensive part.

Questions become

• Which tradeoffs matter?
• Which requirements conflict?
• Which protocol survives change?
• Which architecture admits future evolution?
• Which risks are acceptable?

Those aren’t programming-language questions.

They’re engineering questions.

I also think the machine-first language idea may not survive contact with economics.

A compiler already is a machine-first translator.

LLVM IR already exists.

SPIR-V exists.

WebAssembly exists.

MLIR exists.

SSA exists.

These are all intermediate representations optimized for machines or compilers.

The interesting question isn’t

Will AI invent another IR?

It almost certainly will.

The interesting question is

Does anyone outside the compiler ever need to see it?

Probably not.

I also think there is another force at work that isn’t discussed.

Verification.

If AI writes software…

we need stronger guarantees.

That suggests enormous investment in

• formal specifications
• property testing
• model checking
• contracts
• proofs
• runtime verification

Those become more valuable than prettier syntax.

There’s another direction I think the posts miss.

Programming languages aren’t only languages.

They’re ecosystems.

Python isn’t valuable because of indentation.

It’s valuable because of

• NumPy
• Pandas
• PyTorch
• FastAPI
• decades of libraries
• millions of developers

AI doesn’t erase network effects.

If anything it amplifies them.

Here’s where I think the really interesting question lies.

Not

What language will AI generate?

But

What representation best preserves engineering intent?

Those are different.

Machine efficiency is cheap.

Human intent is expensive.

If AI can regenerate implementations endlessly, then preserving intent becomes the scarce resource.

This also connects to something you’ve been building for months.

You’ve repeatedly argued things like:

• Architecture matters.
• Every solution is a commitment.
• Never optimize what you haven’t taken the time to understand.
• AI made code abundant. Engineering judgment is still scarce.

Notice none of those mention programming languages.

They’re all about decision-making under constraints.

That’s exactly where I think software engineering is heading.

In fact, I’d push the idea one step further.

The future repository may not primarily contain software at all. It may contain a model of the system:

• goals
• stakeholders
• constraints
• invariants
• interfaces
• quality attributes
• acceptable tradeoffs
• business rules
• evidence
• rationale

The code becomes a derived artifact, much like compiled binaries are today.

That would represent a much bigger shift than moving from C# to a machine-first intermediate language.

As a self-critique, I may be underestimating the value of a machine-oriented representation. AI systems could very well converge on richer intermediate forms than today’s LLVM IR or MLIR because they encode optimization opportunities or semantic information that’s useful during regeneration. But I suspect those representations will be implementation details. The enduring change is likely to be above the language level: treating intent, constraints, and architecture as the canonical artifacts of software engineering, with executable code becoming increasingly ephemeral. I think that’s the more transformative idea.

---

As a critique of my own suggestion: “The Future of Software Isn’t Code. It’s Intent.” is intentionally provocative. Strictly speaking, software will still be code in an executable sense. The title is shorthand for “the primary engineering artifact shifts from code to intent.”

Human Note — I told ChatGPT that I would be posting its response. It thanked me and decided on the title of the response. Additionally, I asked ChatGPT to create its choice of images for the post.