Is a factory actually possible?
The argument so far has assumed the answer is yes. Chapter 5 described an operator's day inside a working factory. Chapter 6 described the transition path. Chapter 7 described what the strategic landscape looks like once factories are common. But the operator reading this on a Tuesday morning in 2026 is reasonably entitled to a sharper version of the question: can I, today, reliably reproduce a product from a blueprint? And then the harder follow-up: if yes, what does my engineering organisation actually have to do differently to live with the consequences?
The honest answer is: yes, but not the way most teams currently attempt it. A traditional factory works because inputs are standardised, processes are repeatable, and outputs are predictable. Software has historically failed all three: requirements are ambiguous, systems evolve continuously, tooling is fragmented. AI authoring changes one variable in that equation, it collapses the cost of translating intent into implementation, and that single change is enough to make the factory model viable. But only if the rest of the system is structured for it. Pointing an agent at an unstructured brief and hoping for a working SaaS is not a factory; it is volume without shape.
This chapter is the operator's view of what the rest of the system has to look like. Three case studies show what blueprint-to-product looks like at the frontend, the backend, and the full-stack level. Then the chapter turns to two consequences that follow from the factory working: why agents do not need a UI, and why you should not rebuild what your enterprise already runs. The downstream consequences, phases of adoption, the talent grab, the AI-washing layoff cycle, autonomous operations, get their own chapter (Chapter 9: After the Factory) because the construction-side and the consequence-side argue different things and the operator needs to read each at their own pace.
"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency." Bill Gates, Business @ the Speed of Thought, 1999 "A factory built around an unstructured blueprint magnifies the unstructured blueprint." this paper
8.1 What a regeneratable blueprint actually contains
Most attempts at "spec-driven development" fail because the spec is treated as a prompt, a paragraph of intent the agent interprets. Interpretation is the enemy of regeneration. A blueprint that survives a rewrite has to carry, structurally, every constraint the operator would otherwise hold in their head:
- Product intent. What is being built and why. One paragraph; the brief.
- User journeys. The named flows from Section 2.2.2, written as executable Playwright specs.
- System boundaries. Where the frontend ends, where the backend begins, which third-party systems are integration points and which are commodity dependencies.
- Data contracts. Every API surface pinned by a Zod-or-equivalent schema and a contract test, the shape Section 2.2.1 names.
- Operational expectations. Scale targets, observability hooks, named failure modes, the SLOs the system is allowed to violate and the ones it must not.
Without these, AI produces volume, not systems. With them, the same brief produces the same product, every time.
The factory model works iff the blueprint is structured and constrained, the outputs are automatically validated (the seven corners of Chapter 4 are the validation surface), and the system enforces consistency across builds. The accretion Section 3.5 names is the consistency engine. The three properties are not optional. A blueprint missing any one of them produces drift, not regeneration.
8.2 Three case studies: blueprint-to-product
The three case studies below are the empirical reproduction of the chapter's claim. Each takes one slice of the stack (frontend, backend, full-stack) and shows what a blueprint capable of regenerating that slice actually looks like. The shape of each blueprint is the point, not an exhaustive listing of every clause.
8.2.1 Frontend factory
Focus: UI generation from blueprint. Given a product's UX flows and component vocabulary, the factory emits the screens, routes, and component implementations.
Inputs. UX flows (the journey specs from Section 2.2.2), the component palette (a small typed catalogue: button, card, modal, table, form), branding tokens (colour, type, spacing), and the route map.
Output. A Svelte / React / HTMX frontend whose every screen satisfies the journey suite and whose components are drawn only from the declared palette.
Failure mode the blueprint prevents. Inconsistent component sprawl. The single biggest cost of frontend factories without a constrained palette is that each generation invents a slightly-different button, a slightly-different modal, a slightly-different form-field shape. Six builds in, the design system is unrecoverable.
What this case demonstrates. A frontend blueprint that regenerates is a typed input structure (the component-palette declaration, the journey spec format, the branding-token contract) feeding a staged generation pipeline (palette first, routes next, screens last, with a gate between each stage). The validation surface, component-palette adherence, journey-spec pass, an accessibility budget, and a console-clean default, is what keeps each regeneration drawing from the same palette instead of inventing a new button.
To see why the gate is the load-bearing part, watch the choice it forces. Suppose the palette defines a button as a single typed interface: rounded corners, three sizes, two states, default and disabled, a strict contract to the branding tokens. On the third regeneration the brief asks for a button that shows a loading spinner. The factory agent faces a fork: extend the palette definition and regenerate every button usage against the new interface, or emit a one-off button for this one screen that quietly deviates from the palette. Without the palette-as-contract, the agent takes the cheaper path and emits the one-off. Six builds later the catalogue holds the original, the loading variant, a disabled-loading variant someone else added, a third variant that is almost the loading one but not quite, and a fourth that is the original button themed for a dark card. The design system is unrecoverable; the operator has to hand-read the code to find out what buttons even exist. With the palette enforcing one source of truth, the gate makes the fork explicit: the agent can extend the palette and re-validate every consuming screen against the new interface, which is expensive and visible and routes through review, or reject the brief as incompatible with the declared constraints and hand the blueprint back for amendment. The expensive choice is visible; the drift choice is blocked. The operator watches the palette grow on purpose, not by accident.
8.2.2 Backend factory
Focus: Service creation from blueprint. Given a domain model and an API surface, the factory emits the handlers, the persistence layer, and the integration scaffolding.
Inputs. Domain models (entities, relations, lifecycle states from Section 2.2.3), API contracts (every route's request / response schema), data flows (which integration writes which event onto which bus).
Output. A Go / Rust / TypeScript backend whose every endpoint satisfies its contract test, whose every entity satisfies its lifecycle suite, and whose every integration boundary satisfies its contract on both sides.
Failure mode the blueprint prevents. Dependency tangles and silent duplication. Without the factory enforcing a single source of truth for the domain model, each service grows its own slightly-different version. Three services later, the same User is encoded four ways and the integration layer becomes a translation tax.
What this case demonstrates. A backend blueprint that regenerates rests on a service-template system (the skeleton every emitted service inherits, with the factory varying only the parts a blueprint differentiates) plus contract enforcement that verifies the inbound and outbound contracts of each integration boundary on every regeneration. The deployment pipeline is the third leg: a fresh backend emit reaches staging without an operator hand-rolling the rollout, which is what lets the single source of truth for the domain model hold instead of fragmenting service by service.
Walk the mechanism across three services. The domain model defines a User as a set of required fields plus a lifecycle state machine, pending to active to suspended, with legal constraints on the transitions. The first emit builds a user-service that embeds the model and enforces the state machine in its handlers. The second emit adds a messaging-service that needs to reference users, so the factory inserts a shared-domain definition, generated from the blueprint, into its dependencies, and both services now speak the same language for User. The third emit adds an analytics-service that consumes lifecycle events off the bus. Each integration boundary is pinned by a contract test: the user-service's outbound events match the schema the blueprint names, the messaging-service's inbound reference matches the shared-domain User, the analytics-service's inbound stream matches the declared topic. Now the operator amends the model to add a required field. The factory regenerates all three together: it updates the shared-domain definition, the user-service that populates the field, the messaging-service that accepts it on the reference, and the analytics-service handler that ingests it. Without the contract gate, each service would regenerate on its own and the operator would meet the mismatch at runtime, the messaging-service calling a user-service shape that no longer exists, the analytics handler failing to parse an event with a field it never learned. With the gate, the mismatch is caught at emit time: the regeneration either succeeds across all three or fails visibly, with no partial set of services shipped against a changed contract. The single source of truth survives because the contracts are verified, not because the services trust each other.
8.2.3 Full-stack factory
Focus: End-to-end system generation. Given a product blueprint, the factory emits the frontend, the backend, the persistence, and the infrastructure together.
Inputs. Everything from Section 8.2.1 and Section 8.2.2 plus the cross-system flows Section 2.2.5 names, which describe how a journey actually traverses the stack.
Output. A deployable product on a real URL. Not a code archive; a live system the operator can hand to a customer.
Failure mode the blueprint prevents. Cross-layer drift. Frontend and backend emit independently, the contracts agree on paper, the integration breaks at runtime. The cross-system corner Section 2.2.5 names is the gate that catches this; the orchestration layer is what makes it survivable.
What this case demonstrates. A full-stack blueprint that regenerates needs an orchestration layer (the pipeline that emits frontend, backend, and infra in the right order, with the right gates between each) and cross-layer contracts that force a coordinated frontend regeneration when an API contract changes, so neither layer ships against a stale partner. The testing strategy is where the cross-system corner sits in the gate stack and how a failure routes back to the layer that caused it, which is the mechanism that catches the runtime drift two independently-correct layers would otherwise hide.
The point of the three case studies, taken together, is to make the shape of a regeneratable blueprint concrete: it is not a paragraph; it is a set of typed contracts at every layer, and the factory's job is to produce a satisfier of all of them simultaneously.
8.3 Agents do not need a UI
A quiet mistake the first wave of "AI dev platforms" is making, and it is going to cost the platform vendors more than they currently realise, is dressing every agent interaction in a UI. Web app, dashboard, chat surface, drag-and-drop pipeline editor. The platforms look polished. They are also, structurally, the wrong shape.
Humans need UIs. Agents do not.
A UI exists to translate ambiguous human intent into deterministic system commands. An agent already has deterministic intent, expressed in code or in a structured prompt; the translation layer is dead weight. What an agent needs is structured communication (MCP, REST, gRPC), deterministic inputs and outputs, and clear contracts. None of that requires a button.
When an agent goes through a UI to talk to another system, three costs appear:
- A bottleneck. The UI's request rate is calibrated for human clicks, not for an agent's hundreds-per-minute throughput.
- A translation layer. The UI converts the agent's structured request into HTTP, then back to structured data inside the next system. Two losses per round-trip.
- An accidental product surface. The vendor now has to maintain the UI's quirks because some operator has built workflows on top of them.
The implication is uncomfortable for the current crop of AI-platform companies: most of what they are selling is overbuilt and overpriced for the actual customer (the agent). The customer they think they are serving (the human operator) is, in a working factory, an escalation surface that fires when the agent cannot proceed, not the daily-driver interface. A platform that recognised this would ship an MCP endpoint and a thin admin console, charge an order of magnitude less, and serve the same workload at a tenth of the cost.
For the operator building their own factory: roll your own dev tools, but make them agent-first. The CLI, the REST endpoint, and the MCP server are the load-bearing surfaces. The dashboard is the convenience for the human standing behind the agent. Build the load-bearing surfaces well; ship the convenience as a thin layer on top.
8.3b The collapse to core functionality
Once you have stripped the UI off because the agent does not need it, a second realisation lands. *The agent does not need most of the features either.* It needs the small core of functionality the product actually exists to deliver. Everything else, the settings panels, the customisation surfaces, the dashboards-of-dashboards, the in-app onboarding flows, the help bubbles, the tool-tip systems, the export-to-five-formats menus, was built so a human could discover what the product does and configure it to taste. An agent has neither of those needs. It already knows what it wants; it does not browse.
This inverts an assumption that has driven SaaS product development for two decades. Companies have been adding feature after feature after feature, each one defended on the basis that some human user, somewhere, asked for it, and the marginal cost of one more feature was lower than the marginal cost of saying no. The accreted feature surface became a moat. "You can't replicate our product without replicating five years of feature requests." The competitor would have to rebuild the long tail of edge cases the incumbent had patiently absorbed; the cost of replication was the cost of catching up to a moving target.
The feature accretion that defended yesterday's incumbents is the feature accretion an agent-only consumer does not need. Cut to the core, and the moat goes with it.
When the consumer becomes an agent rather than a human, the moat collapses from both sides. The incumbent was already paying to maintain a feature surface no agent uses; the challenger does not have to rebuild that surface to be competitive. The five-year feature-tail moat that protected the incumbent against a human-built challenger does not protect the incumbent against an agent-served challenger. Two consequences follow.
The reverse is now true. The product that wins the agent-served market is not the one with the most features; it is the one with the smallest coherent core that satisfies the agent's contract. Less code, less surface, fewer tests required, faster regeneration, fewer breakage modes, lower operational cost. The same Phase 2 collapse from Section 9.1 (10x less code, against the same product surface) plays out at the feature layer too. The product gets smaller, on purpose, because the surface that made it large was a translation layer for a consumer that no longer reads it.
The huge companies become more cloneable, not less. This is the structural disinflation Chapter 7 Section 7.3 named at the codebase layer; here it lands at the feature layer. A challenger with a factory and a small core can replicate a competitor's agent-facing surface in days, not years, because the competitor's agent-facing surface is a thin slice of their total product. The 95% of the incumbent's codebase that exists to serve the human-facing UI is irrelevant to the agent's consumption. The challenger does not have to clone it. They have to satisfy the agent's contract, which is much smaller than the human's.
The operators who recognise this in 2026 will deliberately ship products with less surface than their competitors. Not as a minimum-viable-product compromise but as a strategic choice: the smaller surface is cheaper to maintain, faster to regenerate, easier to gate, and structurally harder to out-feature. The operators who do not will continue to add features under the old assumption (more is more), and will discover, around 2029, that their feature moat is exactly the inventory their challengers are not paying to maintain.
The pricing model collapses with the feature surface. SaaS pricing has been organised around tiers (Free / Pro / Enterprise / Custom-quote) for two decades, and the tiers exist to monetise the feature accretion. The Enterprise tier carries the permissions matrix, the audit log, the SSO integration, the SLA addendum, the dedicated success manager. None of those has a buyer when the consumer is an agent. The agent does not need a permissions matrix at the UI layer; it needs a single, well-bounded API token. It does not need an audit log dashboard; it pipes events into the operator's existing Grafana (per Section 8.4). It does not need a success manager; the OpenAPI spec is the documentation. The tier structure flattens to one tier: per-call, per-output-unit, or per-blueprint-license. The "premium features" line on the income statement, which at many mid-market SaaS businesses is a large share of revenue, has no obvious successor in the agent-served pricing model. Either the company finds a different price-discrimination axis or the gross margin compresses. Most will not find the new axis in time.
The recursion is the deepest version. AI coding tools are themselves SaaS products with massive feature surfaces. Cursor's chat-plus-IDE-plus-agent-runners, GitHub Copilot's panels and policies and admin dashboards, Claude Code's slash-commands and skill registry, the major IDE-with-AI vendors are all selling featureful human-facing wrappers around what is, structurally, a small core: take the agent's request, route it to a model, return the model's response, optionally call tools. When the consumer of the AI coding tool is itself an agent (a meta-agent orchestrating worker-agents, the shape this book's anchor factory already runs), the wrapper goes too. The next-generation AI coding platform looks less like a featureful IDE and more like a small CLI binary that speaks MCP, ships an OpenAPI spec, and competes on contract clarity rather than UI polish. The directional bet this section makes is that today's high valuations on AI-IDE companies will, over the coming years, look the way the dial-up-portal valuations of the mid-1990s look in hindsight: real companies, real revenue, structurally on the wrong side of the same collapse they are currently selling to their customers.
A structural-debt note. This section names the feature-surface collapse in the smallest defensible form: less code, fewer features, smaller moat. The deeper implications spread further than one section can carry: the SaaS sales motion dies (no human walk-through of an agent-facing contract); the integrations industry collapses (Zapier / MuleSoft / Workato are translation layers between products that, after the collapse, speak the same MCP); the professional-services consultancies lose the implementation hours their model is built on; the brand-premium moat dissolves (agents do not feel anxious about which vendor they pick; they read the spec); the IPO playbook (ARR + feature-accretion growth story) needs new valuation models that public markets will take 18–24 months to absorb; the regulatory machinery, calibrated for big-tech-vs-startups under the human-UI assumption, may simply not see the agent-served upstart category until after it has won. None of this fits in Chapter 8. Each is a chapter-9 candidate. The honest move for the reader of the v0.1 working paper is to name the surface area, then leave the depth for a v0.2 release that has the room to engage with each consequence properly.
8.3c What humans actually want from the residual interface
If the agent does not need a UI, and the product collapses to a small core, the question becomes: what is the residual human interaction shape, and what does it look like? The honest answer is the one the operator already prefers when they are tired: a single sentence. Not a dashboard of a hundred fields. Not a wall of charts that requires the human to spot the anomaly. A single sentence, in plain language, that summarises overnight reality and offers a follow-up if the human wants depth.
"All systems OK." That is the dashboard. The hundred-field grid was the workaround for not having an AI competent enough to read the grid for you.
What this looks like in practice, on a Tuesday morning, with the operator picking up coffee:
"Good morning. We upgraded three containers yesterday, they were on track to run out of disk space in mid-2027 so we lifted them now while it was cheap. Six support tickets came in overnight, four were the same routing edge case so we resolved them with the user and shipped the fix; the remaining two we replied to with a workaround and have a clause queued for the morning review. The factory ran 47 regenerations against the spec, all green. Would you like a run-through?"
That sentence (or two paragraphs of it) is the new dashboard. It is generated by an AI reading the existing dashboards, the existing alerts, the existing ticket queue, the existing factory-run logs, and producing the intent-bearing summary the operator actually needs. It is AI on AI on AI: the operating AI watches the system; the meta-AI summarises the operating AI's output for the human; the human reads two paragraphs instead of a hundred panels.
Three implications fall out, none small.
The dashboard industry inverts. Today, observability vendors compete on dashboard richness. Most charts. Best drill-down. Most metric integrations. The vendor whose dashboard is easier to read wins because the human is the consumer. In an AI-summarised world, the vendor whose dashboard is easier for the meta-AI to read wins, because the meta-AI is the consumer. The dashboard becomes a structured-data feed; the visual layer collapses to a single status sentence. The Grafana that won the 2020s wins the 2030s only if it pivots to be the backing store for the summarisation AI rather than the consumption surface for the human.
Voice is the right modality. The operator is not at a screen; they are walking, driving, having breakfast. A two-paragraph spoken summary delivered when they ask, "how did we do overnight?", is the natural shape. The phone, the smart speaker, the in-ear assistant become first-class operator interfaces. The screen is reserved for the rare drill-down (when the summary says "we noticed an unusual spike at 03:14 that the heuristics couldn't classify, do you want to look?"). Most days, the screen never gets opened.
The escalation contract becomes the load-bearing one. The single sentence is fine when the answer is "all systems OK." The harder design problem is what triggers the escalation. When does the meta-AI say "we have a thing you need to look at," and how does it ask? Done badly, it cries wolf and the operator stops trusting the summary. Done well, it triggers exactly when the human's judgement is structurally required, never when it isn't. The escalation contract is the AI-on-AI version of the gate: it gates the operator's attention, the most expensive resource in the system.
This is the natural endpoint of the chapter's argument. The factory produces the product. The autonomous-operations layer Section 9.4 names keeps the product running. The summarisation layer (this section) tells the human, in one sentence, that everything is fine. The human's job becomes the small set of things only a human can decide: which markets to enter, which clauses to add to the blueprint, which escalations are real. Everything else is below the residual interface. That is what agents do not need a UI lands at when you push the reasoning to its endpoint.
8.3d Build the visibility portal in from the start
Section 8.3c described the steady-state interface as a single sentence: "all systems OK." That is the tip. Underneath the sentence there has to be something for the human to look at when the sentence says look at this, and that something is a visibility portal: one place that collapses the system's total state into a surface a human can see, watch, and act on. The single sentence is what the portal says on a good morning. The portal is what you open on a bad one.
The need for it grows from a mismatch the factory makes worse. A working factory emits state across many places at once: the work queue, the gates, the deploys, the agent runs, the incident stream, the support tickets, the regeneration logs. A computer can hold all of that simultaneously. A human cannot. As the team shrinks and the system grows, which is the whole direction this book points in, the ratio of system-state to humans climbs until no person can track it by visiting each surface in turn. The only viable relationship a human can have with a system larger than their working memory is through a portal that does the collapsing for them. This is the inversion hiding inside Section 8.3: AI thins the per-feature product UI toward nothing, and the same forces thicken the need for the one interface that survives, the operator's window onto the whole.
AI removes the UI from the product and makes it indispensable for the operator. The screens collapse into one portal, and that portal carries more, not less.
A visibility portal earns its place by doing three jobs, and all three are needed from the beginning.
You watch the system being built. During construction the system is not in steady state; it is emitting, gating, failing, and re-emitting. Without a window onto that, the factory is a black box, and you cannot tell a good build from a confident-looking bad one. The portal is how the operator supervises the agents while they work, which is the only supervision that scales to the throughput Section 6.2b describes.
You maintain it. The operational tail of Section 9.3e, the support queue, the regression triage, the incident response, runs through the portal or it runs through archaeology. Maintenance without visibility means reconstructing the state of the system from raw logs every time something breaks, which is the most expensive way to operate anything.
Other people operate it. This is the job that decides whether the system outlives its builder. A portal is the simplification layer that makes a genuinely complex backend operable by someone who did not build it. Without it, only the person who holds the system in their head can run it, which is the sweet-factory wizard of the About chapter reborn at the operations layer. The portal is the recipe for operating the system written down, the same way the blueprint is the recipe for building it written down.
That symmetry is the reason visibility has to be designed in from the first commit, not bolted on when the system gets big. The blueprint makes build-intent explicit so any AI can regenerate the system; the portal makes operating-state explicit so any human can run it. They are the same move, make the implicit explicit so it survives the individual and scales past one head, applied to the two halves Section 8.5 names. Retrofit visibility late and you spend the project reverse-engineering state that should have been emitted as a contract from the start; the observability surface scored in Chapter 12 is exactly that contract, cheap at the beginning and expensive forever after. Build the portal in first, and every component added afterwards reports into it by default.
8.4 Don't rebuild what your enterprise already runs
The other quiet mistake of the first factory wave is the temptation to rebuild the entire surrounding ecosystem from scratch. New CI, new observability, new deployment, new docs portal, all bespoke to the factory. The vendors selling AI-native versions of each layer encourage this; greenfield rebuilds are easier to demo than integrations.
The mistake is structural. Your existing enterprise stack already operates at scale, already solves hard problems, and already integrates with your environment. The CI pipeline that runs your test suite, the Argo CD that deploys your workloads, the Grafana that holds your dashboards, the internal developer portal where your runbooks live, the wiki where your incident retrospectives are written, all of it is years of accreted capability that no factory rebuild will reproduce in its first six months.
The factory principle is the same one Section 5.1 stated for the codebase, applied to the surrounding tooling: only build what differentiates your system. The blueprint, the gate stack, the regeneration pipeline, the persona reviewers, those are the differentiators; build them well. Everything else, integrate. The factory's emit step calls into your existing CI; the factory's deploy step calls into your existing Argo CD; the factory's monitoring step writes into your existing Grafana. The integration is the work, not the rebuild.
The exception is when the existing tool is structurally incapable of what the factory needs (e.g. the CI cannot run a regeneration in under fifteen minutes; the deployment system cannot ship N versions of the same service for canary). In those cases the rebuild is justified. In every other case, integration beats replacement. The vendors who promise the all-in-one AI-native stack are selling you the rebuild; the rebuild is rarely the right move.
8.5 The factory is only halfway
There is a failure mode that does not belong to the sceptics or the wave-two CFOs. It belongs to the people who do everything in this chapter correctly. You stand up the work queue. The agents start returning work and the feedback loop closes. The pipeline becomes cyclic: emit, gate, review, re-emit, and the code coming out the far end is genuinely good. After the months it takes to get here, a humming pipeline is the most satisfying thing you have built. The temptation, exactly at this point, is to conclude that you have arrived.
You have not. Building the factory is the hardest and most absorbing half of the work, which is precisely why it is the easiest place to stop. A working factory still leaves three things unbuilt, and none of them announce themselves while you are admiring the pipeline.
A good pipeline still produces divergence between applications. The factory emits excellent code for each product. It does not, on its own, emit the same code across products: the same folder shape, the same test conventions, the same patterns for the same problems. Quality is not consistency. Ten products built by an excellent pipeline are ten excellent codebases that differ from each other, which is the original maintenance problem of Section 5.1 reborn at higher quality. Consistency across products is a separate clause you have to put into the blueprint deliberately; the pipeline will not discover it for you.
A fast pipeline can still bake the logic into the code. This is the subtle one, and it is the one that quietly undoes the whole argument. A factory that produces high-quality code with the intent living in that code is Builder culture with a faster author. The spec is not the asset; the codebase is, and you have only learned to write it quickly. The test is simple and unforgiving: could you throw the codebase away and regenerate it from the blueprint, or could you only re-run the coder? If the answer is the second, you have optimised the wrong layer, beautifully. The factory feels like Architect culture and is not.
The factory is the build engine, not the business. Around it sits a value chain the factory does not touch: distribution, project management, documentation, quality assurance, and the operational tail that Section 9.3e describes. None of these build themselves while you are absorbed in the pipeline, and none of them run at factory speed. The product that ships in three days still has to reach a customer, be coordinated against the next product, be documented, and be carried in production for years.
So the honest shape of the work is two halves, not one. The first half is the factory: the queue, the gates, the agents, the regeneration loop. It is the half that feels like engineering, and it is the half this chapter has been about. The second half is everything that turns the factory's output into a product and a business, and it is the half that is easy to forget precisely because the first half is so absorbing.
The factory now works, which is the midpoint, not the finish. The next chapter traces what working changes for the company, the careers, and the operations.