After the factory works, what next?
The previous chapter stopped at the moment the factory ships its first reproducible product. The argument it left implicit, and that this chapter makes explicit, is that the factory working is the start, not the finish. A factory that emits 100x products against a coherent blueprint forces a different shape of company, a different shape of engineering career, a different shape of operations. The five sections below trace what each of those shapes becomes, and what the operator reading this on a Tuesday morning has to do about it.
The book's earlier horizon was a smooth-curve view of the five-year ahead; this chapter is the empirical reality view of the same five years, anchored on what is happening in 2026 and what is likely by 2031. The two views are the same story in different registers. an earlier chapter is what to expect; this chapter is what is happening.
"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." George Bernard Shaw, Maxims for Revolutionists, 1903 ↳"And the operators of factories adapt the factories to the world while the world adapts to the factories." this paper
11.1 The two phases of AI adoption
The five-year horizon sketched earlier in the book was a smooth curve. The empirical reality, looking at how organisations actually adopt AI authoring through 2026 and 2027, is closer to two distinct phases with a discontinuity between them.
Phase 1: code explosion
Phase 1 was sold on a clean story, AI is going to replace the programmer, and has so far delivered the opposite shape. Companies discover that AI can author code faster than humans and immediately do the wrong thing with the discovery: they spend the new throughput on more of the same shape of code, more features, more services, more lines. Output rises tenfold; the dashboards turn green; the CEO updates the board. Then the bugs start, and the systems they fail in start, and the AI gets sent out to patch the symptoms one row at a time (the Section 4.1 weird-state case at industrial scale). Now there are 10x more lines of patch code on top of 10x more lines of feature code, and the trap closes about eighteen months later. Code is not free: every line can break, must be understood, is an attack surface and a maintenance liability. A 10x-more-code codebase is not a 10x-more-product company; it is a 10x-more-cost company shipping the same product slightly faster.
The lesson is the one Fred Brooks named in 1975 and that the executive layer never believes until it pays twice: adding more people to a project makes it take longer, and AI agents are not exempt. The communication-overhead, integration-cost, and merge-conflict curves apply just as cleanly to twenty agents on one codebase as to twenty engineers. The agent's authoring speed was never the bottleneck Phase 1 thought it was; the codebase's coherence is. Throwing more agents at an incoherent codebase produces an even more incoherent codebase, faster.
Wave one was the headcount cuts blamed on AI; it wasn't AI. Wave two was AI replaces the programmer. It didn't. It made everything 10x worse. Wave three starts when the industry realises that the answer to "too much code" is not "more agents to manage the code", it is "a small number of unusually good people, plus a blueprint."
This is the phase most of the industry is entering through 2026. It will produce a wave of "AI didn't work for us" writing in 2027–2028 whose conclusion is wrong: AI worked exactly as advertised; the company's strategy for using it did not.
11.1b Why the explosion engulfs the company
The mechanism behind that disillusionment is precise, and it has a name from 1978.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" Brian Kernighan and P.J. Plauger, The Elements of Programming Style, 1978
Kernighan's law is the load-bearing physics of Phase 1's collapse. The harder you push the cleverness budget at authoring, the less survives for debugging. A human managed this by writing well below their own ceiling. AI changes the arithmetic: the model writes at the top of its capability, every time, leaving no headroom for the maintainer it does not know exists. So when the bug surfaces, the intelligence required to debug that code exceeds the model that wrote it. The budget went on the easy half of the lifecycle; nothing is left for the hard half. The model proposes a fix, it passes the tests it can see, and it re-breaks something three modules away it could not hold in context. The cycle is the Section 11.4 AI can only operate on what it understands failure mode arriving from the other side.
The counterintuitive prescription falls out of the same arithmetic. Write simpler code than the model can. Constrain the agent's authoring; instruct it for legibility, not cleverness; in some cases use a less capable model on purpose, so the cleverness ceiling sits below the maintenance ceiling and headroom survives the next bug. The pattern is the Section 11.5 simplify pillar restated from the maintenance side: simple code that a smaller model can re-derive is the only code a future agent, or future operator, can safely maintain. This is not a slogan. It is the only way the arithmetic closes.
The same arithmetic runs on the human side as the cognitive-load version, which Section 11.3c develops into the headcount-cut rebound: a 200,000-line codebase is past the carrying capacity of any one head, so the team retreats to high-level decisions and is then too abstract to step back into the detail when the detail breaks. The resolution falls out of the same observation. The blueprint is the abstraction a human can hold: a hundredth the size of the codebase it produces, readable in a sitting, kept tethered to actual behaviour by the tests. The codebase is rented because it is too big to hold; the blueprint is owned because it is small enough to hold. That is the carrying-capacity argument, not a metaphor.
Phase 1 ignores three distinct multipliers, and they are the same trap on three axes. Brooks is the headcount version: adding people makes it take longer. Kernighan is the cleverness version: authoring at the ceiling leaves no headroom to debug. And the raw-throughput version is the two-developers story of Section 8.2b, where two authors wrote equally weak code and only speed separated them, the slow one survivable because his debt arrived inside the team's capacity to repair it, the fast one a disaster because he produced bad code faster than the team could turn it good. AI runs into all three walls at once: it writes at its own ceiling, at a volume no review process was sized for, and it removes the slowness that used to keep a weak author survivable. Cleverness and headcount do not multiply naively into output, and the gate is the only one of the three an operator can rebuild on purpose. The companies that survive Phase 1 gate their authoring below the maintenance ceiling deliberately; the rest discover the gap when the maintenance bill arrives.
Phase 2: factory realisation
The shift happens when an operator (or a board, or a CFO who finally reads the maintenance line) realises the goal was never "more code faster." The goal was always "more product, fewer liabilities." A factory that operates like a factory, standardised assembly, bespoke per product, but reusing every part it can, does not produce 10x more code. It produces 10x less code than the company had a year ago, against the same product surface. Every regeneration consolidates patterns that the previous era of hand-authoring fragmented.
Phase 1 ships 10x more code. Phase 2 ships 10x less code, against the same product. Only one of them is a factory.
A true factory:
- Standardises patterns. Every emitted service uses the same skeleton; only the parts that differentiate vary.
- Reuses components. The component palette in Section 10.2.1 is one example; the service template in Section 10.2.2 is another.
- Eliminates duplication. Three services that all need an event-bus consumer share the consumer; the factory does not re-emit it three times.
The outcome is the inverse of Phase 1: less code, higher reliability, faster iteration, because the smaller substrate stays comprehensible to the AI on every regeneration and the gates around it are sharper. This is where AI authoring becomes transformational rather than disruptive. The companies that recognise the discontinuity early skip Phase 1 entirely; the ones that don't burn eighteen months on it first, then pivot or fall behind.
11.2 Where this leaves developers: the talent grab
A reasonable reader, having followed the argument this far, will ask the question every reader of every AI-and-software essay is silently asking: so where does this leave developers? Wave two's answer was "replaced by AI." That answer was wrong. Wave three's answer is sharper, and harder for the people in the middle of the bell curve to hear.
The Phase 2 product is less code, fewer services, smaller surface, sharper gates. That is the deliverable. The skill that produces it is not the skill the last twenty years of the industry has been hiring for. The bulk of the engineering profession in 2026, mid-level engineers shipping incremental features against a calcified codebase, has spent five to fifteen years getting good at exactly the work AI now does for the cost of an API call: implementing the next ticket, reviewing the next PR, debugging the next regression, following the existing pattern. None of those skills become more valuable in Phase 2. The market for them gets cheaper every quarter as the model layer improves; many will be priced down to zero on a five-year horizon.
The skills that do become more valuable are the ones the industry has historically under-trained for, never had a clean career-ladder shape for, and rarely paid in proportion to. Holding a whole product in one head. Reading a fifty-thousand-line codebase across a weekend and rebuilding it from the spec down. Phrasing operator intent as executable clauses with the precision a regenerative agent can act on. Recognising that two clauses contradict before the factory tries to satisfy both. Designing the smallest core that satisfies the agent contract instead of the largest accreted feature surface that satisfies the salesforce. Knowing when the gate is wrong because the test was wrong, not because the code was wrong. Operating at the boundary of what an AI can do without supervision and what only a human can decide. Almost none of this is what a junior or mid-level engineer is taught to do, and almost none of it is what a senior engineer's career has rewarded.
The number of people who can do this work, today, in the global engineering profession, is small. Not because the skill is rare in some absolute sense; because the path that produces it (years of holding entire systems in your head, repeated rewrites of your own work, a deep enough toolchain habit that you can build the gates from scratch) was an off-the-books apprenticeship. It happened to the engineers who happened to find themselves doing it; the industry did not select for it on the way up. The 2026 hiring market is calibrated for the wrong shape.
That mismatch will produce the largest talent-grab the industry has seen since the late 1990s. When the boards realise (around 2028, on the timeline of Section 8.4) that the Phase 2 work cannot be done by the volume tier of the engineering profession, the question becomes who can do it, and the answer is a small number of people whose names are already circulating quietly in the operator-class network. Salaries for that small group will detach from the rest of the engineering market the way ML-research salaries detached around 2018. Not by 50% or 100%; by a multiple, several times the rate the rest of the engineering market clears at. The distance between a Phase-2-capable engineer and a top-decile feature-shipping engineer in 2030 will not be a factor; it will be a category. The industry has seen this shape before. It was the COBOL-to-relational shift in the 1980s, the mainframe-to-client-server shift in the 1990s, the on-prem-to-cloud shift in the 2010s. Each time, the small number of people who could do the new work were paid the way the old work would never have paid them, while the median continued to do the old work at the old rate, and was eventually wound down with it.
There are three things to do with this prediction depending on where the reader sits.
If you are an early-career engineer reading this in 2026, the playbook is depressingly familiar but actually-actionable: deliberately get good at the work the median is not getting good at. Stop optimising for shipping more features against the existing codebase; start optimising for holding whole products in your head, for writing the test before the code, for rebuilding small systems from spec under time pressure, for reading other people's blueprints and finding the missing clauses. The senior engineers who will be in demand in 2030 are the ones who treated 2026 as the year to retool. The ones who treated it as the year to ship more JIRA tickets are the ones who will be having harder conversations.
If you are an engineering manager or staff engineer in 2026, the playbook is the same shape one layer up: deliberately structure your team's work so the senior engineers spend their time on the spec and the gates, not on hand-stitching feature code the AI can do twice as fast for an API-call's price. Performance-review the spec authors for clauses landed and bug-classes structurally killed, not for lines of code shipped. Build the career ladder you wish your previous employer had had, the one Section 1.6b argues the industry never built because it could not see reliability, only heroics. The engineers you retain through 2027–2028 with that ladder are the engineers your competitors will be paying triple to poach in 2029.
If you are a CEO or CTO reading this in 2026, the playbook is the hardest one. The talent the company will need for Phase 2 cannot be hired in 2028; it can only be grown in 2026 from the engineers already in the building. The capital-allocation argument from lands here in its sharpest form: every dollar spent on AI-as-feature-velocity is a dollar not spent growing the small number of engineers who could do the Phase 2 work. The CFO who reads this will reflexively want a smaller engineering budget; the strategically-correct move is the opposite, a smaller team paid more, with a larger development budget per engineer, organised around growing exactly the skills the talent grab will price most steeply. By the time the talent grab is visible in the labour-market data, it is too late to build the capability internally. The window to grow it is now.
The brutal counterpart is that the bulk of the profession does not navigate the transition; the COBOL programmers and on-prem sysadmins who did not move were not retrained, they were retired and managed out. The honest case the book owes its primary reader, the working software engineer, is that the transition is real and the window to retool is short, which the AI-cheerleading content of 2026 will not say but the historical record predicts. The reader in a position to act has, today in 2026, the easiest access to the work that builds the skill, the smallest field of competitors, and the longest runway to compound the lead. The one who waits for the labour market to confirm it in 2029 will find it already priced.
11.3 Why most companies will not get there (yet)
The strategic argument was about the companies that will make the transition. The honest counterweight is that most will not, and the reason is structural, not cultural.
Capitalism rewards short-term throughput. A public-company CTO who ships features this quarter is rewarded; one who refactors the engineering organisation around a new operating model gets the headcount cut next quarter. AI is currently being absorbed into existing engineering processes, not used to redesign them, because redesign carries career risk and the existing process carries career safety.
The fundamentals of running businesses haven't changed. All the operating logic, the market intelligence, the customer relationships, the revenue model, sits in the existing codebase and the people maintaining it. A factory rewrite is a research project. Capital does not fund research projects when the existing system is profitable.
Only two cohorts will make the leap early. The first is companies already failing: the calcified incumbent whose codebase has aged into immobility, whose competitive position is eroding, and whose only path back to relevance is a structural reset. For them, the factory is not optional. The second is highly forward-thinking teams, usually small, usually founder-led, usually one or two layers removed from the public-company quarterly cycle. Both cohorts together are a small fraction of the industry today.
The wide middle, the profitable, growing, agile-but-not-radical companies, will use AI to accelerate existing processes for the next two to three years. By the time they realise the existing processes are the wrong target for the acceleration, the early factories will have a structural lead that is no longer cheap to close.
This is the uncomfortable bridge between the book's optimism and the operator's lived reality. The strategic argument is correct. The market timing is uneven. The operator who recognises this in 2026 has a window; the operator who waits for industry consensus does not.
11.3b CEOs following CEOs: the AI-washing trap
There is a darker version of this dynamic worth naming, because the operator reading this in 2026 will see it happening in real time. Big tech cut more than 80,000 jobs across 86 companies in Q1 2026 and blamed AI for most of it. Meta announced ~10% reductions; Microsoft put 7% of staff on voluntary buyouts; Epic Games shed over a thousand roles; Oracle, Spotify, Quora, Eventbrite all moved in the same direction in the same window. The press release language was almost identical from one company to the next: AI productivity gains, organisational efficiency, flatter org structures. The independent commentary was less generous. Sam Altman, running the company most invested in the AI-as-productivity-multiplier narrative, said in the same period: "Almost every company that does layoffs is blaming AI, whether or not it really is about AI." Tim Sweeney at Epic Games went out of his way to clarify: "Since it's a thing now, I should note that the layoffs aren't related to AI." Marc Andreessen put a number on the underlying state: companies were 25% to 75% overstaffed from pandemic-era hiring combined with the post-2022 rate environment, and AI was the politically cheap cover for cuts that were going to happen anyway.
The first wave of "AI did this" cuts is mostly the previous era's overstaffing being unwound under a fashionable banner. The second wave will be real. Operators should not confuse the two.
This is CEOs following CEOs, and the operator who is trying to draw a strategy from the headlines should treat it as the noisy signal it is. The real signal in the data is two clusters running simultaneously: a 2025-style ZIRP unwind dressed in 2026's vocabulary, and a separate, smaller, genuinely-AI-driven productivity cut from the small number of teams that have restructured their operating model around the factory shape this book describes. The press cannot easily distinguish them, and the CEOs being asked the question on earnings calls have no incentive to. "AI made us more efficient" lands better with shareholders than "we hired ahead of the demand curve and rates went up." So everyone says the first thing, the herd moves together, and a year of headlines reinforces a story whose load-bearing claim is, on the data, largely false today.
The trap closes in two ways. First, for the operator: if you adopt the cuts because the herd is cutting, you will pay the same cost the post-2022 over-cut paid, with no productivity uplift to show for it, because you will not have done the structural work that produces the uplift. The cuts get made; the factory does not get built; eighteen months later the company is shipping less, with fewer people, against the same calcifying codebase. Second, for the AI narrative: when the real AI-driven restructuring lands in 2028–2030 (the Phase 2 outcome of Section 11.1), the boards will have heard the story so many times in its empty form that they will dismiss it as fashion. The genuine inflection arrives wearing the same costume the AI-washing wave wore, and gets sent away at the door.
There is also a quieter risk in the herd behaviour itself. CEOs follow CEOs because the cost of being wrong alone is greater than the cost of being wrong in a crowd. A CEO who refuses the AI-cut story while the rest of the S&P 500 announces theirs has to defend the headcount line on the next earnings call without the AI cover. So the cuts go through whether or not the AI productivity gain is real, because the career incentive of the executives making the decision is to align with peers, not to optimise for the company's three-year position. This is the same dynamic that produced the 2021 over-hiring (everyone hired because everyone was hiring) and is now producing the 2026 over-cutting (everyone is cutting because everyone is cutting). The operator's position is unchanged across either: the herd is not a strategy, and the structural work this book argues for is what produces the actual productivity uplift the herd is currently claiming.
Hold two things together: the 80,000 cuts are real (real people, real numbers, not in dispute), but the attribution of them to AI productivity is, on current evidence, mostly fashion. The operator's job is to keep the two separate, when reading the news, when defending their own headcount line to a board, and when deciding whether the trade-press panic is a signal to act on or to wait out.
: Big Tech cut 80,000 jobs and blamed AI. Experts say a real problem is that companies are 25% to 75% overstaffed, Moneywise / Yahoo Finance UK, 3 May 2026. Quoted figures: Q1 2026 layoffs across 86 tech companies; Meta ~10%, Microsoft 7% buyout-eligible, Epic Games 1,000+. Sam Altman quote on layoff-attribution; Marc Andreessen on 25–75% overstaffing; Tim Sweeney on Epic's cuts being unrelated to AI. See Appendix A for the full citation.
11.3c The cognitive-overload rebound: cut, then re-hire
The cleanest mistake the wave-2 board makes is not visible until well after the cut. The shape: in 2026, the operator gives the engineering team AI tools that genuinely speed them up. Call it 2x on authoring, 3x on cross-microservice exploration, all real, all measurable. The CFO sees that the engineering throughput per head has doubled and concludes the obvious: "if engineers are 2x more productive, we have 2x more headcount than we need; let's cut half." The press release goes out, the cuts land, the savings hit the next quarterly report, the share price ticks up.
Then the rebound. The cognitive load of the company didn't fall by 50%. Same products, same customers, same regulatory surface, same incident rate, same sprawling architecture, same on-call rotation, same subsystems whose decisions were made by someone now gone. The AI tools made each remaining engineer faster at the work they already knew; they did not double anyone's capacity to hold the system in their head. The cognitive ceiling didn't lift; the load against it did.
The first symptoms appear around month six post-cut: incident times rise, root-cause analyses get shallower, on-call burn-out spikes, the people who held the most cross-cutting context start leaving voluntarily. By month twelve the board is told the engineering org needs to grow back. By month eighteen the company has re-hired close to the headcount it cut, at higher market salaries (the 2027-2028 talent grab from section 11.2 is now in full swing). It does this without the institutional knowledge that walked out at the original cut. And it does it against a competitive landscape in which the wave-3 entrants have spent the same eighteen months building the unified-codebase, low-cognitive-load shape that does not have the rebound in the first place.
The rebound stopped being a forecast on roughly the same schedule as the token bill. By spring 2026 outplacement-firm research found two-thirds of companies that had laid workers off for AI were rehiring some of the same people, the trade press had a name for them, AI boomerangs, and Forrester's Future-of-Work report put employer regret at 55% and predicted half of all AI layoffs would be reversed in some form by the end of 2026. A third of the employers in the same research spent more on restaffing than the layoffs had saved. The 2027–28 wave of "AI didn't work for us" posts this book predicts has a published first draft.
The board accounting then reads: we cut to save 18 months of payroll, paid the cost of the cut twice (severance + re-hire premium), lost the institutional context for free, fell behind the wave-3 entrants on the only axis that mattered (operating velocity in a coherent codebase), and the share price that ticked up at the announcement is back where it started. This is the textbook "all the costs of the action, none of the benefits" shape that capital-allocation literature names but that boards under quarterly-pressure consistently miss.
The structurally honest version of the same move does not produce the rebound. It is the one this book argues throughout: don't cut the headcount carrying the cognitive load; rebuild the system so the load is much smaller in the first place. The Phase 2 collapse from section 11.1 (10x less code against the same product surface) is cheaper not only in compute and licences but in cognitive load per remaining engineer, the load-bearing variable. So a 50-engineer team holding 50,000 lines of regenerable, blueprint-anchored code has more operating-velocity capacity than a 100-engineer team holding 500,000 lines of accreted monolith. The cuts that work follow the structural simplification; the cuts that backfire pretend it has already happened.
The 2027-2028 prediction: every AI-attributed headcount cut in 2026-2027 will, by mid-2028, be matched by a quieter re-hire round dressed as "strategic capacity rebuild." The minority that escape the rebound are the ones whose cuts followed real structural simplification. So when modelling the savings from an AI-productivity cut, build a paired model that prices in the eighteen-month rebound (severance + re-hire premium + lost institutional knowledge + fallen-behind opportunity cost): the honest model rarely justifies the cut, and the alternative, simplify first, then cut from a lower baseline, is the only play that actually reduces the cost line by 2030.
11.3d The belief that pulls the trigger
Section 11.3b and Section 11.3c named the cuts and the rebound; the piece that ties them is the trigger, the move that turns a felt productivity gain into a press release.
The trigger is the belief, not the productivity.
Wave-two job loss is not AI replacing the worker; it is leadership believing the work can be done by far fewer people and cutting on the belief, ahead of the evidence (the 19% measured slowdown against a confident felt speed-up). The board hears that engineers are 2x faster, infers the team is 2x oversized, and signs.
The belief is half right, and that is what makes it dangerous. A factory-shaped company genuinely does need fewer staff (the whole moat argument of and, so the executive concluding "fewer engineers" reaches the correct destination from the wrong premise: it needs fewer engineers because it did the structural work that lets it hold the system in fewer heads. The wave-two cut is the destination without the journey, cutting the people while keeping the 10x-code liability, so it hits Kernighan's wall and the Section 11.3c rebound at once. The practical move is to separate the trigger from the outcome in every cut conversation: where the trigger is the felt-productivity belief, invest the uplift in simpler code first and cut from a lower baseline (see Section 11.1b); where it is portfolio normalisation, name the ZIRP unwind on the earnings call and do not borrow the AI cover. The boards that confuse the two pay both costs and earn neither saving.
11.3e Where is the support team?
The whole "10x" claim of wave two is a delivery number. The factory builds the product faster; the sprint cycle compresses from two weeks to two days; the team that used to be ten engineers becomes two. Each of those is real, and each of them is positive. They are also, every one of them, about getting the product out of the door.
What about the product after the door?
The product that shipped on Tuesday afternoon has to be supported on Wednesday morning. A customer files a ticket the spec did not anticipate. A regression surfaces in production traffic the test stack did not generate. A third-party API the product depends on deprecates a field with six weeks' notice. A regulator publishes a guidance update that lands on the operator's desk. A model the product internally calls drops a tool-use surface. The on-call rota fires at 3 a.m. None of these are 10x-compressible: they are human-mediated by definition, because the work is judging what to do about a thing the spec did not predict.
The 10x is for delivery, not operations. AI ships the build; the build still has to be carried.
The wave-two team cut is therefore answering the wrong question. How few people can build this? is what AI compresses; how few can carry it in production for five years? is a different number, and no model compresses it. The two-person team that ships a 10x-delivery codebase by Friday cannot also drain the support queue, hold the on-call rota, triage the regressions, read the regulator's PDF, and renegotiate the API deprecation, five jobs that do not run at AI speed and that begin the morning the same team is told to start the next half-day feature. Section 11.3f shows why that feature takes longer than half a day.
There is a sharper observation hiding in the sprint-compression itself. Section 11.1b named Kernighan's wall: AI authoring at the limit of its cleverness leaves no headroom for debugging. The sprint cycle surfaces a second mechanism on top of it. AI agents take shortcuts under pressure. The Section 1.4c savant, brittle on the parts it does not know, is brittler under deadline. A two-day sprint is two days the agent has to land the work; if the test stack passes, the agent has no further incentive to deepen the implementation. A restless developer under deadline takes the path that compiles. An AI agent under deadline takes the path that turns green. The shortcuts ship. They do not surface until production, in the operations queue the two-person team is also supposed to be running. The faster the sprint, the larger the shortcut residue, and the heavier the operational tail.
The book's existing argument that the codebase should be small, comprehensible, and regenerable closes some of this gap. A smaller surface is a smaller support load. A blueprint-anchored codebase regenerates against a new API faster than an accreted one. Section 11.4 names four operational lanes where autonomous agents can absorb the rhythm at factory throughput. Substantial absorption is not total absorption. The residual is the work that needs a human in the loop: the ticket the spec did not anticipate, the regulator's PDF, the customer who is angry, the postmortem of the failure no one has seen before. The gate accepts or rejects the delivery candidate; operations is a longer rhythm than any gate fires at.
So the shape of the post-factory team is not zero. It is a team sized for the operational tail, not for the build. The build is what the factory does. The team's role becomes growing the blueprint as the product encounters operational reality, judging the tickets the blueprint did not anticipate, and operating the gates the AI must satisfy when it re-emits the product against the new clause. The Section 11.2 talent-grab argument lands here in its operational form: the engineers who can carry that role are the small group whose career has already exposed them to the build-operate boundary. The two-person team the wave-two cut imagines is a team of those engineers, not a team of two random survivors of the cut. Building the factory without staffing the operational rhythm is the second self-inflicted failure mode of wave two, after Kernighan's wall.
The rebounds are only the first half of this chapter's ledger. The cuts have bounced back as re-hires, the belief that pulled the trigger has been named, and the support load has refused to compress. The conveyor belt the chapter opened on is still running; the chart on the wall has done its dip and started to climb. What nobody at the desk has looked at yet is the meter. The factory works, and the first invoice for the factory working has not yet landed.
The factory working is the start, not the finish, because the morning it ships its first product is the morning the bills start arriving.
The second feature costs what the first one did not. The token meter inverts its own mandate. The offshore arithmetic that justified the whole move stops adding up, and the scaling problem begins on the day the factory finally works rather than the day it fails. Those are the bills, and they are already in the post.