Vibe coding is often presented as either a revolution or a reckless shortcut. Both descriptions miss the useful management question. Natural-language development can let a process expert demonstrate an unmet need, test an interaction and learn from users before a conventional project would have finished discovery. That is valuable. A working screen, however, proves only that a screen can work under the conditions of the demonstration.
The practical answer is to preserve the speed of exploration while changing the delivery system around the artefact as its consequences grow. The more people, data and business processes depend on it, the more evidence is required.
The opportunity is the shorter feedback loop
The strongest use of AI-assisted development is not simply cheaper code. It is a tighter loop among the person who understands the work, a tangible implementation and the people who will use it.
An operations manager can describe an exception workflow, inspect a generated interface, discover that the original requirement was wrong and correct it in the same session. That learning might previously have passed through documents, handovers and a development queue. Coding agents can make neglected internal tools, small automations and departmental applications economically testable.
This does not remove engineering. It changes where engineering produces value. Less time may be spent typing predictable scaffolding. More attention is needed for boundaries, data models, permissions, integration contracts, tests, deployment and operation. Those responsibilities become more important because generation makes change cheap and plausible-looking output abundant.
Place the work in one of four zones
Use four zones rather than one universal definition of “production ready.”
Zone 1: Sketch
The purpose is to make an idea visible. Data is synthetic, access is limited and the artefact may be discarded. The minimum evidence is that the interaction helps clarify the problem. There is no promise of continuity.
Graduation gate: a named problem owner confirms that real users should test a working prototype and that the proposed data can be handled safely.
Zone 2: Working prototype
A small user group tests a real workflow in a controlled environment. Source is versioned, dependencies are known, test data is governed and the team records known limitations. The prototype may fail without material business interruption.
Graduation gate: the team can explain the architecture, demonstrate user value, identify affected data and integrations, and estimate the work required for support.
Zone 3: Supported product
The application has a product owner, a technical owner, documented access rules, separate development and production environments, repeatable releases, tests for material paths, monitoring, support and a retirement route. Changes are reviewed according to their risk, regardless of whether a human or an agent wrote the code.
Graduation gate: the service can survive the absence of its original creator and its failure can be detected, contained and recovered.
Zone 4: Critical system
Failure could affect safety, legal duties, financial reporting, regulated decisions or a core operation. Independent assurance, stronger segregation of duties, traceability, resilience testing and formal change control may be required. In some components, direct generative implementation may be inappropriate even if AI remains useful for analysis, tests or documentation.
Graduation gate: the accountable risk owners accept the residual risk on evidence, not on the quality of a demonstration.
Make comprehension a release condition
AI-generated code can be syntactically valid while depending on the wrong library, weakening authorization, exposing a secret or handling an edge case incorrectly. GitHub’s responsible-use guidance explicitly instructs users to review and test coding-agent output before merging. Microsoft similarly tells makers to review, validate and test generated Power Apps source. These are not ceremonial warnings. They identify the central control problem.
Before a supported release, the team should be able to explain:
- what the application is allowed to do;
- where data enters, is stored and leaves;
- which identities and permissions it uses;
- which dependencies and generated components it relies on;
- how material behavior is tested;
- how a faulty release is detected and reversed;
- who owns incidents, changes and retirement.
If nobody can explain a material part, the system has not crossed the comprehension gate. More prompting is not the remedy. The team must inspect, simplify, replace or deliberately accept the component through the appropriate risk process.
A worked example: an operations exception app
Imagine a logistics team that tracks delivery exceptions through email and a spreadsheet. A process owner uses an AI coding tool to generate an application that imports exceptions, assigns an owner and drafts a customer update.
In Zone 1, fictional records reveal that the most important field is not the delay reason but the promised recovery time. The sketch has already created value by correcting the process model.
In Zone 2, ten coordinators use the application with controlled data. The team learns that duplicate imports and missing customer consent are real risks. The code is placed under source control, permissions are narrowed and representative acceptance tests are recorded.
Moving to Zone 3 changes the work. The production version receives a proper data model, service identities, audit logging, environment separation, deployment through a governed pipeline, monitoring for failed imports and a support owner. The message draft remains subject to human approval. The prototype is not simply promoted because it worked. Its useful interaction is retained while weak foundations are replaced.
If the application later triggers contractual penalties or dispatch decisions automatically, it approaches Zone 4. Additional assurance is needed because the consequence of an error has changed, even if the interface has not.
Watch for shadow production
The most common failure is not an obviously broken prototype. It is a useful prototype that quietly becomes indispensable. Real customer data appears, more colleagues receive access, an automation runs overnight and the creator becomes the unofficial support desk. There was no explicit production decision, so ownership and controls never caught up.
Other warning signs include credentials embedded in generated code, dependencies nobody has evaluated, tests that cover only the happy path, broad connector permissions and confidence based on a successful preview. Valid syntax is not evidence of correct authorization, recoverability or maintainability.
Maintain a lightweight register of active experiments. Record the owner, users, data class, integrations, current zone, expiration date and next gate. A prototype that reaches its date must graduate, be deliberately extended or be retired.
Keep the controls proportional
Not every sketch needs an enterprise architecture board. A disposable calculator using synthetic data should remain easy to create. Equally, a system making regulated or safety-relevant decisions should not enter production merely because the generated code passed a quick review.
The decision should follow consequence, not fashion. Ask how many people depend on the system, what data it handles, how reversible an error is and what obligations apply. Then match the evidence to that exposure.
Vibe coding is therefore a chance to improve delivery, not an exemption from delivery discipline. Organizations that establish clear zones can let more people test ideas while making fewer accidental production systems. Amplified Pi can help build that path: select the platform, define the gates, strengthen the artefact and create an operating model that preserves speed after the first impressive demo.