工程规范应放进智能体编码循环，而不是等 CI 才发现问题

"Quality gate failed." If CI is the first time your coding agent discovers it broke an engineering standard, the feedback is arriving too late.

The PR is open. The implementation now depends on a library that shouldn't be there, or a method has grown beyond the team's complexity limit. You send the agent back to unpick work it considered done.

We've known for years that earlier feedback reduces rework. Coding agents give us another place to apply that lesson.

Run the checks while the agent is still implementing.

Tests, linters, type checks and security scanning are obvious starting points. The more useful checks may be specific to your codebase. A dependency rule that stops the domain layer importing the web layer. A custom check for a pattern your team keeps having to remove.

"Keep methods simple" leaves the agent to decide what simple means. Give it a check that fails above the agreed complexity threshold, and require that check to pass before it calls the implementation complete.

I want the agent to make a small change, run the relevant checks, fix what fails and run them again. Return the results with the work. A developer should be able to run the same checks against the same code and reproduce them.

Sonar Vortex looks like a commercial example of this approach. Sonar describes it as giving agents project context and checking their changes inside the coding loop. Read Sonar's product announcement https://www.sonarsource.com/blog/introducing-sonar-vortex/

CI still matters. It independently runs the checks again before merge. Human review still has to judge whether the change makes sense. Passing checks only tells us it met the rules we've managed to encode.

When a standard can be checked, I'd rather give the agent the check than another paragraph asking it to behave.

Put the engineering standards where the engineering is happening.