Lenny Rachitsky walks through how he reviews code without technical skills: manual QA first, then Claude via a /review command, sometimes running multiple reviewers in parallel. He also uses a /peer review command that makes Claude act as dev lead and either defend flagged issues or fix them.
Chapters
It's very difficult for me to catch mistakes. So my review process has gone through a bunch of iterations to really be as good as possible. I'll always manually QA at first and then what I'll do is slash review and this tells Claude to start reviewing its own code. But what's even cooler is I will usually do multiple reviews and I'll have codecs as well as cursor open. I will have each of them review the code and then what I do is I have a slash command called peer review, which is really interesting. It's going to take Claude, which is usually the agent who I'm working with, basically saying, you're the dev lead on this project. Other team leads within the company have looked at your code and reviewed it and found these issues. Don't take what they said at face value. The reason is you have more context than them and you led this project. You need to either explain why the stuff they found are not real issues and wrong or fix them yourself.