The Short Leash AI Method

Coding agents go rogue when you give them too much autonomy. Here is a different approach.

Coding agents have a habit of going rogue. They promise to refactor a whole module, delete three necessary imports, and then get stuck in a loop trying to import them back. I have spent the last few weeks testing a different approach: the short leash method.

Instead of giving an agent full autonomy over a repository, you treat it like a very enthusiastic intern who is not allowed to touch the front door. You give it one specific file, a clear goal, and zero permission to run anything that changes the state of the system without an explicit go-ahead.

This sounds like more work for the human, but it is actually faster. When an agent is on a long leash, it makes mistakes that take ten minutes to debug. When it is on a short leash, it makes mistakes that take ten seconds to catch. The goal is to maximize the time the agent spends writing code and minimize the time it spends "thinking" about how to fix its own errors.

One trick I found is to limit the number of files an agent can see. If I give an agent access to every file in a project, it usually decides the architecture is wrong and tries to "fix" it. If I give it only the file it is working on, it stays focused. It is less "smart" in the abstract sense, but it is much more productive in the concrete sense.

I also stopped letting agents execute shell commands. Every shell command needs a manual review. If I want to run a test, I run the test. I do not ask the agent to run the test because the agent will then try to debug the test failure instead of the code.

The verdict is simple: autonomy is overrated. I want a tool that writes the boring parts of the function and then gets out of the way. If the tool thinks it is the architect, we are both going to have a bad time.