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

Breaking the spell of vibe coding

fast.ai

Post reply on HN
Print view View original

291–300 of 375 posts

Re: Breaking the spell of vibe coding

#291

Post by failingforward »

manmal wrote: post #283
jackfranklyn wrote: post #219

[flagged]

> A hallucinated edge case in a tax calculation doesn't throw an error. Would double entry book keeping not catch this?

Not necessarily. Double entry bookkeeping catches errors in cases where an amount posted to one account does not have an equally offsetting post in another account or accounts (i.e., it catches errors when the books do not balance). It would not on its own catch errors where the original posted amount is incorrect due to a mistaken assumption, or if the offset balances but is allocated incorrectly.

Re: Breaking the spell of vibe coding

#292

Post by chrisjj »

> “People who go all in on AI agents now are guaranteeing their obsolescence. If you outsource all your thinking to computers, you stop upskilling, learning, and becoming more competent”

Likewise those people are guaranteeing "AI"s obsolesence. The parrots need humans to feed them.

Re: Breaking the spell of vibe coding

#293

Post by ej88 »

slopinthebag wrote: post #208
atleastoptimal wrote: post #165

Earlier quoted context omitted.

They probably still need to be able to read and distinguish good vs bad code, evaluate agent decisions, data structures, feasibility, architectural plans, etc, all of which require specific software engineering expertise, even if they don't end up touching the code directly.

But that doesn't make sense. They claim that AI is writing 100% of the code, yet if they need to be able to read and distinguish good vs bad code, evaluate agent decisions, data structures, feasibility, architectural plans, etc, that implies they are writing at least some of the code? Or else why would they ever need to do those things?

what doesn't make sense? "writing" the code is implementation

you still need good swes to distinguish if the generated code is good or bad and adjust the agent and plan the system

ime opus is smart enough to oneshot medium to small features by learning the existing codebase provided you give it the business context

Re: Breaking the spell of vibe coding

#294

Post by chrisjj »

ryan_n wrote: post #244
rafaelmn wrote: post #221

Earlier quoted context omitted.

> Vibe coding would be catastrophic here. Not because the AI can't write the code - it usually can - but because the failure mode is invisible. A hallucinated edge case in a tax calculation doesn't throw an error. It just produces a slightly wrong number that gets posted to a real accounting platform and nobody notices until the accountant does their review. How is that different from handwritten code ? Sounds like s…

It’s shocking to me that people even ask this type of question. How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human that will logic through things and find the correct answer.

I'd say more importantly, vs. human who on failing to find an acceptable answer, says so.

Re: Breaking the spell of vibe coding

#295

Post by vidarh »

jackfranklyn wrote: post #219

[flagged]

If the failure mode is invisible, that is a huge risk with human developers too.

Where vibecoding is a risk, it generally is a risk because it exposes a systemic risk that was always there but has so far been successfully hidden, and reveals failing risk management.

Re: Breaking the spell of vibe coding

#296

Post by chrisjj »

jt2190 wrote: post #290
ryan_n wrote: post #244

Earlier quoted context omitted.

It’s shocking to me that people even ask this type of question. How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human that will logic through things and find the correct answer.

> How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human... Your claim here is that humans can't hallucinate something random. Clearly they can and do. > ... that will logic through things and find the correct answer. But humans do not find the correct answer 100% of the time. The way that we address human fallibility is to create a system t…

> The way that we address human fallibility is to create a system that does not accept the input of a single human as "truth".

I think you just rejected all user requirement and design specs.

Re: Breaking the spell of vibe coding

#297

Post by matwood »

kalaksi wrote: post #276
matwood wrote: post #162

Earlier quoted context omitted.

Sort of, but the speed at which I can see results and the ability to quickly get unstuck does pull me in more than just coding. While I find both enjoyable, I'm more of a 'end result' person than a 'likes to the type in the code' person. There was a conversation about this a month or so ago referencing what types of people like LLMs and which do not.

I saw a conversation like that but, like here, I didn't always understand what they meant with "end result". Was it only the app GUI and they don't care about the code at all, or do they still care about the code quality, the architecture and planning.

I've written software that solved business problems in everything from Visual Basic to C++. The end result can include the things you list, but typing in the code to me is down the list of importance.

Re: Breaking the spell of vibe coding

#298

Post by jayd16 »

rafaelmn wrote: post #221
jackfranklyn wrote: post #219

[flagged]

> Vibe coding would be catastrophic here. Not because the AI can't write the code - it usually can - but because the failure mode is invisible. A hallucinated edge case in a tax calculation doesn't throw an error. It just produces a slightly wrong number that gets posted to a real accounting platform and nobody notices until the accountant does their review. How is that different from handwritten code ? Sounds like s…

One major difference is the code has an owner who might consider what needs a test or ask questions if they don't understand.

To argue that all work is fungible because perfection cannot be achieved is actually a pretty out there take.

Replace your thought experiment with "Is one shot consultant code different from expert code?" Yes. They are different.

Code review is good and needed for human code, right? But if its "vibe coded", suddenly its not important? The differences are clear.

Re: Breaking the spell of vibe coding

#299

Post by linsomniac »

>Should you gamble your career? [...] Consider the case where [you let your skills stagnate and AI falls flat].

Sure. But the converse is true as well: consider the case where you don't learn the AI tooling and AI does improve apace.

That is also gambling your career. Are you ready for pointed questions being asked about why you spent 2 days working on something that AI can do in 15 minutes, so be prepared with some answers for that.

Re: Breaking the spell of vibe coding

#300

Post by vidarh »

ryan_n wrote: post #244
rafaelmn wrote: post #221

Earlier quoted context omitted.

> Vibe coding would be catastrophic here. Not because the AI can't write the code - it usually can - but because the failure mode is invisible. A hallucinated edge case in a tax calculation doesn't throw an error. It just produces a slightly wrong number that gets posted to a real accounting platform and nobody notices until the accountant does their review. How is that different from handwritten code ? Sounds like s…

It’s shocking to me that people even ask this type of question. How do you not see the difference between a machine that will hallucinate something random if it doesn’t know the answer vs a human that will logic through things and find the correct answer.

Because humans also make stupid random mistakes, and if your test suite and defensive practices don't catch it, the only difference is the rate of errors.

It may be that you've done the risk management, and deemed the risk acceptable (accepting the risk, in risk management terms) with human developers and that vibecoding changes the maths.

But that is still an admission that your test suite has gaping holes. If that's been allowed to happen consciously, recorded in your risk register, and you all understand the consequences, that can be entirely fine.

But the problem then isn't reflecting a problem with vibe coding, but a risk management choice you made to paper over test suite holes with an assumed level of human dilligence.

Post reply on HN