Vibe Coding Has a Name. Now It Needs a Landing Zone

On February 2, Andrej Karpathy put a name to something a lot of us had already noticed: vibe coding. It means building software by talking to a model and letting it handle the code, or, in his words, choosing to "fully give in to the vibes." The phrase spread quickly among developers.

The name is new. The habit isn't. People outside engineering are already building internal tools in an afternoon: a dashboard on top of a spreadsheet, an intake form, a small approval workflow. Some of these tools are genuinely useful, and that is the problem. Useful tools get shared, and once a tool is shared it is production, whether or not anyone decided that.

So the question for IT isn't whether to allow it. The question is where these apps will live once they stop being experiments.

Shadow production is the real risk

A vibe-coded app on someone's laptop is a toy. Put the same app on a public URL with a customer list and an API key inside, and it becomes a system. It just has no owner, no backups and nobody reading its logs.

Days before Karpathy's post, Wiz Research showed how fast that goes wrong, even at a well-funded AI company. They found a publicly accessible ClickHouse database belonging to DeepSeek. It was completely open and unauthenticated, and it exposed chat history, API secrets, backend details and a log table of more than a million entries. DeepSeek secured it promptly once Wiz disclosed it. Nothing about the exposure was exotic, though. It was a database on the internet with no authentication, which is about the most ordinary mistake in operations.

We expect shadow production to fail the same way. Clever attacks won't be the cause. Missing basics will: a hardcoded key in a public repo, a database left open because the tutorial said so, no backups because nobody knew the app mattered until it broke.

What a landing zone for vibe-coded apps looks like

Banning these tools won't fix this. A ban only pushes the work further out of sight. What works is a paved path: if an app took an afternoon to build, it should take about an afternoon to deploy, with the basics already in place. Think of it as a landing zone sized for small internal tools rather than enterprise workloads.

At minimum, it should give every app:

• Hosting you control. A standard container or app platform in your organization's cloud account, not someone's personal free-tier account.
• Identity in front by default. Every app sits behind your SSO. An app gets a public endpoint only when someone explicitly asks for one and justifies it.
• A secrets store. API keys come from a managed vault or are injected at runtime, never from source code. Scan every push for leaked keys.
• Managed data with backups. A provisioned database with authentication on, restricted network access, and automated backups you have actually restored in a test.
• Logs and an owner. Basic logging, an uptime check, and the builder's name recorded as the owner.
• A template repo. Starter code with all of the above already wired in, so the fastest way to start is also the safe one.

None of this is new technology. It's the platform work good DevOps teams already do for engineers, opened up to a new kind of builder.

The regulatory clock started the same day

The day Karpathy coined the term, the first provisions of the EU AI Act began to apply. According to the European Commission, the bans on prohibited AI practices and the AI literacy obligations have applied since February 2, 2025.

For a Canadian organization, the Act matters mostly if you offer AI systems in the EU or their output is used there. The idea behind AI literacy is worth borrowing either way: people who build with AI should understand what the tools can and can't do. For vibe coders, that means knowing a model will happily write a working app that stores passwords in plain text. An app that runs is not necessarily an app that is safe.

A landing zone helps with literacy as well. Guardrails built into the platform teach better than any training deck, because they show up right when someone is about to make the mistake.

Graduating from experiment to system

Most vibe-coded apps don't need the full treatment. Many will stay small and quietly fade away. What you need is a clear trigger for when an app graduates. For example:

• More than one team uses it.
• It stores personal, financial or customer data.
• It writes to another system of record.
• Someone would notice, and complain, if it went down.

When any of these is true, the app gets a short review covering who owns it, where its data lives, how it's backed up and what it can reach. That usually takes about an hour. Skip it, and a weekend experiment can become next quarter's incident.

What we recommend

If you lead IT or a platform team and you're watching vibe coding spread through your organization, start here:

• Find out what already exists. Ask instead of auditing. An amnesty gets more honest answers.
• Stand up a minimal landing zone with SSO, a secrets store, a managed database with backups, and logging.
• Publish one template repo and make it the easiest place to start.
• Define graduation triggers and a lightweight review to go with them.
• Keep the review fast. If the safe path is slow, people will go around it.

Vibe coding is going to produce a lot more software. The organizations that come out ahead will be the ones that give that software somewhere safe to land.

Building this kind of paved path for IT teams is everyday work for HAZL's DevOps engineers. If you'd like help setting one up, we're happy to talk.