Vibe coding is enabling non-technical users (or as we call them, citizen builders) to build applications with AI that they simply could not have built before. When our AI applications team in Global Marketing at Thoughtworks was asked to scale a vibe coded prototype built by one of our citizen builders in global marketing, we discovered serious cracks that prevent vibe coded applications from going into production safely.

Speed without guardrails is a risk no team can afford to ignore. What follows is the story of what we found, what it means for teams building with AI and the steps we are taking to make sure every workflow, prototype and app we ship is one we can stand behind.

What we learned the hard way

The AI applications team within Global Marketing was asked to scale a video assembly prototype built with Gemini, Replit AI and Claude AI to create on-brand videos to be used across our 10,000 employees. The team ran into two moments that stopped work cold. In both cases, the AI suggested a path with serious security implications. In both cases, it took a human asking the right question to catch it.

Key insight: AI tools often suggest the path of least resistance. That path is not always the secure one. Human judgment remains essential, but it should not be the only control. The goal is to give agents technical security rules as context from the first prompt, then validate their output through deterministic checks in the development workflow so insecure code, permissions, secrets, or infrastructure cannot pass unnoticed.

The numbers behind the risk

These incidents are not isolated. Research published in 2026 confirms that AI-assisted coding at speed creates systemic security exposure. The same risks we encountered are playing out across the industry right now.

The 2026 codebase risk picture

The real problem: prompts are not enough

After sharing these incidents with engineering and security colleagues, a clear message came back: telling an AI agent to be safe is not the same as enforcing that it is safe. Prompts can be overridden, misunderstood, or ignored. The moment a user pushes back on a restriction, or phrases a request differently, the constraint can evaporate.

It's not sufficient to merely tell the LLM the desired behavior of your output artifacts. If you absolutely do not want something to be true, it must be codified in non-negotiable rules somewhere in your development lifecycle.

— Engineering leadership

Think of it this way: prompting for test-driven development is not the same as enforcing code coverage thresholds in your build tool. One is a suggestion; the other is a gate. Birgitta Boeckeler’s work on harness engineering makes this concrete by outlining a mental model for building trust in coding agents. Instead of relying solely on prompts, developers wrap the agent in an outer "harness" structured along two axes:

  • Guides vs. sensors: Guides (feedforward controls) anticipate unwanted behavior and steer the model before it acts, while sensors (feedback controls) observe the code after the agent acts to flag errors. 

  • Computational vs. inferential: Computational controls are deterministic, fast and CPU-run (like linters or test suites). Inferential controls rely on semantic analysis and AI-driven judgment (like specific system prompt constraints).

Why business functions need to pay attention 

Business functions like our marketing team, who are building with AI, are not exempt from the security obligations that apply to engineers building applications. Building security into software  is a fundamental requirement for protecting customer and employee data. Even lightweight internal prototypes must comply with enterprise security standards. Without the right guardrails, AI-assisted development can expose sensitive data long before an application reaches production.

  • Client trust: compliance is contractual. Adhering to standards like ISO 27001 ensures the protection of sensitive data. All applications, regardless of how quickly they are built, must meet these security benchmarks to maintain the trust of customers and employees.
  • Brand integrity: brand assets need protection. Core work involves sensitive functional data (e.g., unreleased campaign assets, financial data, or audience insights). Over-permissioned service accounts put far more than code at risk.
  • Reputation: business functions can set the standard. When business functions like marketing lead with security discipline, they signal responsible AI adoption to the wider organization and to clients.

Short-term habits: start building responsibly today

You don't need to be a security expert to start building responsibly. These three habits can get you started:

Feed your technical security rules into every session. Add your organization's security guidelines as "Rules" in Claude, Cursor, or Replit to begin with (later on invest in a shared sensible default layer across all tools). The AI agent uses them as guidance, making secure patterns more likely from the start. They still need to be backed by deterministic checks that fail unsafe code, exposed secrets, broad permissions, vulnerable dependencies or insecure infrastructure before anything is deployed.

Question every permission the AI suggests. If a tool recommends making something public or assigning a broad service account role, stop and ask why. The path of least resistance and the secure path are rarely the same thing.

Try the red team prompt. Ask your AI to roleplay as a bad actor and pen test what it just built. This technique consistently surfaces vulnerabilities that forward-looking prompts miss, particularly around permissions and data exposure.

Medium-term solutions: two approaches that made a practical difference

Reading about risk is one thing. Doing something about it is another. These incidents prompted two practical initiatives. The principles behind them are replicable by any team building with AI, regardless of technical background.

The security context file in practice

The idea behind this approach is straightforward: AI tools read context at the start of a session, so make that context your technical security rules. The file is the result of working through your organization's security requirements and structuring them in a form the AI can act on, not just acknowledge.

What follows is the kind of coverage any such file should include. The specifics will differ by organization, but the categories are consistent.

The difference that matters

The key distinction from a prompt is that the file contains non-negotiable rules that force the AI agent to refuse requests that violate policy. If the AI agent is asked to bypass a check, disable logging or set something to public access, the rules should steer it to decline and explain why. But the important control is that deterministic checks and deployment gates should still catch the issue even if the agent fails to follow that guidance. That refusal is precisely what was missing in both of our near-miss incidents.

The security intelligence feed in practice

Staying informed is its own form of defence. The workflow monitors the tools and languages your team actively uses and delivers a daily digest of new CVEs, platform advisories and security bulletins. The coverage areas that matter most are consistent across organizations: the languages they write in, the cloud platforms they deploy to, the AI coding tools themselves and the CVE database as a whole.

The goal is simple: learn about a vulnerability on the day it is disclosed, not weeks later. At 42% of all new enterprise software now AI-generated or AI-assisted, the tools that accelerate development are also the tools most likely to appear in new CVE disclosures. Monitoring them actively is part of owning your security.

The broader point is that neither of these approaches requires an engineering background to adopt. One is a policy document structured for AI consumption. The other is an automated search. What they share is the recognition that passive security awareness is not enough when AI is generating code at speed.

Long-term organizational changes: A recommended path forward

  1. From prompts to pipelines. Integrate harness engineering into your standard prototyping templates. Move from probabilistic prompts to explicit feedback loops. If a computational sensor (like an automated security scanner) triggers, the agentic loop must structurally force the model to self-correct until it passes.
  2. Feed security rules into the application builder (Cursor, Claude etc). Compile your organization's technical security rules into a structured context markdown file and load it as “Rules” which the model will have to adhere to. It catches the most common missteps at the point where they are cheapest to fix, before any code is committed.
  3. Make the secure path the easy path. Give builders a secure-by-default starting point. Templates that pre-configure authentication patterns, private storage defaults, secrets handling and dependency scanning reduce the chance that anyone takes a shortcut under deadline pressure.
  4. Define a starter harness across functions. A shared starter harness built together by business functions, engineering and security gives every builder a secure foundation from day one, rather than each team independently rediscovering the same mistakes.

Conclusion: Scaling beyond the prototype

This journey started when we were brought in to support another team building a video assembly platform for a Global Marketing hackathon. As we helped scale the solution, it became clear that vibe coding without enterprise-grade guardrails can introduce risks that organizations simply cannot overlook.

By embedding our technical security rules directly into the agent workflow, we transformed those early near-misses into a secure, production-ready platform that was successfully rolled out to 150 users during the hackathon. 

That shift — from depending on humans to catch issues, to building technical security rules, automated checks and human accountability into the workflow has become our blueprint for moving fast while maintaining engineering rigor in the agentic era.