Software is entering its Cambrian Explosion, and - it is worth remembering - that means most specimen will go extinct, and the survivors will look rather different. Both products and processes will undergo intense evolutionary pressure, with fast migrations enabling the full exploration of the space of all possible software until a new optimum emerges.

The contemporary stack is structurally broken: The "stack" is a thousand little silos, each with their own slightly incompatible slice of software, each demanding its own terms and standards and formats. It was never designed as one whole; it evolved as a mosaic of different technologies and services where nothing quite fits together.

Now, the technical debt accumulated over decades of organic software growth is coming due. Probabilistic computing is finally here and we could infuse intelligence into all software, but we can't, because we're stuck on an opaque stack that rejects integration and modification at every layer. Instead, we got "APIs" and now "MCPs".

To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

The familiar features that make modern software "modern" - SaaS, multiplayer, multi-vendor, multi-cloud, heterogeneity - also make it hostile to agents. Fragmenting context and siloing control as widely as embodied by the old stack is exactly the opposite of what personalised, malleable, intelligence-infused software needs.

So, half a century after the last software crisis, the computing stack is once again buckling under the weight, volume and speed of a more powerful machine. Once again, we get to retrace from the beginning, reconsider what programming even means, and reshape what 21st century software should look like.

Higher Order Programming

The history of programming is one of monotonically increasing levels of abstraction in specifying mechanically repeatable behavior: from handcrafting mechanical gears, to wiring up vacuum tubes, to punching paper cards, to coding assembly, to writing C, to programming Java, to scripting Python, to asking an LLM.

Climbing the ladder of abstraction yields more output for every (human) bit of input. We gradually remove ourselves from the cumbersome burden of having to spell out exactly what we want the machine to be doing: which gears? which wires? which bits? which registers? what memory? what computer? where computer? when computer?

Programming, then, is just reified problem solving: iterating, thinking, working to understand the shape of a problem and specifying its solution in some mechanically repeatable form. We used to solve software-shaped problems with artisanal next-character-prediction of symbolic code, but, really, programming doesn't have to be any formal language at all.

Indeed, there was programming before code, there is programming after code - and programming alongside code already has rich prior art! Game developers have iterated on multimodal software production over decades: early game development was a schlep where only a tiny guild of brilliant nerds managed to produce presentable commercial games.

To build a game, everyone had to write their own graphics, networking, scripting, asset pipelines, editors - a whole engine for every game, on top of the actual game! Then, we figured out how to package the hard bits into reusable components and more complete, higher level packages of reusable software components we call a "game engine".

Crucially, modern game engines go far beyond traditional "software frameworks" like Django or Rails or some blend of cloud services. The best game engines are integrated software platforms: a runtime, an editor, tools, VCS integrations, netcode, deployment platform, and myriad affordances for prototyping, iterating, refining, and shipping games.

Like most new abstractions, game engines initially didn't provide quite the same level of control as their underlying substrate. Over time, however, building with a game engine became so much more productive that it enabled a new scale of project, and empowered a new type of contributor - designers, writers, and artists, could now contribute directly.

Games never "superseded" code, even as a lot of code was abstracted away for use cases that previously required it. Code is still there, it's still relevant, but - thanks to game engines - you can build and ship commercial games without thinking in code.

The Software Engine

General purpose software is now hitting the same issues that game developers have long solved. The principal components of modern software have ossified, but they're scattered and reconstituted a thousand different ways. General software needs its own "software engine": integrated "platform software" with building blocks for a new level of "userland software".

It is insufficient to accelerate the software production process, not just because of Amdahl's law, but because missing any part of software is to lose the shape of the whole product - and software that doesn't solve any reality-shaped problem is pointless. In frighteningly short order, steering only through the peephole of a chatbox makes it almost impossible to figure out where to go next and how to get there.

Oddly, the primary objective of "software factories" seems to be removing oneself from all production processes without any new higher order specification to anchor this higher level of programming. In other words, the software factory requires a software engine, because the precise industrial-scale manufacture of quality software must be built on new integrated processes that span the entire lifecycle.

Despite half a century of development, our tools for building and understanding software systems are surprisingly primitive. We still struggle with "works on my machine", and reproducing observed issues in the "laboratory" is virtually impossible. If software is going to run everything, faster than anyone can verify, how do we make sure it's the right software?

Fundamentally, there is not a single test, certificate, proof, or magic gate that you can run to convince me that some non-trivial general software program is correct. The correctness of any complex software systems spans many granularities, and mathematical "proof", green tests, smoke tests, and passing gates all mean nothing if it's not what I actually meant.

The only way to ensure correctness for general purpose software - that is: does it do what it should? - is to look, to see the software in motion under many different angles and granularities. Notably, this is not an intelligence problem at all - it's a human problem, and a real world integration problem. I just don't know what I want until I see it.

The continuous and iterative process of shaping is critical not just for "malleable" software but - because programming is just reified problem solving - for all software. Software development - from databases to web apps to spreadsheets - spans one continuous spectrum of reified program solving that has been separated into rigid planes only by historical happenstance.

Until now, the cardinal sins of "malleable software" has been that "userland software" like spreadsheets are too limited, while "general software" is annoying to build and maintain. Now, the equation has flipped: building is cheap, and the lack of integration is expensive. How do you join "reminders in Notion" with "leads in Salesforce" and "events in Outlook"?

There are amazing new probabilistic computing capabilities to embed deep and wide into all software, and the lack of integration is why we just have MCPs with chatboxes in the sidebar. Forms don't even prefill, software is not adaptive, apps are not magic - where is all the automation? If we truly have higher order programming, where is the higher order software?

The Destack

Higher order programming requires higher order processes with higher order specifications, the necessary control for which can only be achieved by integrating and standardising the full stack. Thus, we need a complete software engine that provides both the fundamental building blocks for development and the platform services for deployment.

That is Destack: an open source, hackable, software engine and platform. In product terms, think of Destack as an integrated system of software production with the principal building blocks for modern software and a ready-to-wear suite of common applications built on top of them, ready to deploy, remix, and adopt.

Destack does not require everyone to "own their stack" literally - that would be too annoying, and give up all the nice benefits of modern cloud-based software. Rather, the standardised Destack users to actually own their data, makes deep integration and customisation table stakes, and reduces app switching to just a single click.

In technical terms, think of Destack as a unified GitHub + NPM + SQlite + Durable Object with all the boring integration like auth, schemas, migration, sync, triggers, workflows, telemetry, infra. It's all standardised to enable a higher level of abstraction.