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.
My agent.md to improve LLM-assisted code quality
91–100 of 200 posts
Re: My agent.md to improve LLM-assisted code quality
#92Can't wait to modify my agent.md file and then forget about it until it becomes useless again
Re: My agent.md to improve LLM-assisted code quality
#93A 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…
One thing I don’t get with a lot of these agents.md and other skills are… why not throw as much mechanical checks and other stuff at the repo to constrain as you want instead of asking a non-deterministic agent (squishy or non-squishy) to maintain it. With the mechanical routes, we get checks, failures, and so much more. A bit wild to me. Make an agent operate within defined constraints and yell at it when it doesn’t…
> Make an agent operate within defined constraints and yell at it when it doesn’t.
And tell it what the constraints are.
Re: My agent.md to improve LLM-assisted code quality
#94Earlier 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.
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.
It’s almost the “we built a robot who loves to play Sonatas and gave it no hands” type of thing.
Re: My agent.md to improve LLM-assisted code quality
#95A 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…
> Propose ASCII drawings to explain complete systems. LLMs are very bad at ASCII drawings. https://medium.com/data-science/why-llms-suck-at-ascii-art-a...
Re: My agent.md to improve LLM-assisted code quality
#96To 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.
Re: My agent.md to improve LLM-assisted code quality
#97> - 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...