Live data from Hacker News

My agent.md to improve LLM-assisted code quality

fabiensanglard.net

81–90 of 200 posts

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

#81

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…

[deleted]

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

#82

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…

> The what _is_ the code.

Even the why sometimes shouldn’t be a comment, unless it’s very immediate to the code itself. What’s often more necessary is a high level overview of the design of the solution, because that’s what drives the design of the code and link disparate section. Especially the glossary , which you let you understand the name of the symbols (variables, struct. functions,…) used in the code.

It’s like learning the culture associated to a foreign language instead of trying to translate each single word with a dictionary.

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

#84
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.

That seems like a really smart workflow I wish my coworkers would adopt this. I’m sick of reading a fucking Charles dickens novel for every fucking tiny function

[flagged]

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

#85
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.

I would rather bet that people don’t know that their problem has been solved for ages. Either they don’t know about the tools or can’t make the leap to think of using something like awk or sed to quickly script out their use cases. Or even quickly draft up a quick function/plugin in something like vim, emacs, sublime,…

In “The Pragmatic Programmer”, the power of unix tools and editor fluency is well argued. There are plenty of other books like “Unix Power Tools”, “Small, Sharp Software Tools”,…

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

#86
The most powerful change I have run into is: "Positive phrasing" as a default, prefer to tell the model what they should do, and why. Not a prohibition on a behavior.

When you say "don't do x" you are just pre-seeding the model with "x" and the prohibition mitigates that some, but not as much as never having put "x" in the context in the first place.

"Do Y, for these reasons" can be shaped to achieve what you mean by "Don't do X"

"Don't do X" leads to "Wait, I need to make sure I didn't X" and "Let's look up X to make sure I don't do that." And each time the odds of X happening keeps going up, not down.

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

#87

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.

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 why I don’t like TDD, even though some of the generated tests can be useful.

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

#88
> - Keep function names short. Less than 30 characters.

Recently I asked GPT to port a browser game to Rust. It voluntered this gem:

draw_image_with_html_image_element_and_sw_and_sh_and_dx_and_dy_and_dw_and_dh(...)

I thought it was smoking some good stuff, but it turned out, that is actually the name of the function!

https://docs.rs/web-sys/latest/web_sys/struct.CanvasRenderin...

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

#89
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

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.

Post reply on HN