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

301–310 of 375 posts

Re: Breaking the spell of vibe coding

#301

Post by whateveracct »

wavemode wrote: post #67
daxfohl wrote: post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

> I think it all boils down to, which is higher risk, using AI too much, or using AI too little? This framing is exactly how lots of people in the industry are thinking about AI right now, but I think it's wrong. The way to adopt new science, new technology, new anything really, has always been that you validate it for small use cases, then expand usage from there. Test on mice, test in clinical trials, then go to ma…

> The right amount of usage is knowable - it's the amount which you've validated will actually work for your use case, in your industry, for your product and business.

This is fair. And what I've been doing it. I still mostly code the way I've always coded. The AI stuff is mostly for fun. I haven't seen it transformatively speed me up or improve things.

So I make that assessment, cool. But then my CEO lightly insists every engineer should be doing AI coding because it's the future and manual coding is a dead end towards obsolescence. Uh oh now I gotta AI-signal for the big guy up top!

Re: Breaking the spell of vibe coding

#302

Post by Kiro »

reppap wrote: post #285
gbnwl wrote: post #245

Earlier quoted context omitted.

They need to generate revenue to continue to raise money to continue to invest in compute. Even if they have the Midas Touch it needs to be continously improved because there are three other competing Midas Touch companies working on new and improved Midas Touch's that will make their's obsolete and worthless if they stay still even for a second.

But most of their funding comes from speculative investment, not selling their services. Also, wouldn't selling their own products/services generate revenue?

Making a profitable product is so much more than just building it. I've probably made 100+ side projects in my life and only a handful has ever generated any revenue.

Re: Breaking the spell of vibe coding

#303

Post by written-beyond »

linsomniac wrote: post #299

>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…

"Learn AI tooling"

What is there to learn, honestly? People act like it's learning to write a Linux driver.

The maximum knowledge you need how to write a plan or text file. Maybe throw in a "Plz no mistakes"

There's no specific model, a better one comes out every month, everything is stochastic.

Re: Breaking the spell of vibe coding

#304

Post by Kiro »

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?

This is not the fantastic argument you think it is. 100% is only achievable if you have software engineers at the helm so there's no contradiction here.

Re: Breaking the spell of vibe coding

#305

Post by timmytokyo »

CoinFlipSquire wrote: post #163
RsAaNtDoYsIhSi wrote: post #157

Earlier quoted context omitted.

