By Greg Nowak. Updated 27 September 2026.
A vibe-coded feature can look finished remarkably quickly. An AI coding agent may research the repository, propose a plan, change the code, run tests and open a polished pull request. That speed is valuable when an agency has deadlines to meet or an internal team has a stubborn backlog.
But a pull request is evidence that work has been proposed—not that a feature is safe to launch. Production readiness also depends on business intent, security, data handling, monitoring, support and a credible way back. Those responsibilities still need named human owners.
Define “done” before reviewing the code
Start with the outcome rather than the diff. Write down who the feature serves, what should change for them and what must remain unchanged. Include acceptance criteria for permissions, error states, mobile use, accessibility and any client-specific workflow. If nobody can explain the expected behaviour without referring to the implementation, the handoff is not ready.
Use the following matrix as a release gate. The evidence can be brief, but every row needs an owner and a clear answer.
| Gate | Question before launch | Evidence to keep |
|---|---|---|
| Scope | Does the feature solve the agreed problem without unrelated changes? | Acceptance criteria, exclusions and product or client approval |
| Code | Has someone who understands the stack reviewed behaviour and maintainability? | Human approval, relevant test results and resolved comments |
| Security | Were secrets, permissions, dependencies and untrusted inputs checked? | Resolved alerts, dependency review and permission notes |
| Data | Can migrations, imports and destructive operations be tested and reversed? | Backup, migration rehearsal and recovery procedure |
| Operations | Will the team notice failure and know who should respond? | Logs, alerts, owner and support instructions |
| Release | Can this change be deployed gradually or rolled back safely? | Release steps, rollback trigger and post-launch checks |
Treat the pull request as a handover, not a victory lap
GitHub’s cloud agent can work in an ephemeral environment, modify a branch, and run automated tests and linters. GitHub also requires human review before its draft pull requests can be merged. That control is important, but it does not make review ceremonial. GitHub’s own responsible-use guidance says generated code can be inaccurate or insecure and should be carefully reviewed and tested.
The reviewer should trace the important path through the code and the user journey. Check assumptions, authorization, failure handling, side effects and maintainability. Confirm that tests exercise the changed behaviour rather than merely preserving the existing test count. For a client project, ask whether another developer could diagnose the feature six months later.
A quick local orientation can make a large pull request easier to assess. Replace origin/main if the repository uses another base branch:
git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git diff --check origin/main...HEADThese commands expose the size and shape of the change and flag whitespace errors. They do not establish correctness. Review generated files, configuration, migrations, workflow files and lockfiles deliberately; the most consequential change may not be in the feature’s main source file.
Make secrets and dependencies explicit release gates
AI-assisted work frequently touches analytics, payment services, CMS APIs and other integrations. Scan code and pull-request content for credentials, but do not confuse removal with remediation. GitHub advises treating a committed secret as compromised and rotating or revoking it promptly. Rewriting history may be appropriate later, but it does not neutralise a credential that somebody may already have copied.
Review dependency changes separately, including the manifest and lockfile diff. GitHub’s dependency review can identify added or changed packages and known vulnerabilities, while its action can fail a pull request under configured conditions. GitHub also warns that some manifest changes or unsupported dependencies may not appear in the rich review. Automation is therefore a gate, not a substitute for checking why a package was added, what it executes during installation and whether the existing stack already solves the problem.
If the coding agent can use external tools, read untrusted content or act on other systems, review its permissions too. OWASP’s guidance on excessive agency recommends limiting available tools, functionality and permissions, and requiring human approval for high-impact actions. A coding task rarely needs production credentials or unrestricted write access.
Test the release, not only the feature
A green test suite says little about an untested deployment path. Rehearse schema migrations against a realistic copy of the data. Check cache invalidation, queues, scheduled jobs, environment variables and third-party rate limits. Decide what will signal trouble after launch: errors, slow responses, failed transactions, unusual support requests or a business metric moving in the wrong direction.
Keep a short release note with the change: what changed, how it was tested, known limitations, monitoring links, the responsible person and the rollback trigger. “Revert the commit” is not a sufficient rollback plan when a release changes data, sends messages or invokes an external service. In those cases, document the compensating action as well.
Give the handoff one accountable owner
Several specialists may contribute, but one person should decide whether the evidence is complete. For a busy business or agency, that owner may need to translate between the client, developers, hosting provider and operations team—not simply inspect code.
That is where Greg can help: shape acceptance criteria, coordinate technical review, tighten release gates and leave behind a handoff the team can operate. If an AI-generated feature is nearly ready but nobody quite owns the last mile, talk to Greg about the production handoff.
Related on GrN.dk
- A Voice Agent Is Only Ready When the Human Handoff Works
- WordPress 7.1 Exposes AI-Ready Actions. Who Gets to Run Them?
- OpenAI Presence Is Here: Is Your Workflow Ready for an Agent?
Need help with this kind of work?
Plan your production handoff with Greg Get in touch with Greg.
