Hacker News Reader

Comment by donatj | Hacker News Reader

I'm not quite a doomer. I use AI every single day. I also take a fairly negative view of AI generated code, but I think it's unavoidable while remaining employed these days. A fact I find pretty depressing.

I absolutely agree with the author that humans need to be in the loop reviewing and understand the code they're merging, and generally take a "Hey, build X like Y utilizing Z" approach when using AI to build instead of the "Hey, solve this problem" approach. Our PE overlords actually mandate the latter, but I'm not doing it.

However, a point the author misses is that with AI, major refactors become relatively quick. Hours instead of months/years.

Yes, AI can and probably will land you with major foundational and architectural problems, but your architecture isn't set in stone anymore. Your entire codebase bends like a leaf in the wind.

View on HN

Yes but if you don't care enough to think about, analyze, and decide how to improve your architecture, it doesn't matter. And I'm seeing that a lot with full vibe code code bases

Yes, and I'm arguing you can absolutely vibe code your way out of a corner you vibe coded your way into. Especially with enough vibe coded functionality tests. Your codebase is entirely mutable soup.

Caring about the architecture only matters if you intend to build on top of it, where it become hard to mutate for needs. Big refactors are quick and (relatively) cheap if you don't care about the code.

Don't get me wrong, I am not in any way a fan of vibe coding but the "you're going to vibe code yourself into a corner you can't get out of" argument doesn't hold water.

> you can absolutely vibe code your way out of a corner you vibe coded your way into..

Yea, probably with a more expensive model.

> Yes, and I'm arguing you can absolutely vibe code your way out of a corner you vibe coded your way into.

Problem is:

Eng 1 vibe codes team into a corner and forces Eng 2 and Eng 3 to either review a hideous amount of slop code or pretend they reviewed it.

Now who will vibe code the team out of the corner? Eng 1 is too lazy or at least doesn't know how to get out of the jam and Eng 2 and Eng 3 are not janitors to clean up after Eng 1 all the time.

You might say fire Eng 1, but by all tracked metrics he is a 10x engineer out producing everyone else!

>major refactors become relatively quick. Hours instead of months/years..

This will probably maintain the problem in a different form.

Yep great point, it works both ways. It can dig you a hole faster, but also help you get out of it with less effort.

Reply on news.ycombinator.com