This is one of the reasons I'm so interested in sandboxing. A great way to reduce the need for review is to have ways of running code that limit the blast radius if the code is bad. Running code in a sandbox can mean that the worst that can happen is a bad output as opposed to a memory leak, security hole or worse.
Every layer of review makes you 10x slower
11–20 of 339 posts
Re: Every layer of review makes you 10x slower
#12I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours.
I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed.
The reality is that any individual dev will get dinged for not meeting a release objective.
Re: Every layer of review makes you 10x slower
#13I think the problem is the shape of review processes. People higher up in the corporate food chain are needed to give approval on things. These people also have to manage enormous teams with their own complexities. Getting on their schedule is difficult, and giving you a decision isn't their top priority, slowing down time to market for everything.
So we will need to extract the decision making responsibility from people management and let the Decision maker be exclusively focused on reviewing inputs, approving or rejecting. Under an SLA.
My hypothesis is that the future of work in tech will be a series of these input/output queue reviewers. It's going to be really boring I think. Probably like how it's boring being a factory robot monitor.
Re: Every layer of review makes you 10x slower
#14As they say: an hour of planning saves ten hours of doing. You don't need so much code or maintenance work if you get better requirements upfront. I'd much rather implement things at the last minute knowing what I'm doing than cave in to the usual incompetent middle manager demands of "starting now to show progress". There's your actual problem.
> As they say: an hour of planning saves ten hours of doing.
In software it's the opposite, in my experience.
> You don't need so much code or maintenance work if you get better requirements upfront.
Sure, and if you could wave a magic wand and get rid of all your bugs that would cut down on maintenance work too. But in the real world, with the requirements we get, what do we do?
Re: Every layer of review makes you 10x slower
#15I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed. The reality is that any individual dev will get dinged for not meeting a release objective.
At the bottom of the page it says he is CEO of Tailscale.
Re: Every layer of review makes you 10x slower
#16This is one of the reasons I'm so interested in sandboxing. A great way to reduce the need for review is to have ways of running code that limit the blast radius if the code is bad. Running code in a sandbox can mean that the worst that can happen is a bad output as opposed to a memory leak, security hole or worse.
And if the bad output leads to a decision maker making a bad decision, that takes down your company or kills your relative ?
Re: Every layer of review makes you 10x slower
#17Valve is one of the only companies that appears to understand this, as well as that individual productivity is almost always limited by communication bandwidth, and communication burden is exponential as nodes in the tree/mesh grow linearly. [or some derated exponent since it doesn't need to be fully connected]
Re: Every layer of review makes you 10x slower
#18Meanwhile there are people who, as we speak, say that AI will do review and all we need to do is to provide quality gates...
Re: Every layer of review makes you 10x slower
#19If you save 3 hours building something with agentic engineering and that PR sits in review for the same 30 hours or whatever it would have spent sitting in review if you handwrote it, you’re still saving 3 hours building that thing. So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput (good lord, we better get used to doing more code review) This doe…
Except that when you have 10 PRs out, it takes longer for people to get to them, so you end up backlogged.
Re: Every layer of review makes you 10x slower
#20If you save 3 hours building something with agentic engineering and that PR sits in review for the same 30 hours or whatever it would have spent sitting in review if you handwrote it, you’re still saving 3 hours building that thing. So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput (good lord, we better get used to doing more code review) This doe…
If your team's bottleneck is code review by senior engineers, adding more low quality PRs to the review backlog will not improve your productivity. It'll just overwhelm and annoy everyone who's gotta read that stuff.
Generally if your job is acting as an expensive frontend for senior engineers to interact with claude code, well, speaking as a senior engineer I'd rather just use claude code directly.