The title of this article seems way too glib.

Code review isn't the same as design review, nor are these the only type of things (coding and design) that someone may be trying to use AI for.

If you are going to use AI, and catch it's mistakes, then you need to have expertise in whatever it is you are using the AI for. Even if we limit the discussion just to coding, then being a good code reviewer isn't enough - you'd need to have skill at whatever you are asking the AI to do. One of the valuable things AI can do is help you code using languages and frameworks you are not familiar with, which then of course means you are not going to be competent to review the output, other than in most generic fashion.

A bit off topic, but it's weird to me to see the term "coding" make a comeback in this AI/LLM era. I guess it is useful as a way to describe what AI is good at - coding vs more general software developer, but how many companies nowadays hire coders as opposed to software developers (I know it used to be a thing with some big companies like IBM)? Rather than compartmentalized roles, it seems the direction nowadays is more expecting developers to be able to do everything from business analysis and helping develop requirements, to architecture/design and then full-stack development, and subsequent production support.

My official title is "Software Engineer", in the last five years I have..

1. Stood up and managed my own Kubernetes clusters for my team

2. Docker, just so so much Docker

3. Developed CI/CD pipelines

4. Done more integration and integration testing then I care to think about

5. Written god knows how many requirements and produced and endless stream of diagrams and graphs for systems engineering teams

6. Don't a bunch of random IT crap because our infrastructure team can't be bothered

7. Wrote some code once in a while

Seems so.

> Using AI agents correctly is a process of reviewing code. [...]

> Why is that? Large language models are good at producing a lot of code, but they don’t yet have the depth of judgement of a competent software engineer. Left unsupervised, they will spend a lot of time committing to bad design decisions.

Obviously you want to make course corrections sooner than later. Same as I would do with less experienced devs, talk through the high level operations, then the design/composition. Reviewing a large volume of unguided code is like waiting for 100k tokens to be written only to correct the premise in the first 100 and start over.