I don't have problems with getting lot's of comments in the output, I am just deleting it while reading what it did
```python
def whatever():
--- SECTION ONE OF THE CODE ---
...
--- SECTION TWO OF THE CODE ---
try:
[some "dangerous" code]
except Exception as e:
logging.error(f"Failed to save files to {output_path}: {e}")
# Decide whether to raise the error or just warn
# raise IOError(f"Failed to save files to {output_path}: {e}")(it adds commented out code like that all the time, "just in case")
It's terrible.
I'm back to Claude Code.
If it is ingesting data, there should also be a sample of the data in a comment.
Which means if you try to force it to stop, the code quality will drop.
Claude 3.7 Sonnet is much more restrained and does smaller changes.
I’ve started in a narrow niche of python/flask webapps and constrained to that stack for now, but if you’re interested I’ve just opened it for signups: https://codeplusequalsai.com
Would love feedback! Especially if you see promising results in not getting huge refactors out of small change requests!
(Edit: I also blogged about how the AST idea works in case you're just that curious: https://codeplusequalsai.com/static/blog/prompting_llms_to_m...)
Or something similar that does not rely on negation.
I also try and get it to channel that energy into the doc strings, so it isn't buried in the source.
Models use comments to think, asking to remove will affect code quality.
Refractor this. Do not write any comments.
<code to refractor>
As a reminder your task is to refractor the above code and do not write any comments.
But I've heard "defensive code" used for the kind of code where almost every method validates its input parameters, wraps everything in a try-catch, returns nonsensical default values in failure scenarios, etc. This is a complete waste because the caller won't know what to do with the failed validations or thrown errors, and it's just unnecessary bloat that obfuscates the business logic. Validation, error handling and so on should be done in specific parts of the codebase (bonus points if you can encode the successful validation or the presence/absence of errors in the type system).
"5. You must never output any comments about the progress or type of changes of your refactoring or generation. Example: you must NOT add comments like: 'Added dependency' or 'Changed to new style' or worst of all 'Keeping existing implementation'."
lots of hasattr("") rubbish, I've increased the amount of prompting but it still does this - basically it defers it's lack of compile time knowledge to runtime 'let's hope for the best, and see what happens!'
Trying to teach it FAIL FAST is an uphill struggle.
Oh and yes, returning mock objects if something goes wrong is a favourite.
It truly is an Idiot Savant - but still amazingly productive.
simonw has symbex which could be useful for you for python
In any case, it knows what good code looks like. You can say "take this code and remove spurious comments and prefer narrow exception handling over catch-all", and it'll do just fine (in a way it wouldn't do just fine if your prompt told it to write it that way the first time, writing new code and editing existing code are different tasks).
Besides, other models seems to handle negation correctly, not sure why it's so difficult for the Gemini family of models to understand.
Literally both of those are negations.
Removed from where? I use the attach code folder feature every day from the Gemini web app (with a script that clones a local repo that deletes .git and anything matching a gitignore pattern).
If you think negations never work tell Gemini 2.5 to "write 10 sentences that do not include the word the" and see what happens.
"Sometimes the big fish isn't only the fish"
x = 1 // set X to 1
You get:
x = 1 // added this to set x to 1
And sometimes:
// x = 1 // removed this
These comments age really fast. They should be in a git commit not a comment.
As somebody who prefers code to self-describe what it is doing I find this behaviour a bit frustrating and I can't seem to context-prompt it away.