There Are Many Software Factories. This One Is Mine. And It’s Brutal.

It was February. I was fresh off what I can only describe—affectionately, and with the benefit of sleep—as Claude Opus-induced AI psychosis. The machines could write so much code, so quickly, that for a moment it felt as if the difficult part of software had been deleted.

Then I had to read the code.

On February 3, ReadySet published Michael Victor Zink’s “/brutal-review and the new 80/20 rule”. Its central provocation was simple: if an agent spends twenty million tokens producing a feature, be willing to spend eighty million more trying to prove that feature deserves to exist. Testing, safety, reduction, and adversarial review were no longer supporting work around implementation. They were the work.

That ratio felt absurd for approximately five seconds. Then it felt obvious.

I was already, in the terminally online phrasing, Bitter Lesson-pilled: when a general method can turn more computation into better results, throwing more compute at the problem has an irritating habit of beating the cleverer, hand-crafted alternative. The Brutal wager was a sideways application of that lesson. Do not spend all the compute producing a larger first draft. Spend most of it searching for failures—running tests, finding counterexamples, attacking assumptions, and repairing what the search exposes.

Code generation had collapsed the price of a first draft. It had not collapsed the price of knowing whether the draft was correct, coherent, maintainable, secure, or even necessary. If anything, cheap generation made those questions more expensive, because there was suddenly so much more code demanding an answer.

I made a skill called brutal-review. The instruction was not subtle: inspect the change from multiple perspectives, follow the evidence into adjacent code, and report what another agent—confident, fast, and occasionally deranged—had missed. It was less a code-review persona than an immune response.

The first commit landed on February 9 with Brutal review, project review, planning, and a task worker already present. Over the next nine days came parallel research, resume and context-loss protections, and code-reduction passes. That requirement to survive a forgotten context turned out to be a clue. I was no longer writing prompts. I was designing production machinery.

Generation is cheap. Judgment is the bottleneck.

Most “software factory” demos begin with throughput: many agents, many terminals, many pull requests. This is visually persuasive and operationally incomplete. A room full of power tools is not a factory. A factory has routing, isolation, quality control, inventory, ownership, gates, and a precise answer to what happens when one station poisons the next.

The first version of my workflow focused on making one agent work harder on one change. The current version focuses on making a whole chain of agents legible. It asks: What exactly is the task? Which decision authorized it? What other task blocks it? Which branch is its real base? Who owns the failure? What evidence makes it ready to merge? Where does the state live when the model forgets everything?

Those questions pushed the Brutal family upstream and downstream at the same time. Upstream, a feature needed grilling, research, a decision-complete specification, and small executable tickets. Downstream, every ticket needed an isolated worktree, its own branch, its own pull request, and review loops that could not quietly declare victory because a pass limit had expired.

This also changed what “autonomous” meant. Autonomy was not the absence of human involvement. It was the ability to continue safely between explicit human decisions. People approve the specification. People approve the ticket graph. People merge. Between those gates, the machinery can run hard.

The frame came from one direction. The missing front half came from another.

Factory.ai had already put the idea of a software factory in the back of my mind. Their Droid coding agent deserves a small, uncomplicated shout-out too: it is really good—fast, capable, and unusually pleasant to work with.

A couple of months ago, I came across Matt Pocock’s ninety-six-minute “Full Walkthrough: Workflow for AI Coding.” He started from a different end of the problem. Brutal had begun with distrust of generated code; Matt’s workflow began with distrust of ambiguous intent.

He demonstrated a human-in-the-loop grilling session to reach a shared design concept before implementation, then turned that understanding into a destination document, sliced it into vertical “tracer bullet” issues with explicit blocking relationships, and handed the resulting backlog to an AFK agent loop running on tight feedback cycles. The implementation could become autonomous because the alignment had not been.

I followed the video into his evolving Skills for Real Engineers repository and kept watching the newer ideas appear there. The lineage is obvious in brutal-grill and brutal-wayfinder: relentless requirements interrogation on one side, a durable map through work too large or uncertain for one agent session on the other. Decision-complete specifications, tracer-bullet tickets, expand-and-contract planning, and explicit fog-of-war work also entered the Brutal planning line through that encounter.

