Every Senior Developer Believes in DRY

Yesterday I wrote about making your engineering principles explicit for agents. Writing them down is the first step. But what happens when agents read the rules and break them anyway?

I have enforced DRY for fifteen years. Don’t Repeat Yourself. Every senior developer believes in it. Refactor duplicated logic, extract shared components, centralize configuration.

I wrote it in my agent instructions. “Use theme tokens. Don’t hardcode colors.” Clear, direct, explicit.

They did it anyway.

So I stopped asking and started enforcing. I built an ESLint plugin that makes DRY non-optional. Every hardcoded hex color, every raw fontWeight, every inline fontFamily triggers a lint error. The agent cannot commit the code. It has to use theme references instead.

You can see it yourself: eslint-plugin-theme-guardrails

Here is the thing I did not expect. I should have built this years ago. Not for agents. For myself and every developer working in my repos. We believed in DRY. We just never insisted on it with tooling. We caught violations in code review and moved on. The agents forced the issue because they don’t learn from code review. They just do it again next time.

That is the real lesson. The principle was always worth enforcing. We just never did until the agents made ignoring it impossible to tolerate.

I built two more plugins after that. One for branded type safety, one for component architecture. Same pattern every time: I wrote the rule, agents ignored it, so I encoded it.

Prompting is asking. Linting is enforcing. If a principle matters enough to enforce in code review, it matters enough to encode in your toolchain.