What is governed vibe coding, and who decides what merges
Governed vibe coding lets people outside engineering build software with AI, while engineering controls where it runs, who reviews it and what merges.
Governed vibe coding is vibe coding inside rules that engineering sets. People outside engineering describe software and an AI builds it. Engineering controls where the code runs, which keys it can reach, who reviews it and what merges. In SHIP, those controls run today on every mission. Each build gets a sandbox, the keys stay outside it, and a pull request waits for a person after review against your own rules. A workspace for non-engineers to describe and change prototypes is in early access.
Separate vibe coding from governed vibe coding
Vibe coding means a person asks an AI for software in plain language and uses what comes back, and often does not read the code. The method works well for a demo. The risk starts when the demo goes to real users with nobody between the prompt and production.
IAPP published an opinion piece on this risk in September 2025, Vibe coding: Don't kill the vibe, govern it. Its answer is "Mandatory human-in-the-loop review." Its author, ShanShan Pa, heads AI and data governance at GlobalLogic. The same piece says to "Treat AI-generated code the same as human-written code."
The term itself reached product announcements in 2026. Databricks used the term in a post about governed vibe coding for enterprise apps on June 16, 2026. The post puts the scale problem this way: "As more people build more apps, governance cannot happen one application at a time."
| What differs | Vibe coding | Governed vibe coding |
|---|---|---|
| Who asks for the software | Anyone with an AI tool | Anyone with access to the team's tracker or workspace |
| Where the code runs while it is built | On the person's machine or the tool's own servers | In an isolated sandbox the team controls |
| Who reads the code | Often nobody | A reviewer that checks it against the team's rules, then a person with merge rights |
| How it reaches users | However the person publishes it | Only through the team's own delivery pipeline |
| What is recorded | Whatever the tool keeps | Every agent session, prompt, token count and cost |
List what a team must govern
Six questions cover what a team must control before a vibe-coded change reaches production. The table gives each question and the SHIP control that answers it today.
| Question | What can go wrong without a control | SHIP control today |
|---|---|---|
| Where does the code run? | An agent runs commands on a laptop or a shared server | Each agent runs in an isolated sandbox |
| Which keys can it see? | A provider or cloud key ends up in the code or the logs | Keys stay outside the sandbox, and a placeholder takes their place |
| Who reviews it? | A change edits the rules that check it | Review and QA rules come from your main branch, and CI changes need your instruction |
| What deploys it? | A prototype goes live on an account nobody manages | Your own pipeline deploys a preview with your own secrets |
| What merges? | A demo becomes production without a decision | A person merges, and checkpoints can hold a mission earlier |
| What does it cost? | One idea runs for hours on paid models | Each mission has a spend limit and a credit pause |
Run every build in a sandbox
Each SHIP agent runs in a sandbox, an isolated container with the toolchain your repository needs (Custom sandboxes). The Builder writes and tests the prototype there, and the sandbox is gone when the stage finishes.
Your provider keys never enter that sandbox. SHIP starts the container with a placeholder and puts the real credential on each outbound call to the provider, outside the container (LLM credentials). So an agent cannot read a key, even if a prompt tricks it. If SHIP does not replace the placeholder, the provider rejects the call.
Keep the review rules on your main branch
A prototype cannot change the rules that check it. SHIP reads each role's instructions from your main branch, never from the branch of the pull request (Agent prompts). A change to the Reviewer's rules applies to the next pull request, after a person merges it.
Two more limits apply to every mission (Connect GitHub). SHIP checks every change before the commit exists and blocks a change under .github/workflows/ that you did not ask for. The QA agent holds a read-only token, so it cannot push.
Deploy through your own pipeline
SHIP never holds a credential for your cloud account, and it does not deploy your application (Deployments). After the Reviewer approves, SHIP asks your delivery pipeline to deploy the pull request to a preview, and your pipeline uses its own secrets. QA then tests the prototype on that preview.
A prototype therefore goes only where your pipeline would put any other change. When the pull request merges or closes, SHIP asks the same workflow to remove the preview.
Decide who merges, and when a mission holds
By default, a SHIP mission runs to the end and waits at a pull request for a person to accept it (Human in the loop). Auto-merge is off unless you turn it on for a project or a mission. For a prototype from outside engineering, that default already puts the decision with engineering: an engineer with merge rights merges it or not.
Checkpoints add earlier gates. A checkpoint on the Planner holds the mission before any code exists, so an engineer can read the approach. A checkpoint on the Reviewer holds it after a clean review, before the preview and QA.
# ship.yml
agents:
planner:
checkpoint: true
reviewer:
checkpoint: trueA person can also pause, resume or stop any mission from the issue, the console or the API. A stopped mission leaves its pull request open.
Cap what a prototype can spend
Each prototype is one mission, and each mission has spend limits by default (LLM credentials). A mission stops at $5. It also pauses at 2 credits, or 6 agent-hours, until a member of your organization approves 1 more credit.
Retry limits stop a mission that makes no progress (Retry limits). When a gate fails the same way twice in a row, the mission stops and asks for a person. A ceiling of 25 Builder attempts sits above that as a backstop.
SHIP also records every agent run (how a mission runs). Before an agent reports back, SHIP stores its full session, the assembled prompt, the token usage and the cost.
Check what runs today and what early access adds
Every control on this page runs today, on any mission. A teammate outside engineering can hand an idea to SHIP now. On Linear, they assign the issue to SHIP. On GitHub Issues, they comment @SHIP, which needs write access to the repository (how teams hand work to SHIP). The prototype comes back as a pull request that passed review and a test on a preview.
A workspace for product, design and operations teams to describe a prototype and change it in conversation is in early access. Read governed prototyping for what it opens, and join the list from there or from the end of this page.
Questions
What is governed vibe coding?
Governed vibe coding is vibe coding inside rules that engineering sets. People outside engineering describe software and an AI builds it, while engineering controls where the code runs, who reviews it and what merges.
What is the difference between vibe coding and governed vibe coding?
In vibe coding, a person asks an AI for software and uses what comes back. In governed vibe coding, the same request goes through a sandbox, a review against the team's rules and a human merge. Only then can the code reach production.
Is governed vibe coding available in SHIP today?
Partly. The controls run today: sandboxed builds, keys kept outside the sandbox and review against rules from your main branch. Previews from your own pipeline, checkpoints and spend limits run today too. A workspace in which non-engineers describe and change prototypes is in early access.
Who approves a vibe-coded prototype?
A person with merge rights on the repository approves it, as with any other pull request. In SHIP a mission waits at the pull request by default, and auto-merge stays off until someone turns it on.
What does a governed prototype cost?
In SHIP a prototype is one mission. A mission stops at $5 by default, and it pauses at 2 credits or 6 agent-hours until a member of your organization approves more.