Live data from Hacker News

My agent.md to improve LLM-assisted code quality

fabiensanglard.net

71–80 of 200 posts

Re: My agent.md to improve LLM-assisted code quality

#71

A great piece. I esp liked: "- Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature." The feature where you ask the LLM to fix one thing and it fixes three things. I kept noticing this in diffs.

> As much as possible try to minimize the number of changed lines when implementing a feature

Great way to get LLMs to start making an endless profusion of methods instead of adding parameters to or switching to a richer return type from an existing method, in my experience.

I’m tired of seeing “get_total_rounded_up” + “get_total_float” bloat when a few changes to unrelated code to round floats to ints would keep the method API surface small.

Re: My agent.md to improve LLM-assisted code quality

#72

I disagree with the less than 30 characters. Im against restricting anything related to code length this goes for function names and length, file length ect. I rather the dots be as close as possible than trust the agent connects the dots. I dont care if the file is 5000 lines I rather the agent reads one file and get all the context than trust it will read all the need files. I see so many review skills that puts ha…

When it's instructions for agents it's not really "hard" limits, the agents can go more or less

Re: My agent.md to improve LLM-assisted code quality

#73

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…

Incidentally, I'm from the opposite school and consider every “if” followed by a braced block a smell. If a conditional body needs a block, it's doing enough to deserve a name, so I promote it to a single named call, à la "Extract till you drop".

Another phrase for this is "functional decomposition", which usually is a good thing.

Better yet is to identify conditional execution paths as early as possible in order to obviate conditionals in the call tree. For example, identifying a "create a new something" verses an "update an existing something" based on the workflow initially invoked greatly simplifies service and/or persistent store logic.

Re: My agent.md to improve LLM-assisted code quality

#74
post #38

Earlier quoted context omitted.

I forbid my agents from adding any comments. I review the code and add comments manually. If I can't understand something despite having the context then I throw away the code instead of having an LLM generate comments to explain what it did. This way the code stays readable/debuggable by humans.

How do you stop LLMs from making comments? In my experience, LLMs treat requirements for code output as suggestions

Ask the agent to write a script to run after each changes, against the newly added code.

Use that script as a super linter.

That’s the only way I found to strictly enforce some rules, like the no comments rule, without enforcing them against my own changes or old code.

Re: My agent.md to improve LLM-assisted code quality

#75
post #32

Earlier quoted context omitted.

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.

The best way I've found to solve this is using LLM as CI - use a small cheap model to inspect the diff and look for those kinds of comments. Prompt left to the observer but using `claude -p` / `codex exec` gets you a lot cleaner output usually, and makes robots fight robots instead of you constantly having to reprompt and it ignoring you.

I've reached that point as well. Is there a preferred model and prompt you use for that?

Re: My agent.md to improve LLM-assisted code quality

#76

Just this one line in AGENTS.md has given better results to reduce if not eliminate verbosity and grandeur. **Always use ASD-STE100 Simplified Technical English Disclaimer: I saw this listed in some other HN post that I can' locate right away.

Agreed. ASD-STE100 makes automated code reviews tolerable.

Re: My agent.md to improve LLM-assisted code quality

#77

A great piece. I esp liked: "- Don't touch blocks of code unrelated to the feature you implement. e.g. Don't add comments to a block of code if you did not create it or modify it. As much as possible try to minimize the number of changed lines when implementing a feature." The feature where you ask the LLM to fix one thing and it fixes three things. I kept noticing this in diffs.

An earlier version of Gemini used to do this a lot to me back when I used it for some light tinkering around on my projects. "Oh by the way, I fixed a misspelling in a comment file completely unrelated to the feature you asked for, so I fixed that as well, shall I commit everything now?" GAHHH. NO.

These days I have an instruction in my default AGENTS.md to bring issues unrelated to the prompt to my attention when found, but never to just automatically fix them.

Re: My agent.md to improve LLM-assisted code quality

#78

Just this one line in AGENTS.md has given better results to reduce if not eliminate verbosity and grandeur. **Always use ASD-STE100 Simplified Technical English Disclaimer: I saw this listed in some other HN post that I can' locate right away.

Do you give the model access to the ASD-STE100 spec for reference/review or are you just assuming that enough of it is baked into the model for it to mostly adhere to it?

Re: My agent.md to improve LLM-assisted code quality

#79
post #58

This is a problem that people mostly have to solve themselves. Like, I've been working with Claude for almost a year now and I have never once seen it write "Arrow Anti-Pattern" code. That, and much of the rest, would be fluff in my projects. Agent instructions are best learned from experience project-by-project.

Yes, the interesting part about seeing other people's agent.md files, is getting to see what issues they have with working with agents. Seems different people run into very different issues, which probably is caused by how differently we work. So a the file probably should be personalised.

Might also be per model. Different models might have different issues and require different instructions

Re: My agent.md to improve LLM-assisted code quality

#80
post #50

Earlier quoted context omitted.

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.

So it turns out that a lot of these unix utilities have such bad UX that having a tool that knows how to really leverage them feels like a superpower. If you've ever used an LLM to deal with ffmpeg you'll know exactly what I mean.

It is incredibly difficult to make an UX that can beat simply typing what you need in your own words.

You think of what you need, and you type it. No need to even ask “what options should I use?”

Post reply on HN