this + any coding conventions should ALWAYS be a post process. DO NOT include them in your prompt, you are losing model accuracy over these tiny things.
this + any coding conventions should ALWAYS be a post process. DO NOT include them in your prompt, you are losing model accuracy over these tiny things.
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).
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.
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.
https://en.wikipedia.org/wiki/Wu_wei
Presumably the Go source files in the training corpus used tabs?
Obviously I'm not a $100M AI genius but haven't they tried transforming both training data and context into some normal form (whitespace neutral)?
Does codex have a good way of doing post process hooks? For Claude Code hooks I never found a way to run a formatter over only the file that was edited. It’s super annoying as I want to constantly have linting and formatting cleaned up right after the model finishes editing a file…
Check out lint-staged in npm. You can configure it so it will run even if the files aren’t staged, thus linting any changed files.
Stop telling the normies the secrets please! You've just harmed job security quite a bit for a lot of people!