Platforms will eat the world

In 2011 Marc Andreessen argued that software companies were taking over large parts of the economy, because software had become the mechanism through which an industry could be reorganized, scaled and eventually replaced. The line between a technology company and an ordinary company was starting to disappear. Banking, retail, logistics, media, telecoms and transport would all end up running on software, and so would nearly everything else.

He was right.

Software was never going to be the last abstraction. It is one layer in a process that started long before computers existed: people take a mechanism that demands explicit knowledge and manual control, wrap it behind an abstraction, and build something more powerful on top. The mechanism does not disappear. It becomes infrastructure.

That is happening again, and this time the mechanism is software development itself.

The industry currently reads AI as a better programmer. We built coding agents, AI IDEs and products that turn a paragraph of English into a running application. Replit, Lovable and Claude Code have shown how far the cost of producing code has fallen — describe an app and watch databases, APIs, screens and business logic appear in an afternoon instead of a quarter.

That is a real achievement, and it is probably a transitional one. The interesting question is not whether AI can write software faster than people. It can, and it will get much better at it. The question is why most business systems should keep being written down as source code at all. Our answer is that they should not.

The next abstraction splits the system from the software that runs the system. The platform is software. The systems running on it are declarative data. AI works on the declarative layer, assembling systems out of constrained, tested platform capabilities instead of generating a fresh implementation of those capabilities for every customer.

That sounds like an architectural preference. It decides who can build business software, what it costs to change, and how long it survives.

If software ate the world, platforms are going to eat software.

New technology always automates the old world first. Early cars looked like carriages missing a horse. Early websites looked like printed pages. Early smartphones inherited assumptions from desktop computers. The old paradigm supplies the vocabulary we use to understand the new one, so the first thing anyone does with a new capability is aim it at yesterday's job.

For seventy years, producing software has meant producing code. So when machines became capable of reasoning about programming, the obvious move was to have them produce code. Describe the result, get an implementation. Enormously useful, and an automation of an abstraction we already had.

The output is still a codebase. It still contains architecture, dependencies, state models, interfaces, database assumptions, authorization rules, integration strategies and several thousand implementation decisions. It still changes. It still needs migrations. It still accumulates history nobody remembers making, still has interactions nobody intended, and still has to stay coherent while the organization it represents changes underneath it.

AI makes that complexity cheaper. Cheap complexity is still complexity.

There is a stranger consequence waiting behind that one. We may soon be able to produce software complexity faster than organizations can understand it. A company that accumulated ten million lines over a decade could generate the same volume in a few months. The typing problem disappears. The coherence problem does not.

Better models will take some of this back. Bigger context windows, repository-level reasoning, automated testing, formal verification and more capable agents will let AI manage far larger codebases than any human team could hold. That still leaves the architectural question standing: why spend that much intelligence generating, and then re-reading, millions of unique implementation decisions that describe capabilities somebody has already solved?

The best use of AI is not to make the old abstraction infinitely cheap. It is to build the next one.

The earliest programmers worked in representations tied directly to the hardware. Assembly put a readable layer over machine instructions. Higher-level languages removed registers from the job. Operating systems took over the hardware. Database engines took over storage. SQL let you describe the data you wanted instead of the steps required to fetch it. Garbage collectors deleted an entire category of bug from ordinary application work.

Every one of those transitions looked expensive, restrictive or underpowered to the people who understood the layer beneath it. They were often right. Assembly could do things early compilers could not. C exposes control that managed runtimes hide. A hand-written query still beats the abstraction sometimes, and dedicated infrastructure still beats generic cloud services. Lower layers stay essential wherever the extra control is worth the extra work.

That is not the interesting part of the history. The interesting part is that the center of value moved up.

Almost nobody building a business system today writes machine code, assembly, an operating system, a database engine or a network stack. They depend on enormous quantities of software they did not write and could not explain in detail. That is not a weakness in modern engineering. It is the reason modern engineering works at all.

For business systems, application code is the next layer to go down.

A lending system is not controllers, database tables, React components and REST endpoints. Those are mechanisms. The system is customers, applications, loans, collateral, decisions, documents, permissions, calculations, states and workflows, plus the rules saying what may happen, under what conditions, who may cause it, what information is required, which other systems get consulted and what follows once it does.

