Breaking up with vibe coding | Hacker News Reader

Breaking up with vibe coding

lucasaguiar.xyz

75 pointsisfttr80 comments

I find reports on how others are using LLMs to code interesting to read.

I've personally found LLMs to have recently crossed the "uncanny valley" of programming for me, meaning that I'm much much more productive than without them.

I find that if you're really good at describing a problem and the constraints you want to solve, using a language it knows well (like Go) and following well known patterns in that language, you can describe thousands of lines of code and get accurate results.

Maybe this isn't vibe coding speicfically, but I actually review every line of code that the LLM puts out. It doesn't take long if you know what you're reading, and the LLM make a weird solution to the problem. Usually if I'm specific about how I want it solved, it does it well.

I also found it useful to say "Please tell me your plan to implement the solutions and ask me about any ambiguities that need clarification." In other words, don't make your own assumptions.

The results are incredible. Thousands of lines of code that maybe not stylistically like mine, but are structurally very accurate to what I'm looking for. Giving function/interface signatures and code examples works wonders.

What dev tools/processes are you using? I’m enjoying the enhanced capabilities of Windsurf with Sonnet 3.7, but I mostly use it for analyzing and problem-fixing in a huge codebase I recently inherited. I have yet to feed it anything like a PRD.

I recently set up a conventions.md file for Aider along with configuring sonnet 3.7 with reasoning.

It really was another leap forward for me with AI. Using it for exploratory analysis of solutions is the best rubber duck I’ve ever had

Can you share what properties you set?

I've started with a 'taskfile.md' (but the filename is irrelevant).

It contains:

- AI assistant instructions (with things like: "for a new task, ALWAYS first present and discuss different approaches before starting implementation", "update this file with relevant information while working", "unless prompted otherwise, work on the first task in the current tasks section of this file")

- basic info about the project: general, technical (general architecture, dev setup, etc.)

- locations of generally important stuff in the repo

- general context of the current task

- task specific locations of important stuff in the repo

- relevant (non-sensitive) task specific data/variables

- list of the current active/relevant tasks.

I tweak the file a bit for a new task and then just add only the taskfile.md as context, add a '.' as text in the Cursor agent chat window and it's off. Works like a charm.

Next step will be to add MCP servers and just point it at an issue in the relevant issue tracker in the task file.

Same.. huge productivity boost, and in general it writes better code than me, because quite frankly, I'm pretty lazy with the first lines of code.

But yeah, the better you know how to describe what you want, the better the results. Not really a difference from humans, eh?

Just like Google or Stackoverflow.

There was a time when I felt my greatest programming ability is googling, I think that transferred well to LLMs since googling and asking question on stackoverflow required a very similar skill set.

