Field notes
Know what leaves your repo
AI coding agents are useful, but once they can read a repo, run commands, see stack traces, and send context to a model, they become part of the data path.
I use AI coding agents because they remove real work: scaffolding, tests, refactors, and the occasional cursed debugging loop. But once an agent can read a repo, run commands, see stack traces, and send context to a model, it becomes part of the data path. Before it touches serious code, a team should be able to explain what the tool can read, what leaves the machine, what is retained, and when the work has to stay local. If that answer is vague, the tool may still be useful, but it is not safe by default.
Step 1: Classify the repo before choosing the agent
Most teams do this in the wrong order: They pick the shiny agent first, then invent the policy afterwards, even though the repo should come first.
For public code, demos, throwaway prototypes, and open source experiments, cloud agents are usually fine when the settings are sane. For internal business code and internal tools, the team should still use agents, but only with file exclusions, retention settings, visible context, and review. For auth, payments, pricing, customer-specific logic, regulated data, production logs, incident dumps, security code, and unreleased product work, the default should be local or self-hosted. If cloud use is still required, the approval should be explicit and the team should write down what is allowed to leave.
That is not a huge framework. It is just enough friction to stop people from treating every repo like a toy project.
Step 2: Separate the harness from the model
This is where I get annoying about tool ownership, because I do not want my coding workflow welded to one vendor bundle.
I want a harness I can control, whether that is OpenCode, pi.dev style tooling, Aider, Continue, Hermes, or whatever fits the job. The exact tool matters less than the architecture: Can I choose the model, point it at a local endpoint, switch providers without rebuilding my workflow, and keep sensitive repos away from cloud models?
If the answer is no, the tool may still be fine for some work, but at least I know the cage size. Owning the toolchain matters, and when that is not possible, the team should at least know which parts it does not own.
Step 3: Make exclusions real
Every coding-agent setup should block the obvious stuff: .env files, private keys, credentials, customer exports, production logs, pricing spreadsheets pretending to be harmless CSV, and internal strategy docs that somehow ended up next to the code because teams are like that.
After that, test the exclusions instead of admiring the setting. Ask the agent to read a blocked file, trigger a failing test that prints something sensitive, paste a stack trace, and run the workflow that people will actually run when they are tired and trying to ship.
If the exclusion fails, the team learned something useful before it became an incident.
Step 4: Treat failure loops as the risk
The first prompt is rarely the scary part. The loop is: The agent edits, the test fails, the agent reads the error, asks for logs, opens another file, sees another test fail, and slowly pulls in more output, more context, and more guesses.
That loop is also where much of the value is, because debugging needs context. The answer is not to ban it, but to decide in advance what terminal output can be shared, whether production logs are allowed, whether stack traces from real systems are allowed, and what happens when the agent asks for a file it should not read.
If nobody has decided any of that, the agent will decide it during the run. I am not a fan of that management model.
Step 5: Keep review boring too
An agent is not a senior engineer. It is a fast worker with no memory of consequences and a gift for sounding reasonable.
The normal controls still matter: tests, branch protection, diff review, secret scanning, dependency review, local runs for sensitive code, and audit logs where the tool supports them. If the change touches auth, payments, security, data export, permissions, or customer data, the agent's confidence should never become the review.
Confidence is cheap, and incidents are not.
The rule
The setup I want is not complicated: model routing by repo sensitivity, local or self-hosted inference for sensitive repos, cloud models where the risk fits, tested exclusions, clean logs, and human review before merge.
This is less magical than the vendor demo, which is part of the point. Magic is usually where the lock-in hides.
Use the agents, but know what they can read, what they sent, where it went, and how to stop it next time. If you cannot answer that, do not wrap the uncertainty in an enterprise subscription and call it strategy.