We ran a live Vibecoding 101 session this week with Mark Montalban, who teaches our Vibecode 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.
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 through step by step, plus the integration and launch work the live format couldn't get to.
Sign up for the Bootcamp → FI.co/bootcamp/vibecoding
For now, here are the tips that landed hardest in the session:
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 build small
This one surprised the room. The instructions you hand your AI should be shorter, not longer.
Ask an agent to plan your product and it hands back a sprawling document: several goals, multiple types of users, a dozen features, and a pile of technical assumptions you never made. Feed all of that back in and the agent has too many directions to choose from, so it tries to build everywhere at once. Mark told a story about a founder whose simple two-page plan 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 list of features, and what device it runs on. A seasoned 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.
None of this requires you to become an engineer. It requires you to start, stay curious about what your tools are actually doing, and keep your first build small enough to finish. That's the whole game right now. If you want these ideas in order, with someone walking you from idea to working product over ten days, that's exactly what Mark teaches in the Vibecode a Product Bootcamp. Pick a tool, ask a lot of questions, and go make something.
Sign up for the Bootcamp → FI.co/bootcamp/vibecoding