The provenance is messier than the machinery. I no longer remember which smaller idea came from which commit, video chapter, experiment, or late-night adaptation. Matt’s work supplied much of the vocabulary for the factory’s planning side; I bent it around the machinery already here: BRUTAL.md, provider-neutral work stores, exact ticket ownership, isolated worktrees, blocker-based pull-request chains, and hostile review until clean.

Before an agent can work fast, the work has to become boring.

An underspecified ticket is not freedom. It is a slot machine. Pull the lever and an agent will choose a product requirement, architecture, migration strategy, and definition of done on your behalf. Sometimes the result looks plausible enough to survive until production.

The planning line exists to remove those hidden bets. brutal-grill interrogates material decisions against the repository. brutal-spec turns the answers into a coherent implementation contract and attacks it for gaps. brutal-tickets then makes the smallest useful dependency graph—not atomized chores, not one heroic mega-ticket, but cohesive units with explicit inputs, outputs, blockers, and verification.

If the route is still obscured by research, access, prototypes, or decisions that cannot fit in one session, brutal-wayfinder refuses to counterfeit certainty. It records an investigation map and advances the frontier until real planning is possible.

There are two approval gates because “the plan sounds right” and “these are the tasks I am willing to unleash” are different decisions. Nothing is published into the worker intake queue until both have passed. The factory is fast partly because it is willing to wait at the right moments.

Parallelism without shared mutable chaos.

The swarm reads the dependency graph, asks for a concurrency limit, and starts the ready work. Independent roots run at the same time. Each worker gets one stable task reference and one isolated Git worktree. It cannot accidentally absorb a neighboring ticket simply because that code is nearby and tempting.

The worktree is more important than the terminal. Today the default launcher keeps each Codex worker in its own tmux session because retained sessions are inspectable, interruptible, and wonderfully boring. The same contract can run through native subagents. Tomorrow it could run somewhere else. A runtime is an adapter; filesystem and branch isolation are invariants.

Dependencies become stacked pull requests. If B has exactly one unfinished blocker, A, then B is branched from A and temporarily targets A’s branch. If C depends on B, the chain continues: main ← A ← B ← C. Reviewers see only the delta for the ticket in front of them, and downstream work can proceed without pretending its prerequisite has already merged.

Multiple blockers are different. There is no honest single base for a task that needs two unmerged branches, so the scheduler waits. That refusal matters. Much of robust orchestration is knowing which clever shortcut would turn provenance into soup.

One ticket, one owner, one branch, one worktree, one pull request. This is not the most token-efficient arrangement. It is the arrangement that leaves a trail when something goes wrong.

“Three passes” is a budget, not a definition of done.

The factory still has a bounded review loop for ordinary pull-request cleanup: review, fix, repeat, stop after three passes. Bounded loops are useful when you need predictable cost and a human is waiting nearby.

But the worker default is brutal-inf-fix-loop. It has no pass cap and no ceremonial “no progress” escape hatch. A full review produces provider-native, individually actionable findings. The fixer takes them one at a time. Then a fresh review begins against the new state. Completion means an all-severity pass returns zero findings.

Of course, “zero findings” is not proof of correctness. Review agents share blind spots, tests encode assumptions, and a loop can polish the wrong solution. The point is not mathematical certainty. The point is to make stopping conditions describe quality evidence rather than patience exhaustion.

Human merge remains the final irreversible move. A clean review does not close its own ticket. The agent can prepare the decision; it does not get to redefine the authority.

The repo tells the factory where it lives.

The skills stay portable by pushing integration details into a repository-local BRUTAL.md. It names the code host, work store, worker runtime, project rules, and verification commands. GitHub can pair with local Markdown, Linear, Gitlear, Jira, or a custom adapter.

This is configuration with consequences: it defines what agents may touch, how they claim work, where findings go, how blockers are represented, and what “verified” means. By June, that control plane had replaced the provider-specific workflows with one loop: a neutral work graph feeds isolated workers; workers feed stacked reviews; findings feed back into workers. The machinery travels. The repository keeps the rules.