A product manager just opened a pull request. A designer shipped a working prototype instead of a Figma file. Someone in revenue built a tool over the weekend and wants to know when it goes live. None of them report to engineering, and all of them are now producing code. The instinct to ban it or wave it through both fail in predictable ways. There is a better answer, and it fits in four words.
Every CTO needs a vibe coding policy now, because the question it answers has already arrived in your repository. None of the people producing this code report to engineering, and the instinctive responses, a quiet ban or a shrug, both fail in predictable ways. I have watched CEOs drop AI-generated code into a channel and announce, “Let’s launch this today, I vibed it with Claude Code so I know it’s solid.” At our June 11 CTO roundtable on agentic adoption, the group of 7 CTOs converged on a principle that holds up better than either: bring demos, not code. This article unpacks what that vibe coding policy means in practice and how to turn four words into an actual operating policy.
Everyone Can Produce Code Now
The numbers describe a transition that is already complete. A June 2026 Black Duck survey of 831 software engineers and DevOps professionals found that 97 percent of development teams use AI coding assistants, while only 30 percent operate under a fully governed approach. A quarter of teams have no defined AI coding policy at all. The activity is not confined to engineering either. A Varonis analysis of 1,000 real-world IT environments found that 98 percent of organizations have unsanctioned or unverified apps in use, including shadow AI. The tools are already inside the building, whether or not anyone approved them.
This is not only a CTO’s problem. Every unreviewed tool a non-engineer ships becomes new attack surface, and that lands on the CISO’s desk as squarely as it lands on yours. The same Black Duck survey found nearly two-thirds of teams are already worried their AI assistants are introducing security defects. Who may ship code has quietly become a security question, not just an engineering one.
The boundary that used to separate “people who write code” from “people who request code” was enforced by skill scarcity. AI removed the enforcement mechanism, and no committee voted on it. In some cases, it seems as if CEOs and BOD members voted on it.
So the CTO inherits a question that did not exist three years ago: what happens when a non-engineer shows up with working code? Most leaders I talk with have answered it by default rather than by design. That is the gap a deliberate vibe coding policy needs to close.
Five Ways the Default Vibe Coding Policy Fails
When there is no deliberate vibe coding policy, organizations fall into one of five default patterns. Each one feels reasonable in the moment. Each one fails for the same underlying reason.
The most common policy is a prohibition nobody believes and one that makes things worse. Engineering declares that only engineers commit code, the wiki page goes up, and within a month the CMO’s team is running three AI-built tools that IT has never seen. Prohibition does not stop the behavior. It stops the visibility. The near-universal shadow-AI numbers are what a ban looks like in practice.
The opposite failure accepts every contribution in the name of velocity. It feels generous and modern, and it quietly transfers risk to the people least equipped to see it. Someone who builds something that works has proven the idea, not the implementation. Enthusiasm is not the same as ownership, and velocity that skips the people accountable for what ships is not speed. It is deferred cost wearing a costume.
Some teams split the difference informally. They accept the PM’s pull request to be polite, then an engineer quietly rebuilds it from scratch. This doubles the work, hides the true cost of the contribution, and teaches the contributor nothing about why their code could not ship. The org pays for the same feature twice and calls it collaboration.
Other teams route every non-engineer artifact to one senior engineer who “handles AI stuff.” That engineer becomes a human relay between two halves of the company. Review queues grow, the senior engineer stops doing senior work, and the process collapses the first week they take vacation.
Engineers watch executives celebrate a weekend prototype that ignored every standard the team is held to, and they read the message clearly: the rules are for us, not for outcomes. Meanwhile the non-engineers who built something real feel dismissed when it dies in review. A policy vacuum manages to demoralize both sides at once.
The Common Thread
Each failure comes from treating this as a code question when it is an ownership question. None of the five patterns answers the only thing that matters: who is accountable for what runs in production? A workable vibe coding policy starts there, not at the tooling layer.
What “Bring Demos, Not Code” Means in Practice
The four words carry a precise meaning. Anyone in the company may bring engineering a problem, and anyone may bring a demo that shows the problem and a candidate solution. What they may not bring is a contribution, meaning code that expects to ship as written. A strong vibe coding policy makes that distinction explicit through five commitments.
-
Demos, or even prototypes, are specifications and not contributions.
A working prototype from a PM is the richest spec engineering has ever received. It encodes intent, the edge cases the PM cares about, and a tested interaction model. Treat it as input to the build, never as the build itself. The artifact informs the work; it does not become the work.
-
Engineering owns everything that ships.
No exceptions by seniority or title. If it reaches production, an engineering team owns and operates it, and the CTO answers for it. In practice this is a line the CTO and CISO draw together: security owns the bar that anything reaching production must clear, regardless of who built it or how impressive the demo was. Teams that formalize oversight report major efficiency gains at twice the rate of ungoverned teams.
-
Problems get a real intake path.
A principle without a doorway becomes a ban in disguise. Non-engineers need a defined place to bring demos and prototypes, a named reviewer rotation rather than a single hero, and a committed response time. If the path is slower than going around it, people will go around it.
-
“Production-ready” is written down.
Security review, test coverage, observability, data handling, dependency policy. The bar does not move based on who built the demo. Publishing the bar does two things: it protects the codebase, and it shows contributors that the gap between a demo and a product is real rather than political.
-
Credit flows to the problem-finder.
When the shipped feature traces back to a designer’s demo, the designer’s name stays attached. If contributors lose authorship the moment engineering touches the work, they stop bringing it, and the shadow pipeline reopens. Recognition is the cheapest governance tool you have.
The Underlying Principle of This Vibe Coding Policy
The policy works because it trades a false boundary for a true one. The false boundary said only engineers may create code, which is no longer enforceable. The true boundary says only the accountable team may ship code, which is enforceable forever because it rests on responsibility rather than capability.
A demo from a PM is the best specification engineering has ever received. The mistake is letting it become the implementation.
The Policy Skeleton: Making It Real in Your Org
Writing the principle into operations takes less effort than most governance projects because it follows rails your org already has. The roundtable discussion surfaced a skeleton that adapts to most mid-size and enterprise teams. It starts with classifying every non-engineer artifact into one of three buckets.
Disposable
No reviewDemos and explorations that never touch real data. Let people build freely here. This is where ideas get cheap and fast, and nothing is at stake.
Internal, guard-railed
Light registrationTools running on sandboxed data with a defined blast radius. Someone should know they exist, but they do not need the full gate.
Production-intent
Formal intakeAnything customers or critical workflows touch. This enters the intake path, meets the written production-ready bar, and ships under engineering ownership.
Then set the review economics. The reviewer’s job is not to grade the demo’s code, which will usually be discarded. The job is to extract the specification: what problem, what data, what edge cases, what interaction model. A thirty-minute structured review of a working demo can replace what used to be weeks of requirements meetings. That reframe matters, because reviewers who think they are doing code review on AI output burn out fast, and reviewers who understand they are harvesting specs see the value.
Finally, decide where your line sits. The right boundary differs by company. A fintech moving regulated money draws the production-intent line lower than a media company shipping landing pages. This calibration, where the line goes and what it costs to put it in the wrong place, is a judgment call, and it is exactly the kind of decision where operators who have carried the pager tend to see around corners that a generic framework cannot.
Questions to Sit With
- If a PM opened a pull request tomorrow, does your team have an answer, or just a reaction?
- How many AI-built tools are running in your company right now that engineering has never seen?
- What does your written definition of production-ready say, and could a non-engineer find it?
- Who reviewed the last prototype an executive built, and what happened to their enthusiasm afterward?
- If the answer to a contribution is “not like this,” does your process show the contributor what “like this” would mean?
A Final Thought
The arrival of non-engineer code is not a crisis. It is the first time in software history that the people closest to the problems can show engineering what they mean instead of describing it in a document. A CTO who meets that with a clear vibe coding policy converts a governance headache into the highest-bandwidth requirements channel the org has ever had. A CTO who meets it with a ban or a shrug gets the shadow pipeline, the rework, and the morale bill.
The work is deciding where your line sits before the next pull request forces the decision in public. This connects to the broader discipline of managing AI-era liabilities deliberately. Our guide on AI governance covers the cost side of the same conversation, and the companion piece on the five things every CTO must do in the agentic era sets the wider context for this vibe coding policy.
This was inspired from our June 11 CTO roundtable.
We run new tables regularly. If you’d like to join a peer group for engineer leaders, request a seat or talk to us about coaching for the operators making these calls weekly and much more.
