Deciding What Software Deserves to Be Written at All

We spent twenty years optimizing how to write software. The next twenty might be about deciding what software deserves to be written at all. For the last decade, we cared about clean abstractions, reusable components, proper architecture, modularity, maintainability. All of that made sense because humans were the primary producers and maintainers of code. The constraints of our brains shaped the structure of our systems. But something subtle is changing. When I open my editor today, I’m not staring at a blank file anymore. I’m describing intent. I’m reacting to output. I’m refining drafts. The first version of almost anything is now generated in seconds. The role of effort has shifted from construction to evaluation. This changes the unit of leverage. Earlier, leverage came from knowing how to implement something efficiently. Now leverage increasingly comes from knowing what should exist in the first place. If you can articulate the problem well, the implementation follows almost automatically. And this has second-order effects on SaaS. A lot of products historically justified their existence by abstracting away complexity that was painful for humans to build repeatedly. Internal dashboards, workflow tools, small CRMs, reporting layers. These made sense because custom-building them required weeks of engineering time. But if describing your workflow in plain English can generate a bespoke internal tool in minutes, the economics start to wobble. The advantage of “we already built it for you” weakens when building it yourself is no longer expensive. I don’t think SaaS will disappear. I think the definition of value moves up the stack. Distribution becomes more important than implementation. Data becomes more important than UI. Trust becomes more important than feature lists.