Gating AI-Generated Code: Scoring Before Review In short: Every gate in this chapter already works on machine-written code, because none of them ask who typed it. Two things change: volume, and the fact that you can now measure your prompts the same way you measure your code. Chapter 2 argued that you should not build AI-specific guardrails — automate the architectural rules and they hold for everyone. That argument holds here, and the pipeline you have built needs almost no modification. What changes is throughput. When a meaningful share of pull requests are agent-assisted, three things follow. What actually changes Volume goes up, review capacity does not. Twice the pull requests with the same reviewers means each one gets half the attention. The gates absorb that; human review does not. This is an argument for more automation, not less. Plausible-but-wrong becomes the dominant failure. A tired human writes code that is obviously wrong — a typo, a missing case. A model writes code that is well-formatted, well-named, and confidently incorrect. Chapter 7's invented threshold is the archetype: it compiles, it renders, and the generated test asserts it. Failures cluster. If a rules file is missing a line, that mistake appears in every pull request until someone notices. Human mistakes are distributed; machine mistakes are systematic. Which is bad — and also useful, because systematic mistakes are the kind you can measure and fix at the source. The gates you already have Failure Caught by Chapter --- --- --- , , ESLint 1 Invented input on a component 1 Cross-boundary import 2 Business vocabulary in the library 4 A widened public API API diff + CODEOWNERS 4, 8 -style content input ESLint naming rule 5 Hardcoded hex, , utility classes Stylelint 6 Media query used for component layout Stylelint 6 Adapter in the wrong library Boundary lint 7 Layout broken in dark mode Visual regression 8 Contrast regression 8 That is most of it, and none of those rules mention AI. Which is the point — they were correct rules before, and they are load-bearing now. Score the prompt, not just the code This is the genuinely new capability, and it inverts the usual approach. Angular publishes Web Codegen Scorer , an open-source tool for evaluating the quality of LLM-generated web code. It runs built-in checks for build success, runtime errors, accessibility, security, coding best practices, and an LLM-based rating, and it works with any framework and any model. What it is for is the useful part: iterating on a system prompt to find the instructions that actually work, comparing models against each other, and tracking whether generated quality drifts as models change. The Angular team built it to tune their own prompts against the current state of the framework. That reframes the problem. Instead of catching bad output one pull request at a time, you measure your rules file as an artefact and improve it: A workflow that fits this course: 1. Write ten representative prompts — "a status card", "an adapter for this DTO", "a custom form control", "an accessible tab set". 2. Score them against your current . 3. Read the failures. If eight of ten produce , your rules file is not saying it loudly enough, or a stale example in the repository is outvoting it. 4. Change the rules file. Re-score. Keep the version that scores better. 5. Re-run when you upgrade Angular or change models. That last step matters more than it sounds. When Angular 23 ships, your rules file is instantly partly out of date, and the scorer tells you which parts. Fitness checks in CI Beyond the standard gates, three cheap checks catch the specific shapes of machine-written code. Duplication. Agents re-solve rather than reuse, because they do not know a helper already exists. Dependency additions. A model will happily reach for a library to solve something small. Unused exports. Generated code accumulates helpers nothing imports. None of these should hard-fail on their own. They are signals for a reviewer, and they answer questions humans are bad at holding in their heads across a large diff. Label the origin Not to distrust the code — to measure it. With that label you can answer real questions: are agent-assisted pull requests failing more gates? Which gate? Did that improve after we changed the rules file? If agent PRs fail the Stylelint hex rule three times as often as human ones, that is not a reason to restrict agents. It is a reason to put the token list in the library's , as Chapter 6 suggested — and then to verify the fix in the numbers. Where humans must stay The full list, gathered from earlier chapters, because it is short and it is the whole risk: Cannot be automated Chapter --- --- Is this a business rule someone actually decided? 7 Is this user-facing wording right? 7 Is this the right API shape, even though it is legal? 4 Is this the right token, even though it is a token? 6 Is this text meaningful? 8 Should this be a permanent public promise at all? 4 Every…