I wonder what's going to happen after applying no-review practice, when nobody knows what code-base actually does, in enough details to provide technical guidance?

> If I were looking for work as an IC, I would avoid orgs that still practice this as a kind of make-work nearly as offensive as gratuitous meetings.

Would you get on a plane knowing its systems weren't code reviewed by humans?

How are you going to know the AI did not build the wrong thing? Not entirely wrong, but they will make some bad decision without consulting you. Even with a spec, AIs find a way to do it. (Humans can do this too.)

I agree with the direction, but I think "stop doing code reviews" is slightly too far. The review boundary should move up. Engineers should review the plan made by agents and trust they will carry out the implementation correctly.

Because there are better ways now to solve the problems that code review exists to solve.

> Technical debt is nearly a nothingburger now. If you went in the wrong direction, just... change the code to go in the right direction.

Uncharitable though it may sound, what I hear reading this is "Tell me you've never worked on a large system without telling me you've never worked on a large system."

I know reviewing code on github sucks, which was my source of frustration when reviewing code at work. Please use pyor.review, it will make reviewing PRs a heck of a lot easier (i built it myself)

even though I use the latest and greatest models, I still have to review the code AI generates, and it still makes mistakes, I still find it making weird decisions, slop blocks of code, unnecessarily long solutions that can be replaced with a couple lines of code.

code review is required to build good software, and that what separates engineers from vibe coders. you're missing the "engineer" part from the role, and that's still here to stay.