The Citizen Developer Wave Has a Governance Problem
Every organization with 50 or more people probably has someone doing it right now. Maybe it’s the ops manager who discovered Claude and started automating her own workflows. Maybe it’s the analyst who connected your CRM to an LLM through an API and saved himself three hours a week. Maybe it’s the 27-year-old in accounting who’s quietly building things he doesn’t know how to explain to his manager.
The tools work. That’s the good news. And it’s genuinely good news I’m not here to tell organizations to stop their people from building. The capability being developed in pockets of non-technical companies right now is real, and some of it is remarkable.
But I had a conversation this week with Matt Graham, who runs a security firm and watches the dark web professionally, and he said something I want every business owner to hear: the volume of exposed API keys and credentials he’s seeing has reached a level he’s never seen before in his career. Not because of sophisticated attacks. Because well-meaning employees are hard-coding API keys directly into the front-end HTML of apps they built on a weekend and never thought twice about it.
You don’t need to be a hacker to find them. A simple scraping script will surface them from public-facing pages all day long.
Listen to the full conversation:
This is what the citizen developer wave looks like without governance. And organizations are walking into it with their eyes open and their guardrails missing.
What Actually Happens When the Vibe Coder Leaves
Here’s the part of this conversation that I think gets missed in almost every ‘just start building’ narrative: citizen development doesn’t reduce key-man risk. It concentrates it.
In the old world, you needed fifteen engineers to build something meaningful. The institutional knowledge was distributed. When someone left, you lost a piece of it that was painful, but survivable. Now one skilled person with access to Claude Code or Cursor can build what used to require a team. That’s genuinely powerful. It’s also genuinely dangerous if you haven’t thought through what happens when that person walks out the door.
When they leave, you don’t just lose a developer. You lose the documentation that was never written, the architectural decisions that were never recorded, the API connections that were set up with credentials stored somewhere nobody else knows about, and the institutional context for why the workflow was built the way it was. Matt put it plainly: the organizational context what the business does, why the workflow works this way, what the copy in a given section is supposed to accomplish is the hardest thing to hand off. And it’s the part that lives entirely in one person’s head when no governance structure exists.
I’ve watched this happen. We actually built a product called Basecamp partly in response to seeing it happen repeatedly in our client work. The pattern is consistent: a company gives someone a Claude Code license and tells them to go figure it out. They get decent at it. They hire another person and train them. The second person inherits the first person’s bad habits because neither of them knew any better. Now you’re scaling ungoverned practice, not capability.
The fix isn’t complicated, but it requires making a decision before things get complex enough that fixing it becomes genuinely painful. What tools are approved? Where does code live and is it actually backed up in a GitHub organizational layer that someone other than the builder can access? How are credentials stored? What’s the standard for documentation before something ships?
None of that is sophisticated engineering. It’s the boring infrastructure that 30 years of software development figured out the hard way. The citizen developer wave is just rediscovering why those practices exist.
The API Key Problem Is Worse Than You Think
A self-contained answer to a question worth asking directly: what does API key exposure actually mean for a business, and how does it happen?
When you or someone on your team builds an AI-powered application, it typically connects to a model provider Anthropic, OpenAI, Google through an API key. That key is essentially a billing credential. Whoever holds it can use your account to run queries, which costs money at a rate that scales with usage. If that key gets exposed and someone finds it, they can run queries on your account until you notice or until your billing limit is hit.
The exposure happens in a few common ways. The most preventable: the API key gets written directly into the application code, which then gets deployed to a public-facing URL. When the page loads in a browser, the key is visible in the HTML source. No special access required. The slightly less obvious version: the key ends up committed to a public GitHub repository because the builder didn’t set up a proper environment variable structure and didn’t realize the repo was public.
Matt’s team is seeing both happen at a scale that is, in his words, ridiculous. And the downstream risk isn’t just the billing exposure though that can be significant, running into thousands of dollars a day depending on usage before anyone notices. It’s also that an exposed API key gives someone the ability to query your model context, potentially surfacing prior conversations and data that was never meant to be accessible.
The five-minute fix that most organizations haven’t done: set cost caps in your API console. Log into your Anthropic console, your OpenAI API settings, or whatever providers you’re using, and set a hard monthly spending limit. For most organizations, $50 to $100 captures their legitimate usage with some room. If an exposed key gets picked up and someone starts running queries against it, your exposure is capped at that number plus a small overage buffer. It doesn’t prevent the exposure, but it limits the damage to something survivable.
Beyond that, the standard practice is to store API keys as environment variables never in the code itself and to make sure those variables are configured correctly in whatever hosting environment you’re using. If you’re deploying on Vercel, that means setting them in the project settings, not writing them into the codebase. This is table-stakes engineering hygiene that vibe coders often skip because nobody told them it mattered.
Governance Isn’t a Blocker It’s What Makes Building Sustainable
I want to be direct about something: I’m not arguing that organizations should slow down their AI adoption or put bureaucratic hurdles in front of people who are trying to solve real problems. The citizen developer momentum happening right now is one of the more interesting things I’ve watched in 20 years of doing this work. Non-technical organizations are developing real technical capability, often faster than anyone expected.
But there’s a version of this that goes well and a version that doesn’t. The version that goes well looks like a company that supported someone’s initiative, gave them a reasonable standard to build to, made sure the code was backed up somewhere the organization controls, and set up basic cost controls on the APIs being used. That company has a new capability and the organizational infrastructure to sustain it. When the person who built it moves on or gets promoted, the next person has something to work with.
The version that doesn’t go well looks like a company that said yes to everything and governed nothing, and is now sitting on a collection of AI tools that only one person understands, running on credentials that may or may not be secure, with no documentation of what they do or why they were built. That company has the appearance of capability and the liability of a system they can’t actually see.
The good news is that the gap between those two outcomes is almost entirely about decisions made early before the codebase gets large, before the tool goes anywhere near clients, before the one person who built it gets a better offer. A basic tech stack standard, a GitHub organizational layer, a documented approach to credential management, and cost caps on APIs. None of that is expensive. None of it requires a sophisticated engineering team. It requires making the decision to do it before the thing that makes it necessary happens.
If your organization has people building AI tools and you’re not sure what governance looks like in practice, start here: https://assessment.ascendlabs.ai/
If you want to talk through what this looks like for your specific situation, I set aside time every week for exactly these conversations: tidycal.com/kevinwilliams
