Comment by rgbrenner 6 days ago
if you work on a team most code you see isn’t yours.. ai code review is really no different than reviewing a pr… except you can edit the output easier and maybe get the author to fix it immediately
I was about to say exactly this—it's not really that different from managing a bunch of junior programmers. You outline, they implement, and then you need to review certain things carefully to make sure they didn't do crazy things.
But yes, these juniors take minutes versus days or weeks to turn stuff around.
> if you work on a team most code you see isn’t yours.. ai code review is really no different than reviewing a pr… except you can edit the output easier and maybe get the author to fix it immediately
And you can't ask "why" about a decision you don't understand (or at least, not with the expectation that the answer holds any particular causal relationship with the actual reason)... so it's like reviewing a PR with no trust possible, no opportunity to learn or to teach, and no possibility for insight that will lead to a better code base in the future. So, the exact opposite of reviewing a PR.
Are you using the same tools as everyone else here? You absolutely can ask "why" and it does a better job of explaining with the appropriate context than most developers I know. If you realize it's using a design pattern that doesn't fit, add it to your rules file.
You can ask it "why", and it gives a probable English string that could reasonably explain why, had a developer written that code, they made certain choices; but there's no causal link between that and the actual code generation process that was previously used, is there? As a corollary, if Model A generates code, Model A is no better able to explain it than Model B.
Although it cannot understand the rhetorical why as in a frustrated “Why on earth would you possibly do it that brain dead way?”
Instead of the downcast, chastened look of a junior developer, it responds with a bulleted list of the reasons why it did it that way.
>And you can't ask "why" about a decision you don't understand (or at least, not with the expectation that the answer holds any particular causal relationship with the actual reason).
To be fair, humans are also very capable of post-hoc rationalization (particularly when they're in a hurry to churn out working code).
Reviewing code is harder than writing code. I know staff engineers that can’t review code. I don’t know where this confidence that you’ll be able to catch all the AI mistakes comes from.