[aleqs]

At the end of the day LLM output is not deterministic, and the burden shifts from writing code to reviewing it. It makes sense to cover the review surface with deterministic checks/validations as much as possible - unit test, linters, static analysis tools, e2e integration test etc. one gap I noticed when it comes to such tools is that they are generally language/stack specific and don't cover things like file/directory structure/naming, file relationships/references, use of potentially harmful Unicode [0], general file/config structure, permissions, broken symlinks, files which should not be committed but are, etc. , etc. I've been building a tool - a general repo shape/structure linter, with extensible config/rules - to cover these cases in a deterministic way [1] [2].

[0] https://snyk.io/articles/defending-against-glassworm/

[1] https://github.com/asamarts/alint

[2] https://alint.org/

[meerita]

I have my own tooling set in every project https://www.minid.net/2026/6/1/my-ai-workflow. I have couple dozens of make commands, that perform all the checks. I can do them manually after I finish coding or, I relegate these to the AI. If something is wrong, that's when I intervene. If nothing is wrong, that's because I've spent quite some time checking every single change.

[aleqs]

I'm curious what validations/checks you find most useful in your workflows? alint basically started with me taking a bunch of make/shell scripts I already had and combining them into one tool, with some added niceties, and much better performance.

I find manually reviewing every change simply does not scale past a certain point. You need to rely on AI reviews and deterministic static analysis tooling, tests, modeling/verification, etc. to do the much of the heavy lifting.