121–130 of 200 posts
Just this one line in AGENTS.md has given better results to reduce if not eliminate verbosity and grandeur. **Always use ASD-STE100 Simplified Technical English Disclaimer: I saw this listed in some other HN post that I can' locate right away.
> - 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...
Earlier quoted context omitted.
The best way I've found to solve this is using LLM as CI - use a small cheap model to inspect the diff and look for those kinds of comments. Prompt left to the observer but using `claude -p` / `codex exec` gets you a lot cleaner output usually, and makes robots fight robots instead of you constantly having to reprompt and it ignoring you.
I've reached that point as well. Is there a preferred model and prompt you use for that?
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 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.
Yeah, I'm not sure what people are thinking. I keep reading stuff from folks like "I wish models had more common sense" and "I wish they wrote better code", not realizing this is 100% in your own hands, always been. There is no such thing as "clean code" that every programmer agrees on, you have your own subjective opinion and "good" taste about the code, instruct the models to follow it! And automate it while you're on it.
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 the model doesn't follow this, you want to start using a better model ASAP, because SOTA models for the last year or so, been able to following this without an issue.
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.
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.
- Prefer documentation as code
- Comment why, not what
- Document public APIs
- Readability is paramount
That usually gets me 80% there; rest is covered by the linter.
I'm mostly just missing it explaining previous state too much, especially when making edits to plans, but I have not found good wording for that yet.
> Use enums instead of booleans for function parameters ?????????
do_stuff(..., dry_run: bool = false)
enum Mode { dry_run, overwrite }
do_stuff(..., mode: Mode)