Millisecond Feedback: Static Analysis and Code Standards

An Agent writes a line of code. How quickly can it know whether that line is correct?

If the answer is "wait for the tests to finish", that could be seconds to minutes. But there is a class of problems that does not require tests at all: type mismatches, unused variables, inconsistent formatting, missing imports. Linters and type checkers can catch these the instant code is written, with feedback delay approaching zero.

For human programmers, linters are a nice-to-have. You can write code without them; the experience is just a little worse. For Agents, linters are the lowest-cost feedback channel. Every tool call an Agent makes consumes tokens. If a type error is only discovered after running the full test suite, the Agent may have already written a dozen functions based on a faulty assumption. Linters intercept these problems at the source, directly shortening the survival time of deviations.

A few configuration principles matter in practice.

Rules must live in the repository, not in individual developer environments. .eslintrc, pyproject.toml, rustfmt.toml — these files must exist in the repo so that Agents can use them immediately upon cloning, without any additional setup. If linter configuration is scattered across developers' IDEs, Agents cannot see these constraints at all.

Rules should be strict but stable. Frequently changing lint rules produce noise: code that passed in one iteration suddenly fails in the next because the rules changed, and the Agent cannot distinguish its own mistakes from environmental shifts. Once rules are set, do not adjust them while Agents are working.

Formatters should auto-fix rather than report. Agents do not need to be told "your indentation is wrong". They need prettier --write or gofmt to fix the formatting directly. Turning formatting from "feedback" into "auto-repair" eliminates an unnecessary iteration cycle.

Finally, the value of static analysis has shifted subtly in the Agent era. Past debates about code style (tabs vs spaces, naming conventions, line length limits) were largely about human readability. As code is increasingly generated by Agents and consumed by Agents, the dimension of "is the code aesthetically pleasing to humans" matters less, while "is the code consistent for machines" matters more. Structural principles like high cohesion and low coupling remain important, but aesthetic rules around naming style primarily serve codebase consistency rather than any individual human reader's preference.