The Software
Factory.

From terminal to factory.

Five stages, all of which we actually ran. Not a tidy after-the-fact framework, just what happens when a small team keeps pushing AI agents to carry real weight, and the setup keeps reshaping itself underneath.

01 · The pair programmer

One terminal, one developer, one Claude session. A nicer grep, a faster typist, a rubber duck that talks back. You get more done, but the way you build hasn't changed. You're still in the middle of every step. No build cycle yet, just a useful conversation.

02 · The workshop

tmux. Four panes, four Claude sessions, four things at once. You hop between them, kick off a task here, read a report there. Each pane is still pair-programming, just in parallel. The bottleneck shifts from Claude's typing speed to your attention. Real upgrade, but not the moment things change.

03 · The wire

tmux can pipe a keystroke from one pane into another. tmux send-keys -t pane-B "<message>" Enter. With that, sessions can talk, and a small operator script can relay between them. You can walk away for a few minutes and come back to find work has happened. The agents don't know they're talking to each other, but you've stitched a crude nervous system between them. First stage where the keyboard isn't load-bearing.

04 · The org chart

Claude agent teams arrive: shared task lists, agents addressable by name, scoped permissions, lifecycle events. SendMessage replaces send-keys. The lead and specialists know they're on a team. The org chart shows up inside the software: a chief architect with seven specialists, a VP of engineering with six leads. The team metaphor stops being a metaphor.

05 · The factory

The dev loop. Lead, Generator, Validator, each in a fresh context window, with different incentives, hard scope limits, negotiated plan rounds, verdicts written to disk, and a diff check after every task. The human is gone from the build cycle for hours at a time. The agents aren't assisting; they're doing the work. The loop lives on a remote machine over Tailscale, pinned inside a long-lived tmux session. I close my laptop, get in the car, and the loop keeps going. By the time I arrive, three features have moved forward two iterations each. What's left for me are the calls only I can make.

The agents code while I travel. That used to be a joke. Now it's how the day works.

Inside the factory.

What we run in this repo to ship features into Nexentra. Three roles, one reward function each, tightly scoped. State lives on disk under .claude/loop-state/: plan, approved plan, current task, manifest, generator reports, history. If you can't see it in a file, it isn't real. Stop a loop, walk away, pick it up later exactly where it was. When something goes weird, the trail is right there.

Only the Lead sticks around. Everyone else gets spawned fresh, with clean context and no memory of last round, and shuts down when their task is done. If you take one thing from this whole document, take that. It's the choice that holds everything else up.

Why we built it.

The loop wasn't designed on a whiteboard. It grew out of four ways ad-hoc agent use kept burning us. Any one is survivable. Stack them for a few weeks and the difference is between a platform that ships and one that quietly rots.

How it accelerates.

Speed comes from doing small things consistently, not raw throughput. Every feature goes through the same five phases, in order, with real gates between them. Fail a gate and the loop stops. Being a few hours in doesn't buy a pass.

The same .feature file runs at localhost:3001 and against app.dev.nexentra.ai. One suite, two environments. Auth and seed differences live in helpers, not duplicate tests. After each task, the Validator runs a diff check; touch a file outside the approved list and the build fails.

One more rule. If a plan touches domain data and proposes REST instead of an agent tool, it needs an explicit ADR-0066 exception block. Nexentra is agent-first, and "REST by default" doesn't ship here. The loop catches it before architecture review ever has to.

Files as the loop's memory.

The Lead never hands a task to the Generator through agent context. The Validator never returns a verdict through agent context. Every message in the loop is a file on disk. Sounds like a small detail. It's what the rest of the loop is bolted to. Take it out and nothing else survives a working week.