"Where exactly is the skill to know good code from bad code supposed to come from?" Answer: Books. Two semesters of "Software Engineering" from a CS course. A CS course. CS classes: Theory of Computing. (Work. AKA Order(N) notation. Turing machines. Alphabets. Search algorithms and when/why to use them.) Data Structures. (Teaches you about RAM vs. Disk Storage.) Logic a.k.a. Discrete Math. (Hardware stuff = Logic. Al…

I feel like this answer is reductive. It's not just having a bunch of academic syntax. You need reps. You can't seriously be suggesting that reading about a skill is equal to practicing a skill. The skill was never about the syntax in the first place. Also again, this logic only works on absolute greenfield project. If you write enterprise code in large organizations, you also have to consider the established archite…

Exactly. Programming skill, like most human skills, is acquired through practice and repitition. You can't become an excellent programmer by observing other people (or LLMs) doing it. That's like arguing you can become a master musician by reading sheet music or watching live performances by other musicians.

Re: Breaking the spell of vibe coding

#306

Post by injidup »

Fuck vibe coding. If you want a system that actually stays stable, use OpenSpec (or something like it) to build a closed-loop rig where your requirements drive the code and the code proves it met the requirements. In one weekend, I built a system that processes OpenSpec requirements into IMGUI automatic testing scripts. It captures screenshots, compiles them into a report, and assigns each image a prompt—essentially a requirement snippet—that tells a multimodal LLM exactly what to look for. Claude is incredible at stitching these types of tools together. Once you have that closed loop, you can let an agent loose on features and just let the code it writes converge on the spec. The golden rule: If you don't like the results, change the spec. Don't shortcut or "vibe code" a bug away. This keeps the guardrails on. For every feature you add, you have to think about how to validate it automatically. Even a basic smoke test that raises a flag for human review is better than nothing. Think about the workflow: capture screenshots of all your app workflows and commit them to Git as a baseline. On the next commit, run fast smoke tests. If the images match, you’re good. If they differ, the LLM analyzes the diff against the requirements and proposes a fix for either the code or the spec. Rigs like this used to take teams years to build; now you can build them in a few days with a coding assistant. It’s simple, it’s stable, and it actually scales.

Re: Breaking the spell of vibe coding

#307

Post by linsomniac »

jayd16 wrote: post #298
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…

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…

>perfection cannot be achieved

That's not what I get out of the comment you are replying to.

In the case being discussed here, one of code matching the tax code, perfection is likely possible; perfection is defined by the tax code. The SME on this should be writing the tests that demonstrate adhering with the tax code. Once they do that, then it doesn't matter if they, or the AI, or a one shot consultant write it, as far as correctness goes.

If the resulting AI code has subtle bugs in it that pass the test, the SME likely didn't understand the corner cases of this part of the tax code as well as they thought, and quite possibly could have run into the same bugs.

That's what I get out of what you are replying to.

Re: Breaking the spell of vibe coding

#308

Post by ben_w »

manishsharan wrote: post #284
ben_w wrote: post #281

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. I would like to work with the humans you describe who, implicitly from your description, don't hallucinate something random when they don't know the answer. I mea…

Humans are accountable to each other. Humans can be shamed in a code review and reprimanded and threatened with consequences for sloppy work. Most, humans once reprimanded , will not make the same kind of mistake twice.

> Humans can be shamed in a code review and reprimanded and threatened with consequences for sloppy work.

I had to not merely threaten to involve the Ombudsman, but actually involve the Ombudsman.

That was after I had already escalated several times and gotten as far as raising it with the Data Protection Officer of their parent company.

> Most, humans once reprimanded , will not make the same kind of mistake twice.

To quote myself:

  other people in their own team had already admitted this, apologised to me, promised they'd fixed it, while actually still continuing to send letters to the same non-existent address.

Re: Breaking the spell of vibe coding

#309

Post by skydhash »

sidrag22 wrote: post #264
ithkuil wrote: post #8

Earlier quoted context omitted.

I personally found out that knowing how to use ai coding assistants productively is a skill like any other and a) it requires a significant investment of time b) can be quite rewarding to learn just as any other skill c) might be useful now or in the future and d) doesn't negate the usefulness of any other skills acquired on the past nor diminishes the usefulness of learning new skills in the future

As much as i loved the relation of vibe coding to slots and their related flow states in this article, I also think what you are stating is the exact reason these tools are not the same as slots, the skill gap is there and its massive. I think there are a ton of people just pulling the lever over and over, instead of stepping back and considering how they should pull the lever. When you step back and consider this, y…

> I think there are a ton of people just pulling the lever over and over, instead of stepping back and considering how they should pull the lever

There are deeper considerations like why pull the lever, or is it the correct lever? So many api usages is either seeing someone using a forklift to go the gym (bypassing the point), using it to lift a cereal box (overpowered), or using it to do watchmaking (very much the wrong tool).

Programming languages are languages, yes. But we only use them for two reasons. They can be mapped down to hardware ISA and they’re human shaped. The computer doesn’t care about the wrong formula as long as they can compute it. So it falls on us to ensure that the correct formula is being computed. And a lot of AI proponents is trying to get rid of that part.

Re: Breaking the spell of vibe coding

#310

Post by linsomniac »

mprast wrote: post #53
daxfohl wrote: post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?

>if you don't learn how to vibecode now you'll never ever be able to catch up

There's a dissonance I see where people talk about using AI tools leading to an atrophy of their abilities to work with code, but then expecting that they need no mastery to be able to use the AI tooling.

Will the AI tooling become so much better that you need little to no mastery to use it? Maybe. Will those who have a lot of fundamentals developed over years of using the tooling still be better with that tooling than the "newbs"? Maybe.

Post reply on HN