Anyone who regularly uses LLMs to produce code knows that vibe coding anything larger than a to-do app is not currently realistic.
Once your codebase reaches the size needed to solve actual business problems, the quality of the output varies wildly, the complexity of the prompts required to produce useful code increases, and the output code requires significant editing to actually integrate without bugs or errors.
My personal opinion is that for vibe coding to be viable as the complexity of feature requirements or the size of the code base increase, the specificity and complexity of the input prompt will eventually demand more from the engineer than just writing the code, since code is more specific by definition than natural language.
The limitation is the scope of the problem space; reduce the space and it becomes more reliable. Use the LLM to create independent discrete highly-cohesive composeable applications (with test suites), use those to compose the business logic, and it will be reliable. So basically microservices (but, actually correct microservices, rather than how most people make them).
Vibecoding is just not looking at the code. You can not know code, but still know what to ask for. That's already a thing we expect of LLM use; if you don't ask it right, give the right context, etc, it's not as useful. So give it the right architectural guidelines, compartmentalize your use of it, and you'll get good results.
Then we should be seeing something already, this approach exists for many years by the serverless folks. Vibe coding it should be rather straightforward since there's loads of tutorials, example code, etc. available.
The problem of this approach is the problem of "correct microservices". You are moving complexity up from the application layer to the architecture layer. If you ever had to work on "correct microservices", you will know that even for humans it becomes hard to have a mental model and reason about the system as a whole. Good luck having your LLMs tackle it, when at times the best way to describe those services is through diagrams instead of text descriptions.
That expresses it well. For the code output to be good, my specifications have to be very detailed and thoroughly reviewed by multiple LLMs. Even so, I still have to make some changes manually, both before and after the code generation. It could be possible to add broad refactoring steps with vibe coding, but I remain skeptical. I think the frontier of how far one can get with vibe coding will keep pushing forward, but it's not that far yet, especially when security and performance are on the line.
Wow. I’ve never actually heard this take before but I think you’re spot on. Vibe coding has serious limits as the scale of the project grows. As the complexity grows, human language becomes a crude tool compared to just coding and you will find your efficiency falls off a cliff trying to get the LLM to understand and effectively change or implement what you could have done by hand.
You can vibe code chunks, but not whole repo. I have tried to do it and every LLM starts to hallucinate after 2-3 hours. And you have to know what you want to achieve. Coding with “a little help” is feasible.
OpenAPI, microservices segmentation and keeping things small helps a lot. Probably the worst piece of the puzzle is the UI to maintain the coherence but it can be solved.
What's the largest app you've entirely vibe-coded with this architecture? For me, everything fails at a few hundred lines, no matter how micro you keep your services.
Mind you, we're talking zero review at all, just using whatever the LLM produces.
LLMs have an unsolvable problem of "hallucination". It is a bad description of what the problem is because hallucination is all they do, it just also happens to be correct in many cases. The larger the codebase or the problem space, the less accurate LLMs tend to be.
I'm becoming increasingly convinced that you need a purpose-built LLM to generate usable UI code. There are ways to use LLMs to increase efficiency and velocity without sacrificing quality, but they're all at the API/backend/service/whatever-you-want-to-call-it level, or in the initial planning stages.
I basically use LLMs to plan work, then to do the backend work with close supervision, then I do all the UX stuff completely on my own.
That's really interesting. I feel like that runs counter to a broader perception that vibe-coding the FE / UX is straightforward, vs more challenging backend stuff. As someone whose 27-year career began with - and remained largely centered around -- client-side / FE / UX, it's of particular interest.
I've "vibe-coded" a few small hobby projects, and use cursor sometimes for professional stuff, and it always collapses for me on "real" front-end tasks. Yeah I can say "give me a layout of a certain style" and it will do reasonably well if it has no existing constraints. But for example, I vibe-coded a UI and then tried to adjust the tailwind theme it picked, and it was an absolute nightmare. You would have thought "change the primary color from A to B, select a new accent color that is darker than what you've selected and is not A or B, and now update the dark theme to be comparable" spread across multiple prompts was one of those crazy 3d animation puzzles you see used as a way to break LLMs.
AI created openapi is like mud house on beach, the first wave will destroy the whole thing into pieces beyond memory can remember it's original ugly shape...
Yeah, I have a rule to tell the agent to not write to any of our OpenAPI specs, it reliably mangles them and then gets stuck trying to unmangle them. I get better results modifying the specs myself and using that as context for the agent so it better understands what I want.
My comment is more about what to expect in the next 12 months.
I've been using VSCode's Copilot with Claude Sonnet 4 and find it to be terrifyingly competent running 8 hours a day costing ~$10.
I am developing techniques to keep it moving forward producing code and fast. First, prompt engineering like "write clean, simple, and elegant code." Second, I use TypeScript very strictly which helps. Third, the models are amazing at producing very simple test units which will be important in the fifth. Fourth, I use techniques like "look for opportunities to refactor pure functions in the file and put them at the top of file" or "look for opportunities to refactor pure function and put them in shared utils.ts file." Fifth, every hour or so, I will have the agent simplify and clean the code and with complete test coverage both unit and integration as longs as they all pass .... good to go.
This is a process and it is the same every time. So now I'm thinking about how do I write code to automate these steps into an automated process. For example, I keep using the same pattern of steps to solve hard debugging problems which I'm going to leave out of this conversation now. If I can create a process in code, I'd be one step closer to complete automation coding.
The patterns are emerging. I strongly believe in 12 months these systems are going to be able to write extremely complicated programs with very little input from the human in the loop.
Since AI-Gen code is such a roll of the dice, the key is to roll the dice a lot - usually generate at least 3 potential solutions from at least two separate providers at the outset - and get good at quickly reviewing the offered solutions, or iterating on the prompt and regenerating.
In the past 3 weeks I ported Playwright to run completely inside a Chrome extension without Chrome DevTools Protocol (CDP) using purely DOM APIs and Chrome extension APIs, I ported a TypeScript port of Browser Use to run in a Chrome extension side panel using my port of Playwright, in 2 days I ported Selenium ChromeDriver to run inside a Chrome Extension using chrome.debugger APIs which I call ChromeExtensionDriver, and today I'm porting Stagehand to also run in a Chrome extension using the Playwright port. This is following using VSCode's core libraries in a Chrome extension and having them drive a Chrome extension instead of an electron app.
I very heavily use the VSCode Copilot coding agents for all this.
I tried Claude Code because they gave 1 week free about a month ago. I didn't feel there was any advantage over Github Copilot which has been making huge strides trying to stay competitive in the past couple months.
Maybe I should revisit Claud Code with this systematic process workflow that has been evolving.
I've heard of a few SaaS apps that were vibe coded by non-programmers, some of which are generating revenue.
I've also seen incidents of those apps turning out to have security holes you can drive a truck through, and hiring professional help to move beyond their origins.
(I didn't keep notes of the companies and I don't want to specifically call any out, but they exist.)
I'm hoping this is a relatively short-lived trend. I think vibe coding tools for personal use and prototypes is to be celebrated, but vibe coding software that other people will depend on or even pay for is deeply irresponsible.
This isn’t a “vibe coding” phenomenon and isn’t particularly egregious now. It’s usually the same people who peddled crypto, NFTs, multilevel marketing, seo blogspam and a bunch of other “get rich quick” schemes in the past
I've noticed a huge uptick in this brand of "entrepreneur". I think everyone who was inspired by devs like LevelsIO, limped their way through some code academy tutorials and was discouraged that you actually needed to have _some_ technical skills back in the mid 2010s is now encouraged to try again with vibe coding. It's always a combo of vibe coding + automation tools like n8n/zapier that does some simple data plumbing or just calls an API.
Just like you said, they all claim to make $xk per month and have a course to sign up for. I really hate this as places like product hunt are just gummed up now with Slapps (AI slop apps). The courses they sell seem to be how to quickly make Slapps, get people's email addresses and then use the authors email list management software (for a monthly fee) to endlessly send spam.
> It's always a combo of vibe coding + automation tools like n8n/zapier that does some simple data plumbing or just calls an API.
I agree with all that you said, however…
I have found that doing stuff that could be done with code with the automation tools/services that you mentioned above (plus excel) is often preferable for small businesses and certain orgs precisely so that a programmer doesn’t have to be called on every time a change is needed.
Not knocking programmers (I’ve been programming since age 10), but programmers aren’t always easy to hire and evaluate, and their cost (at least until recently) has been extremely high.
These automation tools allow for business to make a tech leap with much lower execution cost and risk.
So while I agree that a lot of the “vibe coding” stuff being promoted is drivel, that doesn’t mean that the tools themselves are not empowering in the right hands.
There was the whole thing about the app for relationship pdiscussions, "Tea" I think, being apparently vibe coded and lacking proper security, leading to a data breach.
More generally, I think vibe coding has replaced lots of mockups and demos for startups. There is really zero excuse to show slides or figma now in am early product demo. There are definitely startups succeeding on this basis, as in getting funding and signing up customers.
If success means being profitable and running stable software, I don't see vibe coding as currently able to carry a company all the way through, but it's definitely part of the journey now.
there’s no evidence “Tea” was vibecoded (especially because it was launched in early 2023, when tools like Cursor weren’t really widely used). All evidence seems to point to the usual issue 9 out of 10 startups face (and have always faced) - unprotected S3 buckets (this was Tea’s issue), misconfigured firebase or supabase RLS (I made some good money helping startups close these holes a few times) or unauthenticated APIs.
My stack lately has been Next.js with Prettier and very strict lint, type, and complexity gates, plus opinionated tests that aim for real signal over mere coverage theatre.
I want to find the time to fine-tune GPT-4o using before/after examples of code that fails the gates and then passes them. The hope being it generates gate-compliant code on the first try much more often, which is cheaper and more reliable than relying on a base model with brute-force retries. I think this might also align with research showing that grounding models in execution feedback yields order-of-magnitude gains in sample efficiency and improved code quality, not just speed [0][1].
What does "real signal" mean in this context? I think (hope?) most people agree test coverage for the sake of coverage isn't particularly helpful but it's not clear to me how an "opinionated test" would differ from the tests you'd find in your standard "we want 100% coverage" projects.
I am trying to capture the idea that opinionated tests assert invariants and contracts at integration boundaries, while coverage-driven suites often spend effort on shallow checks. The goal is fewer but stronger tests that actually prevent regressions.
Here is one attempt at defining a TESTING.md that I pass to Claude Code [0].
Honestly, it is different from what I now use in other projects. For example, I have found that mutation tests are rarely worth the added complexity. I have not yet found a good way to enforce a deterministic gate that only permits “good” tests, so I settle on defining expectations in a markdown file that I pass to whichever coding agent I am using.
Not sure, most were probably created just for this hackathon so I'd expect few if any. It's just a good way to see how far one can take it with vibe coding. It's easy to crank out smaller apps these days so marketing and distribution will be more important going forward.
Note there's a small core set of features and then relentless refining going into the product after that. I think products that require the opposite, a relentless expansion of features vs tightening bolts may be much more doomed.
Can you define vibe coding? I'm seeing it used for anything from not even looking at the code to writing long detailed specs for the LLM and then heavily reviewing its output
If it's a non-programmer trying to build a non-trivial software product with AI I haven't heard of anyone successfully doing that and I'm very confident in saying theres no chance it'll happen with todays AI
Great post; I'm reminded of how firstly 'no-code' was often used adjacent to 'low-code' in blogspam and press releases, but also how the only shop I've ever worked in that used such a tool had an ever-expanding team of devs building stuff with it, as opposed to the non-technical users it was supposedly meant to target.
In reality, when people talk about "vibe coding" they're probably either being self-deprecating (if it's their own work) or snarky (if it's somebody else's).
I've made a couple of things lately that I sometimes tell people are "vibe coded" because they were heavily facilitated by LLMs, but it's not really true in the pure, literal sense.
I got an advert served to me for Lovable yesterday, it contained various screenshots of folks from twitter saying they are at $XXX,XXX MRR on some vibecode app they built on lovable, not clue how real that is but they looked like real screenshots (could be some folks BS'ing for clout tho)
I don't think vibe coding has been around for long enough to produce a "successful startup" even under the most optimistic interpretation. Furthermore, the code is only a slice of what a startup is. And not even a very large one.
The dominant strategy right now might be to be skilled enough to do your job, much more effectively than "AI", but product-wise hop on the hype bandwagon of selling "AI" tools to people who are bad at their jobs.
MySpace's glitz was partly due to poor input sensitization. They tried to weed out things like <script> tags while leaving folks the ability to rewrite the HTML on their pages.
There seems to be an army of people on Twitter making $100k MRR from AI Tinder photo enhancer apps and they have a course to sell you.
This is the same brand of person that was excited to get rich off NFTs and has now just moved on to slapps (AI slop apps).
Vibe coding is fun and great for personal projects or bootstrapping, but the specificity of the prompts needed to effect the change you want grows exponentially with the code base size to the point where you do just need to code it yourself and use the AI as a helper.
I built this spreadsheet over a week with AI writing nearly all the code. It doesn't fully fit your thesis because I have experience coding and I did it for fun not as a startup. Now it's not perfect but does have recalc, undo, and file saving working. I think of it more like one of those assisted e-bikes, you still have to pedal but it gets you much farther on each stroke.
Pure speculation, but people have suggested that the iOS app Tea was vibe coded. (Based on the quality of the code and the founder's stated background)
Lovable was (is?) heavily vibe-coded AFAIK. Allegedly there’s a lot of 1-2 people startups making good money out there, and those were likely impossible without vibe coding (they’d take much more time to build)
The “toy app” feel is really not a big problem if you put some effort into it. It’s very easy to see landing pages made with a one-shot request on Cursor, but if you put some effort into adjusting things, you can get to pretty good design in a fraction of the time.
To be clear, my position is “vibe coding” _must_ include _some_ level of coding by hand (not entirely prompting an AI), at least with the current generation of tools.
Another tidbit, in my personal experience, is that lovable & co are enabling completely non-technical people to push out hot sites, marketing material, etc (including simple interactive experiences, for instance) quite flawlessly and quickly. This would require a dedicated engineer at least, in the past. It’s what the “no code” promise of years past was supposed to enable (IMO it didn’t, webflow/etc are clunky and hard to use even for non-coders).
Anyone who regularly uses LLMs to produce code knows that vibe coding anything larger than a to-do app is not currently realistic.
Once your codebase reaches the size needed to solve actual business problems, the quality of the output varies wildly, the complexity of the prompts required to produce useful code increases, and the output code requires significant editing to actually integrate without bugs or errors.
My personal opinion is that for vibe coding to be viable as the complexity of feature requirements or the size of the code base increase, the specificity and complexity of the input prompt will eventually demand more from the engineer than just writing the code, since code is more specific by definition than natural language.
The limitation is the scope of the problem space; reduce the space and it becomes more reliable. Use the LLM to create independent discrete highly-cohesive composeable applications (with test suites), use those to compose the business logic, and it will be reliable. So basically microservices (but, actually correct microservices, rather than how most people make them).
That's not vibecoding anymore.
Vibecoding is just not looking at the code. You can not know code, but still know what to ask for. That's already a thing we expect of LLM use; if you don't ask it right, give the right context, etc, it's not as useful. So give it the right architectural guidelines, compartmentalize your use of it, and you'll get good results.
True microservices have never been tried.
Like some bizarro world of Unix Philosophy-esque tools mashed into the approach people have when creating "serverless" applications?
Or define what a true microservice is because I think there are many takes on that.
My friend, it's possible you missed the joke.
Oh, I did indeed miss it facepalm.
Do I smell a true Scotsman here?
Not everyone that smells like peaty whisky is a Scotsman!
Then we should be seeing something already, this approach exists for many years by the serverless folks. Vibe coding it should be rather straightforward since there's loads of tutorials, example code, etc. available.
The problem of this approach is the problem of "correct microservices". You are moving complexity up from the application layer to the architecture layer. If you ever had to work on "correct microservices", you will know that even for humans it becomes hard to have a mental model and reason about the system as a whole. Good luck having your LLMs tackle it, when at times the best way to describe those services is through diagrams instead of text descriptions.
That expresses it well. For the code output to be good, my specifications have to be very detailed and thoroughly reviewed by multiple LLMs. Even so, I still have to make some changes manually, both before and after the code generation. It could be possible to add broad refactoring steps with vibe coding, but I remain skeptical. I think the frontier of how far one can get with vibe coding will keep pushing forward, but it's not that far yet, especially when security and performance are on the line.
Wow. I’ve never actually heard this take before but I think you’re spot on. Vibe coding has serious limits as the scale of the project grows. As the complexity grows, human language becomes a crude tool compared to just coding and you will find your efficiency falls off a cliff trying to get the LLM to understand and effectively change or implement what you could have done by hand.
You can vibe code chunks, but not whole repo. I have tried to do it and every LLM starts to hallucinate after 2-3 hours. And you have to know what you want to achieve. Coding with “a little help” is feasible.
OpenAPI, microservices segmentation and keeping things small helps a lot. Probably the worst piece of the puzzle is the UI to maintain the coherence but it can be solved.
What's the largest app you've entirely vibe-coded with this architecture? For me, everything fails at a few hundred lines, no matter how micro you keep your services.
Mind you, we're talking zero review at all, just using whatever the LLM produces.
Funny how devs here used to love bragging about how their job isn't to write code and that they shouldn't be measured on LOC.
Now suddenly the problem is that AI can't write a lot of code.
The problem is that AI can't currently write large quantities of correct and maintainable code to create a larger app.
(For some value of "larger")
Both can be true.
LLMs have an unsolvable problem of "hallucination". It is a bad description of what the problem is because hallucination is all they do, it just also happens to be correct in many cases. The larger the codebase or the problem space, the less accurate LLMs tend to be.
And developers to a lot more than generating LOC.
No, the problem is the AI can't avoid making mistakes often. I'm not measuring it on LOC.
Microservices increase complexity by a lot.
https://www.youtube.com/watch?v=y8OnoxKotPQ
Knew exactly what this was before even clicking on it. Brilliant, funny, but also realistic!
Note: the video is partially NSFW due to abusive language.
I'm becoming increasingly convinced that you need a purpose-built LLM to generate usable UI code. There are ways to use LLMs to increase efficiency and velocity without sacrificing quality, but they're all at the API/backend/service/whatever-you-want-to-call-it level, or in the initial planning stages.
I basically use LLMs to plan work, then to do the backend work with close supervision, then I do all the UX stuff completely on my own.
That's really interesting. I feel like that runs counter to a broader perception that vibe-coding the FE / UX is straightforward, vs more challenging backend stuff. As someone whose 27-year career began with - and remained largely centered around -- client-side / FE / UX, it's of particular interest.
I've "vibe-coded" a few small hobby projects, and use cursor sometimes for professional stuff, and it always collapses for me on "real" front-end tasks. Yeah I can say "give me a layout of a certain style" and it will do reasonably well if it has no existing constraints. But for example, I vibe-coded a UI and then tried to adjust the tailwind theme it picked, and it was an absolute nightmare. You would have thought "change the primary color from A to B, select a new accent color that is darker than what you've selected and is not A or B, and now update the dark theme to be comparable" spread across multiple prompts was one of those crazy 3d animation puzzles you see used as a way to break LLMs.
AI created openapi is like mud house on beach, the first wave will destroy the whole thing into pieces beyond memory can remember it's original ugly shape...
Yeah, I have a rule to tell the agent to not write to any of our OpenAPI specs, it reliably mangles them and then gets stuck trying to unmangle them. I get better results modifying the specs myself and using that as context for the agent so it better understands what I want.
Using HTTP as a linker (i.e. microservices as typically implemented) gives you a ton of other problems to worry about instead though...
My comment is more about what to expect in the next 12 months.
I've been using VSCode's Copilot with Claude Sonnet 4 and find it to be terrifyingly competent running 8 hours a day costing ~$10.
I am developing techniques to keep it moving forward producing code and fast. First, prompt engineering like "write clean, simple, and elegant code." Second, I use TypeScript very strictly which helps. Third, the models are amazing at producing very simple test units which will be important in the fifth. Fourth, I use techniques like "look for opportunities to refactor pure functions in the file and put them at the top of file" or "look for opportunities to refactor pure function and put them in shared utils.ts file." Fifth, every hour or so, I will have the agent simplify and clean the code and with complete test coverage both unit and integration as longs as they all pass .... good to go.
This is a process and it is the same every time. So now I'm thinking about how do I write code to automate these steps into an automated process. For example, I keep using the same pattern of steps to solve hard debugging problems which I'm going to leave out of this conversation now. If I can create a process in code, I'd be one step closer to complete automation coding.
The patterns are emerging. I strongly believe in 12 months these systems are going to be able to write extremely complicated programs with very little input from the human in the loop.
Yeah, I've been able to stack ~200 AI-generated commits on top of each other. Over 95% of the code is now AI generated.
You can see each prompt and each commit that was generated here: https://github.com/sutt/agro/blob/master/docs/dev-summary-v1...
Since AI-Gen code is such a roll of the dice, the key is to roll the dice a lot - usually generate at least 3 potential solutions from at least two separate providers at the outset - and get good at quickly reviewing the offered solutions, or iterating on the prompt and regenerating.
What are you building?
In the past 3 weeks I ported Playwright to run completely inside a Chrome extension without Chrome DevTools Protocol (CDP) using purely DOM APIs and Chrome extension APIs, I ported a TypeScript port of Browser Use to run in a Chrome extension side panel using my port of Playwright, in 2 days I ported Selenium ChromeDriver to run inside a Chrome Extension using chrome.debugger APIs which I call ChromeExtensionDriver, and today I'm porting Stagehand to also run in a Chrome extension using the Playwright port. This is following using VSCode's core libraries in a Chrome extension and having them drive a Chrome extension instead of an electron app.
I very heavily use the VSCode Copilot coding agents for all this.
These are not trivial problems.
What's your feelings on Claude Code? I mean you obviously chose VS Code, what wasn't hitting right using Claude Code?
I tried Claude Code because they gave 1 week free about a month ago. I didn't feel there was any advantage over Github Copilot which has been making huge strides trying to stay competitive in the past couple months.
Maybe I should revisit Claud Code with this systematic process workflow that has been evolving.
I've heard of a few SaaS apps that were vibe coded by non-programmers, some of which are generating revenue.
I've also seen incidents of those apps turning out to have security holes you can drive a truck through, and hiring professional help to move beyond their origins.
(I didn't keep notes of the companies and I don't want to specifically call any out, but they exist.)
I'm hoping this is a relatively short-lived trend. I think vibe coding tools for personal use and prototypes is to be celebrated, but vibe coding software that other people will depend on or even pay for is deeply irresponsible.
What I've seen is mostly small apps and people that claim they're making thousands of dollars every month with them.
And they usually try to sell you their courses/mentorships.
I don't know if I'm being suspicious because they seem fake or because they came out of nowhere and are earning in a month what I make in a year.
This isn’t a “vibe coding” phenomenon and isn’t particularly egregious now. It’s usually the same people who peddled crypto, NFTs, multilevel marketing, seo blogspam and a bunch of other “get rich quick” schemes in the past
I've noticed a huge uptick in this brand of "entrepreneur". I think everyone who was inspired by devs like LevelsIO, limped their way through some code academy tutorials and was discouraged that you actually needed to have _some_ technical skills back in the mid 2010s is now encouraged to try again with vibe coding. It's always a combo of vibe coding + automation tools like n8n/zapier that does some simple data plumbing or just calls an API.
Just like you said, they all claim to make $xk per month and have a course to sign up for. I really hate this as places like product hunt are just gummed up now with Slapps (AI slop apps). The courses they sell seem to be how to quickly make Slapps, get people's email addresses and then use the authors email list management software (for a monthly fee) to endlessly send spam.
> It's always a combo of vibe coding + automation tools like n8n/zapier that does some simple data plumbing or just calls an API.
I agree with all that you said, however…
I have found that doing stuff that could be done with code with the automation tools/services that you mentioned above (plus excel) is often preferable for small businesses and certain orgs precisely so that a programmer doesn’t have to be called on every time a change is needed.
Not knocking programmers (I’ve been programming since age 10), but programmers aren’t always easy to hire and evaluate, and their cost (at least until recently) has been extremely high.
These automation tools allow for business to make a tech leap with much lower execution cost and risk.
So while I agree that a lot of the “vibe coding” stuff being promoted is drivel, that doesn’t mean that the tools themselves are not empowering in the right hands.
Sounds like one of those course-based pyramid schemes similar to life coaches who "coach coaches to coach others how to coach coaches"
Here is the secret:
Step 1: Vibecode 5 trash generic apps (eg AI interior designers, gpt wrappers)
Step 2: Launch with paying 15k in google/meta ads
Step 3: Receive back ~5k in revenue
Step 4: Spam on twitter+linkedin clickbaity "heres how i reached 60K ARR in 3 milliseconds" posts to attract ex-crypto bros and hustlers
Step 5: Use your newfound following for sponsored content, courses and hopefully actual organic growth for your aforementioned trash apps
There was the whole thing about the app for relationship pdiscussions, "Tea" I think, being apparently vibe coded and lacking proper security, leading to a data breach.
More generally, I think vibe coding has replaced lots of mockups and demos for startups. There is really zero excuse to show slides or figma now in am early product demo. There are definitely startups succeeding on this basis, as in getting funding and signing up customers.
If success means being profitable and running stable software, I don't see vibe coding as currently able to carry a company all the way through, but it's definitely part of the journey now.
there’s no evidence “Tea” was vibecoded (especially because it was launched in early 2023, when tools like Cursor weren’t really widely used). All evidence seems to point to the usual issue 9 out of 10 startups face (and have always faced) - unprotected S3 buckets (this was Tea’s issue), misconfigured firebase or supabase RLS (I made some good money helping startups close these holes a few times) or unauthenticated APIs.
My stack lately has been Next.js with Prettier and very strict lint, type, and complexity gates, plus opinionated tests that aim for real signal over mere coverage theatre.
I want to find the time to fine-tune GPT-4o using before/after examples of code that fails the gates and then passes them. The hope being it generates gate-compliant code on the first try much more often, which is cheaper and more reliable than relying on a base model with brute-force retries. I think this might also align with research showing that grounding models in execution feedback yields order-of-magnitude gains in sample efficiency and improved code quality, not just speed [0][1].
References
[0] https://arxiv.org/abs/2307.04349
[1] https://arxiv.org/abs/2410.02089
What does "real signal" mean in this context? I think (hope?) most people agree test coverage for the sake of coverage isn't particularly helpful but it's not clear to me how an "opinionated test" would differ from the tests you'd find in your standard "we want 100% coverage" projects.
I am trying to capture the idea that opinionated tests assert invariants and contracts at integration boundaries, while coverage-driven suites often spend effort on shallow checks. The goal is fewer but stronger tests that actually prevent regressions.
Here is one attempt at defining a TESTING.md that I pass to Claude Code [0].
Honestly, it is different from what I now use in other projects. For example, I have found that mutation tests are rarely worth the added complexity. I have not yet found a good way to enforce a deterministic gate that only permits “good” tests, so I settle on defining expectations in a markdown file that I pass to whichever coding agent I am using.
[0] https://github.com/Airbolt-AI/airbolt/blob/main/TESTING.md
One way to gauge is by taking a look at some of the projects submitted for Bolt's contest at https://worldslargesthackathon.devpost.com/project-gallery
Interesting. Are any at the point where they accept payment, i.e. generate revenue?
Not sure, most were probably created just for this hackathon so I'd expect few if any. It's just a good way to see how far one can take it with vibe coding. It's easy to crank out smaller apps these days so marketing and distribution will be more important going forward.
https://www.post-bridge.com/ by Jack Fricks was mostly(?) made via vibe coding.
Note there's a small core set of features and then relentless refining going into the product after that. I think products that require the opposite, a relentless expansion of features vs tightening bolts may be much more doomed.
Can you define vibe coding? I'm seeing it used for anything from not even looking at the code to writing long detailed specs for the LLM and then heavily reviewing its output
If it's a non-programmer trying to build a non-trivial software product with AI I haven't heard of anyone successfully doing that and I'm very confident in saying theres no chance it'll happen with todays AI
Great post; I'm reminded of how firstly 'no-code' was often used adjacent to 'low-code' in blogspam and press releases, but also how the only shop I've ever worked in that used such a tool had an ever-expanding team of devs building stuff with it, as opposed to the non-technical users it was supposedly meant to target.
In reality, when people talk about "vibe coding" they're probably either being self-deprecating (if it's their own work) or snarky (if it's somebody else's).
I've made a couple of things lately that I sometimes tell people are "vibe coded" because they were heavily facilitated by LLMs, but it's not really true in the pure, literal sense.
Building own tools if you do something that makes money has been more reliable than building for public consumption.
I got an advert served to me for Lovable yesterday, it contained various screenshots of folks from twitter saying they are at $XXX,XXX MRR on some vibecode app they built on lovable, not clue how real that is but they looked like real screenshots (could be some folks BS'ing for clout tho)
In an age of LLMs, what does "looked like real screenshots" even mean?
I don't think vibe coding has been around for long enough to produce a "successful startup" even under the most optimistic interpretation. Furthermore, the code is only a slice of what a startup is. And not even a very large one.
The dominant strategy right now might be to be skilled enough to do your job, much more effectively than "AI", but product-wise hop on the hype bandwagon of selling "AI" tools to people who are bad at their jobs.
MySpace's glitz was partly due to poor input sensitization. They tried to weed out things like <script> tags while leaving folks the ability to rewrite the HTML on their pages.
> Me: Claude, write an app that predicts the future minute by minute using quantum states.
> Claude: Sure! (proceeds to instantly vomit out a react crud app where none of the buttons do anything)
Maybe maybe not but given the pace of improvement of the foundational models and tooling, seems like something that will be possible quite soon.
There seems to be an army of people on Twitter making $100k MRR from AI Tinder photo enhancer apps and they have a course to sell you.
This is the same brand of person that was excited to get rich off NFTs and has now just moved on to slapps (AI slop apps).
Vibe coding is fun and great for personal projects or bootstrapping, but the specificity of the prompts needed to effect the change you want grows exponentially with the code base size to the point where you do just need to code it yourself and use the AI as a helper.
The founder...An LLM...is too busy shopping for their new yacht to reply to you...
I built this spreadsheet over a week with AI writing nearly all the code. It doesn't fully fit your thesis because I have experience coding and I did it for fun not as a startup. Now it's not perfect but does have recalc, undo, and file saving working. I think of it more like one of those assisted e-bikes, you still have to pedal but it gets you much farther on each stroke.
https://www.sumbuddy.net/
It doesn't actually work. Keep vibing
idk there was that one dating app that got hacked...
No.
"Vibe-funding"
Now there’s an idea.
Builder.ai /s
Pieter Levels has made lots of money doing this.
He’s not vibe coding though
Most his apps were definitely hand-crafted, but I think his flight simulator was ~entirely vibe-coded.
The great minds of HN strike again. It's like talking to children of especially feeble wit.
https://x.com/levelsio/status/1893385114496766155
https://x.com/levelsio/status/1899596115210891751
Pure speculation, but people have suggested that the iOS app Tea was vibe coded. (Based on the quality of the code and the founder's stated background)
It definitely wasn't because Tea first launched back in 2023.
It is unlikely to be true as the app had been around for a few years.
Lovable was (is?) heavily vibe-coded AFAIK. Allegedly there’s a lot of 1-2 people startups making good money out there, and those were likely impossible without vibe coding (they’d take much more time to build)
The “toy app” feel is really not a big problem if you put some effort into it. It’s very easy to see landing pages made with a one-shot request on Cursor, but if you put some effort into adjusting things, you can get to pretty good design in a fraction of the time.
To be clear, my position is “vibe coding” _must_ include _some_ level of coding by hand (not entirely prompting an AI), at least with the current generation of tools.
Another tidbit, in my personal experience, is that lovable & co are enabling completely non-technical people to push out hot sites, marketing material, etc (including simple interactive experiences, for instance) quite flawlessly and quickly. This would require a dedicated engineer at least, in the past. It’s what the “no code” promise of years past was supposed to enable (IMO it didn’t, webflow/etc are clunky and hard to use even for non-coders).