A working demo changes a conversation. People who struggle to describe a workflow can point to a screen, try an action and say what is wrong with it. Giving domain experts that ability is a useful change in software development.
The harder conversation begins when someone says, “Can we just use this?”
The prototype has crossed a boundary. A disposable way to test an idea is becoming a service. Someone may put real customer data into it, rely on its calculations or connect it to a system that can make a lasting change. The fact that its creator can ask an AI to fix the next error does not answer who will maintain it, or recover when it fails.
I would encourage this kind of experimentation deliberately. I would also make the transition into operational use a decision that someone owns. That is the line an enterprise policy needs to draw.
Decide what “working” means
Here I use “vibe coding” for building by accepting generated changes and judging the visible result without understanding the code underneath. When someone reviews the code, tests it and takes responsibility for its behavior, I would treat the work as software engineering assisted by AI. The tools can overlap; the responsibility differs.
A prototype works if it helps answer an exploratory question. Can users understand the proposed workflow? Is the missing step important? Does the idea merit more work? It can answer those questions with synthetic data and a limited audience.
A service has to do more. It must keep access appropriate, handle errors, preserve data and remain changeable by somebody other than its creator. A screen that looks right offers little evidence about those properties.
Internal use does not automatically make a service low risk. A small tool used to prepare payroll, approve supplier changes or share confidential documents can have a consequential failure. Classify the proposed use by what it can affect, rather than by the number of people with its link.
A prototype worth building
Consider a hypothetical maintenance supervisor testing an equipment handover tool. The present process uses notes, photographs and a spreadsheet. The supervisor wants to see whether a single screen makes open issues easier to discuss at a shift change.
For the experiment, use made-up equipment records and photographs cleared for that purpose. Keep it separate from production controls. The supervisor can change labels and ordering quickly, and technicians can explain what would make the screen useful. They are testing a workflow, not validating an autonomous maintenance decision.
Suppose they find that it makes missing information obvious. The next step is not to connect it directly to the asset system. It is to describe the useful behavior, the data it needs and the obligations that operational use would create.
Who can read an issue? Who can mark it resolved? What happens if the wrong asset is selected? Can the team export the records? Will a shift receive a warning if a write fails? Those questions turn a promising interface into a service specification. The prototype has earned further work without being mistaken for the finished system.
Make the boundary real
A policy saying “prototype only” is ineffective if the prototype can already access live credentials or publish sensitive data. The environment needs to support the intended boundary.
Give experimenters approved tools, safe example data and a place to test without production permissions. Explain when they need a review: connecting real data, opening access beyond the test group, accepting payments, sending messages or changing operational records are common triggers.
The review should identify the actual consequence. For the handover tool, authorization and reliable writes matter. For an anonymous survey mock-up, the priorities may be different. A proportionate process is easier to use than a blanket demand for every control on every experiment.
Place important permissions outside the model's discretion. Asking it never to expose a record is not equivalent to enforcing which records the account can access. Asking it to preserve a database is not a recovery plan. Test the controls and the recovery path, including what a user sees when something fails.
Pay for understanding before dependence grows
Someone needs to know what was built. That includes the code, dependencies, data model, deployment and access rules. The requirement is not that every line be typed by hand. It is that an accountable person can inspect the relevant behavior and explain why it is acceptable for the intended use.
Sometimes the prototype is a useful specification and the implementation should be replaced. Sometimes a review and cleanup are enough. Sometimes the right decision is to keep it as a private experiment. Throwing away exploratory code is not evidence that the experiment failed; it may be the cheapest route to a maintainable service.
Name the continuing owner before users depend on it. Give them the documentation and time needed to change it. If the creator leaves, the tool should not become an orphan that everyone is afraid to touch.
This is also where an attractive demo can reveal a poor business case. The full cost includes reviewing the generated code, securing it, integrating it, supporting users and maintaining it. A fast first screen is a small part of that total.
Speed needs a complete comparison
Claims about developer speed deserve the same care. METR's randomized study found that sixteen experienced open-source contributors took longer with early-2025 AI tools on work in familiar repositories, despite feeling faster. It is a dated result in one setting, not a verdict on today's tools or on a supervisor exploring an unfamiliar idea.
The lesson for a team is to measure its own complete work. For exploration, ask whether the prototype helped reach a useful decision sooner. For production, count review, testing, correction and maintenance as well as initial generation. These are different questions with different baselines.
An experienced engineer can use AI extensively and still retain responsibility for the system. A nontechnical domain expert can create a valuable prototype without becoming the engineer who supports it. A good process makes room for both contributions and names the handoff between them.
The supervisor's best result may be a tool the engineering team can maintain. It may also be a simpler change to the existing spreadsheet. Either can justify the experiment.
When the demo ends, ask who will answer the next user's problem. If the only answer is “we will ask the model,” the service still has an ownership gap.