Retool Says It Surveyed 307 Technology Leaders About Vibe Coding. Here's the Governance Response

In June 2026 Retool published survey results that every IT leader should read, and read carefully. The headline finding: 93% of the 307 CTOs, CIOs, and CISOs surveyed are concerned about AI-generated internal tools running in production. Only 8% rate their governance as strong. Retool's newsroom release says 59% could not confirm whether they'd had an AI-caused incident.

Those numbers matter. But the survey has gaps you need to understand before you build policy on it. The methodology disclosure is limited: no fieldwork dates, no geography, no sampling or recruitment detail, no quotas, no weighting, no response rate, no margin of error. Retool describes the respondents as medium-to-enterprise companies and says the research was conducted by Wynter. The survey's incident-rate figures disagree with each other: the blog prose says 19% of respondents experienced a production incident caused by an AI-generated tool, while Retool's newsroom release and BusinessWire distribution both say 22%. The newsroom and BusinessWire use 19% for a different metric: the share of respondents who could confidently say they had not had an incident because monitoring was in place.

In our view, the survey is a directional signal rather than a forensic dataset. Treat it accordingly.

What the survey tells us

Here are the numbers that appear in Retool's blog report, labelled by where they sit in the source material:

Repeated in both blog and newsroom: 93% are concerned about vibe-coded tools running in production. 38% call it a top operational risk. 8% describe their governance as strong. Governance breakdown: 40% mostly functional but manual, 37% uneven, 10% reactive. 5% are very confident they have full visibility.

Appearing in the blog only (not verified in the newsroom): 51% of respondents said "not to my knowledge, but I can't say for certain" whether their organisation had experienced an AI-coded incident. 71% of CTOs say AI coding tools are a net positive for productivity; 47% of CISOs agree. 34% overall say AI tools have increased code review time. 55% want centralised platform-level governance. 24% govern at the environment level.

Unreliable and not used here: production-incident rates. The blog prose and the newsroom/BusinessWire release give different figures for the same question. The one stable incident-adjacent finding is that only 19% could confidently say they had not had an incident because monitoring was in place.

The pattern is clear even without a precise incident rate: only 5% are very confident they have full visibility. Among this survey sample, governance processes were built for pre-AI development pipelines.

How vibe coding runs ahead of governance

In many organisations, governance models were designed for software that arrived through defined pipelines: write, review, test, deploy, log. Vibe coding can create routes around a defined review chain if teams do not impose one. Someone opens an AI coding tool, describes what they want, and has a working prototype in hours. If it connects to a database or API, it may be touching production data without formal review.

Here are three hypothetical scenarios. A developer uses Cursor or Claude Code, generates code, commits it, and it passes review because the reviewer trusts the author. A business user builds something in a no-code AI tool, connects it to data they can access, and shares it with their team. A prototype built for exploration gets adopted by a department, and months later it is mission-critical with no review or ownership record.

Code-generation tools do not automatically provide an organisation-wide governance layer across every deployed app; teams need separate controls or a governed platform. Whether and how those gaps matter depends on what data the tools touch, who uses them, and whether the organisation has any way to answer either question.

What to do: one framework, not two lists

Here is a single, ordered plan you can start this week. It draws on what the survey indicates. Nothing here requires a particular vendor.

Monday: discovery. Email five team leads outside engineering. Ask one question: what tools are your people using to build things that touch company data?

Tuesday: triage. Map what you find onto a simple grid: what data does each tool touch, who uses it? Apps reading public marketing data are different from apps querying customer databases. Sort into three levels of concern based on data sensitivity and audience.

Wednesday: act on the highest risk. Pick the highest-concern item and decide whether it stays, gets reviewed, or gets replaced. One decision, not a hundred.

Thursday: assign ownership. Write down who in your organisation owns this question going forward. If the answer is no one, name someone.

Friday: pick a direction. Decide whether your default approach is centralised deployment (import everything into one governed surface) or structured building (use platforms where permissions are part of the build process). You do not need a vendor picked. You need a direction.

Underpinning this framework: for production-data apps, nocode.tech recommends permissions live at the platform or deployment layer rather than inside each app, audit logging be mandatory, review requirements vary by risk level, and monitoring be continuous. Regeneration can change code, so monitoring should cover subsequent releases.

Retool's announcement: what to know

Retool published the survey alongside an announcement expanding governance to vibe-coded apps. Here is what Retool's 17 June 2026 newsroom announcement describes, presented as vendor claims:

• Permissions attached to data sources and enforced universally across apps
• Apps inherit the organisation's existing audit trails and resource-level policies
• Resource-level policies applying to all apps equally
• Application-layer governance extended across ecosystem partners like Snowflake (Retool's wording)
• Apps created with Lovable, Replit, Cursor, Codex, or Kiro; generated by Claude Code via MCP; imported from existing React codebases; or assembled from Figma designs, all governed through Retool

These are product descriptions, not independently tested capabilities. The newsroom says governance is automatic from the moment anything lands in Retool. The real test is whether every AI-generated app inherits policies cleanly and what breaks when apps make assumptions about their runtime that Retool does not satisfy.

The structured-platform alternative

There is a different approach to the same problem. Some platforms were built with permission models and access controls as core features. If you build within them, governance is something you configure as part of building, not a separate step. Like Retool's claims, these capabilities are documentation-backed rather than independently tested here.

Stacker is an example. Its current product, Stacker Astra, is presented as a no-code platform for external-facing portals with configurable permissions and access controls. The same access-control principle matters when evaluating any structured app platform: permissions configured at the platform level can reduce the amount of per-app access-control logic, but teams should validate defaults, integrations, auditability, and deployment fit for their own requirements.

Where this lands

Retool's findings support a narrower conclusion than the survey's own framing. Among this group of respondents, concern about AI-generated production tools is high, governance maturity is low, and visibility into what is deployed is limited.

Whether you respond by centralising deployment through a platform like Retool, or by building on platforms where access controls are native to the product, the starting point is the same. You cannot govern what you cannot see. The first useful thing an IT leader can do is ask a few team leads what their people are actually building. The answer is probably more interesting than the survey.

*Sources*

*Retool blog* *Retool newsroom* *BusinessWire distribution* *Stacker Astra*