from Hacker News

Don't Bother with Vibe Coding

by CER10TY on 4/2/25, 12:10 PM with 130 comments

• by bilekas on 4/2/25, 12:48 PM

  I just went to check that job posting for "Vibe Coder" [0]

  > At least 50% of the code you write right now should be done by AI; Vibe coding experience is non-negotiable.

  That is absolutely ridiculous.. As the kids say these days, I think that company is cooked.

  0 - https://www.ycombinator.com/companies/domu-technology-inc/jo...

• by madeofpalk on 4/2/25, 12:50 PM

  This article makes the fundamental flaw that the only type of programming is for Work For Other People.

  For me at my day job, I find success with Cursor as “fancy autocomplete”. It’s aiding me when I am writing the code. The most code it’ll ever generate is to start on unit tests.

  I’ve also used Cursor on the side for little personal hobby projects where I let to go wild in generating the overwhelming majority of code. I can’t say whether it’s faster or not, but it certainly helps reduce and overhead, initial blockers, ir lowering the barrier for myself to make something.

  For those who are skeptical or haven’t tried it yet, ignore this article and just go give this new tool a decent try -carefully on your existing code base, and in no-stakes hobby projects - to form your own real opinion.

• by moolcool on 4/2/25, 12:38 PM

  > I'd even go as far as saying that you should reject anyone applying for your startup if they claim to have vibe coding experience

  I thought vibe coding was just a meme. There are people who put vibe coding on _their resumes_??

• by jaccola on 4/2/25, 2:15 PM

  The argument for "vibe coding" (or generally heavy-use of AI coding) is always along the lines of 1. Vibe coding is much more efficient than regular coding 2. If you don't learn vibe coding you will fall behind

  I see lots of arguing over point 1. but I think we can reason about 2. such that it makes the veracity of 1. irrelevant.

  There is literally no skill you have to learn NOW (meaning today, this week, this year) that will ruin your career if you don't learn it. There are still very productive and well compensated people writing using editors and other tooling created in the 20th century.

  Equally, your boss isn't going to come in to work tomorrow and say "you aren't already a vibe coder?! We expect you to be even though this is the first time I am mentioning it. You're FIRED!"

  So if you want to learn "vibe coding", go ahead, but don't feel some great existential anxiety over it. People saying you will "fall behind" are just creating clickbait nonsense.

• by codeptualize on 4/2/25, 1:01 PM

  I kinda agree but the article does not do a great job at defending the position. Who cares about docs?

  Vibe coding, or just letting AI take the wheel will work in some situations. It allows non coders to do things they couldn't before and that's great. Just like spreadsheets, no code tools, and integrations tools like Zapier, this will fill a bunch of gaps and push the threshold where you need to get software devs involved.

  But as with all these solutions there is that threshold were the complexity, error margin gets, and scale go beyond workable and then you need to unfuck that situation and enforcing correctness. And I think this will result in plenty "oops my data is gone" types of problems.

  If you know upfront that your project will get complex and/or needs to scale you might be best off skipping the vibe coding and just getting it right, but for prototypes, small internal tools, process "glue", why not.

  It's not a replacement of software engineering as a whole (yet), it's just another tool in the toolbox and imo that's great. Can I use it, no.. I have tried and it just doesn't work at all for bigger more complex projects.

• by reedf1 on 4/2/25, 12:41 PM

  Even writing articles on this stuff feels like insecurity. Just let the AI fad come and go; the real engineers will take what works and everyone else will fail. The tide goes in - the tide goes out.

• by Cthulhu_ on 4/2/25, 12:42 PM

  "Vibe coding" is fine for prototypes, weekend projects, hackathons etc, it's another variant of other quick coding / website making / visual programming IMO. But don't expect it to be production grade, and within the next year or so we'll probably see the fallout of people actually doing so.

