Where humans still matter when agents write the code

What would you be hoping to get out of code review? What are the goals you would have in having it as a process?

When I started in code reviews, it definitely wasn't the projector.

It was more the GitHub style of like, hey, we'll have the diff.

people go through it, you have two people go through it.

And the expectation very much was you go through every line.

There are different kinds of value you can get from that and there are different ways to waste a lot of time.

But I think one of the most valuable things that fall out of that is just it helped people learn how to code in the way that the team wanted you to code.

And that's very different now because we're not writing the code, right? Like a lot of the stuff that you would normally want to catch doing a code review, you can now turn into linters and those linters can be a lot more powerful than they used to be because AI can write those linters, right? Like for example, it used to be like very unreasonable to say, okay, we want like some code review thing that would...

check our architecture.

That's annoying and that's very brittle and fragile to write.

But now, who cares? So a lot of those kind of reasons are gone.

The reason I still kind of do code reviews, not of the line by line, is really complexity.

I think that's a big one.

I think agents still kind of struggle with managing complexity.

and identifying when they're doing something unusual, when something easier would be more appropriate.

And I haven't found a good way of catching that yet.

Yeah, that's one of the points I wanted to make, and I think it's dead on.

We're pretty much past the point where if you ask an agent to build something, it will build something that does the thing you asked.

I at least believe engineers still add a lot of value in steering during that process to make sure that it's doing it in the way that is simplest, doing it in the way that if you get successful tomorrow and you had 500 users, you're not going to just completely blow up the system.

And agents, at least today, could change in six months.

They're not great at self-evaluating on would there have been a simpler way.

And so part of the thing I'm reviewing for at the moment is just Did the engineer who guided the agent to write this code steer it successfully? And that's not a line by line thing.

It might be literally a, hey, I'm rejecting this whole change because I don't think that you put enough thought and guidance and steering into achieving the best outcome with the agent.

But if you get rid of that, my concern is that it's so easy to fall into this just slop cycle of like, cool, I'm jamming, I'm moving fast.

I don't need to look at the output.