I Shipped an Angular v22 Book Update with a Crew of AI Agents. Here's the System

The challenge: a "book update" is not one job

If you've never shipped a technical book, here's the part nobody tells you: a new edition isn't an edit. It's a dozen jobs wearing a trench coat.

• The manuscript has to be rewritten for the new APIs - and every code snippet must actually compile against the framework.
• The companion code repo (one runnable app per chapter) has to be upgraded and kept in lockstep with the prose.
• The build pipeline has to produce a print PDF, a colour digital PDF, an EPUB, and a Kindle file - each with its own finicky toolchain.
• The store listings (Amazon, Leanpub) need fresh, accurate, keyword-aware copy.
• And then the thing has to launch: SEO articles, social posts, a newsletter, images, a coupon, the works.

Doing that solo, by hand, is weeks. The interesting question wasn't "can AI write some of this?" It was: can a coordinated crew of agents do most of it, well enough to ship, if a human stays in the loop?

The system: two tools, two repos, a crew

Here's the shape of it. Two AI tools, each playing to its strength:

Google Antigravity CLI (Gemini 3.5 Flash) co-authored the manuscript and drove the code-repo upgrade to Angular v22 - fast, broad passes across chapters and example apps. Crucially, it wasn't writing v22 code from memory: it ran the Angular CLI MCP server (@angular/cli mcp) and the official Angular extension for Gemini CLI - Angular's own system instructions and best-practice prompts from angular.dev/ai. Its v22 code came from live, authoritative tooling, not guesswork.

Claude Code ran a crew of role-specialized agents for the work that needed depth and judgment: editorial and technical QA, build-pipeline engineering, marketing strategy, SEO, and distribution - backed by its own shared Angular v22 skills (angular-developer, angular-new-app).

Two repositories, deliberately kept separate but wired together:

• The book repo - manuscript, the multi-format build scripts, and all the marketing infrastructure.
• The code repo (modern-angular-signals-book) - one runnable Angular app per chapter, so every snippet in the book is backed by code you can actually run.

The wiring matters: my editorial agent didn't just trust the prose. It read the code repo directly to verify that what the book claimed matched what the code did. That single connection caught the most embarrassing bug of the whole project (more on that below).

The crew

Notice the pattern: both AI tools were wired into real Angular tooling - the Gemini side through the Angular CLI MCP server and Angular's official prompts, the Claude side through shared Angular v22 skills. Neither was inventing the framework from memory. That's the same "ground truth beats vibes" idea, applied at the tooling layer - and it's why the v22 code across the book speaks one consistent, modern dialect (signals, resource, Signal Forms, zoneless).

I wasn't a writer on this project. I was a director: set the intent, review the output, make the calls the agents can't, and hit publish.

Three moments are worth telling in full, because they're where the "AI agents can do real work" claim either holds up or falls apart.

Hero story 1: the agent caught an API that doesn't exist

Here's the one that sold me. A chapter on accessible components had a polished, confident code example using AriaAccordion and AriaAccordionItem from Angular's new ARIA library. It read perfectly. I'd have shipped it.

The book-reviewer agent flagged it: those symbols don't exist. The real API is AccordionGroup, AccordionPanel, AccordionTrigger, and AccordionContent from @angular/aria/accordion. The earlier draft had hallucinated a plausible-looking API - exactly the kind of thing a human author skims right past because it looks right.

It found the error because it didn't reason from memory. It read the companion code repo and the real package surface, then compared. That's the whole trick: a fact-checking agent with access to ground truth beats a confident agent working from vibes, every time.

Here is that agent, cut to the essentials:

name: book-reviewer
description: Review chapters for editorial and technical issues.
tools: [Read, Grep, Glob, Bash]

# The instruction that matters:
# Do not reason from memory. Read the companion code repo and the
# real package surface, then compare every API name and snippet in
# the prose against what the code actually does.

That is how a confident, plausible API that does not exist gets caught.

And it wasn't a one-off. The same editorial pass - logged, chapter by chapter, in an EDITORIAL-REVIEW-LOG.md that ran to nearly 300 lines - caught more than a dozen outright errors, including a roadmap chapter that still said "v20" where it meant v22, and a snippet referencing a signal called items that the actual code had renamed to people. Small things. The kind that erode a reader's trust one paper cut at a time.

The lesson: the highest-leverage agent in the whole crew wasn't the one that wrote. It was the one that verified against ground truth.

Hero story 2: the agents did real engineering, not just prose

Writing is the easy part. The toolchain is where book projects go to die - and this is where I expected the AI to tap out. It didn't.

When I uploaded the paperback interior to Amazon KDP, it was rejected: "text outside the margins." Twice. The crew debugged it like an engineer would.

The diagnosis: my PDF was rendered by WeasyPrint, and Pandoc's syntax highlighter wraps every line of code in a display:inline-block span. When a code block fragments across a page break, WeasyPrint stops wrapping those spans - so long lines on the continuation page spill straight past the margin.

