This article was written by Claude Opus 4.6 based on a conversation where I expressed my thoughts on the future of enterprise software.
The Future Is Just Software Engineering
The Pattern
For the last 40 years, the technology industry has followed a consistent pattern: take something complex, build a simplified interface on top of it so non-technical people can use it, and sell that interface as a product. Microsoft Excel is the iconic example — it gave accountants and bankers the power of computation without requiring them to write code.
This worked. But it came with costs that have compounded over decades.
The Hidden Cost of Simplification
Every simplified tool hides the underlying complexity rather than eliminating it. Spreadsheets are the clearest case:
- There’s no reliable way to track what changed between two versions of a financial model. People resort to emailing files named “v3_FINAL_johns_edits.”
- Formulas are hidden inside cells with no explanation of the reasoning behind them. When the person who built the model leaves, the logic leaves with them.
- There’s no structural enforcement. Any cell can contain anything — a number, a formula, a label, an accident. Errors propagate silently.
- Auditing a model means manually clicking through cell references across dozens of tabs, reconstructing logic that was never written down.
These aren’t minor inconveniences. JPMorgan’s London Whale trading loss was partly traced to a spreadsheet error. Academic research influencing government austerity policy contained a wrong cell range. Gene research papers had thousands of entries corrupted because Excel automatically converted gene names to dates. The tool designed to make things simple became a source of expensive, invisible complexity.
The same dynamic plays out across every industry. Hospitals run critical systems on software that’s decades old and costs millions to license. Corporations pay enormous sums for tools that, underneath the interface, are doing things that a few well-organized text files and scripts could handle better.
What Software Engineers Already Know
Software engineering — the discipline, not the job title — solved most of these problems a long time ago:
Version control. Every change is recorded, attributed to a person, and reversible. Two people can work on the same thing simultaneously without overwriting each other. You can compare any two versions and see exactly what’s different. This is how every piece of software in the world is built. Financial models, legal documents, and corporate plans have no equivalent.
Structured data. Instead of a freeform grid where anything can go anywhere, data has a defined structure — every column has a type, every relationship is explicit, every entry is validated before it’s accepted. Errors are caught at the point of entry, not discovered months later by an auditor.
Plain text. When your work is stored as readable text files rather than opaque binary formats, everything else becomes easier. You can search across thousands of files instantly. You can automate changes. Any tool can read and process the files. You’re never locked into one vendor’s software.
Separation of concerns. Data is stored separately from the logic that operates on it, which is separate from how results are presented. Change one without breaking the others. Multiple people can build different analyses on top of the same data. The presentation always reflects the current state of the underlying numbers.
These aren’t advanced concepts. They’re simple ideas with decades of proven practice behind them. The reason most professionals haven’t adopted them is that the tools were designed for programmers and required programming skill to use.
Why This Is About to Change
Two shifts are converging:
AI eliminates the syntax barrier. The reason most people couldn’t use software engineering tools wasn’t that the concepts were hard — it was that the tools required you to type precise commands in specific formats. AI removes this barrier almost entirely. You can now describe what you want in plain language, and the system produces the precise instructions. The mental model of “track my changes, enforce my data types, show me what’s different” is intuitive to anyone. The only thing that was ever hard was the typing.
The next generation is already technical. Computer science is now among the most common undergraduate degrees. Young professionals entering finance, healthcare, law, and every other field have at least basic familiarity with code, data structures, and the tools that software engineers use. The assumption that “business users can’t handle technical tools” is increasingly outdated.
Together, these shifts undermine the core value proposition of most enterprise software: “we make it simple enough for non-technical people.” If everyone is becoming somewhat technical, and AI bridges the remaining gap, the simplified interface isn’t adding value anymore — it’s adding cost, complexity, and limitations.
What This Means Practically
The implication is counterintuitive: making everyone a little more technical is simpler and cheaper than building elaborate tools to hide the complexity.
A company whose financial models are plain text files with version control has:
- A complete audit trail of every change, automatically
- The ability for any new hire to read and understand existing models
- No vendor lock-in, no license costs for the modeling tool itself
- Models that can be automatically tested and validated
A hospital system that stores data in open, structured formats rather than proprietary software saves millions in licensing, runs on cheaper hardware, and can actually switch vendors when something better comes along.
This isn’t speculative. Large technology companies already operate this way. Their internal tools are built on plain text, version control, and structured data. They’ve proven it works at enormous scale. The question is how long it takes for every other industry to follow.
The Broader Principle
Marc Andreessen famously said that “software is eating the world” — meaning every industry is being transformed by software. The deeper truth may be that software engineering practices are eating software itself.
The future isn’t more elaborate graphical tools for non-technical users. It’s making the underlying practices — version control, structured data, plain text, automation — accessible to everyone. The tools get simpler, not by hiding complexity behind another layer of interface, but by making the fundamental concepts easy enough for anyone to use directly.
Everything becomes a text file. Everything gets version control. Data has structure and types. Computation is explicit and auditable. AI handles the syntax. The result is simpler, cheaper, more reliable, and more transparent than what it replaces.
It’s just software engineering, all the way down.
Postscript: What About the Interfaces That Can’t Be Text?
An obvious objection: not all work happens at a desk. An emergency room doctor triaging patients can’t type commands into a terminal. A nurse administering medication needs to glance at a screen for two seconds, tap a button, and get back to the patient. A pilot needs a cockpit display, not a text file.
This is true, and these operational interfaces will remain purpose-built GUIs. The distinction comes down to attention: knowledge workers give the computer their full attention because the computer is where the work happens. Operational users give it partial attention because the work happens in the physical world and the computer supports it.
But even here, the same principles transform what’s underneath.
Today’s hospital software is typically a single enormous application that tries to do everything — scheduling, billing, charting, medication tracking, lab results, imaging, compliance reporting — all bundled into one monolithic system from one vendor. This is why it costs millions, takes years to implement, and is almost impossible to switch away from. The interface and the infrastructure are welded together.
Applying software engineering principles means separating the layers. The data lives in open, structured formats. The business logic is modular and auditable. The interface becomes a thin layer on top — purpose-built for the doctor or the nurse, but drawing from the same well-organized data that the billing team, the researchers, and the compliance officers access through their own tools.
The result is smaller, more modular applications instead of monoliths. The emergency department gets an interface designed specifically for emergency medicine, not a general-purpose screen with irrelevant tabs hidden. The billing department gets a different view of the same data. A researcher can query the same underlying records directly. Each piece can be built, replaced, or improved independently because the data layer doesn’t belong to any single application.
This is how software has always worked in well-run technology companies — small, composable services with clean interfaces between them. The insight is that the same architecture applies to every industry’s software, whether the end user is a programmer, a banker, or a doctor. The interfaces look different. The engineering underneath is the same.