.claude/loop-state/
├── plan.md           + plan.html      ← dual-format: machine + human
├── plan-approved.md                  ← immutable post-negotiation snapshot
├── plan-review-N.md                  ← Validator's adversarial critiques
├── current-task.md                   ← Lead → Generator handover
├── <task-id>-generator-report.md     ← Generator → Lead
├── <task-id>-validator-report.md     ← Validator → Lead
├── manifest.json                     ← state machine: status · phase · iter · budget
├── evals/
│   ├── <feature>-e2e.yaml             ← Playwright scenarios
│   └── <feature>-llm.yaml             ← LLM-as-judge rubrics
└── history/                          ← every prior round, archived

The Lead writes, subagents read. Handover is one file, current-task.md, with task ID, mode, allowed files, acceptance criteria, and a pointer to plan-approved.md. The Generator spawns, reads, works, writes a report, exits. The Validator does the same in reverse: reads the report and the diff, writes a verdict, exits. The Lead persists; between iterations its only job is to read reports and write the next task.

A handful of nice things fall out of that. None clever, none needing new infrastructure. Together they're why the substrate is the part of the loop I'd lose last.

THE READING LAYER / DUAL FORMAT How the human actually reads it.

Every plan, spec, and design ships in two formats: plan.md for the loop, plan.html for whoever is reading. The HTML version gets the same treatment as this page: inline diagrams, real tables, visual hierarchy, color-coded sections.

This is Tariq's argument in HTML Effectiveness: "diffs and call-graphs are spatial information; markdown flattens them." A 1,500-line markdown plan gets skimmed. The same content as a real document, with the diagram on the page and criteria in a table, gets read.

The week we shipped this, plan reviews got measurably better. Fewer clarifying questions, sharper critiques, faster PLAN-APPROVED.

Plans on disk, rendered as HTML, reviewed by a fresh-context Validator is what turned the loop from experiment into something we rely on. The filesystem is how the loop remembers; the HTML is how the human reads. Both were retrofits. Both changed everything downstream.

Why it actually works.

A few things that look like minor details are actually why this works. Not features, but load-bearing decisions. Pull any one and the setup slides back to "agents wandering with good intentions."

FORCING FUNCTION 01 / DEBATE The two-actor adversarial plan review.

The Lead drafts a plan. The Validator, fresh context, no skin in the reasoning, tears into it. The Lead revises. Up to five rounds. A plan review, before any code exists.

Soft spots show up fast. Vague acceptance criteria are the easiest target, so they go first; the Lead either makes them machine-checkable or drops them. By round three, the weak parts of the plan have been named out loud. Not consensus, something better: a plan where everyone knows where the risk lives.

And it's cheap. Critique costs token-pennies; catching the same mistake during implementation costs a re-spawn, a re-deploy, half an evening. Same instinct as the Devil's Advocate gate in ADR-0064: to make an LLM usefully disagree with itself, put a different LLM in the room.

FORCING FUNCTION 02 / QUOTA Finite resource budgets.

Every loop has a wall-clock budget. Plan negotiation gets five rounds, hard cap. Every Generator task has a declared file list it can't exceed. Every Validator verdict has to land. No "needs further investigation" unless someone explicitly re-dispatches. Quotas are the loop's anti-bikeshedding immune system.

Without them, plan negotiation drifts toward perfectionism, scope quietly grows, and Validators hedge. With them, round five is the end (real disagreements escalate to a human), scope growth means escalating in writing, and hedging is just banned. When in doubt, FAIL.

The constraint is where the discipline comes from. "Engineering judgment" is empty without a budget. With one, it becomes a real trade-off, which is what engineering actually is.

FORCING FUNCTION 03 / FRESHNESS Disposable subagents, by design.

Long-running agents rot. They hold onto wrong hypotheses, hedge against bugs that no longer exist, defend yesterday's mistakes. Context-rot is what kills long agent sessions. So Generator and Validator spawn fresh every task, with no memory of the last round's bad guess. Read the task file, do the work, exit.