We reproduced it in isolation, confirmed the exact failure mode, and then made a call:

• Print PDF → render with --no-highlight. The paperback interior is black-and-white anyway, so plain <pre><code> (which wraps reliably) costs nothing and fixes the rejection.
• Digital PDF → keep full colour syntax highlighting, but render it with Puppeteer (headless Chrome), which does wrap inline-block spans correctly across page breaks.

The result was a dual-PDF build: a B&W, print-safe file for Amazon and a colour, highlighted file for Leanpub - both produced by one build:pdf command.

That wasn't the only toolchain fight. Leanpub's EPUB validator rejected the file over 77 unclosed <br> tags in a comparison table - invalid XHTML that was quietly corrupting the chapter's XML parse and throwing a phantom "broken crosslink" error. The fix was traced, applied, and verified to zero errors, zero warnings.

A separate Kindle MOBI bug came down to a slug mismatch - Pandoc turns Angular's into angulars, but the table-of-contents builder was producing angular-s, so a link pointed at an anchor that didn't exist. One small helper function to match Pandoc's algorithm, and the TOC resolved.

The lesson: "AI can write" is the boring claim. The useful one is that a capable agent can diagnose a rendering bug across a page-break boundary, A/B two renderers, and ship a dual-pipeline fix - with me reviewing, not hand-coding.

Hero story 3: the marketing factory

Once the book was solid, the crew turned into a content factory - and this is where the leverage compounded.

From a single source of truth, the agents produced:

• Store listings for Amazon and Leanpub - keyword-aware, fact-checked, with the subtitle and positioning unified across both.
• A series of SEO articles, starting with "What's New in Angular v22" and an "RxJS → Signals migration guide", each cross-checked against the code repo and Ghost-ready.
• A full launch kit: an X thread, a LinkedIn post with a 7-slide carousel, a Ghost blog post that doubles as an email, a YouTube community post, a Short script, and a newsletter.
• Five image cards plus a slide carousel - a launch hook, a before/after, 9:16 vertical cuts for Shorts/Stories, and a feature image - all rendered programmatically via headless Chrome from HTML, in the book's visual language, no design tool involved.

There was even a creative-strategy moment. A post had just gone viral on X (Andrew McCalip's "Kickbacks"), so the book-marketer agent reverse-engineered why - a shared moment, a before/after in a single cut, a restrained "results" follow-up 48 hours later - and applied that formula to the launch instead of guessing.

The lesson: the expensive part of a launch isn't ideas, it's producing a dozen on-brand, accurate variants across formats. That's exactly the work a coordinated crew eats for breakfast.

The guardrails: why "human-in-the-loop" wasn't optional

I want to be honest about the failure modes, because pretending agents are autonomous is how you ship something wrong.

Everything the crew produced was a draft. I verified and published. And that gate earned its keep:

• A launch hook claimed Signals were "experimental for three years." Technically false - the core signal() / computed() / effect() went stable within months of their 2023 preview. I caught it; we reframed it to the true arc (first experimental signal() in 2023 → the complete stable toolkit in v22). An Angular audience would have torn the original apart.
• A perfectly confident author-bio sentence had an unclosed parenthesis that ran two thoughts together - invisible until you read it aloud.
• Marketing copy and the website still pointed at a retired coupon code and an old paperback price ($29.99 vs the new $24.99). Stale links and prices are exactly what an agent won't know to question.

None of these are reasons not to use agents. They're the reason to stay the editor-in-chief. The model drafts; you own what ships.

The result, and a framework you can reuse

The Angular v22 Edition is live - on Leanpub and Amazon, with the website and blog updated, releases auto-tagged by semantic-release, and a free update for everyone who already owned it. The whole thing, end to end, in 2 days.

If I distilled the system into something reusable, it's four rules:

1. Give agents ground truth, not just a prompt. The reviewer that could read the code repo caught the bug the writer invented. Connect your agents to the source of truth and they stop hallucinating.
2. Specialize the crew. One "do everything" assistant is mediocre at all of it. A reviewer, a marketer, a writer, a distributor - each with a tight job - compounds.
3. Let agents own the toolchain, not just the text. The biggest wins were build-pipeline fixes, not prose.
4. Stay the editor-in-chief. Drafts in, judgment on top, you hit publish.

Want the starter kit? The five agent definitions, with the strategy redacted, are in a public gist: the crew, sanitized.

What I'd do differently

Two things. First, I'd wire the code-repo verification even tighter into the writing loop, so a snippet is checked against runnable code the moment it's written, not in a later review pass. Second, I'd decide the launch metric up front - the "48-hour results" beat is free reach, but only if you know which number you're going to post before you launch.

Want the book the crew rebuilt? Mastering Angular Signals - Angular v22 Edition is out now: signals from the fundamentals to Signal Forms, httpResource, linkedSignal, zoneless, and a step-by-step RxJS/NgRx migration - with a foreword from the Angular team at Google. Get it DRM-free on Leanpub, or on Amazon.