> The problem is that vibe coding makes it possible to build a substantial solution before learning enough about the problem to recognise that a much better solution exists
As a software developer we should fear chasing "better" solutions, that path always lead to procrastination, "kitchen sink" and probably not what users wants. "Good enough" should suffice in most cases. Sure if you are building a super mega critical software to land a plane or something like that, is different. But every day software, shouldn't be treated like "carved in stone" and stuff that should last a 1000 years. Code can be cheap now (calling it "vibe coding" doesn't help).
You can create or modify something quite fast now. Better to focus on testing, documentation, making sure that software will do what is expected.
mromanuk · · focus · HN ↗
As a software developer we should fear chasing "better" solutions, that path always lead to procrastination, "kitchen sink" and probably not what users wants. "Good enough" should suffice in most cases. Sure if you are building a super mega critical software to land a plane or something like that, is different. But every day software, shouldn't be treated like "carved in stone" and stuff that should last a 1000 years. Code can be cheap now (calling it "vibe coding" doesn't help).
You can create or modify something quite fast now. Better to focus on testing, documentation, making sure that software will do what is expected.
rafaelRiv · · focus · HN ↗
What a bad take. This is a discipline problem. You can chase both and be careful with the new solution.