Writing/reading code and reviewing code are distinct and separate activities. It's completely common to contribute code which is not production ready.

If you need an example, it's easy to add a debugging/logging statement like `console.log`, but if the coder committed and submitted the log statement, then they clearly didn't review the code at all, and there are probably much bigger code issues at stake. This is a problem even without LLMs.

Just call it “committing bad code”. LLM autocomplete aside, I don’t see how reviewing own code can happen without either a split personality, or putting enough time that you completely forgot what exactly you were doing and have fresh eyes and mind.

If person A committed code that looks bad to person B, it just means person A commits bad code by the standard of person B, not that person A “does not review own code”.

Maybe it’s a subjective difference, same as you could call someone “rude” or you could say the same person “didn’t think before saying”.

Person A as can commit atrocious code all day, that's fine, but they still need to proofread their MR/PR and fix the outstanding issues. The only way to see outstanding issues is by reviewing the MR/PR. Good writers proofread their documents.

I just don’t see reading your own stuff as a different activity from writing. Generally, there is the author, and proofreader is a dedicated role.

I always review the local diff before pushing. Can sometimes catch typos, or unclear comments or naming issues.

The concept and design were by that point iterated on, so it doesn’t happen that I need to rewrite a significant amount of code.

My preferred workflow requires me to go through every changed chunk and stage them one by one. It’s very easy with vim-fugitive. To keep commits focused, it requires reading every chunk, which I guess is an implicit review of sorts.