I have shipped a dozen production tools this year — a multi-tenant vulnerability-management platform, a NIFTY-50 options engine, a compliance tracker — and I hand-wrote almost none of the code. I described what I wanted, an AI wrote it, and I reviewed and steered. That is vibe coding, and it is already inside your organisation whether your security policy acknowledges it or not.
What vibe coding actually is
The term is loose, but the practice is concrete: you build software by describing intent in plain language and letting a large language model generate, refactor and debug the code, while you act as director rather than author. The “vibe” is the shift in posture — you steer outcomes instead of typing syntax.
For a security leader, the interesting part is not the novelty. It is the velocity. An internal tool that used to take a sprint now takes an afternoon. That speed is a gift and a liability, and both land on your desk.
Why this belongs on the CISO’s radar
Two reasons, pulling in opposite directions.
- Your teams are already doing it. Analysts are vibe-coding detection rules, log parsers and one-off automations. Shadow development always existed; AI just handed it an accelerator.
- It is a genuine force multiplier for defence. I have used it to stand up log-enrichment tooling, triage automations and internal dashboards in hours. A small security team can now punch well above its headcount.
The new attack surface
Speed hides debt. Vibe-coded software fails in familiar ways — just faster, and at scale:
- Insecure defaults. The model will happily log secrets, disable TLS verification or trust raw user input, because it optimises for “works”, not “safe”.
- Invisible dependencies. A three-line prompt can pull in a dozen packages nobody vetted. Supply-chain risk arrives without a purchase order.
- Plausible-but-wrong. Generated code reads confidently and passes a smoke test while quietly mishandling authentication, cryptography or an edge case.
- No mental model. When you did not write it, you are slower to reason about it under incident pressure — exactly when you cannot afford to be.
The danger is not that AI writes bad code. It is that it writes convincing code faster than anyone is reviewing it.
Governing it without killing it
Banning vibe coding is both futile and self-defeating. The job is guardrails, not gates. What works for us:
- Treat AI-generated code like any third-party code. It gets reviewed, scanned (SAST, dependency and secret scanning) and gated in CI before it ships. No exceptions for “the AI wrote it”.
- Ship secure-by-design prompts. Give teams a baseline prompt and policy — parameterised queries, input validation, no secrets in code, least privilege — so the default output starts safer.
- Keep a human accountable. The person who prompts it owns it. AI is the author; a named engineer is the signatory.
- Right-size the blast radius. A least-privilege internal tool is a very different risk from vibe-coded code on a customer-facing path. Match the review depth to the exposure.
This is where AI governance stops being abstract. The same ISO/IEC 42001 muscle — inventory, risk assessment, human oversight and traceability — applies directly to the code your teams generate, not only to the models they consume.
My rule of thumb
Vibe code the tool; govern the trust. Let AI collapse the cost of building, and spend the time you save on the part machines still cannot own — deciding what is safe to ship. The teams that win the next few years will not be the ones that resisted this. They will be the ones that adopted it with a seatbelt on.