The second ultracode Workflow had five chapters to produce. Each covered a discrete obstacle on the path from next export to a live cPanel deployment. Among them: the next/image unoptimized flag, the LiteSpeed .htaccess rewrite rules, the 404.html trailing-slash bug, the GitHub Actions FTP deploy. The Workflow ran them in parallel. It did not need to know the chapter order to write the chapters.
That distinction (running in parallel, not knowing the order) is exactly where the architecture earns its keep. And exactly where it runs out of road.
The setup
The static-next-cpanel course is the second on the /learning/ track of captainrandom.co.uk. Ship-it focus: take a Next.js project with output: 'export' and get it onto a shared host without a Node runtime, without a Vercel account, without changing the hosting provider. Eight chapters. Each chapter is a named problem with a named resolution. One topic per chapter, one chapter per obstacle.
The curriculum spec existed before the first Workflow ran. That detail matters. The spec defined the chapter titles, the learning objectives, the order of the problems. The ultracode Workflows drafted the prose, the code samples, and the frontmatter from that spec. They did not decide what the chapters were.
Two workflow runs: chapters 1–3 first, chapters 4–8 second. The split was deliberate: a checkpoint before scaling up.
What the parallel architecture handled
Parallel agents, each assigned one chapter topic, each drafting independently. No shared state between agents. No agent needed to know what chapter 3 had established in order to write chapter 5.
For this kind of material it works. Each chapter covers a self-contained technical problem. next/image with unoptimized: true has no dependency on the LiteSpeed .htaccess rules beyond the fact that both get solved in the same project. You can draft them in either order. The code samples are independent. The explanations are independent.
Technical tutorials have a structural advantage here. Each chapter is a transformation problem: reader knows X, problem Y exists, here is how to solve Y, reader now knows X + Y. The inputs and outputs of that transformation are local to the chapter. Contrast this with a conceptual narrative, where each section builds on the tone and framing established by the previous one, and where a parallel agent drafting section 5 without having read sections 1–4 would produce something structurally sound but narratively disconnected. The transformation shape of technical tutorials is what makes fan-out work for them.
Structural consistency across chapters came from the spec, not from agents reading each other’s output. Parallel agents drafting to the same template don’t need to communicate to produce chapters that feel like they belong to the same course.
Chapters 1–3 reviewed cleanly. That cleared the way for chapters 4–8. The review checkpoint is still conductor work. One human pass: are these chapters coherent with each other, are the code samples accurate, does the course voice hold? That took less time than writing them would have, but it wasn’t zero.
Where the parallel architecture stops
Prerequisite chips were not part of either Workflow run. They shipped separately, as a distinct navigation sprint: P5 of the learning hub navigation plan.
The conventions.md working doc called them “the single highest-value navigability fix.” Each chapter now carries an N1 chip: a “Read first →” label pointing to whichever chapter must be understood before this one. The chip is a claim about dependency. The fan-out architecture can’t determine that. No individual agent knows what the other agents wrote. No individual agent can establish a dependency that only exists relative to the course as a whole.
The through-line is the same problem in a different form. A course has a shape: here is where we start, here is where we end, here is the capability the reader has at each stage. That shape is a property of the course as a whole, not of any individual chapter. Parallel agents can produce chapters. They can’t produce a course. That synthesis step stayed with the conductor.
Post-ship housekeeping was conductor work too. After the full eight chapters landed, the backlog needed reconciling. Every tracking surface updated to reflect what actually shipped. The living atlas regenerated against the updated spec. The M/E/N/S items in conventions.md got per-item statuses. None of that fans out.
The clean partition
Stated directly:
- Fans out cleanly: chapter body prose, code samples, frontmatter, structural consistency within a chapter. Anything that is a function of (spec + topic) and independent of every other chapter.
- Stays with the conductor: prerequisite ordering, dependency chips, through-line narrative, backlog reconciliation, cross-chapter coherence review, the initial curriculum spec itself.
The curriculum spec is the interesting case. It’s the pre-condition for all the fan-out work, drafted from but not produced by the Workflows. Writing a curriculum spec (deciding which problems to cover, in which order, at which depth) is conductor work that happens before any agent touches the course. If the spec is wrong, the chapters will be consistently wrong in parallel, and the review checkpoint won’t catch it because the reviewer is checking execution against the spec, not the spec against reality.
What I’d change
The two-Workflow split (chapters 1–3 then chapters 4–8) added a checkpoint that proved its value. If the first three chapters had structural or accuracy problems, they’d surface before committing to the same pattern for five more. The checkpoint was worth the overhead.
What I’d do differently: make the prerequisite chip decision earlier. P5 shipped as a separate navigation sprint after all eight chapters existed. It would have been cleaner as a pre-production step. Write the dependency map before any chapter is drafted, embed it in the spec, let the chapter drafts acknowledge their prerequisites inline from the start. Retrofitting “Read first” chips after the fact worked, but it required a full pass over all eight chapters to get the dependency graph right. In a 20-chapter course, that’s a larger audit.
The living atlas, the navigable interactive document of the whole programme, is the right post-ship artefact. It regenerates from the spec. If the spec stays current as chapters land, the atlas stays current. The reconciliation cost at closeout comes from letting the spec drift during authoring. That’s a discipline question, not an architecture question.
What this scales to
Adding chapters means another Workflow run with the same structure. The fan-out cost per chapter is low. The conductor cost per chapter is also low, for chapters that fit cleanly into an established dependency graph.
The scaling pressure point is the dependency map itself. A linear course is trivial to manage. A lattice gets harder: some chapters are independent, some depend on two predecessors, a few are optional. The conductor’s prerequisite graph needs updating every time a chapter lands, and the chips need auditing against it. For an 8-chapter linear course, that was one sprint. For a 40-chapter lattice, it’s ongoing maintenance.
Site-wide search (Pagefind, shipped as P6 of the navigation plan) makes the conductor’s job easier. If readers can search across all chapters, a missed prerequisite link is less catastrophic. Search is the backstop; chips are the primary signal. The two reinforce each other.
Eight chapters shipped. The partition between what the Workflows handled and what I handled was cleaner than expected. The conductor overhead per chapter is low. The pre-conditions for fan-out — spec, dependency map, review checkpoint — are not.
