If AI coding is lowering your code quality, you're not managing quality right
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
If AI coding is lowering your code quality, you're not managing quality right
Unofficial Hacker News client; not affiliated with Y Combinator.
axegon_ · · focus · HN ↗
skybrian · · focus · HN ↗
I’m doubtful that the author’s recommendation always work, but I do some similar things and they do seem to help.
pydry · · focus · HN ↗
You've missed the point. Nobody doubts writing code well or badly is indeed a skill issue.
The question is that "once you account for all of the things you need to do to make the code very high quality, did vibe coding actually provide any real value?"
I'm certain there are guardrails that help bolster vibe coding but I'm equally certain that when ive prompted something important I usually have to redo it enough times that just writing it manually myself usually would have been quicker.
Then I watch other people who code who dump on that opinion and I see total slop. They just can't tell the difference.
AndrewKemendo · · focus · HN ↗
That seems to be the primary difference I’ve found between people who embrace gen code and those who dont
The ones who dont, seem to like the physical act of typing, and that tends to cluster with people who write software all day
pydry · · focus · HN ↗
if you find the ratio between typing and thinking to be very high then you're probably producing a lot of slop.
This is a common theme I find when I hear about people's AI coding success stories. Where they say "its good at X" where X might be "backfilling unit tests" or "writing boilerplate" I usually think "if you find you need to do X a lot youre definitely doing programming wrong.
Ive actually yet to hear an X applied to production code that doesnt make me think that.
Daishiman · · focus · HN ↗
This is one of those things we value in theory in engineering but not in practice. Reducing code as an artifact might mean coming up with clever ways or compressing data, like making code that generalizes and abstracts. This is fine if you're experienced and clever. But a lot of organizations don't have that many clever or experienced engineers and those tools cause more harm in the hands of those people. Hence compromises must be reached and verbosity is valued because it is explicit.
I used to believe otherwise but then I worked in larger orgs with a lot of mediocre people who still provided value but needed to be given the means to add value.