The same is true of an ERP, a CRM, a procurement system, a case management platform, an insurance system and a logistics application. These are executable descriptions of organizations. They say what exists, what people may do, what machines may do, what happens next, how things relate and what the organization is trying to produce.

We wrote those models down as source code because source code was the most powerful general way to express executable behavior. Over time that historical fact quietly became an assumption, and now the industry confuses the implementation with the thing being implemented.

The organization is not TypeScript. The procurement process is not Java. A credit policy is not C#. An approval hierarchy is not a collection of API endpoints.

Those are translations, and a translation exists because the thing doing the executing cannot read the original. Change what executes and the translation can go.

This is not about moving a few constants into JSON files. Not configuration-driven development. Not schemas wrapped around an otherwise conventional application. Not generating source code from metadata and committing the output. Not a visual builder that quietly emits another bespoke application at the end.

We mean the whole system. Domain model, interfaces, workflows, actions, permissions, validations, calculations, integrations, relationships, business rules, state transitions and behavior, all of it able to exist as declarative data that persists.

That data is the system. The platform loads it and executes it.

There is no compile step where the definition turns into a unique application that then begins a lifecycle of its own. No organization needs another repository holding another implementation of authentication, forms, authorization, workflows, persistence, APIs, state management and integration plumbing. The platform already knows how those work.

A system says what exists and what should happen. The platform decides how that executes. That is the difference between describing an organization and building another software stack that happens to represent one.

The platform itself is software, and that part matters more than anything else here. None of this rests on code disappearing from computing. The opposite is true: the more responsibility moves into the platform, the more the platform's engineering quality decides everything.

A platform general enough to be worth the trade has to contain genuinely hard software. Execution semantics, data access, security, authorization, UI capabilities, workflow execution, integration mechanisms, observability, caching, validation, transactions. Adapters that talk to databases and external systems it was not designed against. Abstractions broad enough to serve organizations nobody had in mind when those abstractions were written.

So the hard engineering does not go away. It concentrates. Platform engineers still reason about algorithms, architecture, concurrency, databases, protocols, performance and security, and they use AI coding agents heavily, because refusing better tools would be idiotic. The difference is that they solve those problems once, at the platform layer, instead of solving variations of them inside every customer's system.

Nobody implements process scheduling, virtual memory, device drivers and filesystem semantics before writing an accounting application. Those belong to another layer, and everyone accepts that without argument. A business-system platform pushes the same idea one level up.

The platform is code. The system is data. Confuse those two and none of the rest of this works.

Generative AI is powerful partly because it works over enormous possibility spaces. Ask a model to implement a feature and there are thousands of technically plausible implementations. It picks one, based on the request, the surrounding code, its training and whatever constraints it can infer.

That flexibility is exactly what you want when the thing being built is genuinely new. It is close to worthless when the problem already has a canonical answer.

An enterprise system should not need AI to invent an authorization architecture every time somebody adds a workflow. It should not need a fresh validation strategy per form, or a first-principles decision about how transactions, audit trails, identity and data access ought to work. Those decisions should be settled by the platform before the model arrives.

A platform turns an enormous implementation possibility space into a bounded capability space. If it exposes permissions, the AI describes a permission instead of writing one. If it runs workflows, the AI defines a workflow instead of building an engine. If it understands relationships, the AI states the relationship. The model still reasons. It just cannot improvise the foundation.

The point is not to constrain intelligence. It is to stop spending it on problems that are already solved.

Everything else in this argument rests on one claim: AI should assemble systems out of trusted primitives rather than reinventing systems as source code.

The comparison is manufacturing. An engineer designing a complex product does not rediscover metallurgy, fabricate every transistor and invent every screw. Industrial civilization works because standardized capabilities compose into things of absurd complexity. Software got most of the way there with libraries, frameworks, APIs, services and cloud infrastructure, and then stopped one layer short. We reuse the components and then write bespoke application code to hold them together.

Make the holding-together declarative and the interesting work changes shape. What is the organization trying to achieve? Which entities exist? What information moves between them, and what constrains that movement? Who has authority? Which decisions can be automated and which need judgment? Which steps are sequential only out of habit? Which external systems participate, and which exceptions actually matter?

