Unit tests in the same file wastes context and makes the whole thing hard to navigate for humans and machines alike.

nah, the agents jump around files anyways.

I’ve been doing the least amount of unit tests possible and doing debug asserts instead.

Normally I would put as many invariants in the types as possible, then tests cover the rest. I'm curious how you do this/what you use it for though. Would be cool if you had any examples.

It’s about the best possible documentation.

It isn't documentation. It is example code, in the best case. That shit belongs in other files, not in the main file. There is also a reason why literate programming never took off in general. Good luck getting anything done when 80% (conservatively) of the stuff you have to scroll through contributes nothing to the actual execution of the program and might actually be giving you false impressions of how things need to be done.

I have yet to see a single Rust file where the test comes before source and takes 80% of the file content.

Probably because all the tests are trivial, and people have the bias to not add all the testing that is needed inline with the code.

You can add a callback to e.g. Claude to guarantee it does a cargo check and test.

Fwiw i used to do this (and with lints) - it was the only way to make Claude consistent in the early days when i first started using it (~August 2025).

For many months now though, Claude is nearly consistent with both calling test and check/clippy. Perhaps this is due to my global memory file, not sure to be honest.

What i do know, is that i never use those hooks, i have them disabled atm. Why? Because the benefit is almost nonexistent as i mentioned, and the cost is at times, quite high. It means i cannot work on a project piecemeal, aka "only focus on this file, it will not compile and that's okay", and instead forces claude to make complete edits which may be harder to review. Worst of all, i have seen it get into a loop and be unable to exit. Eg a test fails and claude says "that failure is not due to my changes" or w/e, and it just does that.. forever, on loop. Burns 100% of the daily tokens pretty quick if unmonitored.

Fwiw i've not looked to see if there's an alternate way to write hooks. It might be worth having the hook only suggest, rather than forcing claude. Alternatively, maybe i could spawn a subagent to review if stopping claude makes sense.. hmm.

I find this doesn't work automatically for me because the projects I'm on have a lot of conditional compilation feature flags that it doesn't quite understand how to cargo check properly, unless I tell it.

Maybe for your case you could create a /maybe-check command, and run that in the hook? Then specify the conditions under which a check/test is needed in there.

Even LLMs know they should write tests but hate doing it.

> if you explicitly ask agents to write/run tests, after a while agents just forget to do that

Add a single task using your project's preferred task-runner that performs all the checks you want the agent to adhere to: linting, test coverage, style checks, test, etc, and add a rule in AGENTS.md that agents should always run this tasks after edits, and fix any warnings or errors produced.

Add the same task to your version management's pre-merge checks, in case the agent (or colleague) forgets to check before pushing. This was good practice since before LLMs, but I never was a fan of having such checks to pre-commit hooks.

This is good advice but it highlights the real issue -- were encoding agent workflow into markdown files and hoping the model follows instructions consistently.

AGENTS.md saying "run tests after edits" works until the agent decides it knows better, or the context window gets long enough that it deprioritizes the instruction. The language you write agents in matters way less than the state layer they operate on.

Ive been using ctlsurf for this -- structured blocks agents read and write through MCP. Task checklists the agent checks off, key-value state it updates, append-only logs of what it did. The project owns that state, not the agent session. Instead of "put a rule in AGENTS.md" you have actual task state the agent queries and updates, and a human can see exactly where it is.

The whole thread is debating Go vs Rust vs Python but the language is maybe 10% of what makes an agent reliable in production. The other 90% is state management, and right now most people are doing that with flat files.