AI-Assisted Migrations That Stay Reviewable In short: Use an agent to write the schematic, not to edit twenty repositories. A tested script that makes the same edit everywhere is reviewable; twenty individually-reasoned diffs are not. Migrations look like an obvious job to hand to an agent. Twenty repositories, one mechanical rename, tedious work. The instinct is right and the framing is wrong, and the difference decides whether the result is trustworthy. Write the tool, do not do the work Two ways to run the → migration from lesson three. Delegate the edits: > "In each of these twenty repositories, find every binding on and rename it to ." The agent opens each repository and makes changes. Twenty diffs, each produced by fresh reasoning over that repository's code. To trust the result you must review all twenty in full — because each one was decided independently, and a mistake in repository 14 is not visible in repository 3. That is not less work than doing it manually; it is the same work, moved to review, where it is harder. Delegate the tool: > "Write an Angular migration schematic that renames the input on to . Use from — do not use regular expressions. Include tests for: property binding, static attribute, a different component with the same attribute name, occurrences inside comments and text nodes, and idempotency." Now you review one script and its tests. The script makes the identical edit everywhere, and its correctness is established by tests rather than by twenty readings. Agent edits 20 repos Agent writes the schematic --- --- --- Artefacts to review 20 diffs 1 script + tests Consistency Reasoned per repo Identical by construction Verifiable By reading By tests Rerunnable on repo 21 Start again A missed case is found Per repository Once, by a test Consumers can run it themselves No Yes The last row matters most. Chapter 9's whole argument is that consumers upgrade themselves with one command. An agent editing their repositories does not scale to teams you do not control. The rule: an agent's output should be a tool you can test, not a change you have to trust. Where agents help across this chapter Task Delegate? Why --- --- --- Writing a migration schematic Yes A known transformation with a test harness Writing schematic tests Yes You specify the cases; it writes them Drafting the migration guide from the API diff Yes Structured input, structured output Finding every usage across repositories Yes Search, and the result is verifiable Deciding whether a change is major or minor No Judgement — use the lesson-one table Writing the deprecation warning text Draft only Consumer-facing wording Deciding what qualifies for a backport No A policy decision Resolving a cherry-pick conflict Draft only Semantic, needs the original author Two patterns in that table. Mechanical transformations with a testable output: delegate. Anything that sets policy or is read by a human: draft at most. That second one is Chapter 7's lesson recurring. An invented business rule and an invented deprecation message fail the same way — plausible, well-written, and not what anyone decided. The usage survey Before removing anything, you need to know who still uses it. This is a genuinely good delegation because the output is checkable: The last sentence prevents the quiet failure. A survey that silently omits three files is worse than no survey, because you delete based on it. Then verify the count independently before acting: If the numbers disagree, the survey is wrong and you find out in ten seconds. Drafting the release note Chapter 8's API diff already produces a structured list of what broke. That is good input: Those last two rules matter. An agent will confidently write "estimated effort: 30 minutes" and "this will improve your team's productivity" — both invented, both the sort of claim that erodes trust in the whole document when it turns out to be wrong. Leave the placeholders visible. Missing work that is marked missing is fine; missing work that has been filled in with plausible text is not. The rules file block The gate does the checking Nothing new is needed here. A generated schematic is code, and it goes through the same pipeline as everything else — plus one addition worth having: That second check exists because the failure it catches is invisible. A missing entry produces no error anywhere — runs, reports success, and migrates nothing. It is exactly the kind of omission a model makes, because is the file that looks like the answer. "But I thought an agent editing repositories directly would save the most time" On the surface it clearly does. Twenty repositories, an agent that can open all of them, no tooling to build. The schematic route requires writing and testing a script first — strictly more work before anything changes. The time saved is real. The problem is what you have at the end. You have twenty artefacts and no way to verify them cheaply. Each diff was produced by separate reasoning, so consistency…