Those are reasoning problems, and they decide whether the system is worth anything. Whether the implementation used one state-management pattern or another does not.

We would rather spend the intelligence on the first list.

None of this removes creativity from building systems. It moves it to where it was always doing the most work.

Take two companies implementing order management on the same platform. The first digitizes the process it already has. The second notices that three of its approval stages exist only because information used to move slowly between departments, redesigns the flow, automates the routine decisions and leaves humans the ambiguous ones.

The second company built the better system. Not because its code is more elegant — there may be no application code at all. It built the better system because it understood its own business better.

This matters more as implementation cost collapses. When nearly anyone can produce functionality, functionality stops being the differentiator, and the question becomes which functionality should exist. The scarce skill moves from implementation knowledge toward domain knowledge and systems thinking.

Why does this process exist? Which constraints are real and which are historical accidents? Where is information duplicated, and where are people waiting for other people? Which decision needs judgment and which is just a rule being followed by hand? Which step survives only because two old systems could not talk to each other?

Those are creative questions, and the people who spend careers learning to answer them are usually not programmers.

Every step is defensible. Every step loses something. By the time the system reaches production, an enormous share of the effort has gone into moving knowledge from the people who understand the organization into a form a machine will execute. Then the organization changes and the chain starts again.

AI on top of a declarative platform compresses that chain, because the person building the system can increasingly be the person who understands the problem. A management consultant. An entrepreneur. An accountant who understands one genuinely horrible financial process. A logistics specialist. An insurance expert. An operations manager who has watched the same handover fail for twenty years.

Today those people write requirements for developers. On a declarative platform they can build the executable model directly, with AI translating intent into the platform's constrained semantics.

The programmer does not disappear. The programmer moves down the stack and becomes a platform engineer, while the domain expert moves closer to the machine, and the layer between them gets thin.

That is a far bigger democratization of software than teaching everybody to prompt a coding agent.

The defining skill of a traditional developer is turning desired behavior into a working implementation. The defining skill of whoever builds systems next is understanding systems in the older, broader sense: organizations, incentives, information, constraints, decisions and outcomes.

That is consulting work, with one difference that changes everything about it. Consulting normally ends in documents, diagrams and recommendations, and somebody else has to turn them into operating reality. That is where most of them die.

On a declarative platform the process model is not documentation about the software. It is part of the software. The permission model is not a specification waiting to be implemented; it is what gets enforced. The workflow is not a diagram attached to a ticket; it is the workflow.

The distinction between designing the organization and designing its information system collapses, because a modern organization is already inseparable from its systems.

A mature business system holds a startling amount of institutional knowledge. It knows which customer information matters, which states an order can occupy, who may approve a transaction, which documents a case requires, how pricing is calculated, what triggers a notification and which exceptions get escalated.

In conventional software that knowledge is scattered across source code, database schemas, config files, documentation, tickets, tribal habit and the heads of employees who have been there long enough. That fragmentation is one of the main reasons enterprise systems are so hard to change. Before you can change the behavior, you have to find it.

A declarative system makes the knowledge explicit, and an explicit model can be reasoned about. AI can inspect the workflows, find the waiting states that serve nobody, compare two departments doing the same thing differently, detect rules that contradict each other, explain exactly why a user is allowed to perform an action and simulate a change before anybody applies it.

Eventually it can ask a better question than how to implement the next requirement. It can ask why the organization works this way at all.

The obvious objection: real enterprise systems are complicated. Correct. Organizations are complicated. A multinational manufacturer runs procurement, production, finance, compliance, logistics and quality control across hundreds of external systems. A bank carries products, regulations, risk models, permissions and processes that took decades to accumulate. An insurer encodes rules nobody currently employed remembers writing.

The conclusion normally drawn is that such systems require enormous bespoke codebases. That does not follow.

Complexity cannot be abolished by changing how it is written down. If the business has ten thousand meaningful rules, ten thousand rules have to live somewhere. But business complexity and implementation complexity are different quantities, and we habitually multiply them together.

