Vibe coding for production apps

When an agent belongs in the production path

Agents help when the change has a visible pass condition and the relevant files are readable. They struggle when policy is missing, when correctness depends on undocumented side effects, or when a mistake would be expensive to reverse.

If you are still defining the product, stay on the MVP path described in the handoff walkthrough. Production gates assume the product already has a living source of truth and a way to verify changes.

Production work starts with a bounded request: one user-visible behavior, one bug class, or one operational risk. Ask the agent for a plan that names the files it expects to touch and the checks it will run. Reject plans that rewrite unrelated modules “while we are here.”

Do not depend on an old chat transcript. Point the agent at the current PRD slice, technical design, AGENTS.md, and any MEMORY or handoff notes for the active phase. If those files disagree, stop and reconcile them before code changes.

Treat every agent patch like a pull request from a fast junior teammate. Read the diff for wrong assumptions, silent API changes, new secrets, and tests that assert the wrong behavior. Prefer small commits that land behind a feature flag when the risk is high.

Run the project’s normal checks, then exercise the feature the way a user would. For web apps that means a browser pass. For APIs that means the documented request and failure paths. Record which commands passed, which failed, and what remains open.

Before closing the session, write what changed, what was deferred, and the next small task. Update agent docs only when a standing rule changed. The next person—or the next agent—should not need the chat history to continue safely.

Cursor, Claude Code, and other agent workflows

Tool choice matters less than whether the tool can read project instructions, propose a plan, edit a bounded set of files, and leave evidence you can inspect. Cursor agent workflows, Claude Code sessions, and similar coding agents all benefit from the same rule: standing decisions live in the repository, temporary chat lives for the current task only.

Put durable rules in AGENTS.md or equivalent agent docs. Include real commands, coding conventions, safety boundaries, and pointers to the PRD and technical design. Keep tool-specific wrappers thin so switching models does not require rewriting product policy. The public agent setup instructions show one way to structure that handoff.

Anti-patterns that look productive

1. Whole-app rewrites: a single prompt that asks to redesign architecture, UI, and tests at once hides risk until review is too late.
2. Chat as source of truth: decisions trapped in a long transcript disappear when the session ends or the model changes.
3. Green tests for the wrong behavior: an agent can invent assertions that pass while the user-facing bug remains.
4. Silent dependency or secret changes: production incidents often start with a “small cleanup” that altered auth, env, or package versions without a human call.

The maintainer definition of vibe coding still applies here: natural language directs the work, but a human owns scope, review, testing, security, and release.

A one-page production checklist

Before you merge an agent-assisted change into a production branch, confirm each item in writing:

• The change brief names one outcome and explicit non-goals.
• The agent cited current project files instead of inventing policy.
• The diff is small enough that a human read every changed path.
• Automated checks and a real interface path both passed.
• Rollback or feature-flag strategy is known before deploy.
• The handoff note states what remains and who should do it next.

Local projects and exports stay free. Compare pricing when you want included AI and cloud sync on the same documents.

If you want the same discipline earlier in a project’s life, start from the public workflow repository and keep the documents next to the code they govern.