How to build products with AI coding tools

1 The bottom line

Build with AI in a loop: plan before any code, prototype several versions cheaply, then review with other models and real users before you ship. Clarity, not typing, is the bottleneck, and unreviewed AI code can pass tests yet be brittle.

2 Key takeaways

• Plan before the agent writes any code. AI already types faster than you can think, so clarity is the bottleneck.
  • Lazar Jovanovic, Lovable13:18 spends 80% of his time planning and chatting and only 20% executing the plan.
  • Boris Cherny, Claude Code1:09:58 starts about 80% of his tasks in plan mode.
• Prototype several versions cheaply and keep only the winner. Comparing options sharpens your idea before you commit.
  • Lazar Jovanovic, Lovable22:25 says this saves hundreds of credits and days compared with fixing a weak first build.
• Put your context in files the agent reads every time. What the model sees before it acts sets the quality of its work.
  • Lazar Jovanovic, Lovable43:10 estimates an unguided agent spends about 80% of its tokens reading a project with 60 to 70 edge functions.
• Review with other models, and keep humans on architecture and security. Passing tests does not mean the code is safe to ship.
  • Evan Spiegel, Snap46:30 says automated code review has caught close to 10,000 bugs.
  • Tony Fadell, Build Collective52:00 says engineers who saw the leaked Claude source found the main loop brittle and unreadable, though the company said 90 to 100% of its code was AI-written.
• Turn every mistake into a rule the agent follows. A fix that lives in a file does not depend on your memory.
  • Lazar Jovanovic, Lovable1:12:35 gets a great answer 99% of the time when he asks how he should have prompted, and rarely hits the same problem again.
  • Zevi Arnovitz, StudyMate46:20 calls updating documentation and tooling one of the biggest productivity hacks.

The ceiling on the AI isn't the model intelligence. It's what the model sees before it acts.

Lazar Jovanovic, Lovable

2.1 Set up your workspace

Same models, different control: pick your layer

	Bolt / Lovable / v0	Cursor / Claude Code
Models	Same underlying models	Same models, latest abilities
Sign-in, database choices	Decided for you	You decide
Tool access	Behind added layers	Full access
Fits when	Starting out	You outgrow wrappers (e.g. payments)
Your files	Carry across	Carry across

Give the agent a tool that fits your skill, a small place to work and standing instructions.

• Pick a tool that matches how much control you want, and move up as you outgrow it. Zevi Arnovitz, StudyMate32:12
  • Bolt, Lovable, Replit, Base44 and v0 use the same models but add layers that decide things for you, like sign-in and database choices.
  • Cursor or Claude Code gives full tool access and the latest model abilities. You make those decisions yourself.
  • Zevi Arnovitz, StudyMate13:10 moved off Bolt when connecting payments became too much, then went to Cursor and Claude Code. The same files carry across tools.
• Give non-engineers a small, LLM-friendly playground codebase. Max Schoening, Notion3:55
  • Use tools LLMs are good at, so people can one-shot things and just chat. It avoids the complexity of a decade-old main codebase.
  • Andrew Ambrosino, OpenAI20:25 calls this a baby version: a dramatically simplified codebase that approximates the production app's interactions.
  • Notion designers and PMs moved chat interface prototyping from Figma static images into the playground. Later they began contributing to the production codebase.
  • Several companies now run a baby Cursor or baby Codex for design exploration (Ambrosino).
• Put standing instructions in a file the agent loads in every conversation. Zevi Arnovitz, StudyMate25:40
  • In Claude.md, describe your workflow and how the agent should behave. For example, tell it to challenge your thinking instead of pleasing you.
  • Tell the AI your style, the problem and the context. Otherwise it gives the top generic result from the internet, like a junior told only to write a strategy deck Zevi Arnovitz, StudyMate57:13.
  • Plain ChatGPT once agreed a framework was the same as another, then later said it thought he was making it up.

2.2 Plan before the agent writes code

Spend your effort on clarity first, then hand the agent a written plan.

• Start tasks in plan mode. Boris Cherny, Claude Code1:09:58
  • Plan mode adds one sentence to the prompt telling the model not to write code yet. In the terminal, press shift tab twice.
  • Go back and forth until the plan is good, then let the model execute with edits auto-accepted.
  • With a good plan, Opus 4.6 usually one-shots it.
  • The problem to solve is clarity, not coding. Most people optimize for the wrong kind of speed Lazar Jovanovic, Lovable13:18.
