The fastest way to lose control of an AI-built project is to begin with a vague request, accept a large unexplained change, and postpone testing until the end. A safer workflow keeps each step observable and reversible.
1. Write the outcome before the prompt
Start with a small brief containing:
- who the feature is for;
- what they should be able to do;
- what must not change;
- privacy, security, accessibility, and platform constraints;
- examples of success;
- commands that prove the result works.
This is not bureaucracy. It gives the agent a target and gives you a way to recognise drift.
2. Ask the agent to inspect first
In an existing project, request a read-only inspection before edits. The agent should identify entry points, conventions, tests, data boundaries, and likely files. Correct a mistaken understanding before it becomes a mistaken implementation.
For a new project, choose boring foundations: a supported runtime, few dependencies, documented deployment, and a test command you can run from the first day.
3. Work in reviewable slices
Ask for one coherent behavior at a time. A good slice can be explained, run, and reverted independently. Examples include a form with local validation, one API endpoint with tests, or one deployment configuration change.
Large “build the whole app” prompts are attractive for prototypes, but they hide assumptions and make failures harder to localise. Preserve checkpoints with version control before each consequential slice.
4. Make the agent show evidence
Require the tool to run relevant checks and report the actual result. Evidence might include:
- unit and integration test output;
- a production build;
- a browser screenshot at mobile and desktop sizes;
- an accessibility scan;
- a reproduced error before and after a fix;
- a dry run of an external action.
Tests written by the same model are useful but not automatically trustworthy. Read the important assertions and add cases based on real failure risks.
5. Review boundaries, not every semicolon
If reading every generated line is unrealistic, prioritise the places where mistakes become expensive:
- authentication and authorization;
- secrets and environment variables;
- database writes and deletion;
- parsing of untrusted input;
- external requests and tool permissions;
- payment, personal, or regulated data;
- logging that might expose sensitive values;
- dependency installation and build scripts.
Ask the agent to trace data from input to storage and output. Then verify that trace against the code.
6. Use preview before side effects
For email, publishing, deployment, ticket updates, file deletion, or financial operations, design a preview or dry-run mode. The independent AutoBS project profile shows a useful example: generate a preview, cache the reviewed output, and post that exact output later rather than silently regenerating it.
7. Release with a rollback path
Before deploying, know how to undo the change. Keep migrations backward-compatible where possible, stage high-risk changes, and monitor errors after release. Record which model or agent materially contributed if that matters to future maintainers.
A paste-ready starting prompt
Inspect this repository and propose the smallest implementation for [outcome].
Users must be able to:
- [observable behavior]
Constraints:
- preserve [existing behavior]
- do not expose or persist [sensitive data]
- follow existing project conventions
Before editing, identify the relevant files, risks, and verification commands.
Implement one reviewable slice, run the checks, and report evidence plus any
remaining uncertainty.
The principle
Vibe coding works best when conversation controls a disciplined feedback loop. Speed comes from delegating mechanical implementation, not from deleting verification.