Vibe-coded features need a production handoff before launch

Illustrated infographic summarizing: 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
A practical production handoff for AI-generated feature branches before client release.

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

Need help with this kind of work?

Plan a production handoff Get in touch with Greg.

Sources

Latest articles

Before buying a GPU, test one real team workflow on existing hardware. A Linux pilot can show whether quality, memory, response times, and running costs add up.

Planning a Drupal relaunch? Set clear rules for content, translations, media and old URLs, with a practical checklist for approving the migration and launch.

Use AI for your online store’s alt text with a manageable pilot: map the images, generate suggestions in Danish, and check the results in WordPress and WooCommerce.

Supplier files need more than extraction. Here’s how to check coverage, match SKUs, resolve unclear units and prices, and test product data before a catalogue import.

Shorter TLS certificates leave less room for renewal problems. Check domain validation, scheduling, deployment and the certificate your customers actually receive.

AI image credentials can disappear during routine website processing. Learn how to test your CMS, optimizer, CDN, and publishing workflow end to end.

AI-based ticket analysis can uncover recurring complaints, product defects and gaps in documentation—without the company needing yet another chatbot.

OpenAI’s X.509 workload identity can replace API keys for the right workloads. This practical framework helps teams decide where to start safely.

WordPress 7.1 helps AI agents discover and invoke site abilities. Here is how to keep exposure, authentication and permission firmly separate.

How to use AI for meeting notes and follow-up while fixed rules protect CRM data, customer matching and the sales pipeline from errors and premature changes.

Review Greg on Google

Greg Nowak Google Reviews

 

Written recommendations from Trafik og Veje, Aarhus Municipality (2011) and AgroTech (2010) — read them on LinkedIn.