Who checks the agents' code?

When agents produce code faster than a human can read it thoroughly, deviations such as raw values, deprecated variants, or wrong spacing go unnoticed. Additional coordination does not solve this problem. The check belongs at the points the code passes through anyway.

What can be checked automatically

• Raw values in CSS. The Stylelint plugin stylelint-declaration-strict-value allows only variables, functions, or approved keywords for specified properties such as color. This turns color: #fff into an error. Because functions like rgb() are allowed by default, you should restrict the ignoreFunctions option. The message option also lets you define a custom error text.
• Unknown classes and deprecated building blocks. ESLint rules exist for this, both ready-made and custom.

This approach cannot check whether the right token is used in the right place. No linter can judge whether a red surface actually marks a destructive action.

Messages an agent can work with

Current tools read error output and fix things themselves. For GitHub Copilot in agent mode, Microsoft describes that it monitors test output and attempts to fix failing tests. Claude Code works the same way with the output in the terminal.

This leads to a simple rule for your own checks. The message should name the permitted way, for example “Line 42: #ff0000 is not allowed, for destructive actions use var(--color-danger),” rather than a generic “Style check failed.”

How much responsibility the agent receives

I distinguish three levels. The classification serves as a decision aid and is not a standard:

1. Only flag. The linter reports, the human decides.
2. Self-correct. If a check fails that the agent runs itself or whose output it receives, it fixes the issue. Approval still comes from humans.
3. Self-merge. Certain changes go through without approval after tests pass.

For the third level, automatic merging of dependency updates provides a proven model outside of AI. The Renovate documentation recommends it for updates you would simply merge anyway, and requires good test coverage for production dependencies. Merging only happens after checks pass in any case. The same caution is advisable here. This includes a narrowly defined list of change types, tests you trust, and starting with exactly one type of change.

I am not aware of any published experience on whether level 3 works well for design system changes. At present, level 2 is the step that can be justified.

From the series “Design Systems and AI”. Previous: Tokens instead of guessed color values. Next: Prototypes from your own system: what Atlassian reports.