A tax system with thousands of rules does not need thousands of pieces of custom infrastructure. A workflow with hundreds of transitions does not need bespoke architecture per transition. An organization with thousands of permission relationships does not need thousands of hand-written authorization checks.

The goal is not to eliminate essential complexity. It is to stop multiplying it by the accidental kind, and to leave the organization's complexity visible as organizational complexity instead of burying it in machinery.

None of this works if the platform is a convenient pile of components. It has to be general enough to represent systems its designers never imagined, and that is the genuinely difficult part.

Every abstraction trades freedom for reach. Too narrow, and users hit the wall and escape into custom code. Collect enough escape hatches and the platform is a framework with bespoke applications wrapped around it, which is the thing we are trying to stop doing.

The target is a set of primitives fundamental enough that enormous variation comes out of composition rather than implementation. A database achieves this: its designers do not know what anyone will store. So does a programming language, and so does an operating system. None of them know their own future workload.

A system platform has to hit the same property one layer higher. It cannot know the businesses in advance. It has to know enough about computation, information, interaction and how organizations actually behave that those businesses can describe themselves.

That is much harder than generating another application. It is also the only part worth doing, because it is the part that does not have to be done again.

One of the least discussed costs of conventional software is that its abstractions age on their own schedule. A company builds an application in 2026, and its dependencies, architecture, framework assumptions and patterns are all 2026. Five years later the business still needs the application, and the technical world around it has moved.

Then the archaeology starts. Dependencies need upgrading. APIs are deprecated. Security models change. Frameworks get abandoned. Infrastructure assumptions expire. Somebody proposes a rewrite, somebody else correctly points out that rewrites are how companies die, and the money goes into keeping yesterday's implementation breathing.

AI will make migrations cheaper. The better question is why the migration exists at the application layer in the first place.

If the system is declarative data interpreted by a platform that keeps evolving, most of those migrations happen underneath it. Nobody migrates a workflow because the platform changed how it renders UI. Nobody rewrites a permission model because the authorization implementation improved. The business semantics hold still while the runtime moves.

A system can stay technologically current without its implementation stack being frozen in the year somebody wrote it.

Conventional development has a multiplication problem. Every new application is another attack surface, another dependency graph, another authentication integration, another authorization implementation, another set of APIs and another pile of chances to get it wrong.

Generated code does not fix this. It makes it worse, because the number of applications an organization has to defend rises with the ease of producing them.

A platform changes the unit of security engineering. If identity, authorization, data access and auditing belong to the platform, every system inherits them, and every improvement lands everywhere at once.

This does not make systems automatically safe. A badly designed permission model is still a badly designed permission model, and declarative rules can be wrong in all the ways code can. What disappears is the need to implement enforcement thousands of separate times.

The safest security code is the code an application never gets the chance to write.

Software engineering has chased reuse for decades, and each generation raised the unit. Functions reuse logic. Libraries reuse functions. Frameworks reuse architecture. Services reuse functionality. Cloud platforms reuse infrastructure. And then we still finish the job by writing another application.

That is the boundary a platform moves. The reusable unit stops being code and becomes capability.

A system composes those according to what the organization needs. Platform engineers build and evolve the capabilities. System builders assemble them. AI makes the assembly interface far more powerful than a configuration screen ever was.

It is Lego at the level of enterprise computation, except the bricks are not visual widgets. They are generalized executable semantics.

There was a time when changing what a machine did meant changing the machine. Then behavior separated from hardware: instructions could be stored, and one general-purpose machine could do radically different things depending on what it was told to do. That separation produced one of the largest expansions of technological capability in history.

From here, encoding every new business application into dedicated hardware looks absurd. It is possible, and there are cases where specialized silicon is exactly right, but nobody suggests manufacturing a new circuit because the procurement workflow changed. The behavior belongs at a higher level.

The same question now applies to application code. Why is every business system effectively burned into its own implementation?

Source code is infinitely more malleable than a circuit board, but the pattern rhymes. The desired behavior gets bound to one artifact, and that artifact acquires dependencies, versions, architecture, deployment mechanics and a lifecycle of its own. If a general enough runtime can execute the system definition directly, encoding each system as bespoke application code starts to look like an unnecessarily low-level representation.

