The Software That Shouldn't Exist

Everyone's worried about AI replacing engineers. The more interesting question is what happens when the cost of building software drops so dramatically that entirely new categories of software become viable.

The industry is calling this "personalized software." Custom tools built for a specific person, a specific context, a specific moment. Software that never leaves your machine. Software that would never justify a product. Software that, until recently, simply wouldn't exist.

Inelastic Demand and the Missing Software

The demand for software is remarkably inelastic. Lower the cost of development, and you don't just get existing software faster. You get software that previously had no economic justification to exist.

Think about all the problems in your workday that could be solved with software but aren't. Not because the solution is technically hard, but because the cost of building it exceeds the value of solving that specific problem. These are the ones that live in spreadsheets, manual processes, and "we just deal with it" workflows.

When AI dramatically reduces development cost, these problems suddenly become worth solving. GitHub's research found that developers using AI assistance completed coding tasks 55% faster in controlled studies. That kind of reduction doesn't just accelerate existing projects. It fundamentally changes the calculus of which problems are worth solving at all.

AWS Cost Analysis: A Case Study

I've analyzed AWS costs and usage reports at multiple companies. The pattern is always the same: you find the glaring issues quickly, then hit a wall. Tools can identify high-spend services and compare them to utilization, but they can't understand what the spend should be given your specific architecture.

The gap isn't technical capability. It's context. Generic cost analysis tools don't know that your Lambda functions process batch jobs that should correlate with your data pipeline schedule. They don't know your microservices architecture or why certain EC2 instances spike on the 15th of every month.

Recently, I used Claude Code to build analysis scripts for cost and usage reports while giving it context from the platform and application repos. The result was a custom analysis tool that understood the architecture, correlated spend patterns with actual code paths, and identified optimization opportunities no generic tool would catch.

This is throwaway personalized software. I spent a couple of hours building it interactively. It might get used again next month for a cost touchup. It will never be productized. It will never be shared. It doesn't need to be. It solved my specific problem with my specific context at a cost that justified the effort.

Another Example: DMARC Monitoring

DMARC monitoring follows the same pattern. You get zip files full of reports about email delivery issues. Products exist to analyze these, but if you just need to check for glaring configuration problems, that's a 30-minute Claude Code session. Parse the zips, surface anything concerning, and move on.

The economics have flipped. Previously, the minimum viable approach was buying a product. Now, it's often building a quick custom tool that does exactly what you need.

What This Means for Software Development

The software engineering role isn't disappearing. It's transforming. More software will get built, and a significant portion of that software will never see the light of day outside an individual developer's machine.

Personal analysis tools. Custom automation scripts. One-off data processing pipelines. Helper utilities that smooth over rough edges in your workflow. Plugins that integrate two tools in exactly the way you need.

None of this needs to be production quality. It doesn't need tests. It doesn't need documentation. It doesn't need to handle edge cases it will never encounter. It just needs to work for your specific use case right now.

For engineering leaders, this means your team is likely already building these tools. The question is whether you recognize and support that work.

The Explosion You Won't See

The amount of software being written is going to explode, but you won't see most of it. Much of this won't show up in product launches or public repos. It will be scattered across developers' machines, solving individual problems that were never worth solving before.

This is what happens when you dramatically lower the cost of development. You don't just accelerate existing software. You create entirely new categories of software that exist only because the economics finally make sense.

The question isn't whether AI will replace engineers. The question is what problems become worth solving when building software costs almost nothing.


Related Content

Previous
Previous

Making Interviews Objective with AI (Without Making Them Worse)

Next
Next

Shifting Left - How Small Teams Handle Organizational Gaps Without Breaking