Imagine that you meet a guy at your company’s HQ and find out he’s a freelance junior dev who’s been working for months in here. You’ve never heard of him. The CEO never informed you because you were too busy.

This dev, whom you never onboarded, vibes code everything into production.

While many have already adopted tools like Claude Code, two scenarios of vibe coding for administrators keep coming back. On one hand, there those who accepted to grant AI agent access to the architecture they carefully built. On the other hand, there’re those who are not event aware that dev in their teams are using tools like Claude Code, building with it as if it were a partner.  

In this article, we will explore how vibe-coding changes the way developers work, what it means for administrators and CTO, and how to protect developers' workstations from the new risks which arise from vibe coding.  

Understanding Vibe Coding : What’s all the fuss about

Vibe coding consists in asking an AI tool to generate code that can run directly. Tools like Claude, Gemini, DeepSeek, or Cursor make it possible to build applications very quickly, sometimes with very little manual work.  

In practice, some developers write a spec. This document explains what they want to build, how it should work, and what rules must be followed. The AI then generates the code based on this description. Others write detailed comments directly in their code, and the AI fills in the logic below. In both cases, the idea is the same. The developer gives enough context so the AI can make decisions and not just guess.

Instead of writing a REST API endpoint manually, a developer describes the schema, authentication rules, and expected behaviour and the AI generates the full endpoint, tests included. They delegate to AI one of three pillar of IT: transforming a business need into a safe and functional application.  

A Productivity Boost That Comes With a Cost

There is no doubt that vibe coding improves productivity. Developers can build faster, test ideas quickly, and spend less time on repetitive tasks. It also helps when debugging or looking for quick answers.  

In the long term, this changes how teams work. Developers may write less code, but they do not necessarily feel less pressure. They spend more time checking, fixing, and trying to understand what the AI produced. Indeed, reviewing code that you did not write yourself is harder. You need more focus to understand it. And because AI is not always predictable, it can create frustration and stress.

AI-generated code can look correct but still have problems. It may have weak structure, poor performance, or bad practices that are not always easy to see. If nobody reviews its outputs, they can fragilize systems and lead to code that is hard to maintain. That’s the point where teams may start depending on tools they do not fully understand. ‍

Trust Is Not Enough: Why Reviewing The Code Matters

There is one key idea to remember: trust does not remove the need for review. AI should not be treated as a trusted partner. It should be treated as an external and unreliable source. This is important because AI systems have weaknesses.

The first problem is hallucination. AI can generate answers that look correct but are actually wrong. It can invent functions, create incorrect logic, or miss important security issues. The second problem is more serious. AI systems can be manipulated through what is called prompt injection.  

When AI tools retrieve external data, they can be influenced by hidden instructions embedded in that content. Security researchers have shown that AI tools like Claude can be tricked when they search for information online. An attacker can create a malicious webpage that contains hidden instructions. When the AI reads that page, it processes these instructions as if they were legitimate input, without recognizing the threat.

From the user’s point of view, nothing seems strange. The AI is simply doing its job. But in reality, this can have serious consequences. In some cases, AI tools run with high system permissions. This means an attacker could access sensitive data, steal login information, or install hidden software on the machine.  

The Real Issue: Blind Trust

The biggest problem is not the technology itself. It is how people use it. When developers run AI-generated code without checking it, or give the AI too many permissions, they create risks. The code may look clean and reliable, but still contain hidden flaws or vulnerabilities. Overtime, using AI without understanding its outputs inevitably creates technical debt. And this debt grows quickly.

Developers should always question AI outputs by asking for sources, checking facts, and making sure the conclusions are backed by evidence. When an AI system cannot provide clear references, that is often a sign of hallucination. This is why verification remains essential. Code reviews, testing, and security checks must still be part of the process. AI can help, but it cannot replace responsibility.

What does this piece of code actually do? What proof shows that the issue comes from a specific part of the infrastructure? This kind of reflective approach is where AI becomes truly useful.

It is equally important to give developers a setup that matches their needs. If they use AI tools, those tools should run in a dedicated environment. Developers should work in separate environments: one for their development activities, with their own tools, including AI, and another for testing AI-generated code in an isolated space before anything reaches production. AI tools should also be properly configured and should never have unrestricted access to systems or external tools.

Less PC, more environment: the multi-environment workstation

A practical first step is to create separate environments for AI use. Instead of running directly in the main user space, Claude Code can be placed inside its own operating system profile. This way, access to files and applications is limited by design, rather than left to assumption.

This also opens the door to a broader rethink of workstation architecture. Multi-environment setups, as recommended by the French cybersecurity agency, provide a strong framework. One space can be used for everyday work, another for highly sensitive data, and a third for AI-assisted tasks. Organizing workflows across these boundaries helps control what the AI can access and influence at any given time. Running AI tools inside a virtual machine, ideally supported by a type 1 hypervisor, adds another layer of separation between the system that holds sensitive data and the one that interacts with the AI. This does not remove risk, but it reduces broad exposure to a more contained one.

In this setup, Claude Desktop operates in a controlled environment, while critical information stays out of direct reach. Even if something goes wrong, the impact remains limited to a defined perimeter.

‍Conclusion: Protect your Developers’ workstations, Protect your architecture ‍

Providing your developers with a dedicated environment is the first step to protect the architecture you meticulously built in case their workstations are hacked or contaminated. The real skill lies in human judgment: knowing what must be verified, detecting missing details, and recognizing the limits of the model’s understanding. AI operates without full knowledge of its execution environment, especially when it comes to internal constraints such as network architecture, security policies, and operational requirements. Navigating these blind spots is what separates effective use of AI from risky dependence on it. Our internal developers work with the very solution we built. A solution that gives developers an environment that finally meet their needs for autonomy while enabling the admin’s visibility.

Does it sound too good to be true? Let us show you how we do it.

‍