{"slug": "i-treat-my-ai-coding-agents-as-subcontractors", "title": "I treat my AI coding agents as subcontractors", "summary": "A solo developer describes treating AI coding agents as subcontractors in a workflow where agents operate in YOLO mode with two tokens: a read-only token on the production repository and a write token on a separate staging repository with a tombstone default branch named 'no-main'. The approach, inspired by Simon Willison's 'vibe engineering' and 'Agentic Engineering' concepts, aims to let agents do as much as possible without human intervention while ensuring they never touch anything the developer hasn't seen.", "body_md": "## Intro\n\nSince 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.\n\nI 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.\n\nIt 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…\n\n…and that led me to thinking about my pet project – something around Karaoke. I could code it by\nhand, but why not to use swarm of agents. With a lot of back and forth and with my low\ntrust I ended up to treat them as **subcontractors**. I could take more risks with my own project.\n\n## Why this shape\n\nI’m a solo developer with several agents working across a small ecosystem: an open-source\nformat and toolkit, closed-source products around it, and the infrastructure that runs\nthem all. The constraint that shapes everything is simple: **I’m the bottleneck, and I’m\nalso the only one with judgment.** Agents can do a lot, but they have zero context about\nmy incident history, my edge cases, or the operational constraints that don’t live in the\nrepository. So the design goal is: agents may do as much as possible without me — but they\ncan never touch anything I haven’t seen.\n\n## Where this comes from\n\nThis model didn’t start with me. It started with a post that gave the role a name:\nSimon Willison’s [vibe engineering](https://simonwillison.net/2025/Oct/7/vibe-engineering/)\n(2025-10-07) — the disciplined end of AI-assisted development, where a professional\nstays accountable for the software, against the fast-and-loose end of vibe coding.\nWillison’s own 2026 update notes the term that won out for this is\n[Agentic Engineering](https://simonwillison.net/tags/agentic-engineering/). The\nreadings that followed shaped the rest:\n\n[Embracing the parallel coding agent lifestyle](https://simonwillison.net/2025/Oct/5/parallel-coding-agents/)(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](https://blog.fsck.com/2025/10/05/how-im-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?](https://github.com/orgs/community/discussions/182197)(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.\n\n## Layer 1 — the tokens: agents can’t write near production\n\nEvery agent gets two tokens. A **read-only** token on the production repository, and a\n**write** token on a separate `-staging`\n\nrepository. Task branches are cut\ndirectly from production’s main branch (read is enough for that) and pushed to the staging\nrepository, which exists purely as a place the write token can reach.\n\nThe staging repository’s default branch is a deliberate tombstone, literally named\n`no-main`\n\n, containing only a README: “please use main branch of the original\nrepository.” Nothing ever merges into it. Nothing ever syncs it. It has no history, no\nmirror, no meaning beyond being the agents’ mailbox.\n\nWhy not the standard tools? Because on the plan I’m on, they don’t exist: [GitHub’s\ndocs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)\nmake protected branches available in public repositories on the free plan and in\nprivate repositories only from Pro up; [forking a private repository into an\norganization](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)\nalso requires GitHub Team, not Free. Token scoping is the only\nmechanism that physically prevents an agent from touching production — so the design\nbuilds the guarantee out of tokens instead of settings.\n\n## Layer 2 — integration: I am the merge bot\n\nWhen 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.\n\nThis is an old pattern wearing new clothes. Git’s own documentation describes it as the\n**integration-manager workflow**: contributors without write access submit patches, and\na maintainer applies them. That’s exactly what I do — my agents are patch contributors and\nthe staging repository is their mailbox. It’s the model the Linux kernel has used for\ntwenty years, just with branches instead of emailed diffs.\n\nOne rule keeps this honest: a branch is never deleted until it’s independently verified to\nbe inside production (`git merge-base --is-ancestor`\n\nagainst the production\ndefault branch, or the equivalent check if the commits were squashed). Checkable beats\ntaken-on-word — including my own.\n\n## Layer 3 — the PR policy: judgment, not dogma\n\nThe public repository, `karavox`\n\n, is PR-only. That’s non-negotiable: it’s open\nsource, it faces unknown contributors, and PRs are the contribution norm there.\n\nPrivate 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.\n\nThe vendors converge on the same principles. [Claude Code’s security\ndocs](https://code.claude.com/docs/en/security): in manual mode it starts with read-only\npermissions, and “you’re responsible for reviewing proposed code.” [OpenAI’s Codex\ndocs](https://learn.chatgpt.com/docs/agent-approvals-security): sandboxed by default,\nwith an approval policy — Codex must ask before it executes actions. [GitHub’s own\nagentic workflow tool](https://github.com/github/gh-aw): agent jobs are read-only and\nsandboxed by default, and writes are applied through validated `safe-outputs`\n\njobs with\nscoped permissions. GitHub’s own [community guidance for AI coding\nagents](https://github.com/orgs/community/discussions/182197) puts it bluntly: “AI\nagents can propose code, never own it.” The industry is converging on my side of this\nargument —\nmost of it just hasn’t gone as far as deleting the staging mirror.\n\n## The war story: the model that died\n\nThe tombstone wasn’t the first design. Originally the staging repository carried a full\nmirror of production on a branch literally named `staging`\n\n: task branches were\ncut from the mirror, merged into staging, and then promoted to production. The model\nrequired two things to stay in lockstep by convention — the mirror, and the staging\nbranch itself. On 2026-08-14 it drifted for real: two branches landed straight on\nproduction main while staging sat two commits behind.\n\nThe 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.\n\n## What others do instead\n\n| Variant | Trade-off vs my model |\n|---|---|\n| Fork + pull request, maintainer merges |\n|\n\n[GitHub’s docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches): protected branches are free on public repos; private repos need Pro, Team or Enterprise`git format-patch`\n\n)[Git’s own book](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project)documents the integration-manager workflow: contributors without write access submit patches, a maintainer applies them[GitHub’s agentic workflow tool](https://github.com/github/gh-aw): agent jobs are read-only and sandboxed by default, with writes applied through validated`safe-outputs`\n\njobs with scoped permissions## What this buys me\n\n- Agents do everything up to the point where judgment starts.\n- I only spend attention where it matters — every integration is a review by definition.\n- No PR queue to triage, no merge commits written by machines, no ceremony.\n- The public repo keeps the contribution norm; the private repos keep the speed.\n\n## Honest limitations\n\nProduction main itself is protected only by token scoping plus my discipline — branch\nprotection would be belt-and-braces, but it’s not available on the plan I’m on. And the\nindustry signal is clear: [more than one in five code reviews on GitHub now involves an\nagent](https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/).\nJudgment is the bottleneck, and this model is built around that fact rather than\npretending the bottleneck doesn’t exist.\n\n**Sources:** GitHub docs — [about protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)\nand [forks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks) ·\nGit Pro book — [contributing to a project](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) ·\n[Claude Code security docs](https://code.claude.com/docs/en/security) ·\n[OpenAI Codex — agent approvals & security](https://learn.chatgpt.com/docs/agent-approvals-security) ·\n[GitHub Agentic Workflows (gh-aw)](https://github.com/github/gh-aw) ·\n[GitHub Community: best practices for AI coding agents](https://github.com/orgs/community/discussions/182197) ·\n[GitHub blog: agent pull requests](https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/).", "url": "https://wpnews.pro/news/i-treat-my-ai-coding-agents-as-subcontractors", "canonical_source": "https://karavox.org/devlog/agents-as-subcontractors.html", "published_at": "2026-08-19 13:02:43+00:00", "updated_at": "2026-08-19 13:14:42.718404+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["Simon Willison", "Jesse Vincent", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/i-treat-my-ai-coding-agents-as-subcontractors", "markdown": "https://wpnews.pro/news/i-treat-my-ai-coding-agents-as-subcontractors.md", "text": "https://wpnews.pro/news/i-treat-my-ai-coding-agents-as-subcontractors.txt", "jsonld": "https://wpnews.pro/news/i-treat-my-ai-coding-agents-as-subcontractors.jsonld"}}