Remember the panic when ChatGPT could write a function? Developers feared for their jobs. But the real threat isn’t that AI will replace coders—it’s that it will reveal how little we actually need code.
Here’s the uncomfortable truth: if you think ‘coding is solved,’ you’ve already lost the plot. LLMs are brilliant at turning a well-specified problem into runnable code. That’s the easy part. The hard part—the part that’s about to become the only thing that matters—is deciding which problem to solve in the first place.
The moment code becomes free, the question ‘what should we build?’ becomes the only thing worth paying for.
This isn’t a utopian vision. It’s a threat. The more coding is automated, the more the messy human work—questioning requirements, navigating tradeoffs, understanding users—gains value. And that’s the part we’ve historically treated as less important than ‘real coding.’
You’ve probably felt it: the sinking realization that your team spent months building a feature no one asked for. The code worked. The problem was the problem. That waste is about to become catastrophic when code generation is instant.
Here’s where it gets really uncomfortable. Mature codebases are not assets—they’re liabilities. Every line of code you’ve written is a drag on future iteration. The advantage moves to people and organizations that can throw away code faster and iterate on intent.
Your legacy codebase isn’t a treasure; it’s a pile of assumptions that are now harder to challenge than to maintain.
So what’s the new skill? It’s not prompt engineering. It’s not ‘AI-assisted coding.’ It’s the ability to ask better questions before a single line is generated. It’s the discipline to say ‘no’ to a feature that sounds good but solves the wrong problem. It’s the courage to delete code that works.
I’ve seen this firsthand. The teams that thrive are not the ones with the fastest code generation—they’re the ones with the best product thinking. They understand that the binding constraint has shifted from implementation to problem definition.
If you build or buy software, your edge is no longer shipping code. It’s the quality of the questions you ask before a line is generated.
So stop celebrating the death of syntax. Start worrying about the death of judgment. Because if you can’t decide what to build, AI will happily build the wrong thing faster than ever.
The future belongs to those who can unlearn the habit of writing code and learn the art of deciding what not to build.
FAQ
Q: Doesn't this argument assume that humans will always be needed to define problems? Couldn't AI eventually do that too?
A: Yes, it's possible. But the current generation of LLMs excels at pattern matching, not at the deeply contextual, value-laden work of determining what matters to a specific user in a specific business. That said, if AI reaches that level, then the entire concept of 'software' transforms—and we're talking about a different revolution entirely.
Q: What should I do practically if I'm a developer or a team lead right now?
A: Invest time in user research, product thinking, and the ability to question requirements. Reduce the cost of experimentation by making your codebase modular and disposable. Prioritize fast iteration over perfect architecture. And start valuing the skill of 'saying no' as much as the skill of building.
Q: Aren't mature codebases still valuable because they contain business logic and edge cases that LLMs don't know?
A: Some business logic is valuable, but much of it is accidental complexity. The real value is in the understanding of the domain—which should be documented and shared, not buried in code. If your codebase is the only source of truth for your business rules, you have a documentation problem, not a code problem.