#coding-agents

A short post on a simple framework for AI-assisted coding, credited to an engineer on the author's team — brain, then AI, then brain — so engineers delegate implementation without letting their judgment atrophy.

The first "brain" step is understanding the problem well enough to judge the agent's output, since without it AI can steer toward the wrong problem entirely. The last step is making the work reviewable before it reaches anyone else: read the diff, question whether the complexity is earned, and write a real PR description. The rule of thumb is that if you can't explain what changed and why, it isn't ready for review.

Steve Yegge introduces Gas Town, an opinionated orchestrator for running 20-30 Claude Code instances at once, built on his Beads issue tracker. Coding agents are organized into seven roles (Mayor, Polecats, Refinery, Witness, Deacon, Dogs, Crew) that pick up persistent "molecule" workflows from a Git-backed queue, self-restart across crashes and context limits, and merge work through a dedicated queue — explicitly compared to Kubernetes and Temporal, but optimizing for task completion rather than uptime.

Hadley Wickham writes up a talk on his ambivalence about AI-assisted coding — the "software factory" dystopia of Steve Yegge's Gas Town versus using AI to write higher-quality code — and argues chat interfaces leave ~90% of an LLM's value on the table for programming, compared to giving it a harness to write, run, and iterate on code with a feedback loop of errors and docs.

Three months into AI-assisted development, the author finds the fatigue has shifted from wrestling with implementation details to constant architecture-level decision-making, since the AI is ready to implement whatever is chosen the moment it's chosen. Also flags a code-review blind spot: you can't interrogate an AI's reasoning after the fact the way you can ask a human collaborator why they made a choice.

Referenced in George Hotz's "I love LLMs, I hate hype" as a caution about AI-assisted coding increasing cognitive fatigue.

Argues AI progress is real and driven by Moore's law and general computing progress, not by frontier labs, whose anti-open-source arguments are read as fear of commodification rather than safety concerns. Pushes back on "singularity" hype as a distraction, while affirming coding agents give a genuine, if overstated, productivity boost.

Argues that "orchestrator" workflows in agentic coding create a paradox of supervision — effectively supervising an agent requires the very coding skills that atrophy from over-relying on it — and adds vendor lock-in and unpredictable token costs as compounding risks. Proposes demoting AI to a secondary role: use it for planning and research, but keep manually coding 20-100% of implementation and never generate more than can be reviewed in one sitting.

I love the line that a higher level of ambiguity is not a higher level of abstraction, and the Jeremy Howard quote at the end. It ties back to the "dark flow" article I have saved — Rachel Thomas's gambling-addiction parallel to vibe coding, the same slot-machine-lever feeling.

Hadley Wickham surveys why tightly-scoped tools don't scale for coding agents, and walks through three layers of protection — explicit permission prompts, OS-level sandboxing, and a secondary LLM safety review — explaining the tradeoffs and failure modes of each.

The current state of the art described here — sandbox by default, then LLM review for anything the sandbox rejects — is what Posit Assistant just implemented. The permission-prompt approach is dismissed as security theatre: approval fatigue means users click yes without scrutiny. The narrowly-scoped safe tool approach fails for a different reason: agents perform better with fewer, more general tools than a large menu of limited ones.