HN Reader

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 necessary, and will just build the thing exactly as written in the spec. The result being that to get the end product you want, the spec needs to be so finely detailed and refined that by the time you get both specification and implementation to the desired quality level, it would have been the same amount of effort (and probably less time and frustration) to just build the system in-house.

Of course outsourcing software development hasn't gone away, but it hasn't become anywhere near as prevalent and dominant as its proponents would've had you believe. I see the same happening with AI coding - it has its place, certainly for prototyping and quick-and-dirty solutions - but it cannot and will not truly replace human understanding, ingenuity, creativity and insight.

Not an excuse, but maybe an explanation. I was just talking to someone who was bragging about getting the cost of coding down to a penny a line. Seems like an insane metric to use, to me, since it takes no account of features developed or maintainability/modifiability.

"The big takeaway is that speed means nothing without quality" - I feel like this is not true in 'move fast and break things' ideology

It's hard to take anyone seriously who takes the term "vibe coding" this seriously, considering that the whole thing spawned from a casual tongue-in-cheek tweet. I recently saw a job posting for a "Vibe Coder". Nuts.

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

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 that matters in the end. The second kind has mattered a lot up until now because of how involved humans are in typing up and editing software. It doesn't need to matter going forward. To a machine, the entire application can be rewritten just as easily as making a small change.

I would gladly give up all semblance of the second kind of quality in exchange for formal specifications and testing methods, which an AI goes through the trouble of satisfying for me. Concepts and models matter in the problem domain (assuming humans are the ones using the software), but they will increasingly have no place in the solution domain.

It totally depends on the use case.

As a consultant the majority of my work is around business process automation and integrating cloud systems. We build a lot of small "applications" that change almost constantly. The number of concurrent users is low, the lifespan of the software typically short and to justify the effort has to be done quickly and efficiently.

It's 100% "value engineering".

AI agent pairing has been an absolute game changer. It can single shot most requirements and refactors. I basically am just writing technical requirements and reading pull requests all day now.

I actually think the quality of the output has gone up significantly because you can just accomplish much more in the same limited budget.

This sums it all up:

> embrace the vibes, but honor the craft

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

Vibe seo vibe seo vibe seo vibe seo

I think all this rests on the unacknowleged fact that most software never goes into production. When you have a choice between paying expensive humans to create software that works vs cheap AI to create software that doesn't, if nobody is ever going to use it, the AI option is the one to pick.

If you use AI to make low-quality work, then you made low-quality work. It’s pretty simple.

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?lang=en

I think it is a losing battle. People are energy preserving creatures and we skip paying attention if we can. Because paying attention is effort. Vibe coding is exactly this, low effort development and thus is enticing. Now if we can get away with low effort why shouldn’t we? I am not advocating serious NATO missions to be vibe coded for trajectories, no. When billions are at stake no way. But what if billions are not at stake? What if nothing is? This weekend I added a way to maximise my QApplication app. I just asked Claude code to do it and tested it. It worked. That is all I need for my own app that I use. It’s not that I don’t have any other users but works on my machine is the motto of this specific free and open source app.

I don't mean to be dismissive (here goes, though) but the whole article boils down to one point, and it's one that frightens me that it needs to be repeated so often: use AI as your intern, not your replacement

Simple.

What percentage of companies can hire an engineer who writes better code than o3?

This is common sense. The whole article read like they asked ChatGPT to fluff one sentence "review vibe code with a human before pushing to prod" into an entire article.

>In essence, let the AI handle the grunt work, not the brain work.

And importantly make sure the user doing the brain work has the experience and support to do it properly. The XY problem can cause a lot of damage with AI agents that implement what's asked of them instead of asking why.