A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why . Use examples when possible. Propose ASCII drawin…
I would never tell an agent to write "what does the code do" comments. Their default comments are already way too fluffy.
My agent.md to improve LLM-assisted code quality
41–50 of 200 posts
Re: My agent.md to improve LLM-assisted code quality
#42Earlier quoted context omitted.
> but one genuine blocker is removed and the next blocker is isolated with evidence. What's the difference between a "genuine blocker" and a "blocker"? Why is the next blocker not genuine? Does it become genuine only after isolation?
"Genuine blocker" is mostly there because otherwise LLMs may consider the smallest thing that they couldn't immediately figure out to be blockers and stop without implementing anything. The rule is there to tell the LLM if they can figure out how to resolve the blocker by themselves, they don't have to ask me to help resolve the blocker.
Re: My agent.md to improve LLM-assisted code quality
#43A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why . Use examples when possible. Propose ASCII drawin…
Right. I've really struggling to get AI to stop explaining the what. It seems to add it to the commits, PRs, code, wherever it feels like. I've put in multiple places to not write the "what", but the "why", and in multiple ways, but it still does it in one or other place.
Re: My agent.md to improve LLM-assisted code quality
#44- new model comes out and a bunch of it becomes obsolete
- they get flat out ignored, esp. with larger context windows. The ai just responsds with, "your'e right I shouldn't have done that"
- they sometimes end up poisoning the reasoning because the rule gets interpreted in an unintended way.
Re: My agent.md to improve LLM-assisted code quality
#45Since we are sharing our AGENTS.md, I thought I'd share my own, because most of the time, this is pretty much all you need for LLMs to write good code, everything else can be added per project: ---- *Convergence rule* Every substantial task must end in exactly one of three states: A. Success The intended capability works in the real path and the real motivating case materially improves. B. Meaningful progression The…
How often would you say step C happens and the agent stops when it can’t proceed?
Re: My agent.md to improve LLM-assisted code quality
#46Just say, complete this bit like how the rest is...
Even then they aren't great at it. Idk, the best case use for LLMs are extremely specific requests, for example "write an evaluator for this byte code and if you can't ask for clarification"
The ultimate specification language is code anyways so you might as well stick a to-do, a comment describing the semantics of the function and say "okay codex fill the to-do"
Re: My agent.md to improve LLM-assisted code quality
#47- https://www.minid.net/2026/7/14/how-to-automatise-with-ai
But in summary: the more bloated your AGENTS.md is, the worse the context consumption gets. The best approach I use is telling the agent to first think about what it needs to do, then choose which rules apply. I got 100% consistency across every area of my projects.
In the post there's also a replica of one of projects rules I use, feel free to provide feedback: https://github.com/meerita/monorepo-nextjs-golang-rust-pytho...
Re: My agent.md to improve LLM-assisted code quality
#48What's the point of agents.md if you just use an LLM on a codebase? Just say, complete this bit like how the rest is... Even then they aren't great at it. Idk, the best case use for LLMs are extremely specific requests, for example "write an evaluator for this byte code and if you can't ask for clarification" The ultimate specification language is code anyways so you might as well stick a to-do, a comment describing…
It's much easier to follow the rules than it is to compute the rules on the fly all the time.
Re: My agent.md to improve LLM-assisted code quality
#49A bunch of these should be enforce with linting, that way people who still hand-craft code get the same kind of feedback, e.g. Always use {}, even on a one-line "if" statement. & Keep function names short. Less than 30 characters. Then this one really is a pattern that creates a lot of churn: - Add a small, to the point, comment to explain what the block does and why . Use examples when possible. Propose ASCII drawin…
> Write in-code comments that describe _why_ code or a class does what it does, but not _what_ it does. The "what" should be self-evident.
Re: My agent.md to improve LLM-assisted code quality
#50Earlier quoted context omitted.
My biggest pet peeve with agents is when people beg their (non-deterministic) agents to do something that a lint rule could've accomplished
Seems like 80% of agent use boils down to: grep | sed -i Which is kind of cool if you’re unaware enough to know to do it yourself. Oh, and find. Agents use find a lot.
If you've ever used an LLM to deal with ffmpeg you'll know exactly what I mean.