HN Reader

The hype levels are so overwhelming that AI coding could never hope to meet them. I've tried having a highly-ranked AI coding app write unit tests for a relatively complex codebase. 80% of the generated test cases failed. But an experienced human such as myself could use those as a starting point since it took care of some of the tedious boilerplate. It genuinely saved me some time and annoyance, but could never hope to replace even the lowliest competent junior dev.

That's what AI is good for right now - boilerplate acceleration. But that's clearly not enough to drive the immense transfers of capital that this high ecosystem demands.

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

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.

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.

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

Are today's juniors never gonna reach senior levels because of AI assisted coding ? Do you think AI assisted coding has a negative impact on developer's growth ? Is the need for developers gonna increase in the longterm but decrease in shortterm ?

Those are just some of the questions that are in my head lately. I would appreciate other people's opinion.

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 mainly use vibe coding to figure out how hard something is to do if I would do it 'for real', so I vibe code working prototypes, often to find out there is no way this is feasible and, more often, finding it is easier than I thought it would be. When I have an issue, I search for a library to solve that issue, but to figure it it does and if it does in a friendly way, I have to try it, so I ask claude to give me my example in that library. I already know something is up if it doesn't work first shot; to me is not a shock that 99.9999% (well that is actually not true of all language ecosystems but the most popular ones) of all libraries out there are total garbage with very strange 'opinionated' abstractions/choices in them that truly suck and actually make some use cases impossible without changing the library itself even though it says in the manual it is possible but without an example. In that case the LLM usually hallucinates a parameter or function that it doesn't have but that is from another library or does not exist at all, ideally needed to implement said use case. LLMs save me a ton of time there and I assume it's low quality as I won't use that exact piece of code anyway, but now I know the effort involved to meet my specific use case.

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.

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.

Vibe coding for me meant a roll-the-dice approach to building something that world. Never a care for strong architecture or good code standards. Allowing anyone to become an "engineer". A friend of mine, who can't code, used Cursor to build fully functional Nextjs web apps. I was impressed. Vibe coding is a super power for average people.

I do think this article fully grasps that change. Using AI to do tasks is not vibe coding. At least to me.

When will the first vibe coding book come out I wonder?

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.

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

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

“We as a team are still responsible for every line that goes into the repo”

You use AI to make a PR? You are still responsible. You code reviewed the PR? Also responsible.

The AI is not responsible.

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

The urge to spagetti code is strong but must be denied.

Vibe coding is what we used to call “a hack”

It is not software engineering.

Vibe seo vibe seo vibe seo vibe seo

Funny, that's all I thought it ever was.

LLMs are to software engineering as 3D printers are to mechanical engineering.

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.

This sums it all up:

> embrace the vibes, but honor the craft

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.

Maybe I could introduce vibe cooking, vibe driving, vibe teaching, vibe accounting, vibe plumbing, vibe working.

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

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