• Force an exploration phase before any plan. Zevi Arnovitz, StudyMate9:30
  • Have the AI read the codebase and ask clarifying questions about scope, data model, UX and grading. Only then write the plan.
  • When something is unclear, run a /learning-opportunity command. Tell Claude you are a technical PM in the making and ask for an 80/20 explanation Zevi Arnovitz, StudyMate28:36.
  • Bolt and Lovable start writing code immediately. That works early but caused gnarly bugs on payments and database changes.
• Write the plan as files with task status. Zevi Arnovitz, StudyMate30:40
  • A create-plan command outputs markdown with a TLDR, critical decisions and concise tasks. Each task has a status the agent updates.
  • After picking a winning prototype, have an LLM write a master plan, an implementation plan, design guidelines and a user journey doc. Then write tasks.md with tasks and subtasks Lazar Jovanovic, Lovable33:10.
  • In the project rules, tell the agent to read all docs, check the next task, do it, and report how to test it.
  • Then the prompt is just "proceed with the next task". Lazar runs five projects at once this way without losing context.
  • The plan stays in the repo, so later agents can see what was already done in that area (Arnovitz).
• Decide the big choices one at a time instead of one-shotting the app. Andrew Maguire, Volo Ventures11:28
  • Split creation into onboarding, major features, brand and design. Have the tool force trade-offs and offer recommendations.
  • Be specific. Humans are vague, like asking a genie to "make me taller" and getting 13 feet Lazar Jovanovic, Lovable16:00.
  • This also makes the app modular and easier to maintain. Portfolio company X1 is built this way.

2.3 Prototype wide and throw most of it away

Use cheap builds to get signal and design options, not to polish one idea.

• Start every project with four or five prototypes in parallel. Lazar Jovanovic, Lovable22:25
  • Try a voice brain dump, a typed and thought-through prompt, a prompt with a reference screenshot from Mobbin or Dribbble, and a prompt with a snippet from a library like 21st.dev.
  • Compare the results and keep the clear winner.
  • For pixel-perfect design, attach code snippets. An exact snippet is read better than English Lazar Jovanovic, Lovable24:05.
• If your team is non-technical, scope the screens in Figma first. Evan Yadegari, Locked5:22
  • Finalize onboarding and main screens in Figma, then feed them into Claude to build a prototype.
  • After that, iterate: plug in keys, fix bugs and improve UX and UI.
  • A non-technical team shipped Locked this way.
• Aim the first build at signal, not at a product. Mark Pincus, Zynga37:00
  • Build it wrong before you know it is right. Spend a day or a week on a throwaway version.
  • Use vibe coding as a failure machine that tests more ideas in a week than your industry tests in a year.
  • Pincus says reaching a viable product in 3 months instead of 3 years is a dangerous drug when it feeds hope.
• Have designers and PMs prototype in code to master the material. Max Schoening, Notion9:05
  • The goal is not shipping. Coding makes them interrogate how things like an agent loop actually work.
  • At GitHub, around 10% of the top contributors to the product were designers, even before LLMs.

2.4 Build in small steps with the right tool

Turn repeated steps into commands, guide the agent to the right files and match each model to a job.

• Save each phase as a reusable command. Zevi Arnovitz, StudyMate19:40
  • Make commands for create issue, explore, create plan, execute plan, review, peer review and update docs. Whenever you repeat something, make it a command.
  • When an idea hits mid-build, a /create-issue command asks a few brief questions and files it in Linear via MCP. Dictate it by voice Zevi Arnovitz, StudyMate15:35.
  • He built StudyMate fill-in-the-blank questions live with this chain, and the build step took only minutes.
  • In the demo, a spoken description became Linear ticket STU88 with TLDR, current state and expected outcomes.
• Point the agent at the exact file instead of letting it search. Lazar Jovanovic, Lovable43:10
  • Use reference docs and file references so the context window goes to fixing the problem, not exploring.
• Assign each model the job it is best at. Zevi Arnovitz, StudyMate42:59
  • Use Claude for planning and collaboration, Codex for the hardest bugs, Gemini 3 for UI and design, and Cursor's Composer for fast simple builds.
  • Pairing models offsets each one's weaknesses, such as Gemini's messy process.
  • From one plan file, he uses Composer for simple fast work and Gemini 3 for UI Zevi Arnovitz, StudyMate30:40.
• When you get stuck, follow a fixed debugging order. Lazar Jovanovic, Lovable1:06:10
  • First, click the tool's try-to-fix button. Second, ask the agent to add console logs, rerun, and paste the output back.
  • Third, export to GitHub and have an external tool like Codex diagnose it without editing. Fourth, revert, rethink your prompt, take a break and retry.
  • Stay neutral and add context. An angry user makes a thinking model plan how to calm you down first Lazar Jovanovic, Lovable40:40.
  • Pasting the console log history into chat is enough 99% of the time.
  • He guesses an apology can take about 30% of tokens.

