Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vibe Debugging: Enterprises' Up and Coming Nightmare

marketsaintefficient.substack.com

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#41

Post by bootsmann »

riku_iki wrote: post #40
bootsmann wrote: post #34

Earlier quoted context omitted.

Maybe as a small anecdote: I had a coworker ask an AI to write them a function to auth to aws using boto3 and environment variables. The LLM happily complied and gave them a 30 line snippet but it failed to point out that if they were to open boto3 docs it would tell them that it will already default to environment variables when it has no credentials and the whole function is just reinventing the wheel. If you’re th…

The question is how fast and well dev unfamiliar with that API would achieve the goal alone compared to being assisted by LLM: he could set up snippet, run test, see what are the error, ask LLM to check why error could happen.

I don’t believe that the time a dev spends on prompting an LLM over reading an API reference saves a significant chunk of the TCO for the lines of code they write.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#42

Post by riku_iki »

bootsmann wrote: post #41
riku_iki wrote: post #40

Earlier quoted context omitted.

The question is how fast and well dev unfamiliar with that API would achieve the goal alone compared to being assisted by LLM: he could set up snippet, run test, see what are the error, ask LLM to check why error could happen.

I don’t believe that the time a dev spends on prompting an LLM over reading an API reference saves a significant chunk of the TCO for the lines of code they write.

I personally observe very opposite: it safes a lot of time.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#43

Post by juancn »

From TFA:

    Imagine the 3 AM on-call alert. The engineer trying to fix it might be navigating a section of the codebase they've never seen before, generated entirely by an AI. In this scenario, you can't afford to vibe it out or gamble precious minutes while an AI agent attempts a fix. You need ground truth, and you need it fast.
This is where it breaks down for me. If you trusted the AI to do the code, why don't you trust it with the on-call?

Why automate the fun part and keep a human for the shitty part?

I don't really get the reasoning behind all the hype, or better said: I kinda do, but it's more of a knee jerk reaction or essentially FOMO.

What makes me think this is a bubble is the amount of emotion behind the decision making process (plus the fact that almost nobody is making a dime with this so far).

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#44

Post by bsoles »

itsdrewmiller wrote: post #9

> I suspect best practices for "vibe coding" will end up like test-driven development: a proven method for writing better software that many engineers still choose to skip. I’d like to see the proof for TDD; last I heard it slowed development with only minor reliability improvements.

TDD doesn't work for the same reasons why Todo lists don't work. I don't have a good explanation why that is so, but I know from countless examples (mine and other people's) that they don't work.

In general, doing things work, planning to do things don't.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#45

Post by AstroBen »

dogleash wrote: post #31
seadan83 wrote: post #23

Earlier quoted context omitted.

The proof for TDD is usually looking at bug detection rates. Similar for code review. OTOH, the "design damage" of TDD is something overlooked by those metrics. What it boils down to: - TDD in the hands of a junior is very good. Drastically reduces bugs, and teaches the junior how to write code that can be tested and is not just a big long single method of spaghetti with every data structure represented as another di…

Your comment doesn’t distinguish between having a robust automated test suite and doing TDD. I’ll take your comment as testing is good and constraining your workflow to TDD is worthless.

TDD is really commonly misunderstood to be a testing strategy that helps reliability- it's not. It's supposed to guide your software design

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#46

Post by vjvjvjvjghv »

I feel this not much different from dealing with large teams of offshore devs. You constantly get huge piles of code of questionable quality written by people who don’t understand your domain. Doing thorough review probably takes as much time as writing it yourself so you end up shipping code where nobody really knows what the problems are and hope for the best.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#47

Post by juancn »

itsdrewmiller wrote: post #9

> I suspect best practices for "vibe coding" will end up like test-driven development: a proven method for writing better software that many engineers still choose to skip. I’d like to see the proof for TDD; last I heard it slowed development with only minor reliability improvements.

I think it works only for people with a certain thought pattern, the ones that like to think everything up-front before doing anything.

Most people prefer to play around and make several crappy attempts and combine them until the whole is somewhat solved, then go over and polish it a little, and maybe then add tests and fix the behavior in place.

For this last group, TDD it's jarring, unnatural and requires a lot of willpower to follow.

It's not bad in itself, it's just not for everyone.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#48

Post by fallpeak »

bicx wrote: post #8

I have a basic rule: understand and agree with every line of code in a PR I’m responsible for generating (manually or via agent). This simple act prevents 99% of AI-related bullshit code.

Sure. But, and I will die on this hill, it's not vibe coding if you're looking at and understanding the code.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#49

Post by gramie »

Brian Kernighan wrote:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

— The Elements of Programming Style, 2nd edition, chapter 2

So if vibe coding produces code that is as clever as -- or more clever than -- you, then you have no chance of debugging it.

Re: Vibe Debugging: Enterprises' Up and Coming Nightmare

#50

Post by corytheboyd »

itsdrewmiller wrote: post #9

> I suspect best practices for "vibe coding" will end up like test-driven development: a proven method for writing better software that many engineers still choose to skip. I’d like to see the proof for TDD; last I heard it slowed development with only minor reliability improvements.

TDD works if know what 100% of the inputs/outputs look like, AND you know the implementation will be complex, terse, whatever. Write tests, then twiddle a bunch of regex until the tests pass. This situation rarely comes up in real software jobs, but when it does, yeah use it!
Post reply on HN