• by AshleysBrain on 4/2/25, 1:26 PM

  I'm sure there's a time and a place for "vibe coding", but a related point is with larger software projects, most work is maintenance (shameless plug: see my blog post on the subject[1]). It should be obvious that if there's a problem in a serious project, "just work around it or ask for random changes until it goes away" is probably not going to get you very far. I suspect perhaps "vibe coding" was just pointed out with the attitude of "hey this is kinda cool", but hype is blowing it out of proportion.

  [1] https://www.construct.net/en/blogs/ashleys-blog-2/reality-lo...

• by cjs_ac on 4/2/25, 12:50 PM

  A digital computer is good at executing algorithms, with absolute, well-defined logic. A human brain is good at executing heuristics, with poorly-defined logic.

  AI - of any kind - is about getting the computer to execute these poorly-defined heuristics, and because they're bad at it, they use a lot of energy to do so.

  'Vibe coding' makes the computer execute the heuristic of generating code from requirements, and then makes the programmer execute the algorithm of ensuring that the code is correct: both human and machine are doing the thing they're bad at. It only makes sense if the only problem you have with 'move fast and break things' is that you haven't been able to move fast enough.

• by ChrisMarshallNY on 4/2/25, 12:42 PM

  > When I say professional, I'm explicitly not talking about coding.

  I'd second that. There's a huge difference between "coding," and "shipping" (not to mention "maintaining," and "supporting").

• by icu on 4/2/25, 1:18 PM

  You can get Gemini 2.5 Pro to help you with infra and deploymnet, code quality and ownership, testing, CI/CD and automation, as well as Documentation... as long as you know to ask for it.

  You also don't necessarily need all of that to hack together an MVP. I think a lot of people are not acknowledging that and they are negatively looking down on people embracing a new way of 'writing' code. Users don't care how you make a thing, they just want the thing to work.

  Before ChatGPT made a breakthrough in LLMs, code was leverage. Now, LLMs are leverage. I think people suddenly finding that their leverage has been significantly eroded is the source of the negativity towards a "vibe coder".

  So while anyone can write a book (the technology has existed since about 500 CE), few do, and there are fewer really good books. No matter the medium it's how you leverage the tool(s) you got.

  I think this is a Prometheus moment, LLMs are giving coding to humanity, and it's getting adopted right now by people brave enough to try and embrace it even though 'software development' might be way outside of their comfort zone. I think it's worth cheering those people on even if they fail their way forward.

• by cadamsdotcom on 4/2/25, 9:42 PM

  Every task is different. There are some “dimensions of complexity” that affect where to operate on the “vibecode/handcraft” spectrum..

  First is the degree to which your target framework, language, and domain are in-distribution for the model. You’ll get far rather in python than in Verilog, for example. You’ll get further vibecoding next.js than whatever people use for web apps in Elixir.

  Second is the amount of context gathering. A greenfield project has no context - every project starts from the same zero point: an empty repo or generated scaffold. Large codebases must be loaded into working memory even for humans. This is why professional software engineering depends so heavily on getting into “flow”: https://i.imgur.com/3uyRWGJ.jpg

  It’s just horses for courses.

  My prediction is LLMs will get there; they’ll scale to larger and larger codebases as context windows get larger, and working out-of-distribution will happen thanks to scaling inference-time compute and agentic capability to research, read code, build understanding, and store said understanding in a scratchpad dedicated to you.

• by meowface on 4/2/25, 12:58 PM

  Key point:

  >I've also sometimes let AI do quite heavy lifting; for example, the frontend for my latest weekend project, SquadUtils, was done almost entirely by Claude. It's important to note, though, that I was always able to reason about the code and guide Claude in the correct direction if it made mistakes.

  AI coding - if you know how to prompt and follow-up-prompt and review well - can greatly boost productivity for almost everyone reading this comment. This article is warning about unguided, "AI-take-the-wheel" outsourcing, not prompt-based programming in general.

  Maybe in a few years something approaching true vibe coding will be much feasible, as well. We're early.

