Hacker News Reader

Comment by simonw | Hacker News Reader

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/

View on HN

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

Reply on news.ycombinator.com