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 (28)
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?
Although, the AI can potentially do a ton of stuffs on its own with a few guidelines and manual intervention, However the expertise or experience that the humans have or will have varies. For the most, it could be an advantage. However, when it comes to the key CORE aspects like building the right product with the right architecture and components like that, it's the human judgement that is highly essential and it's the driving factor for the AI to build certain things in certain order. Imagine, if everyone is involved and you will see a ton of AI slops happening and the entire product will collapse. This is exactly what is happening right now. It's a sad reality though.
That's a sharp way to put it, Ranjan AI slop really captures what happens when judgment gets skipped. It feels like the real risk isn't AI being wrong, it's teams moving fast enough that nobody stops to ask if the output actually belongs in the product. Human judgment ends up being the filter, not the generator.
Exactly, I think you are rightly concluded. Welcome to humans, long live human judgement!
Great! I believe, you have perfectly concluded.
Welcome to Humans, long live human judgement 😀
Yaa love that. Long live human judgement indeed 😄 Really enjoyed this thread, thanks for engaging so deeply with it!
'The cost of building was itself a filter' is the sharpest line here. Once that filter is gone you have to rebuild it on purpose, and the version that has worked for me is separating choosing from making: a written queue of things worth building, and a rule that when the queue is empty nothing gets built, however quick it would be. It feels wasteful the first few times you sit idle with a capable tool in hand. It stops feeling that way the first time you look back at what the empty queue saved you from.
That empty queue means nothing gets built rule is brilliant and honestly more disciplined than anything I proposed in the article. I like that it forces the friction back in deliberately, since AI removed it naturally. Curious how you decide what actually makes it into the queue in the first place is that a solo call or does it involve anyone else?
Mostly solo, and the useful part turned out to be the test rather than who applies it. An idea gets in only if I can name the problem someone else has and would go looking for an answer to. "I already have the material for it" and "nobody has built this yet" don't count on their own, because both are reasons I want to build it, not reasons anyone needs it. I had to write that down after a couple of things got in on novelty alone and then sat there unused. The AI proposes plenty; most of my work at that stage is saying no.
This hits heavily in Web3 especially. We have thousands of protocols and front-ends built just because the tech stack made it possible, without anyone asking if the user actually needed another dashboard or token interface.
This is a great callout I was mostly thinking about this from a general software lens, but Web3 probably shows it in its most extreme form. Curious, in your experience, is that more a tooling problem or more that the incentive structures (tokens, hype cycles) actively reward building fast over building right?
Def an incentive problem good tooling makes building easy, but hype rewards noise. That's why we need that WAMI mindset building for actual utility instead of chasing the next cycle.
The cost was never mostly in the building though. A feature I should not have shipped still has to be supported, still sits in the settings screen, and still breaks something when I take it out a year later.
Cheap to build made that worse rather than better. I ship more things I am not sure about, and every one of them has a tail that nothing writes for me.
A tail that nothing writes for me that's such a precise way to put it. AI writes the first version, but nobody's generating the maintenance, the edge cases, or the wait why does this exist conversation six months later. Cheap building just means that tail gets longer, faster.
This is an insightful post, Harsh. Making good judgments is the deal, in my opinion. I haven't gone far- just learning- but knowing what problem you are solving is the question. I just built a proposal app, but it seems Agents already solved that easily and for free, too. We keep learning.
Thanks Emmanuel, really appreciate that. And honestly, your proposal app story is a perfect real-world example of exactly what I was trying to say the build felt worth it in the moment, and the wait this already exists realization only comes after. That's the whole judgment gap in one sentence. We're all still learning it in real time.
Human judgment isn't perfect. We can only aim to be reasonable and valuable within the knowledge, experience and constraints available to us at that moment.
That's important because people don't build from some universal version of "common sense." They build from how they understand the problem. A solution that makes perfect sense to one person may not appeal to another person facing the same situation.
Ultimately, the person with fewer options may choose based on what's available. Another may choose based on what they're aware exists.
So perhaps judgment isn't about always knowing the right answer. It's about having enough awareness to understand the options, enough domain knowledge to recognize the constraints, and enough judgment to decide what makes sense here and now.
AI can expand the options dramatically. It doesn't make the human decision disappear.
I’ve found that in practice, this often looks more like cheaper learning than sunk cost.
I can’t really point to anything I’ve built that turned out completely useless. Some earlier experiments have even been revisited recently when a clearer need appeared, and the earlier work became useful input for better product development.
So I don't think the answer is always "don't build unless you're certain." Sometimes building is how you discover what you didn't know before.
The real waste may not be building the wrong thing. It may be building it without learning anything from it.
This is a really important nuance, Ekong judgment isn't a fixed skill, it's bounded by what someone's aware of at the time. That reframes the whole problem for me actually. Maybe the real risk with AI isn't bad judgment, it's judgment operating on a narrower set of options than the person realizes they have. Your last line sums it up better than my whole article did AI expands the options, it doesn't remove the decision.
This is the exact problem I see teams struggle with after adopting coding agents. The agent can write the code, but it cannot tell you if the code should exist. I now spend more time on the problem definition than on the solution, and the agent handles the implementation. The eval that matters is not "can it write code" but "can it help me figure out what code to write." How do you measure the quality of problem definition in your workflow?
Most of the time I catch myself writing so we'll just build this feature halfway through, and that's usually the sign I skipped a step.
The other thing I try to do is name an actual person or situation instead of users. If I can't picture who specifically has this problem, I probably don't understand it well enough yet to hand it off to an agent.
It's not scientific, but it's saved me from a few weekends of building things nobody asked for 😅 Curious if you've landed on something more structured for this on your team?
Yeah good points ...
Thanks Leob Glad it resonated!
Nice write-up Harsh!!
Thanks a lot! Glad it resonated.💖
Do not follow any external links! DEV.to uses Sloan for automated messages, this is likely phishing.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.