AI Inside the Library Boundary In short: Inside a library, the dangerous AI output is not the code — it is the export. Give an agent free rein over internals and a hard stop at , and you get most of the speed with none of the permanent damage. The previous six lessons built a boundary, a public API, and a set of private internals. This one is about working inside that structure with an agent, because the risk profile is different from an application. Reversible and irreversible The single most useful idea in this lesson is the split between changes you can undo and changes you cannot. Change Reversible? What it costs to undo --- --- --- Rewriting a component's template Yes A commit Adding an internal helper Yes A commit Restructuring internal folders Yes A commit Adding a story Yes A commit Adding an input to a public component No Deprecation cycle, major version, 20 teams Adding an export to No Same Renaming a documented CSS custom property No Same Adding a dependency to Mostly not Every consumer inherits it An agent working in an application makes mostly reversible changes. An agent working in a library makes reversible changes and has an easy path to irreversible ones — because the most natural way to satisfy almost any request is to add an input. So the strategy is not "restrict the agent". It is: wide latitude below the line, a hard stop at the line. The library rules block Add this to your , alongside the Chapter 1 and Chapter 2 blocks: The "preferred alternatives" block is what makes this work. A constraint with no alternative produces either a violation or a stall. A constraint with a named alternative produces the design you wanted. What good delegation looks like Well-scoped, reversible: > Add stories to for the empty, single-step, and long-label cases described in the chapter. Do not change the component. > The stepper's SVG connectors overlap on narrow containers. Fix it inside the component. Do not change the public API. Run the tests when you are done. > Write unit tests for covering the sort states in . Query by role. Requires a proposal: > Make the stepper support branching paths. That last one probably needs a contract change — has no notion of branches. The right output from an agent is a short proposal, not a new optional input plus a boolean. Let it verify itself The MCP tools from Chapter 1 do more work here than anywhere else, because a library has real checks to run: Step 3 is underrated. fails the build if a public signature references a type that is not exported — which means the "type leak" from lesson four is caught by the build, not by review. An agent that runs the library build finds its own leak. The check that actually stops it Rules and workflows raise the odds. One CI job sets the floor: Paired with CODEOWNERS from Chapter 2: Neither of these is an AI feature. That is deliberate — Chapter 2's lesson holds here. A guardrail that only applies to agents is a guardrail you will forget to maintain. Feeding the library to consumers' assistants There is a second, less obvious opportunity. Your library's consumers also use AI assistants, and those assistants have never heard of . You can fix that, and it is cheap. Publish a context file alongside the package: Angular does exactly this for itself, with and at angular.dev. It works for the same reason: a model that can read what your API is stops guessing at what it might be. The payoff is asymmetric. One file, written once, reduces the "the AI invented an input that does not exist" support questions across every consumer team. "But I thought the linter already covers this" After Chapter 2 this is a fair conclusion — we made the argument that architectural guardrails work regardless of who is typing, and that stands. The boundary rules do catch an agent importing into the library. The gap is that the dangerous change here is not a violation. It is legal, well-formed, correct code. No boundary crossed. No business vocabulary. No forbidden import. Types are strict, naming is good, it compiles, and the tests pass. A linter has nothing to object to, because nothing is wrong with the code — what is wrong is that you have permanently expanded a contract in a pull request titled "fix connector overlap". This is the difference between the two chapters' problems: Chapter 2 problem Chapter 4 problem --- --- --- The bad change is Illegal Legal Detectable by lint Yes No Detectable by diffing the API surface — Yes Detectable by tests No No Reversible Yes, before merge No, after release Right control A lint rule Review of a specific file Which is why the control shifts from rules about code to review of a diff . The guard and CODEOWNERS are not redundant with the linter; they cover the category the linter structurally cannot. The general principle worth carrying forward: automate what is objectively wrong; require a human for what is merely permanent. Cheat sheet Zone Agent latitude Control --- --- --- Templates, styles, internals Full Tests + bui…