We spent years trying to make coding easier. Better editors. Better frameworks. Better libraries. Better documentation.
And now AI can write a sur...
For further actions, you may consider blocking this person and/or reporting abuse
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 😀
'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.