Three things follow. Reasoning stays clean: each task is first-principles against the current code, not last week's mythology. Reports become the system of record: the Lead is the only persistent thing, so cross-task messages are written down and become the audit trail. And failure stays local: a bad run can't poison the next. The Lead reads the failure report, writes a debug task, spawns a fresh Generator. Clean slate, every time.

Disposable on principle, not convenience. That's why the loop can run for hours unattended: nothing builds up in the corners.

FORCING FUNCTION 04 / DETERMINISM TDD RED-first.

The most expensive bug in agentic dev is the green-when-it-shouldn't-be test. The agent writes the implementation, then writes a test that asserts what the implementation already does. Test passes. Build is green. Bug ships. We make that impossible by writing tests first and checking they're RED before any implementation is dispatched.

So Phase 1 produces, in order: tests/e2e/features/<feature>.feature (Gherkin scenarios), tests/e2e/steps/<feature>.ts (step defs), .claude/loop-state/evals/<feature>-e2e.yaml (Playwright criteria), and .claude/loop-state/evals/<feature>-llm.yaml (LLM-as-judge rubrics). The Validator runs both modes, localhost:3001 and app.dev.nexentra.ai, and confirms every scenario fails. Only then does the implementation plan get approved. Acceptance criteria aren't prose, they're code. The Lead doesn't say "this works." The test runner says it.

A few things fall out. The Validator's verdict is binary, grounded in real execution. LLM-as-judge is still in the loop for agent-quality scoring, but functional correctness is decided by Playwright clicking buttons and Python asserting against DynamoDB rows, SPARQL results, and pgvector retrievals. The plan and the test become the same artifact: a vague acceptance criterion can't survive being turned into Gherkin. And false positives stop being possible by construction.

Determinism wrapped around LLM reasoning. The agents are creative inside a bounded space; the test suite is the boundary. Where an unbounded LLM drifts, a RED test pulls it back to one binary answer: is the scenario passing or not? Without RED-first, verdicts are confident but uncalibrated. With it, they're reproducible.

Anthropic's framework, recognized in the wild.

The dev loop is built out of patterns Claude is already good at. We didn't invent these. What's ours is the wiring: one build cycle for actual product software.

A specific lineage is worth naming. Anthropic's Building effective agents lays out five workflow patterns and one agent pattern the industry's been converging on. Tariq flagged this lineage recently. Read it against our setup and the resemblance isn't subtle: the dev loop is a tight composition of three of those patterns.

From the outside, the Lead is Anthropic's autonomous agent: a long-running LLM that plans, dispatches, observes, re-plans, with human checkpoints at the moments that matter (where I show up). From the inside, it's orchestrator-workers: break the feature into bounded tasks, delegate each to a fresh worker, roll the reports back into planning. The plan-negotiate phase is textbook evaluator-optimizer: Lead drafts, Validator critiques, Lead revises, with a 5-round quota.

Naming it this way stops it feeling like our weird thing. The dev loop is what naturally happens when you apply Anthropic's patterns to a real build cycle. Workflow rigor on the outside, agent flexibility on the inside. Hybrid by design, not by accident.

Finding the framework was a relief. We'd been calling it "a multi-agent thing" for months, which doesn't tell anyone much. The paper is quiet on state: how the orchestrator remembers, how verdicts persist, how the loop survives a crash. That's the filesystem in §05. It's what turns a research framework into something you can leave running overnight.

THE BROADER LINEAGE Other patterns the loop borrows.

Beyond those three, the loop leans on a wider set of agentic-LLM patterns. Each is a deliberate choice.

Bounded by a written rulebook.

The autonomy is real. It's also not unbounded. The loop runs inside a thick, versioned, machine-readable rulebook, and every actor reads from it at planning and validation time. That's how you govern human engineers: written rules, applied consistently. Turns out it's how you govern AI engineers too.

Here's the actual stack, from highest authority to most local, with notes on who reads what.

HOW THE RULES ENTER THE DECISION Cited, not improvised.

