A few months ago, I used Cursor, an AI-assisted software development tool, to process data and render a dashboard. This new process and dashboard save our business development team dozens of hours a week compared to manually processing data in the past. I wore multiple hats – business analyst, requirements gatherer, software developer – and was able to accomplish more than I ever could have if I had attempted to manually code the solution. I knew what to do next: create test cases, commit the code to source control, publish it to an internal website and teach team members how to use it. I have a background in software development, so this is the normal way of doing things, even without AI.
Meanwhile, other colleagues in non-software-development roles used AI coding tools to create even more sophisticated applications. However, they had no idea what to do next to ensure that their great work could be used across the company and be properly maintained. That situation – how do we enable non-developers to play in the sandbox previously occupied by developers – is what we’re going to discuss. And in the months since all this new productivity, the question has only gotten more urgent: the tools have moved from assisting developers to acting on their own, the industry has given this phenomenon a name (“vibe coding” and “shadow AI”), and the first hard data on what it costs has started to arrive.
The Prior Way of Doing Things
For a long time, the enterprise world drew a clean line between software developers and everyone else. Non-developers handled schedule, budget, strategy, business requirements documentation, creative, and more. They created the requirements for the applications they needed developers to build. The circles rarely overlapped, and specialization worked.
AI has redrawn that map. Non-developers are building real applications using AI coding tools (Claude, Cursor, Codex, etc.) and workflow platforms. People who never opened a manual coding tool like VS Code a year ago are creating functional software today with AI. And the tools themselves have changed character: what were autocomplete-style assistants a year ago are now autonomous agents that take a task description, edit across many files, run terminal commands, and ship multi-file changes with limited human intervention. Meanwhile, developers are writing less code themselves and spending more time validating AI-generated outputs, reviewing data, and interpreting business results, not just requirements. The two circles are converging, and the implications for governance are significant.
What Non-Developers Are Actually Building
Today, our non-developer teams produce sophisticated, high-value tools for our agency. Recent successes include:
- A quantitative ad content assessment tool that evaluates creative assets with rigor that previously required dedicated analysts
- An AEO/GEO (AI search) tool with features available in top commercial tools
- Custom AI creative workflows for everything from product correctness validation to interpolating background scenes across ad formats
- Integrations connecting project management tools to time tracking, finance, and other enterprise systems – and some sophisticated dashboards on top for visualization
Critically, these were never tasks that had developers waiting in the wings. This work would not have existed without AI enablement.
Developer Governance Already Works — But Volume Is a New Challenge
When our developers adopted AI coding assistants, the transition was relatively smooth. Code reviews were already standard practice. Source control systems were already tracking every change. Automated pushes from Dev/Stage to Production (CI/CD pipelines) were already enforcing quality gates. AI mostly fit into existing governance structures.
But even on the developer side, the sheer volume of AI-generated code is straining review capacity. The New York Times reported in April 2026 that one financial services company went from producing 25,000 lines of code per month to 250,000 after adopting AI coding tools – creating a backlog of a million lines awaiting review.1 That story has since become a genre: across 2026, engineering leaders have described AI “code overload” as one of their defining operational problems. The governance structures exist, but they were not designed for 10x output. And the quality of that output is not a rounding error – multiple 2026 analyses, including work from Veracode and the Cloud Security Alliance, find that roughly 40–45% of AI-generated code introduces at least one OWASP Top 10 vulnerability, a rate that has not meaningfully improved across testing cycles.2, 3 In SonarSource’s 2026 developer survey, 53% of developers said AI had a negative impact on their technical debt by producing code that looked correct but proved unreliable.4 If even developers with mature review processes are struggling to keep pace, the challenge facing non-developer teams without any review infrastructure is orders of magnitude greater.
The Gap Where Tech Debt Forms
Non-developer creation is where the real governance gap exists – not because the work is lower quality, but because there is no equivalent infrastructure around it. No version control for the workflows being built. No peer review process for the prompts driving critical business decisions. No handoff protocol when the person who built the tool moves to a different role.
In 2026, security researchers have documented thousands of “vibe-coded” applications leaking corporate data because of misconfigured privacy settings,5 and catalogs of real-world incidents in which such apps exposed credentials and private records – on the order of a million-plus API keys across documented cases.6 Industry analyses now put the average cost of a breach involving shadow AI roughly $670,000 above a standard breach.7
Traditionally, tech debt is what builds up inside a codebase over time: as different developers layer new code on top of old, the system slowly grows more brittle, harder to change, and more expensive to maintain. What is forming now is a new kind of tech debt: the absence of systems that make good work durable in the first place. A brilliant tool that only one person understands is a liability disguised as an asset.
A Governance Model That Keeps Pace
An initial instinct may be to create a centralized AI governance board that reviews every initiative. That approach cannot match the speed at which teams need to move. Instead, governance should be layered – and each layer should carry a concrete practice, not just a good intention:
Group-specific owners come first. Each team or function designates someone responsible for knowing what is being built, what data it touches, and who depends on it. Their first job is unglamorous but essential: keep a simple inventory of the tools their team has built, because you cannot govern what you cannot see – and shadow AI is, by definition, the work no one registered. With that inventory in hand, owners triage. Not every tool deserves the same scrutiny; a throwaway dashboard that reads public data is not the same as a tool that writes to a customer database. Borrowing the logic of NIST’s AI Risk Management Framework8, owners sort tools into risk tiers by the sensitivity of the data involved and the blast radius if the tool fails, then concentrate their limited review attention where it actually matters. These owners operate at the speed of their teams.
A source control layer comes next, with automated checks built in. Work needs to be tracked, versioned, and recoverable, and it is easier than ever to commit changes to Git without knowing the commands. The payoff is that modern repositories can run automated scans on every commit at no extra human cost. Two are non-negotiable for this audience: secret scanning, which flags the API keys and credentials that vibe-coded apps so often leak, and dependency and vulnerability scanning, which checks code against known weakness classes such as the OWASP Top 109 before it reaches anyone who depends on it. This catches the common, mechanical mistakes cheaply and at volume – exactly the errors non-developers are most likely to make and least likely to notice.
But automated scanning is necessary, not sufficient – and the numbers above say so. If roughly 40–45% of AI-generated code ships an OWASP-class vulnerability even as that code is increasingly written by tools with built-in review, then no scanner catches everything, and treating a green checkmark as proof of safety just repeats the original mistake one layer up. The realistic answer is defense in depth. Let automation handle the high-volume, known-pattern checks. Reserve scarce human review – a developer or security partner – for the high-risk tier the owners flagged, not for every dashboard. And contain the rest at runtime, which is the step teams skip and the one that saves them: scoped, short-lived credentials instead of a personal master key, least-privilege access to data, and sandboxed environments so that if something slips through the blast radius is a single low-value dataset rather than the whole company. The goal shifts from proving the code is perfect to ensuring that imperfect code cannot do catastrophic damage.
Security, IT governance, and AI usage policy provide the outer boundary. Data handling policies, AI usage policies, access controls, and compliance requirements apply universally, but they should be the ceiling, not the floor where governance starts. This boundary is also where external regulation now lands. The EU AI Act’s obligations for general-purpose AI and high-risk systems become fully applicable on August 2, 2026 – and they reach U.S. companies whose tools touch the EU market.10 Several U.S. states have layered on their own AI transparency and accountability rules. For any agency operating internationally, “who built this, on what data, and can we account for it?” is shifting from good practice to legal expectation.
A governing board sits on top. Its job is to centralize useful ideas and applications that can be shared across groups and to arbitrate issues the groups cannot resolve on their own – not to gate every initiative. It is also the natural home for the two questions a layered model can otherwise duck: how do we know this is working, and what happens to a tool when its creator leaves? A light audit cadence – a quarterly look at the inventory to confirm that high-risk tools have actually been reviewed and that abandoned ones are retired – answers the first. A short handoff checklist – where the code lives, what credentials it uses, what it connects to, and who to call when it breaks – answers the second, and turns “a tool only one person understands” back into a durable asset.
Encouragingly, this layered, owner-first approach is converging with where independent security researchers are landing. The Cloud Security Alliance, writing about the “vibe coding governance gap” in mid-2026, argues that the industry needs a tiered, citizen-developer-accessible governance track within existing security frameworks – rather than either ignoring the work or smothering it under developer-grade process.7 That is essentially the model above, described from the security side.
The Mindset Shift That Makes It Stick
Non-developers do not need to become developers. But they do need to adopt the mindset that allowed great developers to succeed before AI: Does this work reliably? Can someone else reproduce it? What happens when it breaks? These are not engineering questions – they are operational maturity questions that apply to any business-critical process. And increasingly, lightweight tooling can help answer them without anyone becoming an engineer: a handful of test cases the tool checks itself against, a basic alert when it stops returning results, a README that a colleague could actually follow.
Developers, for their part, need to move toward deeper engagement with business requirements. When AI handles more of the implementation, understanding what to build and why becomes the higher-value skill. This will be a non-trivial shift. Or maybe developers end up more specialized than ever, just keeping up with the deluge of new tools and the work of validating what the agents produce. Either way, one thing is clear: non-developers have crossed into the realm previously reserved for developers, and governance will be part of what determines whether that crossing creates lasting value or lasting debt.
Why RPA
RPA exists to drive business outcomes for our clients, and that is the standard every AI-built tool should be held to, whether it is built by developers or non-developers. Governance is simply how we keep that value durable instead of fragile. It is how a large, full-service, independent agency turns a wave of individual ingenuity into lasting value for the clients we serve.
References
- “The Big Bang: A.I. Has Created a Code Overload,” The New York Times, April 6, 2026. https://www.nytimes.com/2026/04/06/technology/ai-code-overload.html
- “Why AI Coding Tools Are Creating Security Gaps,” Veracode, May 12, 2026. https://www.veracode.com/blog/ai-coding-tools-security-gaps/
- “Vibe Coding’s Security Debt: The AI-Generated CVE Surge,” Cloud Security Alliance, 2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/
- “State of Code: Developer Survey Report,” SonarSource, January 2026. https://www.sonarsource.com/the-state-of-code/developer-survey-report/
- “How Vibe Coding Is Creating New Data Risks,” IANS Research, May 15, 2026. https://www.iansresearch.com/resources/all-blogs/post/security-blog/2026/05/15/easy-to-build--easy-to-expose--how-vibe-coding-is-creating-new-data-risks
- “Vibe Coding Failures: Real Apps That Broke in Production,” Autonoma AI, 2026. https://getautonoma.com/blog/vibe-coding-failures
- “The Vibe Coding Governance Gap,” Cloud Security Alliance, June 2, 2026. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/06/CSA_research_note_vibe_coding_ai_governance_gap_20260602-csa-styled.pdf
- “AI Risk Management Framework (AI RMF 1.0),” National Institute of Standards and Technology (NIST). https://www.nist.gov/itl/ai-risk-management-framework
- “OWASP Top 10 Web Application Security Risks,” The OWASP Foundation. https://owasp.org/www-project-top-ten/
- “U.S. Companies Face EU AI Act’s Possible August 2026 Deadlines,” Holland & Knight, April 28, 2026. https://www.hklaw.com/en/insights/publications/2026/04/us-companies-face-eu-ai-acts-possible-august-2026-compliance-deadline
