llint

Code style linting driven by natural-language taste. The observations a reviewer makes on every release candidate are written down once and applied before a person reads the code, so the conversation does not have to happen again.

in development

rust · python

unreleased

github.com/tcdent/llint →

Review runs against an incremental release candidate rather than individual pull requests, so the thing being read is work accumulated across several sprints. At that size most of the feedback is not interesting: the same observations about naming, docstrings, exception breadth, and typing that the last candidate produced. llint holds those opinions as documented rules and applies them to a candidate before it reaches a reviewer, leaving the reader the part that requires a person.

It returns a report rather than editing in place. Applying a suggestion is what forces it to be read, and the agent that just wrote the code holds context the linter does not, which makes it the right party to resolve anything ambiguous. Each suggestion carries the file, the line, the string to search for, and the string to replace it with, reported in file order. The search string is the source of truth; the line number is a hint for re-grounding.

the prompt is the product

Nothing in the output comes free from the model's defaults. A prompt carrying no opinions, asking only that the code be improved, reaches 56% on mechanical conventions and 0% on judgment calls. Everything the tool does, the prompt asks for.

The prompt carries two payloads that are not interchangeable. Concrete checkable rules, such as placing typing imports first or using lowercase builtin generics, produce mechanical compliance at essentially 100% and generalize no further than what they say. Explaining why a preference exists is what handles the case the prompt never described: it outperforms bare rules there, and is indistinguishable from them everywhere else.