By Greg Nowak. Updated 28 October 2026.
The demo works, the tests pass, and the agency wants to close the ticket. Before you launch a vibe-coded feature, ask one more question: who will look after it when real customers start using it?
AI coding agents can shorten the journey from idea to working software. The production handoff still needs deliberate attention: agreed behaviour, technical review, deployment instructions, monitoring and recovery. For a business owner or operations lead, the useful deliverable is a feature your team can understand, support and safely change.
Define what the business is accepting
Write a short acceptance note before reviewing the implementation. Explain who will use the feature, what they should accomplish and where its scope ends. Include permissions, error messages, accessibility and any workflow that crosses into another system.
For example, a customer export needs more than a working download button. Which staff may export records? Which fields belong in the file? What happens with a large dataset or an interrupted request? These decisions give the developer something concrete to test and the business something concrete to approve.
Scale the review to the consequences. A copy change needs less evidence than a feature that moves money, exposes customer records or changes stored data.
Use a production handoff checklist with named owners
Keep this checklist in the release ticket or pull request. Add a person's name and an evidence link to each applicable row. Record why a check does not apply.
| Release gate | Evidence to keep | Who should confirm it? |
|---|---|---|
| Business acceptance | Agreed behaviour, exclusions and a completed user journey | Business or client owner |
| Technical review | Human review and tests covering the changed behaviour | Developer familiar with the stack |
| Security and access | Permission checks, secret checks and dependency decisions | Technical reviewer or security owner |
| Data recovery | Migration rehearsal, usable backup and recovery steps | Database or hosting owner |
| Operations | Monitoring links, alert recipient and support instructions | Person supporting the feature |
| Release decision | Deployment steps, stop conditions and recovery authority | Named release owner |
Review the change behind the polished pull request
Ask a developer who understands the application to trace the main user journey and its failure paths. Check authorization on the server, unexpected inputs, duplicate submissions and third-party failures. Tests should demonstrate the intended behaviour, including cases where access must be refused.
GitHub's current Copilot documentation describes agents that edit files and run tests in a cloud environment. It also explicitly says session logs do not replace your own review and testing. Apply that principle whichever coding tool produced the change.
For a quick technical orientation, refresh your remote references, check out the proposed branch and run these commands. Replace origin/main with the actual target branch:
git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git diff --check origin/main...HEADAs the Git documentation explains, the three-dot comparison shows committed branch changes since the common ancestor. It excludes uncommitted edits. These commands reveal scope, file changes and whitespace or conflict-marker problems; they do not prove correctness. Give migrations, deployment workflows, configuration and lockfiles deliberate attention.
Check credentials, dependencies and agent access
Review credentials in code, configuration and any shared agent output. If a secret has leaked, follow the provider's revocation or rotation procedure and update affected services. GitHub's remediation guidance says to treat leaked secrets as compromised: deleting the text or committing a replacement does not invalidate the exposed credential.
Ask why each new dependency is needed, whether its licence fits the project and what installation scripts it runs. Where available, GitHub dependency review highlights dependency changes and known vulnerabilities. Its documentation also warns that unparsed dependencies and some manifest changes may be absent, so inspect the source diff too.
Review the coding agent's access separately from the finished application's permissions. Remove temporary credentials and unnecessary integrations after the task. OWASP's excessive-agency guidance recommends minimal tools and permissions, with human approval for high-impact actions. A repository task should receive only the access it needs.
Rehearse deployment and decide when to stop
Test the deployment path in a representative environment using suitably protected test data. Check environment variables, migrations, queues, scheduled jobs and external integrations. For database changes, confirm whether the previous application version can still run against the new schema.
Write recovery steps that account for side effects. Reverting code cannot unsend an email or reverse an external payment. Document how to disable the feature, stop background work and reconcile affected records. Verify that a backup can be restored before relying on it.
Before release, agree what would trigger intervention: failed transactions, permission errors, queue growth or a broken customer journey. Name the person watching those signals, when they will check them and who can pause the rollout. If a limited rollout is practical, start with a small group and expand after checking behaviour.
Leave the next person a usable handoff
Keep one short release record containing the acceptance note, reviewed commit, test evidence, configuration requirements, monitoring links, known limitations and recovery instructions. Include the support contact and a date to review deferred work. For agency projects, make sure the client controls the necessary accounts and knows who owns ongoing maintenance.
If your AI-generated feature is nearly ready but the handoff is scattered across tickets and chat, Greg can help define acceptance, coordinate technical review and bring the release plan together. Talk to Greg about your production handoff with the current scope and the decisions still outstanding.
Related on GrN.dk
- A Voice Agent Is Only Ready When the Human Handoff Works
- Your AI Workflow Needs an Acceptance Test Before It Meets Customers
- Drupal Deployments: Keep Small Fixes From Rewriting Live Settings
Need help with this kind of work?
Plan your production handoff with Greg Get in touch with Greg.
