Live data from Hacker News

My agent.md to improve LLM-assisted code quality

fabiensanglard.net

101–110 of 200 posts

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

#101

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…

> A bunch of these should be enforce with linting

Agreed. One of the first rules I toss into Biome is `noNestedTernary` - LLMs seem to adore completely unreadable nested expressions.

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

#102
post #89

Earlier quoted context omitted.

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

If you don’t trust the code to write a decent comment, why trust it write good code? Of course, ensuring compilation or other checks can verify some code, which it can’t do for comments. But comments still serve the same purpose as human comments.

If I understand correctly, it’s not that the LLM can’t write a good comment, it’s that you want to be able to interpret and understand the generated code without comments - and in that process end up writing comments yourself.

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

#103

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.

It turns out that thinking about and executing these commands at a superhuman speed is, to ape Claude, the real unlock.

Yeah, I've actually found in my own testing and usage of LLMs that this is where I get a lot of benefit. I already have fd, ripgrep, etc. installed and know how to use them, but it's not hard to tell the LLM to do it and it often finds things just as well. Or even better.

It's especially handy on modern style code where things get broken up across a multitude of files based on convention.

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

#104
post #41

Earlier quoted context omitted.

I would never tell an agent to write "what does the code do" comments. Their default comments are already way too fluffy.

But then you don't know about where the load bearing seams are!

Honestly? That’s the kicker.

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

#106
Great stuff. AGENTS.md is not the ideal place for most of it though. Most of what is shown in this article can go in CODING_STANDARDS.md. The skills that I use find this document when it is needed (writing and reviewing code) so it doesn't pollute context when code is being read.

I also have sub-agent reviews (both of a planning phase and the produced code) that would catch some of these problems and demand revisions. [1]

> - If the prompt indicates that a bug is being fixed, don't write the fix right away. First write the test. Observe it failing. Then write the fix. And observe the test passing.

I always use /tdd [2]. Occasionally it results in some silly tests, but it produces much lower defect code. Its not just for bugs.

[1] https://github.com/gregwebs/skills-sdlc/

[2] https://github.com/mattpocock/skills/blob/main/skills/engine...

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

#108

Earlier quoted context omitted.

"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.

Today Codex decided that it could resolve the blocker by just changing the mandatory policy it was running up against into an “advisory policy.”

That's what we get to training LLMs on https://en.wikipedia.org/wiki/Kobayashi_Maru.

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

#109
Hm. I'm curious if this actually helps LLMs iterate on the code, or if it's human nitpicking over things that the author won't really look at? How would you measure?

Personally, I tend to do 3 passes, where I ask the agent to write, and self review; that's been enough to get things functional enough that I don't need to read the code.

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

#110

Earlier quoted context omitted.

I would never tell an agent to write "what does the code do" comments. Their default comments are already way too fluffy.

Hmm, I guess everyone here is using Claude? I find that Sol is much more restrained, to the point where I have a prompt to tell it to add short comments for things that are not obvious. Really, I find the verbosity problem to be worse in tests. I regularly prompt my review agent to remove tests used only for scaffolding to write the code in the first place. The agent is in a way following strict TDD, which reminds me…

Sol adds comments when I use it, but it's not nearly as verbose as Opus 5/Fable.

For the latter I'll often include an example of a comment it wrote, along with my own rephrasing, and tell it that "future readers will understand code context; good naming is the best documentation". This works alright if I include in the actual prompt, but annoyingly it often doesn't in CLAUDE.md or memory.

Post reply on HN