4 ms·
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 cr
by newsomix9xl 2mo ago
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.
- zbentley 2mo ago> 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 method API surface small.
- deleted 2mo ago[deleted]
- bityard 2mo agoAn earlier version of Gemini used to do this a lot to me back when I used it for some light tinkering around on my projects. "Oh by the way, I fixed a misspelling in a comment file completely unrelated to the feature you asked for, so I fixed that as well, shall I commit everything now?" GAHHH. NO. These days I have an instruction in my default AGENTS.md to bring issues unrelated to the prompt to my attention when found, but never to just automatically fix them.
- no-name-here 2mo agoI find too often that models do the opposite - they'll pile small targeted band-aids on code blocks based on new requirements, etc, when having them analyze whether a changed (broader) design would result in a far better overall design?