We ran a live Vibecoding 101 session this week with Mark Montalban, who teaches our Vibe Code a Product Bootcamp and built MindfulText. Around 300 of you showed up. Mark built apps in real time, took questions, and went deep on the parts most demos skip.
If you missed it, or you just want the signal, here are the tips worth keeping. These are the same ideas we go much deeper on in the bootcamp, but you can start using all of them today.
1. Use AI to learn, not to skip learning
Mark opened with a line he credits to Mark Cuban. There are people who use AI to learn, and people who use it so they never have to. Same tool, opposite outcomes.
The shortcut crowd copies prompts in and copies outputs out without reading either one. It feels fast right up until something breaks and they have no idea what their own app is doing. When a permission popup appeared mid-build that he didn't fully recognize, Mark didn't just click allow. He opened a new chat, pasted a screenshot, and asked the agent to explain what it was requesting and why. That habit is most of the skill.
2. Plan before you prompt
The old Lincoln line applies here. Give me six hours to chop down a tree and I'll spend the first four sharpening the axe.
With AI agents that's a budget, not a poster. Every vague, sprawling prompt burns tokens and sends the agent off in a direction you'll have to undo. The thinking you do before the first real instruction is what keeps the build cheap and pointed one way.
3. Know who else is already building it
Part of that planning is competitor research, and Mark was direct about why it matters. Walk into an investor conversation with no idea who your competition is and you get filed under "doesn't know what they're doing." Better to know the niche players nobody's heard of, and to be able to say where they're headed versus where you're going.
Building something purely internal? You can skip this. Planning to sell it? You can't.
4. Keep your PRD small
This one surprised the room. Make your product requirements doc shorter, not longer.
Ask an agent to write you a PRD and it returns a sprawling document with several goals, multiple personas, a dozen features, and a stack of tooling assumptions you never made. Feed all of that back in and the agent has too many directions to pick from, so it builds everywhere at once. Mark told a story about a founder whose two-page PRD had grown past her own understanding of her product. She didn't recognize some of the features in it.
The version we hand people is tiny on purpose. One clear goal, a short feature list, what device it runs on. A real engineer wants the long version. An AI agent at the start of a project does far better with the short one.
5. Pick the tool that fits the job
Four came up, and none of them is "the best." They're for different situations.
Replit gets you to something live fast and bakes in a security layer, so you're less likely to leave API keys exposed. If you're a complete beginner and you want real people testing this week, start there. Codex and Claude Code build locally on your machine. Cheaper, great for tinkering and personal projects, but more setup: pointing them at a folder, working in the terminal, clicking through permissions. Cursor came up for how cleanly it separates context, so a new project isn't dragging in three half-finished ones.
One small gotcha for the local tools: if you move your project folder, you can lose your chat history, though you can usually ask the agent to recover it.
6. The model you pick is a cost decision
Newer model, better output, more tokens. That's the trade every session.
You'd love to run the latest Opus on everything, but it burns through your usage fast. Free tiers, meanwhile, give weak output for exactly the work where quality matters most, like competitor research. For that kind of task, switch into extended thinking, let it run a few minutes, and accept the cost. Then drop back down for the routine stuff. Don't run your most expensive setup to rename a button.
7. "Scale" means something different for you
When an engineer says scale, they mean millions of users. As a founder right now, you should mean ten. Maybe a hundred.
Vibe coding is good enough to get you there. It's how you build fast, put something in front of real people, and find out if anyone wants it. It is not a replacement for an engineering team. When Mark wants to formally launch and harden something, that's when it goes to a CTO. So don't burn your first weeks over-engineering for a load you don't have.
Security follows the same logic. Getting your first ten B2B users, the risk is low and you likely know each of them by name. B2C is more exposed, so you'd pay more attention to auth. The simpler tools carry more of that weight for you out of the box.
8. Just start
If you've never built anything, the real takeaway is that the rough parts are normal and survivable. The popups, the terminal, the agent wandering off for a minute. Every builder hits all of it. Pick one tool, learn it well enough to be dangerous, ask the agent what it's doing whenever you don't understand, and build something small just to feel the moment you realize you can make a product now.
Want the structured version of all this?
The live session was the loose, experimental cut. Our Vibe Code a Product Bootcamp is the structured one: same ideas, walked step by step, with the integration and launch work the live format couldn't get to.
Signup here: FI.co/bootcamp/vibecoding
