Build with AI · Guide for product managers
Vibe coding for product managers — the disciplined way
AI coding agents can turn a product idea into a working app in an afternoon. They can also produce something that looks finished and is insecure, fragile and impossible to change. The difference is not the tool — it is how you direct and review it. This is the workflow we teach product people.
Guide 8 of 10 in the technical PM path
What "vibe coding" means — and why it is not enough
"Vibe coding" usually means describing what you want in plain language and letting an AI write the code, accepting whatever comes back as long as it seems to work. For a throwaway prototype, that is fine and genuinely useful.
For anything real users will touch, "make me an app" skips every decision engineers normally make on purpose: where data lives, who may see it, what happens on failure, how you will change it next month. The agent does not skip those decisions — it makes them silently, and not always well.
As a product manager you are unusually well placed to fix that. Defining the problem, writing acceptance criteria and making trade-offs is already your job. Disciplined AI building is mostly that job, applied to a very fast and very literal engineer.
The loop: plan → define → architect → generate → review → test → secure → deploy
- Plan. What problem, for whom, and what is the smallest version worth shipping? Write it down in a short brief.
- Define. User stories and acceptance criteria. "Users can reset their password; the link expires after one hour; an unknown email shows the same message as a known one."
- Architect. Ask the agent to propose the stack, data model and main components before writing code — and explain the trade-offs. You approve, change or push back.
- Generate. Build in small slices: one feature, one screen, one endpoint at a time. Small slices are reviewable; a 3,000-line change is not.
- Review. Read the plan and the diff. You will not understand every line, and you do not need to. You check that it did what you asked, only what you asked, and nothing alarming.
- Test. Click through the acceptance criteria yourself, including the unhappy paths. Ask the agent to add automated tests for the important rules.
- Secure. Secrets on the server, access rules on the data, input validated. Ask the agent to review its own code for security issues — then verify the obvious ones yourself.
- Deploy. Ship to a real URL, with error tracking and a way to roll back.
Then repeat, feature by feature.
Give the agent context, not just a wish
A strong prompt to a coding agent looks more like a ticket than a wish:
Goal: add a "Share project" button that creates a read-only public link.
Context:
- Stack: React (Vite) frontend, serverless API functions, Firestore.
- Existing sharing code: none. Auth already works (see src/context/AuthContext.jsx).
Requirements:
- Only the project owner can create or revoke a link.
- The public page shows the project name and tasks, never member emails.
- Links can be revoked; a revoked link shows "This link is no longer active".
Constraints:
- Do not add new dependencies without asking.
- Keep secrets server-side; no API keys in frontend code.
Before coding: propose the data model change and the files you will touch, then wait for my OK.
Acceptance: I can create, open (logged out) and revoke a link; a non-owner gets a 403.
Notice what is doing the work: the goal, the existing context, explicit rules about who can do what, constraints, and a request to plan before building. Screenshots, error messages and links to documentation are also excellent context.
How to review AI-generated code when you are not an engineer
You are not looking for elegant code. You are looking for mismatches and danger signs:
- Scope. Did it change files unrelated to the task? Did it quietly rewrite something that worked?
- Secrets. Search the change for words like
key,secret,token,password. Anything that looks like a real value in code is a problem. - Access rules. Where is the check that only the owner can do this? Ask the agent to point to the exact line.
- Errors. What does the user see when the network fails or the input is wrong?
- Dependencies. New packages mean new risk and maintenance. Ask why each is needed.
- Explain it back. Ask: "Explain this change to me like I'm a PM, and list the risks." Vague answers are a signal to slow down.
Using Git helps enormously here: commit working states often, so a bad change is one command away from being undone.
Common ways AI-built apps go wrong
- API keys in the frontend. The app calls OpenAI or a payment API straight from the browser, exposing the key to anyone.
- Missing authorization. The app checks that you are logged in, but not that the record belongs to you — so changing an ID in the URL shows someone else's data.
- Open database rules. A "temporary" rule allowing anyone to read and write everything, which never gets removed.
- Hidden failures. Errors swallowed so the app "works", while data silently fails to save.
- Dependency sprawl. A new library for every small task, some abandoned or vulnerable.
- The rewrite spiral. Each fix breaks something else because nobody, including the agent, has a clear picture of the architecture.
Every one of these is preventable with the loop above, and every one is something a technically literate PM can catch.
Which tools?
Tools change monthly; the workflow does not. Today's options range from chat assistants (Claude, ChatGPT) for planning and explanations, to coding agents that work directly in your repository and terminal (Claude Code, OpenAI Codex, and agents built into editors such as Cursor or VS Code). A reasonable setup for a PM is: a chat assistant for thinking and reviewing, one coding agent in a real Git repository, and a hosting platform with preview deployments. Pick one stack and learn it well rather than switching every week.
What engineers may tell you about AI-built code
- "This works, but it's not production-ready." Usually missing tests, error handling, security rules or monitoring — the unglamorous half of the work.
- "There's no separation between client and server here." Logic or secrets that belong on the server are running in the browser.
- "The agent invented an API that doesn't exist." A hallucination: it guessed a function or option. Always check against the official docs.
- "I can't review a 4,000-line PR." Break the work into smaller, reviewable changes.
Red flags in your own workflow
- You cannot explain what the app stores and who can see it.
- You have never looked at the diff, only the result in the browser.
- The last working version is not saved anywhere (no Git commit).
- "Fix it" has been your only prompt for the last hour.
- You pasted a real password or API key into the chat.
Where to start
Pick a small, real problem you have — an internal tool, a tracker, a calculator your team keeps rebuilding in spreadsheets. Write a one-page brief, set up Git, and build it slice by slice with the loop above. The first project teaches more than any number of tutorials.
TechPMer's 12-week track, Build & Ship With AI, is built around exactly this loop: you pick a pet project in week 3 and take it from idea to a deployed, reviewed and monitored product by week 12, with day-by-day prompts and checklists. Week 1 is free to open without an account.