When the IT specialist at a company of 20 to 30 people left, the responsibility landed with an employee who had little technical experience.
“I’m not really an IT person,” they wrote on Reddit. “I have zero coding skills.”
Yet over a single weekend, they vibe-coded an entire IT support system from scratch, in an effort to streamline a process they found cumbersome.
Until then, employees had submitted tickets through a Google Form, which sent their answers to a spreadsheet. The new system could log and archive requests and use an employee-facing chatbot to resolve basic problems before escalating them.
“I… even got AI to make an initial recommendation on how I should solve the issue,” the employee wrote, clearly proud of the result. “It truly is a wild time.”
Thanks to the recent advancement of AI coding tools, almost anyone can write software, even if they don’t see themselves as developers.
“A finance analyst builds a reconciliation workflow. A security analyst wires up an enrichment step that queries a production system on a schedule,” says Brad Rumph, Field CTO at Tines. “Neither opened a ticket, neither wrote anything to a repo, and both built something that now runs unattended against real data.”
As more employees become accidental developers, organizations are accumulating wild code, AI-generated software created beyond an organization’s ability to track, govern, secure, and maintain it.
I’ve never seen anything like this in my 30+ year career in software engineering. How you ensure this code is secure, maintainable, tested, understandable is something the majority of organizations are struggling to figure out.
Brad Rumph, Field CTO, Tines
Many companies assume they can keep wild code under control through AI policies, mandatory training, or governance committees. But, while each of these measures has some merit, the result is often only an illusion of control. Here, we'll take a look at three of the most commonly cited solutions, and why they fall short.
1. Employee education: necessary, but insufficient
The corporate response to AI-generated code relies on an optimistic premise: once employees understand the risks, they'll behave differently. So organizations publish AI policies, run awareness campaigns, and require staff to complete training.
In theory, these measures can reduce careless behavior. In practice, they do little to contain wild code. That’s because the problem is not simply a lack of knowledge.
Even developers who know how software should be built can produce AI-generated code that is insecure or too burdensome to review. In one case, a junior developer submitted a 10,000-line pull request for what should have been a rather minor task. Faced with more code than anyone could reasonably inspect, the engineering lead refused to review it.
“This issue does not need 10k LoC changed,” the lead wrote, “and I am not going through this.”
The episode appeared in a research paper that analyzed 1,154 Reddit and Hacker News posts about AI-generated code. The researchers found that while AI dramatically reduces the effort required to produce code, it shifts much of that effort downstream, to the people responsible for reviewing and understanding it.
And those were developers, people already trained to recognize the obligations that come with writing software. For employees without coding experience, those risks are harder to recognize.
“The training gap is wider than most organizations think, because the population building software has changed,” says Rumph. “A software engineer reads an AI policy and maps it onto concepts they already live with day in and day out: production versus staging, secrets management, least privilege. A finance analyst building a reconciliation workflow reads the same policy and has nowhere to put it.”
Rumph adds that the finance analyst is not ignoring the rules. They simply can’t process them.
The rules are written in a vocabulary nobody taught them.
Brad Rumph, Field CTO, Tines
Christina Troy, IT manager at Tines, agrees. AI is now woven into the tools everyone gets, and the functionality expands faster than anyone can keep up with.
“Things move quickly and therefore can break quickly, and most people don't yet have a mental model for secure, responsible AI use,” she says. “Since folks are not generally security- or development-minded, things like how to route a workflow webpage or connector to ensure the data remains within the secured workspace and is not publicly available for exploitation are not top of mind, especially when the AI will not generally guide you to secure it.”
But even if someone understands the risk, it doesn’t mean they're willing to change their behavior. Employees are often under deadlines. There are productivity expectations and performance reviews. They can even be pressured to automate repetitive work or to deliver more with fewer people.
In short, they're incentivized to take the shortcut. Particularly when results are applauded, mistakes often remain hidden until something breaks.
2. Tool and system sandboxing: valuable, but limited
Beyond employee education, organizations try to contain wild code by limiting where AI tools can operate. Employees are given access through sandboxes, isolated environments where they can test models, prompts, and AI-generated code without exposing production systems or sensitive company data.
Sandboxing is valuable during experimentation. But it comes with a major trade-off: applications and automations only become truly useful when they access company data and operational systems. Without those connections, approved tools may sound good in theory, but may not address real-world issues.
“Sandboxes solve the design problem and leave the runtime problem alone,” Rumph says. “They work for prototyping and evaluation, and they’re weakest exactly where AI is most useful, which is against real schemas and real data.”
Rumph argues that sandboxes also depend on users recognizing when an experiment becomes a production system. Professional developers typically work with distinctions such as development, staging, and production. Meanwhile, employees in HR or finance may have less reason to recognize that boundary.
When they point it at live data, they don’t experience that as crossing a line, because nobody described how this was supposed to work to them.
Brad Rumph, Field CTO, Tines
The sandbox label can create another problem: users may interpret it as proof that whatever they build inside is safe. “Teams treat the sandbox as a guarantee and stop asking hard questions about what they’re building,” Rumph adds. By the time an application leaves the protected environment, it may have received less scrutiny than software developed openly through established processes.
Sandboxing can therefore reduce some risks, but it can’t govern what happens after an experiment becomes operational.
3. Governance by committee: too slow to keep pace
If education can’t prevent risky choices and sandboxes can’t contain what follows, organizations often add another layer: stronger oversight. But this, too, offers limited results.
Governance worked well in the romantic era of software development, when code emerged through a relatively transparent process. Today, however, employees can use AI to build and deploy applications before a governance committee knows they exist. Governance committees simply cannot keep up.
“Organizations have to be very careful in developing governance practices,” says seven-time CIO Mark Settle. “If you establish a one-size-fits-all set of controls or guardrails, you inevitably over-engineer the constraints on some types of everyday, relatively harmless activities and under-engineer constraints on more sophisticated systems.”
Traditional governance models fail because they operate at a human pace, while AI enables software to proliferate at something closer to machine speed.
A committee may prohibit one risky practice only to find that employees have already adopted a new tool or discovered another route to the same outcome.
“Governance built on predicting specific bad behaviors ages badly, because the behaviors change faster than the review cycle that produced the list,” Rumph says.
Another issue is that organizations tend to focus oversight on engineering, where strong controls already exist. Meanwhile, employees in finance, HR and operations build applications and automations that may go unnoticed.
“The automation nobody can see is built by people in finance, operations and HR who don’t think of themselves as developers,” Rumph says. “It never enters a repo, so code scanning will never find it.”
Rumph argues that governance should begin with inventory rather than prediction.
What I'd build instead: continuous visibility into what AI-generated code and automation exist, what data they touch, and who owns them.
Brad Rumph, Field CTO, Tines
That inventory must extend beyond source-control repositories to the workflow tools and internal platforms used by business teams. Without that visibility, policies and approval processes govern only the fraction of software the organization already knows about.
Training, sandboxes, and governance committees all try to solve wild code by intervening after someone has already chosen to build. None of them change what the easiest path looks like in the first place. And when the easiest path isn't the governable one, that's the path people take — not out of carelessness, but because it's the path of least resistance.
The fix isn't a better set of rules for people to follow. It's making the easiest path the governable one.
A single environment to build, run and monitor
Tines 3B customers take a different approach to wild code. Instead of preventing employees from building, they give them an environment in which their AI-assisted apps, agents and automations can be governed from the start. Tines 3B brings the creation, execution, and monitoring into a single governed environment.
Employees can describe what they want to build in natural language or connect coding assistants such as Claude Code and Codex. Organizations decide which data sources and business systems employees can connect to, and what actions they're allowed to perform.
Governance continues after the software is built. Each workflow step runs in isolation, and credentials are injected at runtime without being exposed. Once a workflow is live, teams can monitor access, performance, dependencies, and AI spending. Potential failures and proposed fixes also remain visible for review.
The goal isn't to add more friction to how apps, agents and automations get built — it's to make sure the fastest way to build something is also the safest and most visible one. When the easiest path is the governable one, governance happens by default, not by effort.