2.5 Review before anything reaches customers

Use several layers of review, and keep a high bar so you discard what fails.

• Have different models review each other's code. Zevi Arnovitz, StudyMate40:02
  • After Claude reviews its own code, run the branch through Codex and Cursor's Composer.
  • Then run /peer-review. It tells Claude it is the dev lead, that other leads found these issues, and that it must explain why each is wrong or fix it. Repeat until no issues remain.
  • He runs this on every feature as a non-technical builder. Claude sometimes replies that an issue was raised a third time and is by design.
  • End with a deslop command to clean leftover slop, and always own what you present Zevi Arnovitz, StudyMate57:13.
• Use agents for prototypes, then lock the real architecture with experts. Tony Fadell, Build Collective52:00
  • Run many prototypes to build an informed gut. Then point the agent only at limited sub-segments.
  • Keep humans in the loop for architecture, optimization and security.
  • Prototypes are like 3D-printed enclosures with visible layer lines. Engineering is optimizing the factory to serve 100 million people Max Schoening, Notion15:05.
• Add automated guardrails so people can ship safely at scale. Evan Spiegel, Snap46:30
  • Snap built automated code review and a shake-to-report system where agents debug what went wrong and suggest a fix.
  • Designers at Snap ship code with AI, but it is not required. The goal is not breaking things at nearly a billion users.
• Test with real customers, because AI review cannot replace them. Claire Vo, ChatPRD14:01
  • Expect to write a lot of code and trash it. Keep a high bar so customers never receive trash products.
  • Adversarial AI reviews cannot turn an untested assumption into fact. You still need real customers, real data and repeated tests.

2.6 Learn from every build

Feed each failure back into your files, and clean up what the agent leaves behind.

• Run a postmortem after every AI mistake. Zevi Arnovitz, StudyMate46:20
  • Ask what in its system prompt or tooling caused the mistake. Then update the docs, commands or tooling so it cannot recur.
  • Early on he kept hitting the wall until it worked and moved on, which wasted the lesson.
  • He says this separates people who are okay with AI from those who know how to use it.
• After a fix, ask the agent how you should have prompted. Lazar Jovanovic, Lovable1:12:35
  • Switch to chat mode and ask what you could have said to get it fixed in one go.
  • Have it save the lesson to rules.md, which it reads every time.
• Read what the agent tells you, not the syntax. Lazar Jovanovic, Lovable14:13
  • Treat the agent as a technical co-founder and educator. Its explanations show what is feasible and build your judgment.
  • He once spent a week brute-forcing an image generation app before OpenAI released an API. A week later he built it in 30 seconds.
• Plan cleanup, because AI keeps adding complexity. Andrew Ambrosino, OpenAI40:50
  • Models usually increase code complexity. Andrew explores overnight garbage collection of the codebase.
  • He is not yet at a loop that listens to Twitter, Slack and email and improves the app unsupervised.

2.7 Where they disagree

Sources split on how technical non-engineers should get, how much to plan, and how much setup to build.

• Push non-engineers to the terminal, or ease them in?
  • Max Schoening, Notion39:55 pushes PMs and designers to use Claude Code or Codex in the terminal instead of GUI wrappers. Once in, they get curious and learn how computers work.
  • Zevi Arnovitz, StudyMate13:10 treats code as exposure therapy. Move gradually from chatbot to Bolt or Lovable to Cursor in light mode, and only later to the terminal.
• Should everyone become an engineer, or should specialists stay?
  • Casey Winters, SuperMe33:50 onboards every hire like an engineer. SuperMe has eight people, one ops growth person, one designer and the rest engineers, with no sales or marketing team.
  • Max Schoening, Notion15:05 warns against letting role-merging remove engineers and designers. He regrets loosening the requirement that designers code, and would rather have fewer, more polymath designers.
• Build it wrong first, or plan heavily?
  • Mark Pincus, Zynga37:00 says to build it completely wrong before you know it is the right product.
  • Lazar Jovanovic, Lovable13:18 puts most of his time into planning. The two fit different stages: throwaway builds to find the idea, careful plans to build the one you keep.
• Ship tiny projects weekly, or build only what you use daily?
  • Anish Acharya, a16z1:08:50 says to ship something once a week. It need not be important, like a Mother's Day slide deck built with Codex.
  • Cat Wu, Anthropic1:13:52 says prototypes you never return to teach little, so build tools you use daily. She also finds that simple setups work better than piles of skills and MCPs.