Vibe-coded features need a production handoff before launch
By Greg Nowak. Last updated 2026-06-21.
Vibe-coded features have a habit of looking finished before they are ready. An AI coding agent can turn a plain-language request into a branch, a diff, and a pull request quickly. For an agency team with deadlines stacking up, that speed is useful. It also creates a new weak point: the moment a generated pull request starts to feel like production work simply because it looks tidy in GitHub.
The approved sources show why this is now a practical workflow issue. GitHub describes Copilot cloud agent as a system that can research a repository, create an implementation plan, make code changes on a branch, and optionally open a pull request. It can work in a GitHub Actions-powered environment, run tests and linters, and handle bug fixes, incremental features, documentation updates, test coverage, technical debt, and merge conflicts. AI-assisted development has moved well past autocomplete. It now sits inside normal branch and pull request mechanics.
That makes the handoff matter more, not less. GitHub also notes that an autonomous agent can access code and push changes, which brings risk. Its mitigations are a useful checklist: branch limits, restricted credentials, required human review before merge, workflow approval, CodeQL checks, dependency checks against the GitHub Advisory Database, and secret scanning. Those controls are not an argument against AI coding. They are the operating model for treating AI output as draft engineering work.
| Handoff area | Risk to catch | What good sign-off looks like |
|---|---|---|
| Origin and permissions | Agent work on the wrong branch, broad access, unclear ownership | Confirm the branch, requester, co-author, branch protections, and who is allowed to approve the merge |
| Review and CI | Passing syntax with broken behavior, unsafe workflow execution, weak test coverage | Read the diff, require checks, approve workflow runs deliberately, and verify the tests match the change |
| Secrets | API keys, tokens, passwords, private keys, or credentials in code, history, PR text, or examples | Run secret scanning, review alerts, rotate exposed credentials, and add custom patterns where client tokens need them |
| Dependencies | Risky new packages, vulnerable versions, install scripts, or lockfile changes hidden inside the feature | Inspect new packages, maintainers, advisories, install behavior, and whether the existing stack already solves the problem |
| Release notes | A change nobody can explain, monitor, or roll back after launch | Record what changed, how it was tested, what to watch, and what to revert if it misbehaves |
Review the pull request as a handoff
A human review is not a ceremonial click at the end. GitHub’s mitigation model requires draft pull requests created by the cloud agent to be reviewed and merged by a person; the agent cannot approve or merge its own work. That puts accountability back where it belongs. The reviewer is deciding whether generated code becomes production code.
The review should cover the same ground a senior developer would check in a contractor handover: scope, assumptions, side effects, tests, data handling, permissions, and rollback. For agencies, there is one more question: can the team maintain this after launch? AI-generated code can pass checks while still introducing unclear abstractions, hidden coupling, or behavior that is hard to explain to a client.
Give secrets their own gate
Secret handling needs a separate checkpoint because AI coding often touches integrations: analytics, CMS APIs, payment providers, map services, CRM connections, and internal automation. GitHub’s secret scanning documentation describes the core issue directly. Credentials such as API keys and passwords become targets when they are committed as hardcoded secrets.
Secret scanning looks through Git history on all branches for known secret types, including API keys, passwords, tokens, and related credentials. It can also scan non-code surfaces such as issue text, pull request content, discussions, wikis, and secret gists.
The business implication is simple: do not find the leaked token on launch day. A generated patch might place a key in configuration, test data, an example file, or even a pull request comment. Add secret scanning to the handoff, and treat a finding as a credential incident. GitHub’s guidance is to rotate affected credentials immediately. Cleaning Git history may help, but revoking and replacing the credential is the urgent control.
For teams handling many client environments, the next step is custom patterns and validity checks. GitHub notes that scanning can be expanded for non-provider secrets, organization-specific patterns, and active-status checks. That matters when an agency is dealing with client-specific tokens, private connection strings, or older naming conventions that standard scanners may miss.
Dependency changes are part of the feature
AI-generated features often arrive with new packages. Sometimes that is justified. It is never neutral.
OWASP includes supply chain vulnerabilities in its Top 10 for LLM applications, and TechRadar reported an example from the AI tooling ecosystem: a package presented as a remote web interface for Codex attracted more than 29,000 weekly downloads, appeared to work, and later received an npm update that added information-stealing behavior targeting authentication tokens. The lesson is not that every AI-related package is malicious. The lesson is that plausible tooling can become a credential risk after it has already earned trust.
A production handoff should treat dependency review as part of feature review. Check whether the agent added a package to solve a small problem the existing stack already handles. Inspect package names, maintainers, install scripts, lockfile diffs, and advisory results. If the release depends on a new library, the release note should say why. If the library is unnecessary, remove it before the client inherits another moving part.
Prompt injection and excessive agency belong in release review
OWASP’s LLM Top 10 names risks that map directly onto AI-coded work: prompt injection, insecure output handling, sensitive information disclosure, excessive agency, and overreliance. These are not only concerns for products with chatbots. They also apply when a development agent reads issues, comments, repository content, or automation triggers and turns that context into code.
GitHub’s risk documentation acknowledges that hidden messages in issues or comments can be prompt injection, and notes mitigations such as filtering hidden characters before input reaches the agent. It also states that automations can run without a person initiating each task, while administrators can control tools, attribution, trusted events, and workflow approval.
The handoff should keep agency bounded. Let the agent prepare a patch. Do not let it quietly expand scope, bypass approvals, run workflows without review, or turn untrusted issue content into deployed behavior.
Where Greg fits
For a busy agency, the missing role is often not another prompt writer. It is someone to own the production handoff. Greg can review AI-generated patches, check repository permissions, verify that branch protections and required checks still matter, add or tighten CI gates, run secret scanning, inspect dependency changes, and write release notes the team can maintain.
That work is deliberately practical. It separates a promising AI-generated feature from a client-ready release.
The best use of vibe coding is speed with accountability. Let the agent create the branch and propose the implementation. Then slow down where the risk becomes real: credentials, permissions, dependencies, tests, and deployment. That is the handoff that keeps AI-assisted development commercially useful without pretending the generated pull request is the finish line.
Related on GrN.dk
- OpenAI's Guardrails and Run State Make Internal Agent Rollouts a Paid Approval-and-Audit Job
- ChatGPT Visibility Without Open Access Takes More Than robots.txt
- Cloudflare BYOIP customers need a rollback plan, not just trust
Need help with this kind of work?
Plan a production handoff Get in touch with Greg.