In my last post, I explored the distinction between probabilistic AI and deterministic encoded software — arguing that for many business-critical workflows, a probabilistic, “usually right” approach simply isn’t good enough. But there’s a second, equally important dimension to why I believe software still matters that gets considerably less attention: speed and efficiency.
The Multitasker Trap
There’s a useful framing — in my mind — for how Large Language Models (LLMs) are being used; and that is as an extraordinary multitasker. You can use them for almost anything. Writing, coding, analysis, translation, summarization — the range is genuinely remarkable. And for many use cases, that versatility is exactly what you need; and I believe that many are using LLMs in that way.
But here’s the thing about multitaskers: they’re excellent for generalists.
Fans of Good Eats — Alton Brown’s deep-dive cooking show — will remember his running crusade against unitaskers: the garlic press, the avocado slicer, the strawberry huller. His argument was that a well-equipped home kitchen should rely on versatile tools that can do many things reasonably well. For a home chef, that’s a sensible philosophy. You can get by without a bunch of expensive tools in the kitchen. But that falls down when speed and quality are required in a more professional environment.
The same logic applies to home improvement versus professional construction. I own a drill, a circular saw, a hammer, a handful of screwdrivers. Those tools work fine for my basic needs around the house, but they would not suffice on a job site. A professional contractor doesn’t show up with just a single circular saw!
There is a similar multitasker trap in software with AI: the assumption that because AI can do something, it’s the right tool to use for that thing — every time, at scale, and even in production!
When Speed and Efficiency Actually Matter
Here’s what encoded software delivers that LLMs often cannot: predictable, repeatable performance … at speed!
If your customer is executing the same workflows over and over — maybe thousands or millions of times per day (or really even just a few) — processing transactions, routing records, triggering automated actions — they need it executed quickly and inexpensively. And they need it done consistently each time, without variable compute costs that scale unpredictably with volume.
Well-designed software is purpose-built for exactly this. It doesn’t need to reason; it doesn’t need to infer. It executes a defined workflow with minimal overhead, and it does so consistently and quickly.
ASICs, FPGAs, and a Hardware Analogy Worth Borrowing
I spent time early in my career investing in semiconductor companies, and a distinction from that world maps surprisingly well onto this one.
FPGAs (Field Programmable Gate Arrays) and ASICs (Application-Specific Integrated Circuits) come to mind as an analogy. An FPGA is flexible — you can actually program the workflow on the chip, reconfigure it, adapt it to new use cases. An ASIC, by contrast, is hardened. It does one thing. It can’t be repurposed. But within that constraint, it executes its specific workflow with extraordinary speed and efficiency — at a fraction of the power consumption and cost of a general-purpose solution.
LLMs are the FPGAs of this analogy: flexible, configurable, useful across a huge range of problems. They are fantastic for discovery, and for use in situations where you need a multitasker — usually because the job isn’t at a large enough scale to justify the cost of a custom-developed ASIC. Encoded software is the ASIC: purpose-built, fast, efficient, and optimized for a specific job (but a lot cheaper to develop than an ASIC)! Neither is universally superior. The question is which is right for the task at hand!
Discovery vs. Production: Two Modes, Two Tools
One place we are seeing this distinction playing out clearly is in product development itself. AI tools like Lovable and Claude Code have become genuinely impressive for rapid prototyping — spinning up mockups, building demoable prototypes, exploring product directions quickly with customers and teams. For discovery work, that flexibility is a significant asset. Speed of iteration matters more than optimized execution.
But the moment you’re ready to move from prototype to production — to hand customers an enterprise-grade, secure, performant piece of software — you’re back in ASIC territory. The flexibility that made the AI tool useful in discovery becomes a liability in production. You need the encoded software.
The capable software teams I work with understand this instinctively: use AI where flexibility and speed of iteration matter, use encoded software where consistency, performance, and reliability do. These aren’t competing philosophies — they’re complementary modes.
The Bigger Point
The AI-as-everything narrative tends to flatten these distinctions. And that’s understandable — the demos are impressive, the range genuinely is broad, and the technology is moving fast. But real enterprise software deployments don’t run on demos, and they require hardened execution. They run on repeatable, reliable workflows with defined performance envelopes and real cost structures.
I believe software companies that have done the hard work of encoding complex workflows — optimizing for the specific jobs their customers run efficiently at scale — have built something that an LLM call cannot simply replace. The efficiency advantage is real. The performance predictability is real. And for customers who need it, those things matter enormously.
In the next post, I’ll turn to the third leg of the argument: the accumulated context, domain depth, and customer trust that software companies have built over years — and why that, too, represents a durable source of defensibility that isn’t easily disrupted by a foundation model.
