Software Factories

New capability, old constraint #

Something foundational shifted under software development. LLMs that specify, code, review, test, deploy. Agents that can run those capabilities in parallel, in the background, on real work.

What that changes about capacity is enormous. What it doesn't change is the constraint that mattered all along: your attention is the scarcest input in the system.

The new tools don't relax that constraint. They sharpen it. Because now the interesting question — the only interesting question — is how to deploy these new capabilities against actual software work in a way that respects the scarcity of your attention, minimizes missed expectations, and keeps the quality of what ships high enough to live with over time.

That's a design problem. It has structure. It has axes. And most of the current tooling in the agent-coding space is only getting one of them right.

The scarcity isn't code #

Human attention is the ultimate scarcity in software work. Not skill. Not tools. Not compute. Attention — the finite hours per day of focused, considered engagement that a skilled practitioner has to give.

Every step in traditional software production is bounded by attention. Someone has to read the requirements. Someone has to design the module. Someone has to review the PR. Someone has to sign off on the deploy. The critical path runs through humans, one attention-transaction at a time.

Earlier attempts to industrialize software production — templates, DSLs, code generators, whole methodologies borrowed from manufacturing — tried to automate the making. Code that stamps out more code. That mostly failed because making wasn't the constraint. Programmers already generate code fast; that was never what was slow.

Agent-based orchestration inverts this. Agents can make. They can also review, revise, test, package, and file a PR. What they can't do — what they shouldn't do — is decide what the human wants, or judge whether the outcome matches what the human meant. Those two touchpoints are where human attention still belongs.

Everything else can move to the agents. The industrialization move, done right, is to squeeze the human attention footprint down to the moments that actually require judgment, taste, or style — and let the agents handle the rest.

Which is exactly what a well-designed orchestrator does.

The three axes of orchestrator design #

Every human-agent interaction is optimized — or fails to be optimized — along three distinct axes.

Bandwidth-when-attending is the first. Given that you are engaged with the system, how much information can you exchange per unit time? Menu clicks and dialog forms are low-bandwidth. Natural language is higher. Voice for abstract intent is optimally efficient because language is the abstract layer. Screen sharing is highest-bandwidth for handing over desktop state. Camera for physical world state. The system picks the right modality for the moment — and, just as important, adapts content between them. Coding agents naturally emit long text streams; a well-designed orchestrator uses another agent to condense that into voice-suitable dialog, a structured summary, or a widget on the nearest screen. The intelligence isn't just picking a channel; it's translating continuously.

I wrote about this on the consumer side last week. The bandwidth axis is why voice-first works when it works, and why multimodal has to be more than a bullet point on a marketing site.

Attention-required is the second axis. Given a desired outcome, how many units of your attention are needed to get there? Traditional apps require constant presence — you sit at the keyboard, you watch the output stream, you approve each step. A well-designed orchestrator dispatches to specialist agents that run in the background. You're absent until the outcome lands. Only when the system genuinely needs your judgment do you re-engage.

Exchange choreography is the third — and the most under-discussed. When exchanges with you do happen, how are they structured? Streaming raw agent output message-by-message is choreography-broken. Batching related decisions, aggregating results into standardized summary formats, prioritizing which interrupts fire immediately vs. which queue for a scheduled review — that's choreography done well. The orchestrator's job is not just to dispatch. It's to choreograph the information back to you in a shape that respects your attention.

Put them together:

Or in one line:

Total user cost = (attention units required) × (structural overhead per unit) × (inefficiency per exchange within unit).

Minimize all three and you get maximum outcome per unit of user attention through optimally-structured exchanges via the highest-bandwidth channel appropriate for each context. Any two axes without the third leaves value on the table.

One thread runs through all three: the orchestrator's core job is translation. Between modalities on the bandwidth axis. Between raw output and choreographed exchanges on the choreography axis. Between what the system produces and what your attention can efficiently receive, everywhere. Not passthrough. Not dispatch. Translation — continuous, contextual, per-moment.

The framework is dynamic, not static #

None of these axes are settings you configure once. Every one of them is context-sensitive. The optimal reading shifts with the moment.

