Comment by withinboredom 11 hours ago
It helps to actually be able to read the diffs of its proposals/changes in the terminal. The changing from tabs -> spaces on every line it touches generally results in unreadable messes.
I have a pretty complex project, so I need to keep an eye on it to ensure it doesn't go off the rails and delete all the code to get a build to pass (it wouldn't be the first time).
Do you not look at changes in your terminal as it is making them?
The thing in the terminal could also run the project autoformatter on the changes before displaying them.
You are poisoning your context making it focus on an unusual requirement contrary to most of its training data. It’s a formatter task, not an LLM task
In fact you should convert your code to spaces at least before LLM sees it. It’ll improve your results by looking more like its training data.
I wrote a bit about this yesterday: https://maxleiter.com/blog/rewrite-your-prompts
> Reason #3a: Work with the model biases, not against
Another note on model biases is that you should lean into them. The tricky part with this is the only way to figure out a model's defaults is to have actual usage and careful monitoring (or have evals that let you spot it).
Instead of forcing the model to behave in ways it ignores, adapt your prompts and post-processing to embrace its defaults. You'll save tokens and get better results.
If the model keeps hallucinating some JSON fields, maybe you should support (or even encourage) those fields instead of trying to prompt the model against them.
Go uses tabs. Full stop. There is no Go code with spaces. Not if they're using the built-in formatter, anyway. In any case, this is about the diff codex is outputting, not the code I commit. With Claude, I generally don't need to run `go fmt`, but with codex, it is absolutely necessary.
Good advice! Reminds me of wu-wei.
Cut wood with the grain, not against it.
Presumably the Go source files in the training corpus used tabs?
I think the idea is that your IDE or whatever should automatically run the project's autoformatter after every AI edit, so that any formatting mistakes the AI makes are fixed before you have to look at them.