Live data from Hacker News

My agent.md to improve LLM-assisted code quality

fabiensanglard.net

191–200 of 200 posts

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

#191

Earlier quoted context omitted.

A comment is just a summary of the code in an abstraction that's easier to follow. Let's say you have a simple function which would produce an almost as large comment, yes obviously useless. If the function is large enough, yeah summarizing it as a comment is a good idea. Now you might say, don't write huge functions. Sure I agree, but most codebase or teams are not super disciplined enough. So comments are a comprom…

Comments lie. What's worse, AI trusts the comments and apparent logic (inferred from identifiers and whatnot) more than the actual logic. You can quickly get into a mess of stale comments. What's worse, the LLM can sometimes just spit out garbage that poisons the context of the next agent. I disallow comments from my LLM for that last reason.

Code can "lie" too.

```auto a = 65535 + 1``` will give you a different answer depending on the architecture. You can then decide.. oh don't use auto or don't use c++ or whatever and have standards... like the standard you set for yourself "disallow comments from my LLM".

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

#192

Earlier quoted context omitted.

A comment is just a summary of the code in an abstraction that's easier to follow. Let's say you have a simple function which would produce an almost as large comment, yes obviously useless. If the function is large enough, yeah summarizing it as a comment is a good idea. Now you might say, don't write huge functions. Sure I agree, but most codebase or teams are not super disciplined enough. So comments are a comprom…

>> A comment is just a summary of the code in an abstraction that's easier to follow. I disagree. The code already tells you what it does. A summary has low value. Comments should be for explaining the why : the reason the function uses a particular algorithm even if it's a bit slower, or why the return format is an unconventional shape or contains redundant bits. This is so that someone coming in later (either a hum…

That's your experience and it's valid. For me documentation AND comments have been useful on occasion.

The core thing that I agree with is that comments (or docs) can get stale and not follow what is actually being executed. The way I work with it is by being structured, consistent and follow standards. Unfortunately for me, not all developers follow the same guidelines.

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

#193
post #182

Earlier quoted context omitted.

The cost of custom linters has like any other code dropped through the floor. I'm sprinkling all kinds of linters over my latest projects. It seems some people are still sleeping on this, expecting great code from the agents. They're fast and deterministic and I run them in git pre-commit.

> They're fast and deterministic and I run them in git pre-commit. Isnt that too late? I would want the agent to stumble into this as early as possible in the agentic loop, eg at the same time as compiler.

It's been working quite well so far and I don't know of any way of hooking custom linters into cargo so they run after compilation.

But that's a pretty good idea, wonder if there is a way...

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

#194
post #50

Earlier quoted context omitted.

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…

My problem is always the time necessary to get good at the tool is slightly more than just brute forcing it one more time.

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

#196
post #150

Earlier quoted context omitted.

I think “This way the code stays readable/debuggable by humans” is a proof by example (not that the generated comments are necessarily bad). If the human can read/understand it well enough to comment it, then it is readable by humans.

> If the human can read/understand it well enough to comment it, then it is readable by humans. No, because the one who is writing the comment has context later reader dont. The writer knows what the requirements are, what he was trying to achieve and what he struggled to comprehend. Writer also presumably spent more time trying to understand it then the person coming later should.

I'm not sure what you're arguing? I'm responding to:

>> This way, LLMs add a bunch of comments, but it doesn't affect your actual experience in trying to read the code

by saying that at least reading the code and generating comments is forcing some understanding. Is there a disagreement in that?

You're saying that it's not (necessarily) enough understanding, which may be true but beside the point.

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

#197

Earlier quoted context omitted.

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…

My problem is always the time necessary to get good at the tool is slightly more than just brute forcing it one more time.

I'm not always forced for time. And the time is slightly less when you know how to use man (with apropos and whatis, a few unix conventions (null vs newline when piping text) and the quirks/feature of your shell.

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

#198

Earlier quoted context omitted.

I added to the memory, system prompts, and the prompt itself and every soa model still litters code with the most inane useless crap. I will then get code to review from a coworker using fable/opus. It has more lines of comments then code. Maybe I am some god tier code reader (i am not) but i dont think i have ever found a comment in code to be useful in my day job. That isnt true, i once came across // submit to the…

Most useful code comment I have encountered read: “”” After you give up on trying to refactor this code, increment the following line accordingly. HOURS_WASTED_HERE=26 “””

I always loved the classic _"Here be dragons"_

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

#199
post #38

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

I'm not convinced, yet, that eliminating LLM-generated comments is the right path for me. I do review everything written by an LLM and some comments are actually pretty good, but sometimes I'm just too tired to try to figure out how to reword an oddly worded one.

I just added Sanglard's rules to my ~/.claude/CLAUDE.md file, did another code review, and found some LLM-generated comments were really hard to understand. I think they're due to invented metaphors and flowery language instead of using standard terms, so I've added this:

- Comments must be literal. Don't invent figurative language for what a plain technical term already says — write "rows still reference it," not "rows still wear it."

Improving LLM code generation is an iterative process. I'm glad people share their efforts to improve it.

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

#200

I think it's a bit too detailed, especially with the linting. To me when I code by hand, I never use {} after an if statement if it's one-line, it's just faster, look cleaner to me.

> it's just faster

And what are you going to do with all that time you saved by not pressing a single key?

Post reply on HN