Lately I keep hearing the same take: "software became a commodity since AI arrived."
I disagree. What became a commodity is writing code. And that is not the same thing as building software or a digital product.
The distinction matters more than most people realize — and confusing the two is already creating real, expensive consequences for companies that should know better.
Writing code vs. building software
Think about construction. We have better tools and methods than ever before. A bricklayer today works faster and with less physical effort than one from fifty years ago. Does that mean construction became a commodity?
Of course not. The cost of building something right was never about laying bricks. It was about design, engineering, planning, and the expensive mistakes that show up when any of those fail.
Software works exactly the same way. The cost was never in typing code. It was in:
- Deciding what to build and — just as critically — what not to build
- Designing an architecture that won't become a liability in 18 months
- Understanding the business domain deeply enough to model it correctly
- Integrating with systems that already exist, each with their own quirks and constraints
- Making something survive in production while a team keeps iterating on it
AI doesn't solve any of that. In fact, it makes some of it riskier.
What does the data say?
This isn't just an opinion. The latest DORA report found that AI adoption increases individual developer effectiveness — but also increases deployment instability. Developers produce more output, but systems break more often. We're seeing more outages globally, not fewer.
Why? Because AI enables larger changes in a single pass. And we've known for years — from research on continuous delivery and lean software development — that large batch sizes in code changes produce exactly this: more failures, more rollbacks, more incidents.
This is one of the most well-documented patterns in software delivery. Small, incremental changes are safer. AI encourages the opposite behavior by making it trivially easy to generate hundreds of lines of code at once.
The excavator problem
Here's an analogy that captures the dynamic perfectly.
Give an excavator to someone with no construction experience. They'll move dirt much faster than anyone with a shovel. They'll also break pipes, cut cables, and compromise foundations without realizing it.
The tool amplifies capability, but it also amplifies error.
An experienced operator uses the excavator to do precise, controlled work — because they understand what's underground before they start digging. They know what they can't see. An inexperienced operator just sees the speed.
The same thing happens with AI-assisted development. An experienced engineer uses AI to accelerate well-understood tasks — writing boilerplate, generating test scaffolds, exploring APIs. They know where the risks are and keep AI away from those zones. A less experienced developer uses AI for everything, including the parts that require judgment, context, and domain knowledge that the model simply doesn't have.
The real cost companies are paying
What I'm seeing in conversations with founders and engineering teams is that this confusion is already generating real consequences.
Companies that believe they're saving on development are actually accumulating technical debt at record speed. They're shipping faster, yes — but they're shipping fragile systems that cost more to maintain, more to extend, and more to fix when they inevitably break.
Some patterns I keep encountering:
- Architecture decisions made by prompts: Critical structural choices delegated to an AI that optimizes for "working code" rather than maintainable systems
- No integration testing: AI-generated code that works in isolation but fails when connected to real infrastructure
- Invisible complexity: Codebases that look clean on the surface but have deep coupling, duplicated logic, and no coherent design principles
- False confidence in velocity: Teams that measure productivity by lines of code or PRs merged, not by outcomes delivered
The irony is painful: the companies trying hardest to cut engineering costs with AI are often the ones creating the most expensive problems for their future selves.
Why good engineering is more valuable than ever
Here's the counterintuitive truth: bad engineering just became cheaper to produce. And that makes good engineering worth more than ever.
When anyone can generate code with a prompt, the differentiator is no longer the code itself. It's everything around it:
- Product thinking: Understanding what the user actually needs vs. what they say they want
- Architecture: Designing systems that accommodate change without collapsing
- Operational maturity: Building for observability, reliability, and graceful degradation
- Integration expertise: Making things work together in the real world, not just in a demo
- Engineering judgment: Knowing when to use AI and when to think for yourself
These skills don't get commoditized by AI. They get amplified by it — but only in the hands of people who already have them.
What should founders and CTOs do?
If you're building a product, here's how to think about AI and engineering:
Use AI for acceleration, not for architecture. AI is excellent at generating implementations for well-defined problems. It's terrible at making strategic technical decisions.
Measure outcomes, not output. Lines of code, PRs merged, and features shipped mean nothing if the system is fragile and expensive to maintain. Track deployment stability, incident frequency, and time-to-recovery.
Invest in engineering judgment. The most valuable skill in an AI-augmented world is knowing what to build, how to structure it, and where the risks are. That comes from experience, not from prompts.
Watch your batch sizes. If AI is helping your team make larger changes in a single deploy, you're trading short-term speed for long-term instability. Keep changes small and incremental, regardless of how fast AI can generate code.
Don't confuse cheap code with cheap software. The code is the easy part. The expensive part is everything else — and that part just got more important, not less.
The bottom line
Software is not a commodity. Writing code is. And the gap between those two things is where companies either build something durable or dig themselves into a hole they can't get out of.
AI is the most powerful tool we've ever had for software development. Like any powerful tool, it amplifies whatever you point it at — including your mistakes. The companies that will win are the ones that understand this distinction and invest accordingly.
The question isn't whether you're using AI. It's whether you have the engineering judgment to use it well.
