Live data from Hacker News

Breaking the spell of vibe coding

fast.ai

331–340 of 375 posts

Re: Breaking the spell of vibe coding

#331

Earlier quoted context omitted.

"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.

>What is there to learn, honestly? With all due respect, that answer shows that you don't know enough about agentic coding to form an opinion on this. Things to learn: - What agent are you going to use? - What skills are you going to use? - What MCPs are you going to use? - What artifacts are you going to provide beyond the prompt? - How are you going to structure it so the tooling can succeed without human interacti…

I can bet that a single standard instance of existing tool like codex and Claude Code to do whatever someone with a convoluted setup like that can. It could be marginally slower if you but it's all literally just English language text files.

I use codex almost everyday, none of that is necessary unless you're trying to flatten up your resume.

It's micro services all over again, a concept useful for some very select organisations, that should've been used carefully turned into a fad every engineer had to try shoe horn into their stack.

Re: Breaking the spell of vibe coding

#332

It's astonishing to me that real software developers have considered it a good idea to generate code... and not even look at the code . I would have thought sanity checking the output to be the most elementary next step.

I suggest move the sanity check to the point of employing the parrot.

"Fixing defects down the road during testing costs 15x as much as fixing them during design, according to research from the IBM System Science Institute."

Re: Breaking the spell of vibe coding

#334

Earlier quoted context omitted.

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

Not sure how things work at your company, but I’ve never seen a design spec that doesn’t have input from many humans on some form or another

We're agreeing, I think.

Re: Breaking the spell of vibe coding

#335
post #304

Earlier quoted context omitted.

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.

If the AI is doing 100% of the work why would you need software engineers at the helm?

Re: Breaking the spell of vibe coding

#336

Earlier quoted context omitted.

>What is there to learn, honestly? With all due respect, that answer shows that you don't know enough about agentic coding to form an opinion on this. Things to learn: - What agent are you going to use? - What skills are you going to use? - What MCPs are you going to use? - What artifacts are you going to provide beyond the prompt? - How are you going to structure it so the tooling can succeed without human interacti…

I can bet that a single standard instance of existing tool like codex and Claude Code to do whatever someone with a convoluted setup like that can. It could be marginally slower if you but it's all literally just English language text files. I use codex almost everyday, none of that is necessary unless you're trying to flatten up your resume. It's micro services all over again, a concept useful for some very select o…

>I can bet that a single standard instance of existing tool like codex and Claude Code

This is a perfect example of what I'm saying. You'd bet that, because you don't have enough experience with the tooling to know when you need more than a "standard instance of existing tool"

Here's a real-world case: Take some 20 year old Python code and have it convert "% format" strings to "f strings". Give that problem to a generic Claude Code setup and it will produce some subtle bugs. Now set up a "skill" that understands how to set up and test the resulting f-string against the %-format, and it will be able to detect and correct errors it introduces, automatically. And it can do that without inflating the main context.

Many of those items I mention are at their core about managing context. If you are finding Claude Code ends up "off in the weeds", this can often be due to you not managing the context windows correctly.

Just knowing when to clear context, when to compact context, and when to preserve context is a core component of successfully using the AI tooling.

Re: Breaking the spell of vibe coding

#337

Earlier quoted context omitted.

>What is there to learn, honestly? With all due respect, that answer shows that you don't know enough about agentic coding to form an opinion on this. Things to learn: - What agent are you going to use? - What skills are you going to use? - What MCPs are you going to use? - What artifacts are you going to provide beyond the prompt? - How are you going to structure it so the tooling can succeed without human interacti…

I can bet that a single standard instance of existing tool like codex and Claude Code to do whatever someone with a convoluted setup like that can. It could be marginally slower if you but it's all literally just English language text files. I use codex almost everyday, none of that is necessary unless you're trying to flatten up your resume. It's micro services all over again, a concept useful for some very select o…

[deleted]

Re: Breaking the spell of vibe coding

#338
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.

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

Humans who fail to do so find the list of tasks they’re allowed to do suddenly curtailed. I’m sure there is a degree of this with LLMs but the fanboys haven’t started admitting it yet.

Re: Breaking the spell of vibe coding

#339
post #319

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…

Humans make such mistakes slowly . It's much harder to catch the "drift" introduced by LLM because it happens so quickly and silently. By the time you notice something is wrong, it has already become the foundation for more code. You are then looking at a full rewrite.

The rate of the mistakes versus the rate of consumers and testers finding them was a ratio we could deal with and we don’t have the facilities to deal with the new ratio.

It is likely over time that AI code will necessitate the use of more elaborate canary systems that increase the cost per feature quite considerably. Particularly for small and mid sized orgs where those costs are difficult to amortize.

Or maybe this is a SaaS opportunity for someone.

Re: Breaking the spell of vibe coding

#340

Just because you’re a good programmer / software engineer doesn’t mean you’re a good architect, or a good UI designer, or a good product manager. Yet in my experience, using LLMs to successfully produce software really works those architect, designer, and manager muscles, and thus requires them to be strong.

The irony considering "good" ui to a ui designer is completely at odds with users. We got better ui when it was people who had no clue what they were doing just trying to make some sense out of it, vs the cult of dogmatic ui design we see today where everything follows the same crappy patterns and everyone is afraid to step out of line.
Post reply on HN