I treat my AI coding agents as subcontractors

karavox · devlog I treat my AI coding agents as subcontractors 2026-08-14 · how I run software development Intro Since 2026 I started to develop software with AI agents, mostly for work. I started with one agent, then slowly evolved to more. I tried various approaches, but none really fit my work workflow. I distrust (frankly, I do not know the correct English word for this – it’s total distrust but with a full of curiosity and kind of expectation of good work) every agent. They make mistakes, I have to guardrail them with tokens, users and VMs. Nevertheless they proven to be useful at my work. My agents run in YOLO mode – no questions asked about editing files, committing, pushing, as they are responsible for their part. It started to work at work. Our team delivered working solutions. I was able to offload part of my workflow to a tool and focus on what’s important. It really worked… …and that led me to thinking about my pet project – something around Karaoke. I could code it by hand, but why not to use swarm of agents. With a lot of back and forth and with my low trust I ended up to treat them as subcontractors. I could take more risks with my own project. Why this shape I’m a solo developer with several agents working across a small ecosystem: an open-source format and toolkit, closed-source products around it, and the infrastructure that runs them all. The constraint that shapes everything is simple: I’m the bottleneck, and I’m also the only one with judgment. Agents can do a lot, but they have zero context about my incident history, my edge cases, or the operational constraints that don’t live in the repository. So the design goal is: agents may do as much as possible without me — but they can never touch anything I haven’t seen. Where this comes from This model didn’t start with me. It started with a post that gave the role a name: Simon Willison’s vibe engineering (2025-10-07) — the disciplined end of AI-assisted development, where a professional stays accountable for the software, against the fast-and-loose end of vibe coding. Willison’s own 2026 update notes the term that won out for this is Agentic Engineering. The readings that followed shaped the rest: Embracing the parallel coding agent lifestyle (Willison, 2025-10-05) — parallel agents with review bandwidth as the bottleneck; research/PoC tasks and carefully-specified work as the safe categories. How I’m using coding agents in September, 2025 (Jesse Vincent, 2025-10-05) — an architect/implementer split across isolated git worktrees, with a human playing PM between them. Best practices for using GitHub AI coding agents in production workflows? (GitHub Community, 2025-12-17) — “AI agents are powerful teammates, not autonomous committers”: agents propose code, never own it; draft PRs only; a human-in-the-loop merge contract. Layer 1 — the tokens: agents can’t write near production Every agent gets two tokens. A read-only token on the production repository, and a write token on a separate -staging repository. Task branches are cut directly from production’s main branch (read is enough for that) and pushed to the staging repository, which exists purely as a place the write token can reach. The staging repository’s default branch is a deliberate tombstone, literally named no-main, containing only a README: “please use main branch of the original repository.” Nothing ever merges into it. Nothing ever syncs it. It has no history, no mirror, no meaning beyond being the agents’ mailbox. Why not the standard tools? Because on the plan I’m on, they don’t exist: GitHub’s docs make protected branches available in public repositories on the free plan and in private repositories only from Pro up; forking a private repository into an organization also requires GitHub Team, not Free. Token scoping is the only mechanism that physically prevents an agent from touching production — so the design builds the guarantee out of tokens instead of settings. Layer 2 — integration: I am the merge bot When a branch is ready, the agent tells me. I fetch it, review the diff, and incorporate it however fits: cherry-pick, rebase-merge, or apply by hand. No pull request machinery, no merge commits written by agents, no PRs that sit unread while the queue backs up. This is an old pattern wearing new clothes. Git’s own documentation describes it as the integration-manager workflow: contributors without write access submit patches, and a maintainer applies them. That’s exactly what I do — my agents are patch contributors and the staging repository is their mailbox. It’s the model the Linux kernel has used for twenty years, just with branches instead of emailed diffs. One rule keeps this honest: a branch is never deleted until it’s independently verified to be inside production (git merge-base --is-ancestor against the production default branch, or the equivalent check if the commits were squashed). Checkable beats taken-on-word — including my own. Layer 3 — the PR policy: judgment, not dogma The public repository, karavox, is PR-only. That’s non-negotiable: it’s open source, it faces unknown contributors, and PRs are the contribution norm there. Private repositories are my judgment call. Why is that defensible? Because the review happens either way — the question is only which layer it happens at. In the PR model the review is ceremony enforced by GitHub; in my model the review is the integration itself. For a solo integrator who is also the QA, the pull request is overhead; the review is not. I never skip the review — I skip the ceremony. The vendors converge on the same principles. Claude Code’s security docs: in manual mode it starts with read-only permissions, and “you’re responsible for reviewing proposed code.” OpenAI’s Codex docs: sandboxed by default, with an approval policy — Codex must ask before it executes actions. GitHub’s own agentic workflow tool: agent jobs are read-only and sandboxed by default, and writes are applied through validated safe-outputs jobs with scoped permissions. GitHub’s own community guidance for AI coding agents puts it bluntly: “AI agents can propose code, never own it.” The industry is converging on my side of this argument — most of it just hasn’t gone as far as deleting the staging mirror. The war story: the model that died The tombstone wasn’t the first design. Originally the staging repository carried a full mirror of production on a branch literally named staging: task branches were cut from the mirror, merged into staging, and then promoted to production. The model required two things to stay in lockstep by convention — the mirror, and the staging branch itself. On 2026-08-14 it drifted for real: two branches landed straight on production main while staging sat two commits behind. The fix wasn’t hardening the sync. The fix was deleting the mirror. Task branches are now based directly on production’s own history, so there is nothing left to stay in lockstep. The staging repo became a tombstone the same afternoon, and the workflow has been simpler ever since. A governance model that dies in production is a good governance model — it proved it could be redesigned instead of patched. What others do instead Variant Trade-off vs my model Fork + pull request, maintainer merges GitHub’s docs: a fork is a separate repo with its own settings, connected to the upstream; a private repo can be forked to a personal account, but to an organization only on GitHub Team Branch protection + required reviews on the same repo GitHub’s docs: protected branches are free on public repos; private repos need Pro, Team or Enterprise Patch email (git format-patch) Git’s own book documents the integration-manager workflow: contributors without write access submit patches, a maintainer applies them Automated verifier-merge (agent writes, verifier merges) GitHub’s agentic workflow tool: agent jobs are read-only and sandboxed by default, with writes applied through validated safe-outputs jobs with scoped permissions What this buys me Agents do everything up to the point where judgment starts. I only spend attention where it matters — every integration is a review by definition. No PR queue to triage, no merge commits written by machines, no ceremony. The public repo keeps the contribution norm; the private repos keep the speed. Honest limitations Production main itself is protected only by token scoping plus my discipline — branch protection would be belt-and-braces, but it’s not available on the plan I’m on. And the industry signal is clear: more than one in five code reviews on GitHub now involves an agent. Judgment is the bottleneck, and this model is built around that fact rather than pretending the bottleneck doesn’t exist. Sources: GitHub docs — about protected branches and forks · Git Pro book — contributing to a project · Claude Code security docs · OpenAI Codex — agent approvals & security · GitHub Agentic Workflows (gh-aw) · GitHub Community: best practices for AI coding agents · GitHub blog: agent pull requests. ← devlog