Remix.run Logo
aleqs 2 hours ago

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 2 hours ago | parent [-]

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.