Research · 10 September 2026 · 11 min read
Vibe coding: what happens after the demo
Every demo ends at the working prototype. We read the comments under 25 of them, and the transcripts, to find out what the audience keeps asking about the part that comes next.
Read from 25 videos and 340 comments across 14 channels. Every claim links to the minute it was said.
The most liked comment we found under Y Combinator's “Vibe Coding Is The Future” is eleven words long. “Vibe coding is the future unless you need to do 'Vibe debugging'” (907 likes). Just below it, a person still waiting: “Yeah sure the vibes might be good but my database connection is still timing out” (631).
That is the shape of the report. The videos show the demo. The comments are about what happened after it.
We read the transcripts and the comment sections of 25 videos across 14 channels: YC and a16z at one end, Greg Isenberg and Starter Story and Nate Herk and Peter Yang at the other. We looked for the moment a creator or a viewer went past the prototype. Four questions came up under video after video. What do you do when the bug loop starts. Who checks the security. What does it cost to run. Who fixes it at 3am.
The first one is the only one the creators answer well.
The loop
Greg Isenberg's “67 mins” build has the moment every vibe coder recognises. The input field does nothing. No error. He tells Cursor what he wanted, hits enter, and admits he only gets short with the model “when it fails 10 times in a row” (36:44). Three minutes later: “the most annoying part about this is we're not getting any error… it should say API is failing because you have an incorrect API key” (39:47).
The comment under that video with 392 likes is from a team that tried every generator. “Bug fixing what they produce would be more expensive than us building an app with our own hands” (392).
Tom Blomfield's YC Startup School talk is the closest thing to a manual. Commit before every feature, because “I know the tools have these kind of revert sort of functionality. I don't trust them yet” (6:08). Paste the error and nothing else: “Simply the error message is enough” (9:13). When the model keeps regenerating the same broken thing, stop. Get a clean reference implementation working on its own, then point the model at it (12:15). Keep files small, because a file thousands of lines long confuses the model as much as it confuses you (15:17).
The full report is free. It costs an email.
One email unlocks this report and every report after it, on this device, for a year. One message per report. No pitch in between.
Already unlocked on another device? Enter the same email.