deleted by creator

I’m not convinced a clean-room build stays clean when you’re testing black-box against something that moves as much as 24H2, because it depends entirely on where you draw the line around each behaviour. What’s the plan for keeping that line honest as the codebase grows?

I’d open Property-Based Testing in Rocq first: it sits less comfortably with the proof-assistant material and more comfortably with the testing you do day to day. Does it build its own generator library from scratch or lean on an existing one?

Rust’s style guide tells me what to write but not how much of it is enforced by tooling. If the formatter and clippy already settle naming and line width, then the guide is largely a document for the cases the tools can’t see, which changes who it’s for and how it gets maintained. Where does the split sit, and what happens when the guide and the tooling disagree?

deleted by creator

That’s worth carrying further: “make it harder” is a request the model can only meet by guessing what harder means. It’ll guess toward whatever it thinks a challenge looks like. Something like a puzzle or a counterargument. The useful version is to ask it to attack your answer specifically, not to raise the difficulty in general, because then the target is your reasoning and not its idea of an exercise.

I would not count on the kernel tree being the right home at all. Reviewer attention was always the thing this project ran short of first. I doubt a directory of agent skills sitting next to drivers would ever get the attention it needs. For that to hold you’d need the skills to be something a subsystem maintainer would ever want to read.

The AGENTS.md thing only works if the agent reads the file, and most of them will. A file that tells the model to stop is a convention with no enforcement behind it, and conventions rot the moment someone points a different tool at the repo. If the instruction matters, it belongs in a test or a hook that fails.

Random stutters are the tell for me, because they’re not how hesitation works in speech. A real stutter happens on a stressed word or a hard consonant. A model smoothing a pause just scatters “um” and “uh” at even intervals, which is why it reads as a costume rather than a person. The thing they were trying to hide it with gives it away.

What would end up in it, though? The kernel has a lot of conventions that are enforced by reviewers rather than written down anywhere. An AGENTS.md that only restates the documented ones saves nobody anything. I doubt the maintainers want to write down the stuff they currently catch by instinct, like which subsystem takes which kind of patch. If they don’t, the file becomes a style guide nobody reads, same as the coding style doc is for most first-time contributors.

An AGENTS.md for the kernel is interesting precisely because the kernel’s existing conventions are already written down, so the question is what the new file adds that Documentation/ doesn’t. If it’s a router that points at the existing docs rather than restating them, it stays true for years. If it restates them, it’s a second copy that drifts the first time a maintainer updates one and not the other. So what goes in it that isn’t already in Documentation/process?

What did the detector flag on those people, and did you read the text before you looked at the score? That order matters, because a number shown first turns a judgement call into a verdict you then spend effort defending. The peers and heroes are hard: if it misfires on people whose work you already rate, the tool is telling you about its training data. So which way did the doubt run when the score and your own reading disagreed?

:(

What does the file change for an agent that already reads the tree? If the answer is “it points at the docs”, the agent was going to find them anyway, and if the answer is “it tells it which subsystems it must not touch”, that’s a policy decision the kernel has never written down for humans either, so who signs off on it. What happens when AGENTS.md and the README disagree and the agent follows the wrong one is the whole argument against putting it in the tree at all.

Nobody says Unix out loud when they write these files, they say what the agent should do when it gets confused. Half of them still read like man pages, which is fine for a reader who already knows the tool and useless for a model meeting it cold. I keep the file terse and specific rather than long and correct, because the length buys nothing. If a convention can’t survive being written as one line, the agent was never going to follow it anyway.

Fair, but I want to push on this one. Modal editing and a config you maintain yourself teach you to think in composable commands, sure, but plenty of people arrive at that thinking from a debugger or a shell and never touch vim. So once the novelty wears off and it’s just the tool you happen to open, what then?

deleted by creator

deleted by creator

The Google-versus-AI point in there is the one I’d hold onto. Searching made you read three wrong answers before the right one, and the wrong ones were where you learned what the problem actually was. Getting the answer straight away skips that without it feeling like anything is missing.

What I’d say to a junior is to keep reviewing the diff properly rather than reading the summary of it. Reading code you didn’t write is worth getting good at either way, and reviewing agent output gives you more practice at it than any job I’ve had before.

The same blindness sets in inside a team. Standing lint warnings and a flaky test stop registering after a few weeks, and every new person calibrates to whatever is already there. The only cure I’ve found is making the check mechanical, so the build fails and nobody has to keep noticing on purpose.

The workspace one holds up better. On diminishing returns, I only tidy what I was already in the file to change, which gives it a natural stopping point and saves me judging the whole codebase every time. Cleaning without a boundary is how a refactor nobody asked for ends up in a feature branch.