The Lead reads the relevant layers during PLAN-DRAFT. The Validator reads the same layers when writing a verdict. Both quote from the rulebook, not improvise. When the Lead proposes a new REST surface, the Validator doesn't say "this feels wrong." It says "this violates ADR-0066; missing the required EXCEPTION subsection." Disagreements get resolved by pointing at written rules.

When a rule is missing or ambiguous, the loop doesn't guess. It surfaces the gap via AskUserQuestion and waits. That escalation is itself a rule, written into the Lead's charter.

SCOPED AUTONOMY What the rulebook actually does.

Unbounded autonomy in a financial-services repo is a non-starter. The rulebook scopes the loop's autonomy: plan, build, deploy, verify within written boundaries; escalate the moment a decision lives outside them. Same as how we govern human engineers: written, reviewed, versioned. The twist is that the agents read the rules more carefully, because they're required to cite them.

Rules aren't constraints, they're the institutional knowledge that makes autonomy defensible. Not "unleashed AI." Scope-bounded AI. Rules are first-class artifacts: they get PRs, they get reviewed, they ship.

Autonomy is what the loop has. The rulebook is what scopes it. Together they make it usable in a regulated codebase.

Trusted as engineers.

Most orgs can't bring themselves to give coding agents production-grade access. The "AI as autocomplete" framing is part brand, part real trust constraint. The sandbox stays because the consequences of letting them out feel unbounded. We took the other bet. Inside the dev loop, the agents have the access a junior engineer has on day one: scoped AWS credentials, deploy to dev, CloudWatch, database reads, GitHub push, ECS spawn, ECR push. Not assistants. Engineers, treated like engineers.

THE RELUCTANCE Why organizations stop at Tier 2.

The ceiling on trust is rarely technical, it's institutional. Handing an LLM AWS credentials feels different from handing them to a new hire, even when the scope is identical and the audit trail is better. Four honest fears: bad code, leaked credentials, runaway spend, destructive calls. Each has a defensible answer inside the dev loop, the same answers you'd give for a junior engineer. Most orgs just haven't built the muscle to give them to an agent.

WHAT MAKES IT SAFE The discipline that earns the access.

The same discipline that makes the loop converge also makes the trust safe. The Lead can't write code, so bad code only lands via a Generator report the Validator has to clear. The Validator fails closed. The wall-clock budget caps AWS spend. Every API call traces back to a task ID, iteration, and generator report. Loop state on disk means tampering shows up on the next read. Every capability has a matching constraint that earned it.

The agents end up more traceable than a human engineer. Every command, read, and write lives in a file that outlives the session. The trust isn't blind, it's instrumented.

WHAT WE STILL DO NOT GRANT Honest boundaries.

A lot, but not everything. Production deploys need human approval. The Lead proposes, a person merges to main and triggers the pipeline. Customer data isn't reachable from the dev loop; even staging runs on synthetic seed. Secrets rotation and new IAM roles are human-only. Spending past the per-loop budget needs human override. Same boundaries we'd put around a junior engineer in their first six months. The agents are engineers, just not senior staff. Yet.

THE KEYBOARD-LESS MOVE Speaking to my developer.

The last "I'm operating a tool" instinct lives in the keyboard. As long as you're typing commands, part of your brain treats the agent like a system to be driven. So I stopped. Whisperflow takes my voice and turns it into a prompt: laptop open, lid closed, walking to coffee, on a call between meetings. The Lead turns spoken intent into plan drafts and tasks.

Talking to a colleague is different from typing at a tool. Inflection lands, context comes naturally, you think out loud. After a week, the agent stops feeling like something you operate and starts feeling like someone you work with. Real access is half the shift; talking to it is the other half. "My tool" becomes "my developer," and you don't go back.

Not a tool you supervise. An engineer you trust, given real access, kept honest by real discipline, talked to like a person. Once you cross that line, the question stops being "can we trust this?" and starts being "what's next?"

The self-hosted engineer.