On the bandwidth axis, the rule isn't "always use the highest-bandwidth channel." It's "use the highest-bandwidth channel appropriate to the circumstances." Voice is silent in a meeting. Screen sharing is unusable in the car. Camera is impolite in company.

The other two axes work the same way. On the choreography axis: developer in deep work → batch more aggressively, interrupt less. Developer available at their desk → interrupt normally. Developer away or driving → surface only critical items via voice. Developer in a meeting → suppress non-critical entirely. On the attention axis: weekend batch is fine for routine work; middle of an outage demands real-time engagement. The system reads whether attention is available or scarce right now, and adapts.

Get one axis right while ignoring circumstance and you've built a rigid tool. The intelligence is in reading which axis matters most in the moment.

What good choreography looks like #

The concrete producer-side examples land better than the abstract framing.

Weekly status report, one exchange: "Here's what shipped this week, here's what stalled, here are three decisions I need from you." Structured summary format. Standardized shape. You review 20 things in the time it used to take to review one, because the shape is predictable and the surfacing is discriminating.

Architectural interrupt vs. cleanup batch: design decisions get real-time surface — those need judgment. Style, lint, routine refactor: batched into weekly review. Same underlying flow of work; radically different attention footprint.

Aggregated agent output: fifteen sub-agent runs collapse into one coherent status report, not fifteen raw streams for you to context-switch through.

Just-in-time surfacing: don't tell me until it's actionable. Six status updates that could have been zero were probably choreography failures, not information transfers.

Learned preferences: the orchestrator observes how you actually work — that you prefer summaries over detail, that you hate approve-per-file, that your focus hours are 8-11 AM — and adjusts. Your future exchanges get lighter without you having to configure a thing.

Notice what's missing from every one of these: the interactive drip of "the agent did this, then it did that, then it wants to know if..." That's not the shape a well-designed factory takes. That's the shape today's coding agents take — which is a different problem.

Why current agent tools fall short #

Claude Code, Cursor, Devin, Copilot, opencode — all real, all useful, all sitting on the wrong side of the choreography axis.

They're bandwidth-maximized. Natural language input is the highest-bandwidth interface most developers have ever had. That's real progress.

But they're also attention-maximizing and choreography-broken. You sit at the keyboard. You watch each step stream by. Permission dialogs interrupt every meaningful action. Your inbox fills with raw agent output. Your focus fragments across sessions. When you close the laptop, everything stops.

They feel powerful and they feel exhausting, and both experiences trace to the same root: they're bandwidth-optimized point tools, not orchestrators. You're drinking from a firehose of well-articulated interruptions.

That's not the endpoint. That's the interregnum — a stage where bandwidth got much better but choreography and attention are still stuck in the previous era's assumptions. The endpoint is autonomous execution with orchestrated choreography of the exchanges that do require you. Not fewer capabilities; different shape.

What it looks like when it works #

You describe a feature by voice from the car. By the time you're home, the PR is filed, the tests pass, a preview environment is up. You click through it on the TV while making dinner. You have one design question; the orchestrator responds. You approve; the PR merges.

You dictate a batch of small work items before dinner. The next morning: a single consolidated report — five items shipped clean, two need your review, one hit an ambiguity worth talking about. Fifteen minutes to triage the whole batch.

You're in the middle of a real outage. The orchestrator knows. Interrupts get priority; batches get suspended; every exchange is optimized for velocity over politeness. Two hours later, incident resolved; the orchestrator files the post-mortem draft for your morning review.

None of that requires you to be at the keyboard. None of it requires you to be watching output stream. None of it requires you to context-switch through fifteen raw agent voices. What it requires is an orchestrator that treats your attention as the scarcest input in the system.

Now, for the first time, we can actually build it.

Coming next #

The three-axis framework is the what and the why. There's a specific architectural question sitting under it: how do you actually build a personal orchestrator that keeps these three axes in balance? Where does the orchestration layer live? Why can't it just be another feature of the coding agent you already use?

Next post: how one specific architectural pattern — a meta-layer above the coding agent — is doing the work that the coding agent can't do alone, and why that separation matters more than any single-tool improvement.

Follow along at storminthecastle.com — or reply if you're building in this space.

• Previous: AI will be your only UI