Live data from Hacker News

Vibe Coding is not an excuse for low-quality work

addyo.substack.com

41–50 of 213 posts

Re: Vibe Coding is not an excuse for low-quality work

#41
post #24

Earlier quoted context omitted.

From that tweet: > I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it That sums up vibe coding, imo. The article talks about code quality with vibe coding, but I think that misses the point. The real problem is code knowledge. When a vibe coder inevitably needs to debug something, if they have no idea what any of the code does, or why it is the w…

Also from the tweet; > It's not too bad for throwaway weekend projects, but still quite amusing You were never supposed to vibe code on serious projects.

Any project that solves a real need will invariably become serious.

I have lost count of the number of quick one off scripts that ended up still being used in production workloads five (or more) years later.

Re: Vibe Coding is not an excuse for low-quality work

#42
post #3

> treat the AI like a super-speedy but junior developer on your team That sounds like it's going to take a lot more time that just writing the code for an experienced developer. The issue with AI for me is that it produces plausible-looking code which requires a lot of attention to read through, because things that look superficially "right", including any justification in code comments, can actually have really prob…

I remember when I'd rushed a piece of work when studying, I had a lecturer who told us something like: There are a few kinds of developers: good, bad, slow and fast. Everyone wants to be a good developer but a fast and bad developer is worse than a slow and bad developer because they end up doing so much damage.

He could have been copying General Kurt Hammerstein. Paraphrasing here:

There are four kinds of military officers: smart and lazy, smart and hard working, dumb and hardworking, dumb and lazy.

Keep the dumb and hardworking away from any high level position. They actively make things worse. Dumb and lazy are useful for simple tasks with oversight. Smart and hardworking are excellent for high level staff and analyst positions.

The Smart and Lazy should be saved for high level command. They expend only the energy necessary to get the job done and then focus on the next important task.

Re: Vibe Coding is not an excuse for low-quality work

#43
post #31
post #5

So what have we redefined vibe coding to mean exactly? The original tweet[1] talked very specifically about not caring about quality, just accepting whatever code the AI produces blindly, as long as you get the black box output you're looking for, and just randomly try again if you didn't. Are people now using this term to mean "giving an AI agent broad tasks"? [1] https://x.com/karpathy/status/1886192184808149383?la…

I absolutely hate the polarization around "vibe coding". The whole point of AI agents is to eventually get good enough to do this stuff better than humans do. It's okay to dogfood and test them now and see how well they do, and improve them over time. Software engineers will eventually become managers of AI agents. Vibe coding is just version 0.1 pre-alpha of that future.

> Software engineers will eventually become managers of AI agents.

Source? This seems very optimistic on both ends (that AI will replace SE work, AND SEs will still be employed to manage them).

Re: Vibe Coding is not an excuse for low-quality work

#44
post #18

This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications. Turns out most of those outsourcing parties won't truly understand the core ideas behind the system you're trying to build, won't think outside the box and make corrections where necess…

Oh yes[1] Then remember when we said tests should be the specs? Then we said the end users are the specs? All of them can be construed as a joke in our erratic search for the correct way to write software without those $150k developers that seem to be the only ones getting the job done, assuming they have a competent management hierarchy and stock options incentives. [1] We have a waterfall software and I wonder whet…

I think this erratic manner of trying to find the correct way is the issue. I am currently nearing my 2nd year at a company A in my industry, and while I did know they all kinda suck in their own special way, I honestly had no idea it was this bad until I had to try to make this craziness somehow work for us. Even if there are standards, I do not see people following them. Last year, the one girl, who did seem to try to follow some common sense approach, got fired for effectively using common sense against big boss wishes.

What I am saying it is a mess from beginning to end and I am honestly not sure if there is one factor that could solve it..

Re: Vibe Coding is not an excuse for low-quality work

#45
I built Plandex[1] to try to enable a more sustainable approach to vibe coding. It writes all of the model's changes to a cumulative version-controlled sandbox by default, which in my experience helps a lot to address many of the points raised in the article. While there are still categories of tasks I'd rather do myself than vibe code, the default-sandbox approach makes it feel a lot less risky to give something a shot.

On another note, a related but somewhat different technique that I think is still under-appreciated is "vibe debugging", i.e. repeatedly executing commands (builds, tests, typechecks, dependency installs, etc.) until they run successfully. This helps a lot with what imo are some of the most tedious tasks in software development—stuff like getting your webpack server to startup correctly, getting a big C project to compile for the first time, fixing random dependency installation errors, getting your CloudFormation template to deploy without errors, and so on. It's not so much that these tasks are 'difficult' really. They just require a lot of trial-and-error and have a slow feedback loop, which makes them naturally a good fit for AI.

I put a lot of focus on execution control in Plandex in order to make it helpful for these kinds of problems. It's built to be transactional—you can apply the changes from the sandbox, run pending commands, and then roll back all changes if the commands fail. You can do this repeatedly, even letting it continue automatically for some number of tries until the commands succeed (or you hit the tries limit). While there are some limitations to the terminal modality in terms of UX, I think this is an area where a CLI-based agent can really shine.

1 - https://github.com/plandex-ai/plandex

Re: Vibe Coding is not an excuse for low-quality work

#46
post #38

Different people clearly mean different things when they talk about software quality. There is quality as perceived by the user: few bugs, accurately models the problem they have, no more complicated than necessary, etc. Then there is this other notion of quality as something to do with how the software is built. How neat and clear it is. How easy it is to extend or change. The first kind of quality is the only kind…

> The first kind of quality is the only kind that matters in the end. From a business perspective, this is what's exciting to a lot of people. I think we have to recognize that a lot of products fail not because the software was written poorly, but because the business idea wasn't very good. If a business is able to spin up its product using some aspect of vibe coding to test out its merits, and is able to explore pr…

Low/no code MVP solutions have existed for a long time. Vibe coding seems like you'll get worse results than just using one of those, at least from a bug/support standpoint.

Re: Vibe Coding is not an excuse for low-quality work

#48
post #18

This all reminds me a lot of the early 2000's, when big corporations thought they could save a lot of money by outsourcing development work to low-income countries and have their expensive in-house engineers only write specifications. Turns out most of those outsourcing parties won't truly understand the core ideas behind the system you're trying to build, won't think outside the box and make corrections where necess…

Deleted

It’s sad you’re getting downvoted by gatekeepers. It’s absolutely a good thing that more people have access. Maybe not for inflated costal salaries and egos, however.

Re: Vibe Coding is not an excuse for low-quality work

#50

Different people clearly mean different things when they talk about software quality. There is quality as perceived by the user: few bugs, accurately models the problem they have, no more complicated than necessary, etc. Then there is this other notion of quality as something to do with how the software is built. How neat and clear it is. How easy it is to extend or change. The first kind of quality is the only kind…

> The first kind of quality is the only kind that matters in the end.

Yes. But the first kind of quality is enabled with the second kind.

Until we live in a faultless closed loop[1], where with AI "the entire application can be rewritten just as easily as making a small change." you still need the second kind.

[1] and it's debatable if we ever will

Post reply on HN