There's a machine in a room. It's on right now. It doesn't sleep, doesn't stop when I close my laptop, doesn't care where I am. A real engineer has a workstation; this one has the same. The trust, the rulebook, the substrate, the forcing functions all have to run somewhere. The hardware is the part most people skip, and it's what makes "self-hosted" literal instead of a metaphor.

THE THREE LAYERS What the workstation actually is.

The machine: a Mac. A Mini, any Mac with enough RAM works. Always plugged in, same dev tooling our team uses, same runtime, same architecture. A build that works here works on every developer's Mac. No special hosted environment, no sandbox hiding bugs the team would hit. The agent develops in the same conditions its work has to land in.

The network: Tailscale. Mesh VPN with identity built in. No public exposure, no port forwarding. The Mac is reachable from every device I own and nowhere else. Per-device auth, one-click revoke. Same posture as a sensitive jumpbox at a hedge fund: private subnet, identity-bound, audited at the edge.

The session: tmux. A long-running multi-pane session that survives ssh drops, sleep cycles, restarts, Wi-Fi changes, cellular handoffs. Lead in one pane. Live monitor (CloudWatch tail + manifest.json) in another. Break-glass shell in a third. Reconnect from anywhere and the cursor is exactly where you left it. tmux turns continuity from a wish into a property.

WHAT THIS MEANS IN PRACTICE The travel story, literally.

The travel story is what a Tuesday looks like. Laptop in Houston, ssh into the Mac, the loop is mid-iteration. Validator FAILed PR #437 fifteen minutes ago. Dictate a re-plan over Whisperflow. Lead writes the next task. Close the laptop, get in the car, drive to Austin. Three hours later I'm at a gas station off I-10, open my laptop, ssh in: two more PRs shipped to dev. By the time I roll into Austin, three features have each moved forward two iterations. The workstation never stopped.

This is what "AI software engineer" at full strength means. Not a chatbot you ping. Not an assistant idle until prompted. An engineer with a workstation, on a network, in a persistent session, always available, always working. Without the always-on machine, the dev loop is something you start each morning. With it, it runs alongside your life.

HONEST CONSTRAINTS What this is, and is not.

Two things this is not. Not a production agent. The workstation runs dev (and occasionally staging) loops, no prod IAM, no customer data. AWS spend is capped by the per-loop budget. Fail-safes are a daily restart cron, a billing alarm that pings me, and a kill switch in a secondary tmux pane. I can shut the loop down from anywhere in under a minute.

Also not a recommendation that every team needs a Mac in a closet. The form factor is incidental. What matters: somewhere to run, something to run in, a way to reach it from anywhere. Cloud VM works. Linux box in a rack works. Mac in a home office works. Copy the architecture, not the silicon.

A trusted engineer, given real access, kept honest by a written rulebook, talked to by voice, working from a persistent session on a workstation that never logs off. That's what we mean by self-hosted AI engineer. A teammate with a desk.

The deeper resemblance.

One more parallel. Nexentra is governance-first, audit-everything, fail-closed, layer-isolated. The dev loop is the same architecture, turned around and applied to the act of building Nexentra. The same shape builds the thing we sell.

The Lead is governance: stops anything, writes any policy, but doesn't reach into the Generator's work. The Generator is the agent runtime: stateless, disposable, focused, reset between tasks. The Validator is audit and policy: append-only verdicts, evidence-bearing, fail-closed. Plan, manifest, and history files are the institutional memory; every iteration is reconstructable from disk.

We build Nexentra with the same shape Nexentra exposes to its customers. The symmetry isn't aesthetic; it's how a small team ships an institutional-grade platform. Trust the discipline of the loop more than the talent of any one agent in it.

That's the shift. The agents we used to treat as productivity tools are, on the other side of this loop, software engineers. They plan, build, critique, re-plan. They run on a remote box over Tailscale while their architect is in the car. The humans aren't faster typists with a smarter assistant; they're architects, free to decide what should exist while the factory hums.