Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My agent.md to improve LLM-assisted code quality

fabiensanglard.net

Post reply on HN
Print view View original

61–70 of 200 posts

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

#61

Post by throwatdem12311 »

getnormality wrote: post #4
OptionOfT wrote: post #3

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.

I tell the agent to NEVER write comments in the system prompt and it ignore it like 90% of the time. RLHF is a helluva drug.

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

#62

Post by lkjdsklf »

hawk_ wrote: post #38
OptionOfT wrote: post #3

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.

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

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

#63

Post by selcuka »

irishcoffee wrote: post #33
culi wrote: post #30

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

Pi even installs ripgrep and fd if it can't find them in the path.

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

#65

Post by robby_w_g »

hawk_ wrote: post #38
OptionOfT wrote: post #3

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.

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

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

#68

Post by [deleted] »

robby_w_g wrote: post #65
hawk_ wrote: 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

[deleted]

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

#69

Post by throwatdem12311 »

OptionOfT wrote: post #3

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…

Linters and static analysis -> setup as hooks in your harness. Don’t rely on CLAUDE.md because it’ll ignore it a lot.

> ASCII drawings in code

Please don’t this is super obnoxious. Make proper diagrams and kee them in knowledge base. Link out to them if you need to and let the agent fetch them via MCP or API or whatever if it wants them.

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

#70

Post by impulser_ »

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 hard limits on these thing and it just bad.

The function name shouldn't be limited they should be as clear as possible and if for some reason it over 30 chars so be it.

I want to read the function name and the logic and it match exactly. I don't want the agent being lazy because of some limit I set.

In fact I force my agents to write long functions because I specifically tell it not to break out repeated code that doesn't actually deserve a function.

A check on a function input doesn't need to be a function. A auth guard doesn't need to be it own function.

types.go types.ts absolutely the worst file to see in any code base. Put the type next to the code that uses it.

Post reply on HN