I treat my AI coding agents as subcontractors — karavox devlog
karavox · devlog
I treat my AI coding agents<br>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<br>one agent, then slowly evolved to more. I tried various approaches, but none really fit<br>my work workflow.
I distrust (frankly, I do not know the correct English word for this – it’s total distrust<br>but with a full of curiosity and kind of expectation of good work) every agent. They make mistakes,<br>I have to guardrail them with tokens, users and VMs. Nevertheless they proven to be useful at my work.<br>My agents run in YOLO mode – no questions asked about editing files, committing, pushing, as they are<br>responsible for their part.
It started to work at work. Our team delivered working solutions. I was able to offload<br>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<br>hand, but why not to use swarm of agents. With a lot of back and forth and with my low<br>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<br>format and toolkit, closed-source products around it, and the infrastructure that runs<br>them all. The constraint that shapes everything is simple: I’m the bottleneck, and I’m<br>also the only one with judgment. Agents can do a lot, but they have zero context about<br>my incident history, my edge cases, or the operational constraints that don’t live in the<br>repository. So the design goal is: agents may do as much as possible without me — but they<br>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:<br>Simon Willison’s vibe engineering<br>(2025-10-07) — the disciplined end of AI-assisted development, where a professional<br>stays accountable for the software, against the fast-and-loose end of vibe coding.<br>Willison’s own 2026 update notes the term that won out for this is<br>Agentic Engineering. The<br>readings that followed shaped the rest:
Embracing the parallel coding agent lifestyle<br>(Willison, 2025-10-05) — parallel agents with review bandwidth as the bottleneck;<br>research/PoC tasks and carefully-specified work as the safe categories.
How I’m using coding agents in September, 2025<br>(Jesse Vincent, 2025-10-05) — an architect/implementer split across isolated git<br>worktrees, with a human playing PM between them.
Best practices for using GitHub AI coding agents in production workflows?<br>(GitHub Community, 2025-12-17) — “AI agents are powerful teammates, not autonomous<br>committers”: agents propose code, never own it; draft PRs only; a human-in-the-loop<br>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<br>write token on a separate -staging repository. Task branches are cut<br>directly from production’s main branch (read is enough for that) and pushed to the staging<br>repository, which exists purely as a place the write token can reach.
The staging repository’s default branch is a deliberate tombstone, literally named<br>no-main, containing only a README: “please use main branch of the original<br>repository.” Nothing ever merges into it. Nothing ever syncs it. It has no history, no<br>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<br>docs<br>make protected branches available in public repositories on the free plan and in<br>private repositories only from Pro up; forking a private repository into an<br>organization<br>also requires GitHub Team, not Free. Token scoping is the only<br>mechanism that physically prevents an agent from touching production — so the design<br>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<br>it however fits: cherry-pick, rebase-merge, or apply by hand. No pull request machinery,<br>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<br>integration-manager workflow : contributors without write access submit patches, and<br>a maintainer applies them. That’s exactly what I do — my agents are patch contributors and<br>the staging repository is their mailbox. It’s the model the Linux kernel has used for<br>twenty years, just with branches instead of emailed diffs.
One rule keeps this honest: a branch is never deleted until it’s...