[addaon]

> But when I need to write code in areas I'm less confident about, I'll let AI take the reins and the do a thorough review myself.

I see this mindset a bunch, and I just don’t get it. Reviewing code is so much harder than writing code! To write code, I need to find one path to achieve my goal, and convince myself, the compiler, and the reviewer that it does so. To review code, I need to consider all reasonable paths to achieve the goal, and confirm that a sufficiently-good one was selected. This is why we have junior engineers write code and seniors review it. If you’re beyond your comfort level writing it, how can you possibly review whether the author (AI or otherwise) made good choices? You only have exposure to one possible choice lane, and by problem statement you weren’t comfortable populating the other lanes…

[zahlman]

To write code, I effectively need to do a mini-review as I go, and type vastly slower than the AI. To review code, given that all the automated checks are out of the way, I need to consider the objectives of the code (in terms of fitting into the existing codebase, having a reasonably appropriate style, etc.) and ensure there isn't anything too far out of line. Knowing that something is "sufficiently good" doesn't entail awareness of all possibilities, because you aren't ranking the thing but measuring it.

Seniors review code because they have a much better understanding of the necessary taste and discretion, and an awareness of the larger system the code will integrate into, whereas there's only so much you can learn about coding that's relevant to most of the code you'll write (and only so fast you'll ever really be able to type it, and most of the issues can be caught by automated, deterministic systems).

[glimshe]

Seeing a solved problem and verifying the solution's correctness is much easier than solving the problem yourself. it's a bit like riddles. You can find examples of that when studying any topic. I disagree that reviewing code is harder than writing code in all/most instances.

Also, there's code that is just tedious and repetitive to write. AI can write that and reviewing is pretty easy.

[hegstal]

You could ask someone a math question, and they can write an equation down, and the equation can be mathematically sound, but it still not be the right form of the equation, or even relate to the question correctly at all. If all you're being asked to do is validate the mathematical soundness of the equation then sure, it's not that hard and it often mechanical, probably easier than having to generate the equation. But that isn't review -- that's cargo-culting what review is supposed to be.

To bring back to code: They are making the point that verifying "correctness" is not the be all and end all of code review. In every situation, there are multiple "correct" solutions, and only a few of them are actually correct and fit within the past, current and future context (technical and business). If someone isn't doing this, they aren't reviewing effectively and are acting as a glorified linter, which is an astonishingly low value-add use of human capacity.

There are situations where nobody really cares about the output, and nobody wants the true form of review, so it reverts to (at best) human-linting. In those situations, engineering capability of any kind functionally has no moat and all participants are equally fungible. If the business is dependent on engineering it's also a horrendous business. I would personally avoid being involved in these environments in an engineering capacity. I mean this in a diagnostic sense - it's a terrible career move, though there will always be busy work that's exactly what we have LLMs for.