The Vibe Father
An AI agent can produce a convincing diff long before it produces a shippable change. It may compile. The screen may look right on the happy path. It may even have a green test run. None of that automatically means the work is complete.
A definition of done is the agreement that turns “the agent says it is finished” into evidence you can trust. It starts before implementation, applies to every run, and ends with a clear answer to one question, is this change safe to merge and safe to recover from if we are wrong?
Why a green build is necessary but incomplete
Builds and tests are powerful because they make claims checkable. They are not omniscient. A test suite can miss a permission rule, a migration can behave differently on production-shaped data, and a polished component can quietly alter an existing user flow.
Use several small gates, each designed to catch a different class of mistake. That gives a team more protection than either blind trust in tests or permanent line-by-line inspection. The more risk a change carries, the more evidence it should earn.
The five gates
1. The intended behavior is observable
Write down what a user, API client, or operator can now do. Include at least one failure or edge case when the behavior touches authorization, money, data, or a destructive action.
- Can the account owner update a payment method?
- Does a non-owner receive the correct denial?
- Does a failed provider response preserve the existing method and show a useful message?
This is where a good AI coding task brief pays off, the expected behavior already exists before the first file changes.
2. The automated evidence matches the change
Run the narrowest relevant check first, then the project-level check that would catch integration damage. The exact commands depend on the project, the principle does not.
- Run the targeted unit, feature, or integration test for the behavior.
- Run the build, typecheck, linter, or test suite that protects the affected boundary.
- Record the real output. “Tests should pass” is not a result.
When an agent writes tests, read the test’s assertion before congratulating it. A test that only checks whether a component rendered is not evidence that the payment method actually updated. Our guide to writing tests with AI is useful here, ask the agent to explain the behavior each test would fail on.
3. The diff stayed inside the brief
Review changed files against the task, not just for syntax. Look for unrelated formatting sweeps, silent dependency changes, altered defaults, temporary logging, or a “helpful” refactor that expanded the blast radius. These are common agent failure modes because a model notices nearby patterns and tries to make them consistent.
A simple review question catches a surprising amount if this line disappeared, would the requested outcome still work? If yes, ask why it is in the diff. A small focused change is easier to validate, easier to roll back, and easier for the next engineer to understand.
4. The production shape was considered
Not every change needs a release ceremony. Some do. Before merging anything that touches data, permissions, billing, external services, or a high-traffic path, answer these questions
- Does the change require a migration, backfill, environment value, or third-party configuration?
- What happens with existing records, missing data, retries, and timeouts?
- Can the change be released gradually or hidden behind a flag?
- What observable signal tells us the new path is healthy?
If those questions expose uncertainty, the task is not done yet. Split off an investigation or rollout task. That is good engineering, not hesitation.
5. Recovery is cheap
Every meaningful agent run needs a way back. Keep the diff reviewable, preserve a checkpoint before risky work, and know whether a rollback is a code revert, a feature toggle, a reversible migration, or an operator step. The best recovery plan is usually boring enough to write down in one line.
For parallel or exploratory work, isolate changes in a branch or worktree so an abandoned run does not contaminate a healthy one. Our checkpoints and worktrees guide shows how that turns a bad run into a short reset instead of an afternoon of archaeology.
A practical completion note
Ask the agent to finish every task with a short completion note. It makes the next review faster and exposes missing evidence immediately.
Outcome delivered
- <what changed for the user or system>
Changed
- <files or areas touched, with one-line reason>
Validation
- <command> — <actual result>
- <manual or API check> — <actual result>
Risk and recovery
- <known edge case, rollout dependency, or rollback step>
Open questions
- <anything that still needs an owner decision>If the agent cannot fill in one of these sections, treat it as a signal to investigate—not as an invitation to fill the blank with confidence.
Do not let the builder grade its own homework
For low-risk chores, one agent and a human review may be enough. For bigger changes, use a separate perspective. The reviewer can be another agent, a CI check, a staging environment, or a person who did not make the implementation choices. The key is independence, the same reasoning that introduced a mistake is a poor mechanism for detecting it.
That is why verification-first workflows outperform prompt-only workflows. A more capable model can reduce mistakes, it cannot make its own self-report into evidence. The model proposes. The repository, tests, environment, and reviewer decide.
Scale the gate to the risk
| Change | Minimum evidence | Add before release |
|---|---|---|
| Copy or isolated styling | Focused visual check | Build if the asset pipeline changed |
| Normal product behavior | Targeted test, build, diff review | Manual happy and failure path |
| Data, permissions, billing, integrations | Targeted and integration tests, diff review | Rollout plan, production-shape check, rollback path |
| Destructive or irreversible work | Dry run and independent review | Explicit approval and a tested recovery plan |
That gate directs attention toward the changes where a wrong answer costs the most.
Make done a property of the workflow
You should not have to remember every gate from scratch. Put stable commands and release rules in the repository. Use small task briefs. Keep checkpoints. Make the validation note part of the handoff. When a workflow consistently runs the right checks, speed stops being the enemy of quality.
TheVibeFather’s Safe workflow is built around the same idea, isolate risky work, keep restore points, and verify changes with the project’s actual build and tests. The durable lesson is bigger than any one tool “done” is not a feeling an agent has. It is evidence your workflow collects.
