You've seen the scene in every vampire movie.
The vampire is standing outside the door, asking to be invited in.
The person inside hesitates. The vampire seems calm enough. Reasonable enough. Maybe even helpful.
But everyone watching knows the rule.
Don't do it.
Don't open the door.
Don't invite the vampire into the house.
Agentic coding has a similar moment.
ChatGPT or Claude writing code for you in a chat window is one thing. Installing an AI coding agent on your machine and giving it permission to act inside your development environment is something else.
At that point, you're not just asking for code.
You're opening the door.
That doesn't mean the agent is evil. It doesn't mean agentic coding is a bad idea. It doesn't mean developers should avoid the tools.
But it does mean you need to think carefully about what you're inviting in, where you're inviting it, and what it can reach once it's inside.
Suggestions are not the same as actions
There's a big difference between asking an AI for help and giving an AI the ability to act.
If I ask ChatGPT or Claude to write a routine, explain a bug, suggest a design, or review some code, the model is giving me text. I still have to copy it. I still have to paste it. I still have to run it. I still have to decide what makes it into the project.
That's a fairly natural extension of the way developers already work.
Agentic coding changes the relationship.
Now the tool may be able to create files, edit files, run commands, install packages, execute scripts, chase compiler errors, start test runs, and make changes across a repo. In some workflows, that's exactly the point. You don't want the AI to just suggest the next step. You want it to take the next step.
That can be useful.
It can also be risky in a completely different way.
The question is no longer just, "Can this model write good code?"
The better question is, "What can this agent touch if something goes wrong?"
The agent at the door
The agent is standing at the door saying:
"Trust me. I'll only touch the files you tell me to touch."
That sounds reasonable.
It may even be true most of the time.
But "trust me" is not a security model.
If the agent is running on your main machine, inside your normal development environment, with access to your files, credentials, folders, repos, scripts, package managers, and tools, then the important decision has already been made.
You invited it in.
Maybe it follows the rules perfectly.
Maybe it doesn't.
Maybe the agent itself behaves, but a script it writes has the wrong path.
Maybe a cleanup command runs one folder too high.
Maybe a package it installs has a bad post-install step.
Maybe a generated refactor touches more files than anyone intended.
Maybe a long thread drifts away from the original boundary.
Maybe the agent tries to be helpful and fixes something you never asked it to fix.
None of that requires the AI to be malicious.
That's the part developers need to take seriously.
A lot of damage can happen through good intentions, sloppy instructions, bad assumptions, unsafe defaults, or one command that does exactly the wrong thing very efficiently.
An apology is not a backup
One thing I've never seen in a vampire movie is the vampire apologizing after killing everyone in the house.
An AI agent might.
If it deletes the wrong folder, rewrites the wrong files, or turns 5,000 lines of working code into 150 lines of elegant nonsense, it may apologize sincerely when you call it out.
It may explain what went wrong.
It may agree that it should have asked first.
It may promise to be more careful next time.
But the damage is already done.
The apology doesn't restore the files.
It doesn't put the project back the way it was.
It doesn't give you back the time, the lost context, or the confidence that the codebase still says what you meant it to say.
An apology is not a backup.
It's not a snapshot.
It's not a boundary.
That's why the boundary has to exist before the mistake.
You don't build the lock after the vampire is already in the house.
Don't confuse instructions with boundaries
It's easy to tell an agent:
"Only work in this folder."
That's an instruction.
A boundary is different.
A boundary says:
"This is the only project drive mounted."
"This VM doesn't have access to my personal folders."
"These credentials can't push to everything I own."
"The repo doesn't contain secrets."
"The agent can't reach unrelated projects because unrelated projects aren't attached."
That's a very different kind of protection.
Instructions depend on the agent doing what you meant.
Boundaries limit what can happen even when something goes wrong.
That's the difference between saying, "Please stay in the room," and locking the doors that lead to the rest of the house.
The lawn chair problem
One of the appeals of agentic coding is what I think of as the lawn chair approach.
You give the agent a task. It creates files. It runs tests. It chases errors. It updates code. It does the boring mechanical work while you sit back and watch.
That's not automatically bad.
In fact, that may be the whole reason you're interested in using an agent in the first place. If you're paying for the tokens and the tool can do real work, you probably want it to do more than answer questions.
But the more you want the agent to act independently, the more important the containment becomes.
If you're reviewing every line, approving every command, checking every path, and watching every change, the risk is one thing.
If you're letting the agent run longer task chains, install packages, modify several files, execute scripts, and recover from errors on its own, the risk is something else.
The lawn chair is fine.
Just don't put it inside the blast radius.
Build the workshop first
The safer pattern is not complicated.
Don't invite the agent into your whole house.
Build it a workshop.
For serious agentic coding experiments, I'd rather see a dedicated virtual machine than an agent installed casually on a developer's main machine.
Then I'd rather see each project live in its own separate storage space that can be attached to that VM when needed.
When you want to work on Project A, you mount Project A.
When you want to work on Project B, you mount Project B.
The agent doesn't get to browse the whole kingdom. It only sees the project you attached for that session.
That kind of setup gives you several practical advantages.
You can snapshot the VM.
You can back up the project storage.
You can limit credentials.
You can avoid exposing personal folders, customer data, accounting files, password stores, SSH keys, unrelated repos, or anything else the agent doesn't need.
You can make sure the repo doesn't contain secrets.
You can keep the agent from reaching things it has no business touching.
Most importantly, you're no longer depending entirely on the agent remembering the rules.
You've built a room where the rules are physical.
The agent can only break what it can reach
That's the simple principle.
The agent can only break what it can reach.
That doesn't make the work risk-free. You can still damage the mounted project. You can still accept a bad refactor. You can still approve a broken design. You can still let the agent burn tokens chasing the wrong problem.
But there's a big difference between damaging one mounted project and damaging your whole development environment.
There's a big difference between losing work that was backed up before the session and losing work scattered across several unrelated folders.
There's a big difference between a limited credential and a token that can reach everything.
There's a big difference between a repo that contains no secrets and a repo that quietly exposes the keys to your business.
You don't need the environment to be perfect.
You need it to fail small.
This isn't about being afraid of AI
I'm not arguing that developers should avoid agentic coding.
I'm arguing that they should treat it like what it is.
It's not just autocomplete.
It's not just ChatGPT or Claude writing a function.
It's an actor inside your development environment.
That means the professional question changes.
Instead of asking only:
"Can this agent help me write code?"
You also need to ask:
"What can it reach?"
"What credentials does it have?"
"What scripts can it run?"
"What folders can it see?"
"What happens if it gets confused?"
"What happens if a dependency does something unexpected?"
"What happens if I get too comfortable and stop watching closely?"
Those aren't anti-AI questions.
They're basic professional questions.
Where the book goes deeper
In Real Programmers Use AI, I'm planning to go deeper into this setup pattern.
That includes dedicated virtual machines, project-specific storage spaces, limited credentials, backups, snapshots, repo hygiene, review discipline, and the practical habits that make agentic coding safer.
But the core idea is simple enough to state here:
Don't give an AI agent access to anything it doesn't need to touch.
If you want to experiment with agentic coding, do it.
If you can afford the token cost and the workflow makes sense for the kind of work you're doing, there may be real value in it.
But build the workshop first.
Don't install the agent on your main machine and hope it behaves.
Don't give it access to every project you own.
Don't leave secrets sitting where it can read them.
Don't rely on "trust me" when you could rely on actual boundaries.
The vampire rule still applies.
Once you invite it in, the only things protecting you are the boundaries you built before you opened the door.
Where this comes from
This guide grew out of some planning I've been doing around how I'd use agentic coding safely. The more I thought about it, the clearer the real question became. It's not just whether ChatGPT or Claude can help write code. It's what kind of environment I'd be inviting an agent into when I let it act on my machine.
You can read the more personal side of that in the companion Field Note, Do Not Give the Agent the Keys to the Kingdom.
-- Charles