Why I Stopped Treating AI Coding Agents Like Employees and Started Treating Them Like Subcontractors
Let me tell you about the moment I realized I needed to change how I worked with AI coding agents.
I was three hours into debugging a "simple" feature one of my agents had written. The agent had confidently committed changes, pushed to production, and even left a cheerful message about completing the task. There was just one problem: the code was completely wrong. Not buggy—fundamentally misunderstanding what we were trying to build.
That incident broke something in my mental model. I had been thinking about these agents as helpful junior developers who needed guidance. But junior developers don't ship untested code to production while you're sleeping.
So I changed the metaphor entirely.
The Subcontractor Framework
Instead of treating AI agents like employees or assistants, I now treat them like subcontractors. Here's what that means in practice:
A subcontractor doesn't have keys to your building. They don't show up uninvited. They complete their scope of work and submit an invoice—which you review before paying. If their work is substandard, you send it back.
This isn't about distrust. It's about alignment of incentives and accountability. When a subcontractor understands their role is to deliver a completed artifact for your review—not to make unilateral decisions—they perform better. They're focused. They're productive within boundaries.
The Technical Layer
This mental model needs technical teeth. For my projects, that means:
Token Scoping is Everything
My agents operate with scoped credentials that physically cannot touch production. They have read access to the main codebase and write access to a separate staging repository. That's not a policy—it's a cryptographic constraint. Even if an agent goes rogue or produces hallucinated git commands, it cannot modify production code. The tokens won't allow it.
The Staging Repository is a Mailbox
Nothing merges from staging automatically. The staging repo's default branch is literally a tombstone—a branch named "no-main" that contains only a README saying "please use the main branch of the original repository."
Agents push their completed work here. They message me when branches are ready. Then I review, cherry-pick what works, and integrate it manually. This feels tedious until you realize: this is exactly how the Linux kernel has worked for twenty years. Contributors submit patches. Maintainers apply them.
Review is Non-Negotiable
No agent ever merges their own code. Full stop. A branch doesn't get deleted until I've verified—independently, programmatically—that its commits are safely inside production. "Trust but verify" isn't enough when verification is free.
Why This Works for Solo Developers
Here's the thing about being a solo developer or small team: you're not just building software. You're maintaining context that exists nowhere in the codebase. Your incident history. Your edge cases. The customer who has a weird configuration. The three things you tried that didn't work.
Agents have zero access to this context. They read files, but they don't understand your world. So the goal isn't to give them more autonomy—it's to maximize the work they can do safely within your review bandwidth.
This is where "vibe coding" gets a bad reputation. Done wrong, vibe coding means letting agents do whatever and hoping it works. Done right, it means using AI as a force multiplier for your judgment, not a replacement for it.
The Practical Upside
Once you accept the contractor relationship, something unexpected happens: you take more risks. You're willing to spin up that experimental feature because the downside is bounded. The agent can't break production. They can deliver something surprising and wrong, or something surprisingly good—but either way, you catch it before it matters.
I've started more side projects in the past six months than in the previous two years. Not because I'm working harder—because I'm delegating aggressively within safe boundaries.
Building This Into Your Workflow
If you're using AI agents for development, ask yourself:
- What can my agent touch right now? If the answer is "production," that's a problem.
- Is there a technical constraint preventing wrong actions, or just a policy?
- Who merges code? If it's not a human, why not?
The tools exist. Token scoping, separate staging repos, branch protection—these aren't exotic Git workflows. They're the difference between AI-assisted development and AI-accidental disasters.
At NameOcean, we're thinking about this a lot as we build out vibe coding support in our hosting environment. The goal isn't to automate everything—it's to create spaces where AI can be genuinely useful without creating new categories of risk.
Your judgment is still the bottleneck. That's not a limitation—that's the point. The agents exist to amplify what you can do, not to replace the judgment that makes software actually work for real users.
Build accordingly.