Which is why comparing this shift to moving from C++ to C# understates it. The closer analogy is the separation of software from the machine. The platform becomes the general-purpose machine, and the declarative system is what it runs.

Git is extraordinarily good at what it does, and it is good at it because source code is currently the authoritative representation of an application. Change that and the tooling question reopens.

Versioning still matters. So do history, auditability, testing, rollback and collaboration. None of those require the system to exist as files full of programming-language syntax, and we should be careful not to mistake today's development tools for permanent properties of computation.

A future system could carry a far richer history than today's applications while containing no application source code at all, because every structural change can be recorded semantically. “Added an approval step for transactions above €100,000” tells you more than a diff across twelve files. “Granted regional managers access to these entities” tells you more than a change to authorization middleware.

The system starts describing its own evolution in the language of the business, which is also the language the business can argue with.

And AI stops having to infer business meaning from implementation diffs. The meaning is right there.

There is a small paradox in how the industry uses these models. We hand extremely capable systems an extraordinarily messy environment, and then congratulate them for coping.

A mature codebase is millions of tokens spread across languages, frameworks, conventions, stale comments, historical accidents and implementation detail. Before a model can safely change anything, it has to reconstruct the conceptual system from that evidence. Then we ask it to add a feature.

A declarative platform inverts the situation. The conceptual structure is not inferred, it is stated. Entities are entities, relationships are relationships, permissions are permissions, workflows are workflows.

That does not make the reasoning easy. It makes the reasoning relevant — spent on understanding the organization instead of on another engineer's implementation decisions from four years ago.

Once systems are structured executable models, agents can do something other than write code. They can work on the system itself.

An agent can read a process and find the step that exists only to notify somebody who no longer reads it. It can notice two departments collecting the same information independently, or a rule that quietly contradicts another rule three processes away. It can propose automation where a decision is deterministic, and mark the places where human judgment is genuinely doing work.

Run that continuously and you have something reasoning about the gap between the outcomes an organization wants and the systems it uses to produce them.

A coding assistant asks what code it should write. This asks what system should exist. The second question is where the money is.

Software as a Service transformed distribution. Instead of every organization installing and operating its own software, one vendor runs one continuously improving product for thousands of customers, and the economics of that are hard to argue with.

It came with a compromise. The organization adapts to the product: the vendor owns the model, customers configure around it, and when a real need diverges from the vendor's assumptions the customization gets expensive or simply gets refused.

Custom development gives the opposite trade. The system fits precisely, and now the organization owns a bespoke implementation with every cost that implies. Whole consulting industries exist to manage that one choice.

A platform separates the two concerns. The machinery is standardized without standardizing the organization: thousands of systems share a runtime, its semantics and its capabilities while running different data models, workflows, interfaces and rules. That is closer to SaaS economics with custom-software fit than either side of the old question can get.

For a large class of business systems, build versus buy is a question inherited from a lower abstraction.

Organizations change constantly. They acquire companies, absorb new regulations, launch and retire products, move people between roles, react to markets, improve processes and discover that last year's assumption is now wrong.

Software has always taxed that. Changing organizational behavior means changing an implementation: requirements gathered, tickets written, developers interpreting, code changed, tests run, releases scheduled, migrations executed.

The latency has a consequence people underrate. An organization whose systems change slowly starts organizing itself around the limits of its software. Anyone who has worked in a large company has watched the inversion happen — people performing an absurd manual procedure not because it makes any sense but because the system works that way.

The tool ends up governing the organization it was bought to serve.

When organizational semantics are represented directly, organizational change becomes system change without a full development cycle in between. That is not developer productivity. It is the difference between a company that can act on what it learns and one that files it for the next release.

Every new abstraction arrives with somebody announcing the death of the profession underneath it, and the announcement is always wrong. Compilers did not eliminate people who understand processors. Databases did not eliminate storage engineering. Cloud did not eliminate infrastructure engineering. Those skills concentrated, and mostly got harder.

The same applies here. Platform engineering is more demanding than application development, not less. The runtime has to be exceptionally reliable because everything depends on it. The abstractions have to be designed carefully because a mistake propagates into every system built on them. Performance work, security work and generalization all carry outsized consequences.

