4 days ago Tom Blomfield from Y Combinator posted a video explaining some of the techniques to be good at Vibe Coding. Tom says in the start that the best techniques for Vibe Coding are the ones used by professional Software Engineers to write code (kinda ironic).
Before we talk about what Tom has to say about Vibe Coding, here are some of the reviews about Vibe Coding from the YC Founders.
Nicole Lu - If your AI editor is taking you into a loop, sometimes it helps to go to the LLM's website and paste the same code.
Skyler Ji - I open both Cursor and Windsurf side by side, give them the same problem to solve and pick the best response.
Sacha Servan-Schreiber - Take Vibe Coding as a new programming language. And to get the best results, you will have to provide a lot of context
Arshad Shaikh - I usually do Vibe Coding in the reverse direction. I write the test cases followed by the code that then has to satisfy these test cases. I never micro-manage an LLM while Vibe Coding.
Antoni Gmitruk - Spend time crafting the architecture and other details with an LLM before offloading it to an AI editor.
Vibe Coding Advice from Tom:
1. Pick Up the Tools: If you don't know a lot about programming start with Lovable or Replit. These tools give you a feel of the UI. And if you know how to write code (doesn't matter how good you are), you should try dabbling with tools like Windsurf or Cursor
2. Use Version Control Religiously: Once you have something you think is working, feel free to push to github. Do not rely on the LLM to revert the code for you because this is not always reliable
3. Write High Level Tests: Have your LLM write high level tests for your software so that you safeguard your application against unwanted changes by the LLM.
4. Bug Fixes: Sometimes, when you encounter an error message, just copy pasting the error stack is good enough for the LLM to solve it for you. For complex bugs, it's okay to reset after a failed attempt and starting over. Again, Github is your friend.
5. Documentation: You can download all the documentation for the framework you're working with and put it into a subfolder for the AI editor to access.
6. Choosing the tech stack: It's a safe bet to work with something that has been around for a long time and has a lot of open source code available.

I spent 25 years on construction sites. Today, I don't write code I orchestrate it.

While my latest launch ('What Do I Say?') was trending on PH, I spent the afternoon using agentic loops to build a Full-Stack AI Navigation App.

The Stack:

• Backend: Real-time Google Maps/Waze data orchestration.

• UI: High-end 'Co-Pilot' dark mode dashboard with 2D/3D perspective switching.

• AI Layer: A multi-intent voice brain that handles routing, traffic interrupts, and 'Pit Stop' predictions.

• The Result: A production-grade, voice-first navigator built without writing a single line of manual code.

Hey everyone

I m exploring different Backend-as-a-Service (BaaS) options for vibe coding projects small but creative builds that start locally and later go live (think quick prototypes, coding agents, or AI-powered hobby apps).

I d love to hear your thoughts on:

• how easy is it to debug or simulate the backend locally?

• how smooth is it to go from local to hosted?

• any gotchas or scale-to-zero tricks to keep costs minimal?

• functions, auth, storage, DB branching, edge runtimes, etc.

I just launched AllPub.co and built pretty much the entire thing using Vibecoding with Claude Sonnet 3.5. I'm a software architect with just some basic Python knowledge, so this was my first full web app build. Wanted to share my experience!

What I Built

Came across the recent Claude Code leak from Anthropic, and what stood out wasn t the leak itself, but what it revealed about how these systems actually work.

• A source map file accidentally exposed ~500k lines of TypeScript

• Turns out Claude Code is basically a multi-step prompt orchestration system, not some mysterious black box

• Includes things like:

  • layered prompt pipelines ( prompt sandwich )

  • fake tools to prevent model distillation

  • simple frustration detection (regex for rage prompts )

• Even hints at future features like background agents and persistent memory systems

What s interesting is this:

It kind of confirms that the real product layer in AI isn t just the model it s everything wrapped around it.

Which raises a few questions:

Are you someone who's built > 10 apps using Lovable, Replit, Mocha, or another vibe coding tool? If so I'm very interested in what is your answer to these 2 questions:

Assume you're the "benevolent dictator" of one of these apps for the day, and can choose to add one thing, and remove one thing:

• What's your most desired feature? Thing holding you back the most?

• What really annoys you and would you change or remove?

Few months ago (like everyone else) I also got overwhelmed with all this vibe-coding happening around me, being a developer myself I got a little FOMO too I have personally built a bunch of tools using "pure" vibe-coding.

It took me a while to understand that one of the biggest challenges of vibe-coding is the back & forth with AI - which can save or burn a huge amount of your time. I got stuck with fixing and recreating code bugs and fighting with the leaks that AI generated for me.

My first product - which was a simple resume parser and enhancer took around 3 months to build for the same reason. It failed badly - because I sucked at marketing.

With the second product that I launched which was a no-code portfolio website builder (Fllaunt AI) took around 2 full weekends only!

Hey everyone

Over the past few weeks I tried something slightly crazy I built an entire AI email client using Lovable and vibe coding.