AI has made writing code incredibly cheap. But building software that can survive change, scale, and someone else’s bad decisions is still engineering.
A founder told me this while negotiating a contract.
His argument was simple:
“If we have AI to generate code, why should we pay for a developer’s hours?”
He said code had become cheap to write. He only wanted a working MVP. He didn’t care about code quality.
I hesitated.
And he didn’t sign the SOW.
At first, I thought it was a fair question.
Then the product engineer in me remembered the last project where we had to rebuild a broken app because the previous agency couldn’t maintain it.
Most of the code was AI-generated.
Random directory structures. Files and functions that didn’t quite match. Long, meaningless comments. Weird test cases. Logic scattered across the codebase with no obvious reason why.
While rebuilding it, we realized just how expensive bad code actually is.
And nobody understands this better than a burnt-out founder or a CTO who has inherited a codebase where every seemingly simple change turns into a mini archaeological expedition.
But from a founder’s perspective, all of this sounds like technical jargon.
Clean Code. System Design. Architecture. Domain language. TDD.
How do you explain the value of all that to someone who just wants the product shipped?
I tried to explain it like this:
AI has made generating code cheap. It hasn’t made building software cheap.
Writing a few thousand lines of code is easy.
Building a system where those thousands of lines continue to make sense six months later is a different problem.
It’s like building a house.
Having AI generate bricks faster doesn’t eliminate the need for a blueprint, structural design, foundations, plumbing, or someone who understands how the whole thing fits together.
The fundamentals of software engineering haven’t disappeared.
If anything, they matter more now.
Because the bottleneck has moved.
The most draining part of building with AI agents isn’t writing code anymore.
It’s keeping the agents in sync.
You need a shared system design.
A shared language for the product and its domain.
Clear boundaries around what each part of the system is supposed to do.
And increasingly, you need a leash.
That’s where practices like test-driven development become interesting in the age of AI agents.
Tests aren’t just there to catch bugs.
They become guardrails for agents that can otherwise happily run in ten different directions.
The irony is that AI can make a bad engineer dramatically faster at producing bad code.
It can also make a good engineer dramatically faster at building great software.
The difference isn’t the cost of generating the code.
The difference is who is responsible for the system.
Top comments (0)