At OpenAI, product managers have stopped making mockups. Katia Gil Guzman, of the Developer Experience team, describes it in an episode recorded in September 2026: "all the product managers code with Codex. And instead of making prototypes and Figma mock-ups, they implement it directly in the product." She describes receiving a pull request from a product manager who has never been a software engineer in their life, and comments: "it's perfect, actually. Sometimes there are a few comments, but otherwise I don't need to do anything."
She also gives the reason, and it is the sentence that matters: "why did we do all that? Because building was expensive. So we wanted to be sure we weren't getting it wrong." The mockup was not a methodological step, it was insurance against the price of code. Insurance stops being worth it when the claim costs nothing.
You could wave the example away - OpenAI tests its own models with no token ceiling, and she concedes as much when her host points it out. Except the same movement shows up in a company that is nothing like an AI lab.
4,000 makers and 500 applications in production, at a railway operator
Deutsche Bahn gives every employee a Power Platform licence. The result, described in a case study published by Microsoft: a community of 4,000 citizen developers and more than 500 applications in production. Two examples carry figures. A shift-log app for the teams who clean passenger trains cuts handwriting-related errors from 20% to 2% and saves shift managers around 70 minutes per shift - which, at three shifts a day, is 24 hours a week. A track maintenance app has recorded 8,440 targets at three minutes saved each: "that's 56 days we've given back to the team," says the person who built it.
Let us name the conflict of interest straight away: the case study is published by Microsoft, which sells Power Platform. The figures come from Deutsche Bahn's own teams, but the page is a sales document and reads like one. What interests us is not the reported performance anyway, it is the governance described around it - and that part is laid out with unusual precision.
What it costs when nobody is looking
Before the governance, the risk. OWASP has published a typology of risks specific to development by non-technical makers, and its sheet on data leakage is instructive because two of its five scenarios explicitly involve an AI assistant.
In one, a product manager asks an assistant for a script that summarises support tickets; they paste raw logs containing customer account IDs into the prompt, and the resulting code posts the summaries to an internal channel open to more than two hundred people. In another, a maker has a webhook listener written: the assistant, "a functional but unthinking tool", logs all incoming data without sanitising it, and a partner's client secret ends up readable in the logs.
The sheet also flags a risk that is operational rather than security-related: when non-technical users connect systems to each other, they create undocumented dependencies, rarely mapped, where a small upstream change cascades. It is the kind of outage nobody sees coming because nobody holds the map.
On top of that comes the risk in the code itself, and it is now measured. A study by Singapore Management University and Huazhong University analysed 302,600 commits attributed to five coding assistants across 6,299 GitHub repositories, running static analysis before and after each change. The result: 484,366 distinct issues, 89.3% of them code smells; more than 15% of commits from every one of the five assistants introduce at least one issue; and above all 22.7% of the issues introduced are still there at the repository's latest revision.
That last number is the only one that really counts. It does not say agents write bad code, it says what they introduce does not clear itself up. Read it with the limit the authors state themselves: the study only keeps commits whose origin is explicitly recorded in Git metadata, and measures debt through static analysis - not architectural debt, not documentation debt, not test adequacy.
It is the same shift we described around Luc Bonnin's 2.3 billion tokens: the work does not disappear, it moves downstream. The difference here is that downstream belongs to someone who did not write the code and does not know they have inherited it.
The arrangement that holds: two levels, three environments, one approver
Back to Deutsche Bahn, because the governance described is concrete and answers the risks above point by point.
- A two-level centre of excellence. A central one defines the guidelines and standardises common components; local ones carry implementation at subsidiary level, including the subsidiary CIO. The person running it puts it plainly: "I don't have to review every question from every citizen developer, only the ones that can't be solved by the local experts." The governance holds because it delegates.
- Three environments, and a gate between them. Makers experiment in development-test, move to staging for evaluation, and only then deploy. What gets evaluated is spelled out: business criticality and value, risk management, data protection, security.
- A named approver. Local expert teams coach the makers, evaluate the apps and approve them when they are ready. Nobody ships to production alone.
- Training, at volume. More than 2,000 sessions opened in one year were fully booked within seven hours, and the community counts 11,000 people around workshops and showcases.
This model does not remove the OWASP risks: it gives them a place where somebody is looking. That is the difference between "business teams produce software" and "business teams produce software that reaches production". The two sentences describe very different levels of commitment.
What governance does not fix: the tool amplifies what is already there
One thing no approval process catches, and it is what the last document in this batch adds. Prasanth Padharthi, CTO of HONO AI, spent two years taking a 40-plus engineering organisation through vibe coding. His conclusion fits in a sentence: the tool does not change who an engineer is, it amplifies whatever they already brought.
His example is vivid. Two engineers, same brief: a CSV uploader, with template download, validation, successes and failures on the same screen. The first ships exactly that, cleanly, passing review on the first pass. The second ships the same, then keeps going: background processing so the user doesn't wait, a detailed audit log naming who uploaded what and when, each row marked success or failed with a reason, and resume from the failed row instead of restarting. Same tools, same time budget. "Neither output was wrong," he writes: the first built what was asked for, the second built what the user would eventually have asked for.
He also names the hidden cost, and it is not the token bill: it is "the engineer who spent ten hours patching symptoms because the actual problem was one architectural question they never paused to write down". His example - a full day of fixes on client-side PDF rendering, when the answer was a five-minute move to server-side rendering - is recognisable from outside and never from inside, because "the model never tells you to stop".
Hence his protocol, which fits on one line and is worth stealing: when a session runs longer than ninety minutes without a clear path forward, close the editor, write the actual problem statement in plain English, and only then open a new session. One honesty caveat: he is describing his own organisation, with no external measurement - read it as field experience, not as a study.
Three questions before opening the gates
Put end to end, these four sources give a fairly clear position. Opening software production to business teams works - it is demonstrated at a railway operator as much as at an AI lab. But what decides the outcome is not the tool, it is three answers:
- Who approves, and against which written criteria? At Deutsche Bahn the criteria are enumerated and the approver is an identified local team. Without that, shipping to production is an individual act with no counterpart.
- Where does the debt go, and who sees it? 22.7% of introduced issues survive. If nothing ties an application to an owner and a history, that debt simply has no owner.
- What stops sensitive data from leaving? OWASP's prevention list is boring and effective: limit connectors to an approved list, restrict who can create custom ones, monitor flows leaving the organisational boundary, involve security teams in reviews of apps touching sensitive data.
This is the ground Survol works on, and it is better said plainly than left to be guessed. A version carries its origin - agent, human or mixed - because the unit of truth is the version, not the author; organisation-wide technical constraints are injected at the start of every session rather than pasted by hand into each prompt; and a promotion to production goes through declared checks. It replaces neither a centre of excellence nor a security team: it gives their decisions somewhere to be recorded.
We have already told the story of 280 pull requests from non-developers at Alan. The difference with the above fits on one line, and it is a big one: at Alan, non-developers went into the engineers' repository, with their tooling, their CI and their review. At Deutsche Bahn, 4,000 people build alongside the information system, on a platform that does not carry those guardrails by default. Same movement, very different risk - and it is the second one that needs a framework invented for it.
Sources
- Katia Gil Guzman (OpenAI, Developer Experience), "Pourquoi les product managers d'OpenAI ont arrĂȘtĂ© les maquettes", Just a Click podcast, episode recorded in September 2026. The quotations on mockups and the cost of building come from it; translations are ours.
- Microsoft Learn, "Deutsche Bahn empowers citizen developers with Power Platform". A case study published by the platform's vendor: the figures cited (4,000 makers, 500 apps, 20% â 2% errors, 8,440 targets, 56 days) and the governance model come from it.
- OWASP, "CD-SEC-04: Sensitive Data Leakage and Handling Failures", Citizen Development Top 10 Security Risks. The risk scenarios and the prevention list come from it.
- Yue Liu, Ratnadira Widyasari, Yanjie Zhao, Ivana Clairine Irsan, Junkai Chen, David Lo, "Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild", Singapore Management University and Huazhong University of Science and Technology. 302,600 verified commits, 6,299 repositories, five coding assistants.
- Prasanth Padharthi, "The bimodal developer - vibe coding and the team you didn't know you had", June 2026. Field notes from the CTO of HONO AI on a 40-plus engineering organisation.