A platform engineer is not a diminished application developer. They are building the machine the applications run on.

Fewer people may be needed than are currently implementing the same screens in different companies. The work that remains is harder.

Plus whole categories nobody has thought of. Code is not obsolete, and saying otherwise would be as silly as saying electricity made mechanical engineering obsolete. Technologies rarely destroy the useful layers below them. They change where those layers sit.

C++ remains essential, and almost nobody building an approval workflow writes C++. Assembly remains essential, and nobody proposes implementing a CRM in it for the extra control.

The question was never whether code survives. It is whether bespoke application code stays the dominant way business systems are represented.

No platform will ever contain every capability anyone needs. Novel requirements arrive, and some systems will want behavior the platform cannot express. Pretending otherwise is how platforms earn a reputation for lying to their users.

The right response treats the boundary as information. When something genuinely new needs code, platform engineers write it, and then the real question gets asked: can this be generalized? If it can, it becomes part of the platform, and what was an escape hatch becomes a primitive. If it cannot, it stays a one-off and everybody knows which one it is.

That creates a ratchet. Every genuinely new problem solved at the platform layer expands what every future system can express without code, and the expressive frontier only moves one direction.

The platform accumulates capability instead of applications accumulating debt.

A bespoke application accumulates. More features, more dependencies, more migrations, more decisions nobody remembers making, more maintenance obligation. Every year it costs more to keep and more to change.

A platform does the opposite. Improve the data access layer and every system gets faster. Improve auditability and every system becomes more auditable. Fix accessibility in one UI primitive and every screen using it inherits the fix. Add a database adapter and every system can reach one more thing.

The return on a day of engineering stops belonging to one application. Traditional development solves similar problems locally, over and over, in codebases that never meet. Platform development tries to solve classes of problems once, and every class removed stops appearing in the next project.

One approach grows its maintenance surface. The other grows what the next system can do before anyone writes a line.

Ray Kurzweil's law of accelerating returns says, roughly, that progress speeds up because each advance helps produce the next one. Whatever you make of the more ambitious predictions attached to his name, the mechanism is visible everywhere in computing. Better computers help design better computers. Better software helps build better software. Better tools help build better tools.

AI sharpens that loop, because the tool now participates directly in making the next generation of the tool. For a platform the loop has a specific shape: AI helps engineers generalize capabilities into the platform, those capabilities constrain the space future AI operates in, better constraints make results more reliable, more reliability lets AI take on more consequential composition, more systems expose more patterns, and the patterns show what to generalize next.

Meanwhile the gaps between abstraction layers keep shrinking. Physical mechanisms took centuries to mature. Electrical systems reshaped industry over decades. Computing abstractions arrived in faster and faster generations. The internet compressed distribution, cloud compressed infrastructure, and AI is now compressing intellectual implementation work itself.

Because AI can help build abstractions, the next layer does not have to be built at human speed.

Code production got faster. Abstraction production got faster too, and that is the one that changes the ceiling.

Most AI software work today asks machines to act like programmers. Generate the files. Write the function. Create the component. Fix the type error. Run the tests. Open the pull request. That is useful, because the world we have is organized around exactly those activities.

It should still strike us as strange to assume that a superhuman software intelligence, if we build one, ought to spend eternity editing text files because that is how humans happened to write programs in the twentieth century.

AI does not need source code for the reasons we need it. It needs representations that make its reasoning reliable, and a structured system model is a better interface for that than a sprawling repository of implementation artifacts.

The goal is not to make AI extraordinarily good at navigating our historical mess. It is to stop producing the mess.

The industry has spent decades trying to bring humans closer to computers. Friendlier languages. Visual programming. Low-code. No-code. Natural-language interfaces. Coding assistants. Every one of them kept the same assumption underneath: somebody, or something, still has to construct the application as software.

The more radical move is to separate humans from implementation entirely. The finance director reasons about finance. The logistics specialist reasons about logistics. The compliance expert reasons about constraints. The consultant reasons about how the organization should work. The platform engineer reasons about computation. AI bridges the layers.

That is what an abstraction is for. Not making everyone capable of programming — making programming unnecessary for most of what a business needs from software.

We are not waiting to find out whether that happens. We are building the platform it needs.