• by btbuildem on 4/2/25, 1:05 PM

  > I'm explicitly not talking about coding. This is easy to learn [...] I'm talking about things surrounding the code

  I have terrible news for the author: LLMs are quite good at the things that surround the code. The danger here isn't that someone will one-shot a working application; that's silly. The practical consequences are that you can now synthesize and rapidly iterate on technical design documentation, then transform it into architecture documents, and quickly into actual (contradiction in terms here) project-specific boilerplate.

  As a senior or principal, if you don't keep up with this, you'll wash out.

• by sota_pop on 4/2/25, 1:13 PM

  I liken ‘vibe coding’ to Low/No-code platforms. It’s an attempt to achieve the same results with the added constraints of less precise control over what you’re ACTUALLY building. It is an abstraction over the code you’re writing (or not writing). Its ability to help or hinder probably depends on the level of precision the application you’re building (or you personally) demands from the software you write.

• by efilife on 4/2/25, 12:54 PM

  I can't believe people are using this term seriously

• by ChrisMarshallNY on 4/2/25, 1:30 PM

  Woah. Just noticed that this story took a huge dive. Could the pile-on to a YC startup have anything to do with that?

  I actually feel ambivalent about that. I think that companies should either succeed or fail on their merits (which can include the Court of Public Opinion), and, personally, I don't really like publicly slagging the work of others; even if I find it problematic.

• by cheevly on 4/2/25, 1:44 PM

  Imo if you aren’t able to AI code at scale, you are probably falling significantly behind the curve.

  If I challenged you to build a large piece of quality software using only AI edits, could you do it? If you don’t believe it’s possible (or productive), I would be happy to generate some codebases or products live, in exchange for $$$ ;)

• by VladVladikoff on 4/2/25, 1:04 PM

  There seems to be a bit of a definition issue here, because the author admits in the article to actively doing I thought was considered Vibe Coding. The author said that he has built something almost entirely with AI. Isn’t that a lot higher of a percentage than the 50% job ad he’s pointing at?

• by qwertox on 4/2/25, 12:51 PM

  I still don't understand what Vibe Coding is.

  "I'll use ChatGPT/Claude instead of StackOverflow" doesn't sound like Vibe Coding to me.

  More like someone who can't code instructing "i want"'s and "do fix" to an AI, that sounds like Vibe Coding to me.

• by zurfer on 4/2/25, 1:10 PM

  The trick is to let senior engineers vibe code and keep them responsible for the code they pushed.

  (maybe that's not vibe coding :)

• by latexr on 4/2/25, 1:14 PM

  > Early-stage, every engineer should have a deep understanding of these four points.

  There were five points.

• by Tejas999 on 4/2/25, 1:56 PM

  there will be a time where either the AI is way to expensive for people to use or the AI will banned just like drugs.

• by luhsprwhk on 4/2/25, 2:47 PM

  "Vibe coding" is an unfortunate buzzword. I do think it's gonna help with burnout, but imposter syndrome is bound to spike.

• by fragmede on 4/2/25, 1:00 PM

  Let's say I could vibecode a viable whitelabel competitor to, say, Eventbrite in, like, a week. Or before LLMs, an unscrupulous version of me steal their source code and then find/replace EventBrite and launch FraEventMede.

  So what? If we presume vibecoding makes the problem no longer the code, there's still the everything else of business. How would I compete with EventBrite? What would I even do with my clone?

• by jstummbillig on 4/2/25, 12:55 PM

  The important point, that the author completely misses, is that vibe coding was not made up. It emerged, suddenly, and a lot of people noticed (and then someone gave it a sticky name)

  Not recognizing that the limits are melting away, that what is coding is rapidly changing, and writing blog posts in defense of mechanics is increasingly silly and cope.

• by elif on 4/2/25, 12:52 PM

  I read a good portion of this but it's so myopic that it overessentializes AI generated code into a caricature of itself simply because someone coined a new cultural term. Unfortunately this takes the piece to an almost useless place which resembles coping.

• by staticelf on 4/2/25, 12:43 PM

  It's retarded to hire vibe coders but in general you can vibe code a solution as a professional engineer. I have done several very small projects with vibe coding and I reviewed all code and then pushed it to prod.

  But as soon as projects balloon in complexity, the less "vibe" the AI gets in my experience.