Code Review (3 blogmarks)

When a human writes code, the code is an artifact of their reasoning process. You can review the code and infer the thinking behind it. When AI generates code, you lose that direct connection. The code might be perfectly functional but reflect no coherent design intent – or worse, reflect a design intent that’s subtly different from what the developer actually wanted.

I ran a variation of the following prompt because the OP sounds pretty hyped about the results they are getting from it.

Do a git diff and pretend you're a senior dev doing a code review and you HATE this implementation. What would you criticize? What edge cases am I missing?

I expanded on it a little to guide it toward overly verbose or overengineered code. And I added some structure by asking it to include a confidence score with each item.

Based on the latest commit (see git show) and the untracked files that go along with it, pretend you're a senior dev doing a code review and you HATE this implementation. What would you criticize? What edge cases am I missing? What is overengineered, too verbose, or overcomplicated? Provide a confidence score with each issue and order your results with highest confidence issues at the top.

These instructions also work better with my workflow where I have in progress changes that I plan to amend into the most recent commit.

It picked up a couple things that I completely missed. It didn't find much in terms of refactoring away verbose or over-engineered code, unfortunately. I'm going to keep trying that though. This was quick to do and give me some actionable feedback. Worth the squeeze in my opinion.

I learned about git’s range-diff from this article which is useful if you adopt this interdiff approach of evolving patch series. Rather than doing additive commits in response to reviews and CI feedback.

This is the essence of "interdiff code review." You

• Don't publish new changes on top, you publish new versions
• You don't diff between the base branch and the tip of the developer's branch, you diff between versions of commits
• Now, reviewers get an incremental review process, while authors don't have to clutter the history with 30 "address review" noise commits.
• Your basic diagnostic tools work better, with a better signal-to-noise ratio.