Digging through source was also helpful to me (I still do it quite a bit) GitHub code search was for a time quite useful, especially for somewhat arcane configuration (over the years, stuff like Cloudformation properties that aren't frequently used, cmake stuff, webpack and others come to mind)

Often grepping through a codebase where I know another example resides of something similar with a vague idea of what i'm looking for helps.

Man.. there are times when trying to debug some error yields no search results and no leads to follow other than "dig through megabytes of the arcane source code with no context of how it's meant to fit together" and if it were possible to have an LLM be able to RAG an entire git repo online and answer questions about it, that would be pretty choice.

I've had basically zero luck with RAG myself so far, especially as I always try to go the local route for better infosec vs relying on cloud solutions like copilot. But trying to tap an LLM to help grok a public github repo wouldn't cover any sensitive data so I wouldn't mind using the cloud for a task like that.

That still works today, LLM tend to almost always hallucinate when you ask it for source details despite it being trained on it.

Especially if the behavior is strange enough that trigger the look into the source.

Exactly, I never use LLMs for looking up the specific CFN properties for that exact reason. Populating a resource in a template sure, but the code-spelunking is always done to find the arcane property/value for said property.

I’ve found it very helpful to write out the boilerplate to allow you to write the few lines needed to do what you conceptually want to do.

Also great with figuring a regex pattern in 5-10s instead of getting derailed by SO or Google search.

Are there many such lines? People are gripping about boilerplate like they're writing XML by hand or Java with Notepad, but the few actual boilerplate I've seen are easily solved by snippets and code generators. Other things that look like boilerplate are in fact specific code that only fits the current context. And more often you only need to write it once, then either abstract it away or copy-paste it and edit it.

I believe most of these people (including myself) in this context are just talking about boring / obvious / easy code. And yeah, I’d say a large percentage of code changes I do is plumbing for the few interesting ones.

AI handles the boring bits very well, and to me that is the most energetically draining part of coding (the hard parts are fun and invigorating).

Whether it only fits the current codebase’s context or not doesn’t really matter, you just give it important samples from and info about the codebase at the start of your prompt. My baseline prompt length is ~30k tokens due to that.

I do review and polish everything that’s generated though, as needed. Vibe coding (not even reading / understanding the generated code) I believe was coined primarily for having fun in side projects. If you’re using it for production code then you’re likely holding it wrong.

Yeah, the context that comes to mind are basic class methods or simple data cleaning functions for messing with numpy/pandas data

Are projects finishing quicker?

Absolutely, especially when working with frameworks or runtimes you're not very familiar with.

how am I supposed to notice and fix the myriad bugs produced if I'm not familiar with the framework or runtime?

and if I am familiar, how is prose literally ever more terse than the actual code?

to me it just comes down to which one is less typing and that's still Just Writing The Code Myself as far as I can tell

I mean maybe it'd be different if I spent hundreds of dollars on 4o-pro but trying the free models have made me want to pay even less, it's all a massive waste of time compared to just using Kagi to look things up

From my own standpoint, it's an even simpler proposition. I program, but I don't develop software. I'd like to know if the AI changes the way we answer the question of when a project will be done.

> how is prose literally ever more terse than the actual code

All the time. Open an android project and tell Claude to create a social feed, or as a recent example I told Claude to add waitlist support to a registration system in Django. It did a better job than most juniors I've worked with, and I think it cost a couple dollars. I tuned it a bit afterwards, but saved me lots of time and energy. With one one sentence prompt it updated the models, created the migrations, found and updated all the views...

My issue with that approach is that it's easier for me to write code than to read code and grok all the subtleties of one approach vs another.

Writing thousands of lines? I'm actively thinking about the specific method.

Reading thousands of lines of someone else's code? I might fall into a more passive mode and miss a problem.

I am more likely to do the reverse: write it myself, have LLMs summarize it or suggest how to test it/break it/whatever.

In many situations a sufficiently-described statement of "here is exactly what I want the code to do" is not significantly easier to write than the code itself. Especially when the AI is doing the annoying tedious bits through autocomplete suggestions, vs letting it try to do the whole thing based on a sufficiently-described prompt.

Hmm, I like this idea of "write napkin code and let LLM review/expand". In principle one can probably be quite fast and loose at this stage after all, and as you mention for coders it's often easier to express an idea in napkin code (be that "pseudocode" or real code with just zero effort into correctness as a pilot hole).

I think I'll experiment with this as well.

> Reading thousands of lines of someone else's code? I might fall into a more passive mode and miss a problem.

Or just bad design. I use AI a fair amount for my personal work (my employer currently bans it), and what I've found is it's a great accelerant, BUT you have to be super vigilant with it to keep the quality decent. It's very good at producing code that will make it past your average code review but has design issues that are going to make things harder down the road and getting it to refactor these itself can be quite difficult at times. I generally find myself in a loop of asking the AI to do something, doing a few rounds of refinement with it, especially around test cases, then a manual refactor/cleanup pass over the tests, followed by a manual refactor of the code.

When I read accounts of other people gushing over AI, allowing them to do some semi-complicated thing in under an hour, it really makes me worry about how this is going to affect the readability of the average codebase in a few years' time.

Could you try the problem I posted at https://news.ycombinator.com/item?id=42145308 ?

The Python solution took me most of a day to write, and I've been curious on how an LLM would handle it.

I think there is inherent value in expressing your own thought, from the start, in a formal language.

This is why mathematics has stayed with us in spite of the fact that it's eminently possible to express mathematical ideas in natural language. The precision, clarity, and brevity we gain from formalization is useful.

I think code falls into a similar bucket. Reaching for LLMs makes some amount of sense for throwaway code, but not for serious systems. Code is not merely the raw material with which you happen to realize fuzzy ideas, it is also a means of making once fuzzy ideas precise—and for this benefit to be realized, the communicating human has to participate in the formalization. I don't want to have to deal with a world in which all our systems were authored through fuzzy imprecise language and half-baked, not completely formally analyzed ideas. That's a step backwards. Life isn't only about cost cutting and short term "efficiency".

As someone else in comments mentioned though, one alternative strat is to describe your problem to the LLM using pseudocode or napkin code that you at least don't have to link every last inch of to get it to function. And then of course the LLM's reply is going to revolve around an iteration upon the code that you wrote (often with most of that linting done for you for free).

Would you be ok to specify the desired input/output types and have a LLM write the implementation? I don't want LLMs naming my functions. I don't want them telling me what functions need to be written. But I sure want it writing them for me! This works nicely in languages with strong types such as Haskell.

Sometimes I'm unsure about the high level architecture, the trade offs of the various possibilities. I find LLMs do a good job summarising them.

Vibe coding isn't for building production code. It's for exploratory prototypes - figuring out if something is possible and trying different versions of how it might work as quickly as possible.

It's also OK for low stakes personal tools where you're willing to risk avoidable bugs since they'll only affect you.

For code you intend to actually to deploy to other people or maintain long term you need to move beyond vibe coding and actually look at, understand and iterate on the code that it produces.

The moment you start doing that it stops being vibe coding, which is defined by the act of not caring about the code that was produced for you.

https://simonwillison.net/2025/Mar/19/vibe-coding/

> Vibe coding isn't for building production code. It's for exploratory prototypes - figuring out if something is possible and trying different versions of how it might work as quickly as possible.

I know people have different mental workflows for solving problems, but I never understood the concept of building software prototypes to see if something is possible, unless you're doing scientific research. I can understand building prototype for demo purposes (to avoid technical speak and to have a common reference for discussions).

Either something is possible or it is not. If you don't know, that just means you're lacking knowledge (and maybe it's never been done before). If it's possible, the only thing left to figure out is the cost of the solution (and if it's acceptable). The nice thing about software is that you don't have to commit everything at the beginning. You may build a working skeleton of the solution that you flesh out as the project goes, but I don't see that as a prototype.

The test may be to see if there's a market for the product. What you'll learn in that test is much more than a binary answer.

My understanding was that to start working on a product, you must have prospective users/customers that you can talk to to get the the gist of what they would like, the build a MVP and then iterate with the feedback you receive. In this case you already know that what they're asking for is possible or not.

Some use cases for figuring out what is possible are when you're building something that relies on APIs (such as a chrome extension and you're not familiar with how they work / what they do or just what permissions are needed) or requires that you have certain data specific to each customer.

One example of where software prototyping helped me was deciding which library or framework to use. At my job, I had the option of two different Futures libraries to handle async, and I had to chose which to start using.

And I went off to write like a quick version using each and when I got to trying to handle consuming pagnated responses, it was a terrible terrible fit for one of the frameworks, and required only like 20 lines in the other.

I then took that back to the planning phase and used that to decide how the entire application was going to be structured, as we didn't want two competing frameworks.

Lots of people pencil sketch before they paint. It's not at all odd to whip up a prototype, a sketch of the final product. You could do that with pen an paper, in Figma, code vibe it, or whatever solution is quick and dirt for you.

I've worked directly on consumer software used by hundreds of millions of users and many people I worked with prototyped in various ways before scrapping it to write production code.

"Either something is possible or it is not. If you don't know, that just means you're lacking knowledge (and maybe it's never been done before)."

Exactly - and that's what I use prototyping to figure out.

It's not just "is something possible?" - it's "is this possible given the time, tools and skills available to me?"

Here's a really simple example from a couple of years ago: I wanted to build a tool that exported my Apple Notes to a SQLite database.

Is that possible to build? What are the export options available?

I ended up using an LLM to write AppleScript (a language I had no prior experience with) to extract the notes data, and it worked great. I wrote up that prototyping experiment here: https://til.simonwillison.net/gpt3/chatgpt-applescript

>> "Either something is possible or it is not. If you don't know, that just means you're lacking knowledge (and maybe it's never been done before)."

> Exactly - and that's what I use prototyping to figure out.

Perhaps "prototyping" is an inappropriate descriptor here. A better one might be "one-off disposable code" considering the example described.

Peer developers could easily interpret prototyping an AppleScript ETL as only requiring minimal research into identifying its applicability and subsequent reusable definition.

However, a "one-off disposable AppleScript approach" expresses minimal investment (time) and also conveys a higher risk tolerance to potential incorrect code an LLM might generate.

HTH

"one-off disposable code" is pretty much exactly what I consider the term "prototyping" to mean.

One-off and prototype share similarities in development methodologies. But not in the long term goals.

In a one-off I don't care about a few output errors that I can fix by hand once. Good enough is enough.

A prototype requires to explore the limitations and estimate the effort required to eventually reach correctness. This estimate juggling time, cost, motivation, knowledge and "human resources" together.

> Either something is possible or it is not. If you don't know, that just means you're lacking knowledge

It's not always you as in yourself but you as in your company or your team. You yourself might know it is possible but management might not believe in it. They ask for a prototype to get you the resourcing for the project to proceed.

Every first major revision is a prototype whether you call it one or not.

I think there's a difference between code you don't understand and code that's "unimportant" / you don't care about.

> "We’ve all been there: headphones on, music pumping, fingers flying across the keyboard, lost in the “flow” with your favorite AI agent. This, my friends, is vibe coding. It’s when you’re in the zone, seemingly effortlessly producing code."

Because everyone knows how much cooler the "hacker / coder" man scenes in movies would have looked like if they were just prompting ChatGPT.

More seriously, my main issue with vibe coding (outside of throwaway prototypes) is that using the "code runs" as a metric isn’t a good way to tell whether the code is actually correct. It just feels like a great way to introduce sublte edge case bugs later downstream. You do your application a disservice by not at least taking a minimal amount of time to review the LLM output.

Its a rehash of the old “but it works on my local machine”

Vibe coding is the worst thing that's happened to our profession in the last 20 years. Or perhaps the best, after all, someone has to debug those catastrophic messes masquerading as applications.

Spending $30/mo means this person has definitely not dug in very hard on Claude Code. My partner and I are spending more like $30/day using it for vibe coding.

$30/day would not be a worthwhile return on investment for such a tool

Let's say a decent software engineer gets paid $100k per year (40hr weeks, 50 weeks a year.)

$100,000 / (50 weeks * 40 hours) => ~$50 per hour.

Extremely conservatively, if this saves a developer ~30 minutes per day, it pays for itself. If you spent $100 per day, it would still be worth it.

> Extremely conservatively, if this saves a developer ~30 minutes per day, it pays for itself.

And when it sends the same developer down a rabbit hole of "something weird is going on" for a couple days (using your math - 2 x 8 * $50 / hr = $800), does it still pay for itself?

The blog author didn't think so, but there's good anecdotal + empirical evidence that working with LLMs boosts *overall productivity*. (A recent study: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5188231)

If you lose 8 hrs to weirdness, but save 10 hrs somewhere else, then yeah it does pay for itself.

My argument is that it doesn't need to improve overall productivity much to have positive ROI. Whether you agree that these tools improve productivity or not is another question.

> If you lose 8 hrs to weirdness, but save 10 hrs somewhere else, then yeah it does pay for itself.

> My argument is that it doesn't need to improve overall productivity much to have positive ROI.

That makes sense.

Problem is, there exists a paradox when relying upon LLM's to make software solutions:

  People use them to "save time."
  
  Saving time by outsourcing understanding to LLM's 
  circumvents learning.
  
  Without learning, the tool becomes a crutch.
  
  When the crutch breaks, there is nothing behind it to fall 
  back onto.

Obviously this depends on the return you are getting. For us it has been incredible. We have mostly been working on greenfield / small apps and making decisions to use popular technology we believe to be correct even though we don't have much experience working with them previously. This is probably the perfect environment for vibe coding. I acknowledge that there are potentials for gotchas with any new technology, but I suspect AI has saved us from 10x as many as it may potentially be steering us toward.

Agreed. $10-20 a day here.

I now find Vibe coding an apt name (because I find it horrible) for something that usually has nothing to do with coding. Like prompt engineering usually has nothing to do with engineering. While non-coders or bad coders can create things that look and act passible if not too large, it turns out it doesn't actually go all the way, even with patience. People who change/build/release large production systems using AI, are actually programmers and use LLMs to whip up swats of boilerplate (which, for us, means only frontend; our backend system has been good enough to just type what you want in terse format code which is far faster than English and of course very precise as no LLMs there), but we read the code after and when LLMs get stuck, we fix it. The new 'vibe coders' cannot really do that as they don't understand what went wrong and the LLM, helpfully, tells them every iteration that YES now it knows and fixes it; change a massive part of your app, but nope, doesn't work. Loop around until sanity gives out or just delete and start over (I see people do that with good results; LLMs are just better at one shot than with changes).

One of the things I find really helpful and grounding, both to me and the LLM, is working in a tree-like (or fractal) pattern.

First I create the trunk (a broad outline of what I wish to accomplish). Then I concentrate on filling out the branches (the individual bullet points of that broad outline). Then I drill down into the twigs and then the leaves.

It's a different workflow than what I used to follow before LLMs arrived, where I tended to build bottom-up, rather than top-down. But it seems to keep both me and the LLM on track.

Even though it's structured, is it still vibe coding? Well, I think of vibe coding mostly in terms of the psychology. If whatever I'm doing induces a feeling of flow, then that's the vibe I'm going for. https://en.wikipedia.org/wiki/Flow_(psychology)

> One of the things I find really helpful and grounding, both to me and the LLM, is working in a tree-like (or fractal) pattern.

> First I create the trunk (a broad outline of what I wish to accomplish). Then I concentrate on filling out the branches (the individual bullet points of that broad outline). Then I drill down into the twigs and then the leaves.

This is also known as "top-down", Structured Programming[0], and/or Imperative Programming[1].

The only difference here is the language used.

0 - https://en.wikipedia.org/wiki/Structured_programming

1 - https://en.wikipedia.org/wiki/Imperative_programming

You read through the evolution of the arguments for using LLMs for coding on HN and it seems like the rediscovery of all the programming principles again. Maybe in a few months, we will have flowchart, some smalltalk like environment, and UML again.

Related note: Karpathy is really good at naming things. Seems whatever name he comes up with for new things sticks.

I use LLM in my workflow a lot, however it never occurred to me there's any vibe until this online running joke.

And no, the vibe is largely the same as before, there was google, then stackoverflow, and then now here's an AI that would most likely take care of the specific question and generate boilerplate if you frame the question correctly.

Framing the question correctly isn't a vibe, it requires logical thinking that feels almost like coding, and results need to be checked. Even then, I usually don't go a day without spotting some sort of hallucination (correcting obvious wrongs during prompting doesn't count). And testing is essential because sometimes that's how you can catch this kind of hallucination.

I do find learning in terms of project and even coding itself improves a lot faster with a capable LLM. It introduces a lot of idiomatic ways to code, and provides a lot of practice to fix whatever didn't work or add things that are just easier to type then asking it to fix.

It doesn’t work to let the model rip and clean up after - well, it works the first time. But the second time you do it, it’ll make duplicates of stuff you didn’t know you already had because you’re not fully across your own codebase and neither is the model.

Instead treat the model output as a spike. By this I mean - first ask for the feature, then put the changes into a patch or stash. Reset with `git reset --hard`, then hand-author the change using the LLM output you stashed as a reference.

It is also awesome to one-shot a giant feature with Gemini, thanks to its long context:

> cd $REPO_ROOT && repomix && llm -m gemini-2.5-pro-exp 'attached is my entire codebase. Please add $FEATURE. In your output give all file paths and find/replace blocks needed for the implementation plus any commands and other instructions I will need.' -a repomix-output.xml

(Thanks Simon Willison and the creators of repomix.)

Welcome to the wild west of what we should call “agentic coding”. Serious professionals are doing this stuff, it isn't pure vibes. You’re at the forefront, upending the way software has been built for decades. Theres huge ROI right now hacking together your own workflows. While it’s still DIY, enjoy being part of the shared learning process & please share what you learn :)

I found my experience with AI Chat vs web search much different than OPs. For me AI chat almost always gives better results than web search. Most of the time I use it it's when I know that what I'm doing is possible but I'm not sure exactly how to do it. For example writing some SQL recently I wanted to know how to write a query in a slicker way and Gemini was able to output something that I'd never have been able to search for and that coming up with on my own would have required 30 minutes to an hour of reading docs.

GitHub code search is way more useful to me than AI for searching how to do something I need an example of. I do use traditional search engines all the time but GitHub code search is great.

My one-evening vibe coding experiment with building a personal rag system ended up lasting three weekends, costing $60, and working MUCH worse than ripgrep.

I find AI very helpful for some programming problems and GH Copilot can be very useful sometimes (especially, when it is not overeager), but this vibe coding business is beyond me.

(I only used OpenHands and Trea in Docker. I haven't tried more premium products due to budget constraints. In hindsight, maybe I should have.)

Will the day come when the LLM will write software/apps for us in some pseudocode that only the llms understand, and deploy into an infra that the llms control and understand, eg it all kind of becomes a big llm black box?

Well that didn't last long.

I don't know... If you leave "with your favorite AI agent" out of that opening paragraph, that describes how I've been coding for the last 40 years or so. I'm not sure what AI has to do with it.

To me it just sounds like awkward product placement. Trade out "with your favorite AI agent" with "while chowing down on Doritos(tm) Cool Ranch(R) Tortilla Chips".

Prolog and Lisp would shine here refactoring code and writting and veryfing unit tests by themselves. For obvious reasons. Lexical parsing it's an exercise for Common Lisp programmers, and ditto with Contrain Satisfaction Problems under that language.

Vibe coding to normal programming (including GitHub Copilot) is what social media feeds to RSS feeds.

Less structure, less optimal, but requires lower mental energy. So, it is likely to win, just like social media feeds won over RSS feeds.

With sfeed you can merge feeds with literally 'cat' into a single file.

> With sfeed you can merge feeds with literally 'cat' into a single file.

And how many people use that? How many who are not geeks?

stupid question: can you "vibe code" unreal engine 5 blueprints? For example "create a blueprint to make this character open the door"

I tried it and it’s not really possible since the Blueprint text representation is so ridiculously verbose. I’m not sure why they used a format that is so difficult to convert to text. I ended up using Angelscript to see if that works, and it does decently but since it’s such a niche language you have to write docs to tell the LLM how to write it.

I think vibe coding is missing the point of AI coding. You need more rigour, not less, to produce complex and reliable software. I use RooCode + memory bank, and use both a product brief and Gherkin-like spec files to guide the agent. I will create the spec files for classes or modules, sometimes using agent help, then tell it to implement the spec. It works really well.

Vibe Coding vs. AI Chat vs. Web Search vs. Thinking for Yourself

this is nothing new. if you copy and pasted code from stackoverflow 5 years ago with no understanding how it works, it would have lead to the same issues. fully understanding what the AI did, and ask questions if you don't understand.

Your comment has a lot of merit and more people should take this approach/view

I dont think it is the same, or at least that is not my experience of using SO. Typically using involved usually requires me synthesising answers, getting a better understand of my issue in order to search/evaluate the answers I need. With an LLM I can be much more vague, and the amount of mental effort I have to spend to get to some "working" code is much less and does not require me understand as many things. Even if I did not understand fully what a piece of code from SO did, it was usually at worst a piece of code that I still needed to integrade inside a function etc. I doubt you could get into having any interesting enough working up simply by copy pasting code from SO. Now I can copy paste entire functions and code files from an LLM.

>fingers flying across the keyboard

You're supposed to use openai whisper, not your keyboard, at least according to the guy who coined the term vibe coding.

Hmm, someone hit the downvote button, but it's right here. https://news.ycombinator.com/item?id=42913909

While vibe coding you're code blind, but you can still be aware of the architecture.

If all the subsystems are simple and sparesly connected, any bug will likely be isolated and easy to detect.

You can build complex systems using simple subsystems while being code blind.

Context problem is mitigated with sparse architectures.

Reply on news.ycombinator.com