We spent years trying to make coding easier. Better editors. Better frameworks. Better libraries. Better documentation.
And now AI can write a surprising amount of the code for us.
So we finally solved the problem.
Right?
Not exactly.
We solved "How do I build this?"
We still haven't solved the harder question: "What should I build?"
And when building becomes cheap, building the wrong thing becomes cheap too.
We always wanted to write code faster
Every generation of developer tools has chased the same goal.
Stack Overflow. GitHub. Package managers. Frameworks. IDEs. Autocomplete. Copilot. Now AI.
The goal was always the same: reduce the distance between an idea and working software.
And honestly, it worked.
Then we got AI
"I need a dashboard."
AI: "Sure."
"I need authentication."
AI: "Sure."
"I need an API."
AI: "Sure."
"I need tests."
AI: "Sure."
A few years ago, some of these things would have taken hours or days. Now you can get a working prototype surprisingly quickly.
And that's where things get interesting.
The cheaper it gets to build, the easier it gets to build the wrong thing
Here's the contradiction at the center of all this.
Earlier: bad idea → expensive implementation → natural friction. The cost of building was itself a filter. Most bad ideas quietly died before anyone finished them.
Now: bad idea → AI → working prototype. The friction is gone.
AI didn't just lower the cost of building good software. It lowered the cost of building unnecessary software.
But I can build it in a weekend
This is where it gets personal, because I've fallen for this exact trap.
You get an idea on a Friday. It sounds useful. You can already picture how it would work. AI makes the implementation feel almost effortless, so you start building.
Ask AI for the initial architecture. Generate the UI. Wire up the API. Fix a few errors along the way.
By Sunday, it works.
And that's when you realize you never actually answered the most important question.
Who actually needs this?
I've built things just because I could
I had an idea. It sounded useful. I could imagine exactly how it would work. AI made the implementation feel almost effortless, so I just... started.
The weird part wasn't that I finished it.
The weird part was realizing I'd spent hours answering "How?" without spending ten minutes on "Why?"
The prototype worked perfectly. Nobody, including me, actually needed it.
AI is very good at answering "How?"
How do I build authentication? How do I cache this? How do I create this API? How do I deploy this?
AI can help enormously with all of it.
But "Should we build authentication for this?" and "Do users actually need this feature?" are different questions entirely.
AI can accelerate implementation. It doesn't automatically provide judgment.
It's easy to build is not a reason to build it
Developers say it all the time: "It'll only take a few hours."
But a few hours to build can become months of maintenance — bugs, dependencies, security, documentation, support, future feature requests, technical debt that someone has to carry.
The cost of writing the first version is no longer the whole cost of the software.
A working feature can still be a bad decision
A feature that ships but nobody opens. A dashboard nobody checks. An abstraction nobody needed. A microservice that could have stayed a function. An AI-generated automation replacing a manual process that took thirty seconds anyway.
Finished doesn't mean valuable. Working doesn't mean worth maintaining.
Maybe coding isn't the hardest part anymore
The question used to be: can you build it?
Increasingly, the question is: can you decide whether it deserves to be built?
The valuable skills are shifting problem framing, asking better questions, understanding users, identifying real constraints, knowing when to stop, saying no.
When implementation becomes cheaper, judgment becomes more valuable.
I'm not saying we should stop using AI
Quite the opposite.
AI is fantastic for prototypes, boilerplate, experiments, repetitive code, tests, documentation, and exploring unfamiliar APIs. It turns an idea into something tangible faster than anything we've had before.
The problem isn't building faster.
The problem is confusing faster building with better decisions.
Before I build something now, I ask five questions
1. What problem does this actually solve?
Not "what does this feature do" but what problem disappears because this exists?
2. Who actually has this problem?
If the honest answer is "developers, probably" that's worth investigating further before writing a line of code.
3. What happens if we don't build it?
If the answer is "nothing," that's your answer.
4. What's the simplest version that proves the idea?
Don't build the whole product. Build enough to learn something.
5. Would I still build this if AI didn't make it easy?
This is the signature question. AI can make bad ideas feel irresistibly cheap this question cuts through that.
Productivity needs a new definition
Productivity used to mean more code in less time. More commits, more features, faster implementation.
But AI can help almost anyone produce more code now. That definition doesn't hold up anymore.
Productivity isn't how much code you produce. It's how much unnecessary code you avoid producing.
We're moving from code scarcity to decision scarcity
Writing code used to be expensive. It's becoming cheap.
Good decisions are still expensive which problem, which user, which architecture, which trade-off, which things to deliberately ignore.
The bottleneck is slowly moving from implementation to judgment.
Maybe the best developers won't be the ones who build the most
Maybe they'll be the ones who know what not to build the ones who can look at an impressive AI-generated prototype and say, "This is impressive. But we don't need it."
That's not doing less engineering.
That's doing more thinking before engineering.
Where this leaves us
AI is making it easier than ever to turn ideas into software. That's incredible.
But it creates a new problem. When almost anything can be built, the hard part becomes deciding what deserves to exist.
We solved the "How to code" problem.
Maybe we haven't solved the more important one yet: what should we build?
And I'm starting to think that's where the real engineering begins.
What's something you built that you later realized didn't need to exist? 😅
And if you could go back what would you have asked yourself before writing the first line of code?
Top comments (6)
What is more important is to have a really good knowledge and understanding of the business and its problem. For that, one needs to have a Domain expertise. Experience in the field matters a lot. That's exactly what an experienced Software Engineers are meant to.
I always keep telling folks - Imagine you search for a medication on ChatGPT or Claude and it provides you with the suggestions, medications and a ton of other stuffs with the guidelines etc. However, neither you nor the LLM could possibly become a doctor 😆
Great point Ranjan and the doctor analogy really lands. AI can produce the suggestion but domain expertise is what tells you whether that suggestion is even the right one for this specific situation. Curious though do you think that expertise gap narrows over time as engineers rely more on AI, or does it actually widen because fewer people are forced to build that judgment from scratch?
Yeah good points ...
Thanks Leob Glad it resonated!
Nice write-up Harsh!!
Thanks a lot! Glad it resonated.💖