12 ms·

Every layer of review makes you 10x slower

• driftnode 7mo ago
  [dead]
• tptacek 7mo ago
  Not before coding agents nor after coding agents has any PR taken me 5 hours to review. Is the delay here coordination/communication issues, the "Mythical Mammoth" stuff? I could buy that.
  • abtinf 7mo ago
    The PR won’t take 5 hours of work, but it could easily sit that long waiting for another engineer to willing to context switch from their own heads-down work.
    • paulmooreparks 7mo ago
      Exactly. Even if I hammer the erstwhile reviewer with Teams/Slack messages to get it moved to the top of the queue and finished before the 5 hours are up, then all the other reviews get pushed down. It averages out, and the review market corrects.
    • bsjshshsb 7mo ago
      Exaxtly. Can you get a lawyer on the phone now or do you wait ~ 5 hours. How about a doctor appt. Or a vet appt. Or a mechanic visit. Needing full human attention on a co.plex task from a pro who can only look at your thing has a wait time. It is worse when there are only 2 or 3 such people in the world you can ask!
  • nixon_why69 7mo ago
    The article specified wall clock time. One day turnaround is pretty typical if its not urgent enough to demand immediate review, lots of people review incoming PRs as a morning activity.
  • lelanthran 7mo ago
    Some devs interrupt what they are doing when they see a PR in a Slack notification, most don't. Most devs set aside some time at most twice a day for PRs. That's 5 hours at least. Some PRs come in at the end of the day and will only get looked at the next day. That's more than 5 hours. IME it's rare to see a PR get reviewed in under 5 hours.
    • CBLT 7mo ago
      I use a PR notifier chrome extension, so I have a badge on the toolbar whenever a PR is waiting on me. I get to them in typically <2 minutes during work hours because I tab over to chrome whenever AI is thinking. Sometimes I even get to browse HN if not enough PRs are coming and not too many parallel work sessions.
    • riffraff 7mo ago
      But there's more than one person that can review a PR. If you work in a team of 5 people, and each one only reviews things twice a day, that's still less than 5 hours any way you slice it.
  • Aurornis 7mo ago
    The article is referring to the total time including delays. It isn’t saying that PR review literally takes 5 hours of work. It’s saying you have to wait about half a day for someone else to review it.
    • yxhuvud 7mo ago
      Which is a thing that depend very much on team culture. In my team it is perhaps 15 min for smaller fixes to get signoff. There is a virtuous feedback loop here - smaller PRs give faster reviews, but also more frequent PRs, which give more frequent times to actually check if there is something new to review.
      • christophilus 7mo ago
        Does your team just context switch all the time? That sounds like a terrible place to work.
        • sn0wleppard 7mo ago
          Similar in my team and I don't feel like there's much context switching. With around 8 engineers there's usually at least one person not in the middle of something who can spare a few minutes.
          • g947o 7mo ago
            How can everyone be familiar with everybody else's work? Usually at most 2-3 engineer have enough context to fully understand what your code is doing.
      • workmandan 7mo ago
        If I'm deep in coding flow the last thing I'm going to do is immediately jump on to someone else's PR. Half a day to a day sounds about right from when the PR is submitted to actually getting the green light
  • ukuina 7mo ago
    > "Mythical Mammoth" Most excellent.
    • furryrain 7mo ago
      Man moth?
  • squirrellous 7mo ago
    One pattern I've seen is that a team with a decently complex codebase will have 2-3 senior people who have all of the necessary context and expertise to review PRs in that codebase. They also assign projects to other team members. All other team members submit PRs to them for review. Their review queue builds up easily and average review time tanks. Not saying this is a good situation, but it's quite easy to run into it.
  • sevenseacat 7mo ago
    I've had PRs that take me five hours to review. If your one PR is an entire feature that touches the database, the UI, and an API, and I have to do the QA on every part of it because as soon as I give the thumbs up it goes out the door to clients? Then its gonna take a while and I'm probably going to find a few critical issues and then the loop starts again
• markbao 7mo ago
  If 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 doesn’t work if you spend 3 minutes prompting and 27 minutes cleaning up code that would have taken 30 minutes to write anyway, as the article details, but that’s a different failure case imo
  • CuriouslyC 7mo ago
    Except that when you have 10 PRs out, it takes longer for people to get to them, so you end up backlogged.
    • zmmmmm 7mo ago
      And when the PR you never even read because the AI wrote it gets bounced back you with an obscure question 13 days later ..... you're not going to be well positioned to respond to that.
  • josephg 7mo ago
    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.
    • eru 7mo ago
      Linting, compiler warnings and automated tests have helped a lot with the grunt work of code review in the past. We can use AI these days to add another layer.
  • lelanthran 7mo ago
    > So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput Hang on, you think that a queue that drains at a rate of $X/hour can be filled at a rate of 10x$X/hour? No, it cannot: it doesn't matter how fast you fill a queue if the queue has a constant drain rate, sooner or later you are going to hit the bounds of the queue or the items taken off the queue are too stale to matter. In this case, filling a queue at a rate of 20 items per hour (every 3 minutes) while it drains at a rate of 1 item every 5 hours means that after a single day, you can expect your last PR to be reviewed in ((8x20) - 1) hours. IOW, after a single day the time-to-review is 159 hours. Your PRs after the second day is going to take +300 hours.
• abtinf 7mo ago
  I find to be true for expensive approvals as well. If I can approve something without review, it’s instant. If it requires only immediate manager, it takes a day. Second level takes at least ten days. Third level trivially takes at least a quarter (at least two if approaching the end of the fiscal year). And the largest proposals I’ve pushed through at large companies, going up through the CEO, take over a year.
• sublinear 7mo ago
  As 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.
  • lmm 7mo ago
    > 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?
    • JoshTriplett 7mo ago
      > In software it's the opposite, in my experience. That's been my experience as well: ten hours of doing will definitely save you an hour of planning. If you aren't getting requirements from elsewhere, at least document the set of requirements you think you're working towards, and post them for review. You sometimes get new useful requirements very fast if you post "wrong" ones.
      • seer 7mo ago
        I think what they meant is you “can save 10 hours of planning with one hour of doing” And I think this has become even more so with the age of ai, because there is even more unknown unknowns, which is harder to discover while planning, but easy wile “doing” and that “doing” itself is so much more streamlined. In my experience no amount of planning will de-risk software engineering effort, what works is making sure coming back and refactoring, switching tech is less expensive, which allows you to rapidly change the approach when you inevitably discover some roadblock. You can read all the docs during planning phases, but you will stumble with some undocumented behaviour / bug / limitation every single time and then you are back to the drawing board. The faster you can turn that around the faster you can adjust and go forward. I really like the famous quote from Churchill- “Plans are useless, planning is essential”
• simonw 7mo ago
  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.
  • KnuthIsGod 7mo ago
    And if the bad output leads to a decision maker making a bad decision, that takes down your company or kills your relative ?
    • riffraff 7mo ago
      The sandbox in question was to absorb shrapnel from explosions, clearly
  • MeetingsBrowser 7mo ago
    Isn’t “bad output” already worst case? Pre-LLMs correct output was table stakes. You expect your calculator to always give correct answers, your bank to always transfer your money correctly, and so on.
    • swiftcoder 7mo ago
      > Isn’t “bad output” already worst case? Worst case in a modern agentic scenario is more like "drained your bank account to buy bitcoin and then deleted your harddrive along with the private key" > Pre-LLMs correct output was table stakes We're only just getting to the point where we have languages and tooling that can reliably prevent segfaults. Correctness isn't even on the table, outside of a few (mostly academic) contexts
      • MeetingsBrowser 7mo ago
        > drained your bank account to buy bitcoin and then deleted your harddrive These are what I meant by correct output. The software does what you expect it to. > We're only just getting to the point where we have languages and tooling that can reliably prevent segfaults This is not really an output issue IMO. This is a failing edge case. LLMs are moving the industry away from trying to write software that handles all possible edge cases gracefully and towards software developed very quickly that behaves correctly on the happy paths more often than not.
• lelanthran 7mo ago
  I 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.
  • jannyfer 7mo ago
    At the bottom of the page it says he is CEO of Tailscale.
  • devmor 7mo ago
    I’ve worked on teams like you describe and it’s been terrible. My current team’s SDLC is more along the 5-hour line - if someone hasn’t reviewed your code by the end of today, you bring it up in standup and have someone commit to doing it.
  • usr1106 7mo ago
    I worked in a company where reviews took days. The CTO complained a lot about the speed, but we had decent code quality. Now I work at a company where reviews take minutes. We have 5 lines of technical debt per 3 lines of code written. We spend months to work on complicated bugs that have made it to production.
  • ivanjermakov 7mo ago
    I'm yet to see a project where reviews are handled seriously. Both business and developers couldn't care less.
    • eterm 7mo ago
      I worked somewhere that actually had a great way to deal with this. It only works in small teams though. We had a "support rota", i.e. one day a week you'd be essentially excused from doing product delivery. Instead, you were the dev to deal with big triage, any code reviews, questions about the product, etc. Any spare time was spent looking for bugs in the backlog to further investigate / squash. Then when you were done with your support day you were back to sprint work. This meant there was no ambiguity of who to ask for code review, and limited / eliminated siloing of skills since everyone had to be able to review anyone else's work. That obviously doesn't scale to large teams, but it worked wonders for a small team.
• jbrozena22 7mo ago
  I 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.
• thot_experiment 7mo ago
  Valve 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]
  • MrBuddyCasino 7mo ago
    The first one to realise this was Jeff Bezos, afaik. One would think the others have wisened up in the meantime, but no.
    • trymas 7mo ago
      > The first one to realise this was Jeff Bezos, afaik I am not aware about the details - can you elaborate?
      • pkos98 7mo ago
        Maybe the Two Pizza rule: No team at Amazon should be larger than what two pizzas can feed (usually about 6 to 10 people).
        • hallway_monitor 7mo ago
          The ‘design everything as a publicly accessible API’ directive seems to play to this as well. If all your data / services are available and must be documented then a lot of communication overhead can be eliminated.
          • strgcmc 7mo ago
            For anyone who doesn't know what you mean, here's an archived copy of Steve Yegge's post about this directive + other musings comparing Amazon vs Google (which is how a lot of us came to find out about this, via Yegge's write-up): https://news.ycombinator.com/item?id=3102800 https://news.ycombinator.com/item?id=3102800 Copied the most relevant snippet below --- So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses. His Big Mandate went something along these lines: 1) All teams will henceforth expose their data and functionality through service interfaces. 2) Teams must communicate with each other through these interfaces. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care. 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6) Anyone who doesn't do this will be fired. 7) Thank you; have a nice day! Ha, ha! You 150-odd ex-Amazon folks here will of course realize immediately that #7 was a little joke I threw in, because Bezos most definitely does not give a shit about your day. #6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Armgy Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Wal*Mart, and is a big genial scary man who used the word "hardened interface" a lot. Rick was a walking, talking hardened interface himself, so needless to say, everyone made LOTS of forward progress and made sure Rick knew about it. Over the next couple of years, Amazon transformed internally into a service-oriented architecture. They learned a tremendous amount while effecting this transformation. There was lots of existing documentation and lore about SOAs, but at Amazon's vast scale it was about as useful as telling Indiana Jones to look both ways before crossing the street. Amazon's dev staff made a lot of discoveries along the way. A teeny tiny sampling of these discoveries included: - pager escalation gets way harder, because a ticket might bounce through 20 service calls before the real owner is identified. If each bounce goes through a team with a 15-minute response time, it can be hours before the right team finally finds out, unless you build a lot of scaffolding and metrics and reporting. - every single one of your peer teams suddenly becomes a potential DOS attacker. Nobody can make any real forward progress until very serious quotas and throttling are put in place in every single service. - monitoring and QA are the same thing. You'd never think so until you try doing a big SOA. But when your service says "oh yes, I'm fine", it may well be the case that the only thing still functioning in the server is the little component that knows how to say "I'm fine, roger roger, over and out" in a cheery droid voice. In order to tell whether the service is actually responding, you have to make individual calls. The problem continues recursively until your monitoring is doing comprehensive semantics checking of your entire range of services and data, at which point it's indistinguishable from automated QA. So they're a continuum. - if you have hundreds of services, and your code MUST communicate with other groups' code via these services, then you won't be able to find any of them without a service-discovery mechanism. And you can't have that without a service registration mechanism, which itself is another service. So Amazon has a universal service registry where you can find out reflectively (programmatically) about every service, what its APIs are, and also whether it is currently up, and where. - debugging problems with someone else's code gets a LOT harder, and is basically impossible unless there is a universal standard way to run every service in a debuggable sandbox. That's just a very small sample. There are dozens, maybe hundreds of individual learnings like these that Amazon had to discover organically. There were a lot of wacky ones around externalizing services, but not as many as you might think. Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers. This effort was still underway when I left to join Google in mid-2005, but it was pretty far advanced. From the time Bezos issued his edict through the time I left, Amazon had transformed culturally into a company that thinks about everything in a services-first fashion. It is now fundamental to how they approach all designs, including internal designs for stuff that might never see the light of day externally. At this point they don't even do it out of fear of being fired. I mean, they're still afraid of that; it's pretty much part of daily life there, working for the Dread Pirate Bezos and all. But they do services because they've come to understand that it's the Right Thing. There are without question pros and cons to the SOA approach, and some of the cons are pretty long. But overall it's the right thing because SOA-driven design enables Platforms. That's what Bezos was up to with his edict, of course. He didn't (and doesn't) care even a tiny bit about the well-being of the teams, nor about what technologies they use, nor in fact any detail whatsoever about how they go about their business unless they happen to be screwing up. But Bezos realized long before the vast majority of Amazonians that Amazon needs to be a platform. You wouldn't really think that an online bookstore needs to be an extensible, programmable platform. Would you?
• p0w3n3d 7mo ago
  Meanwhile there are people who, as we speak, say that AI will do review and all we need to do is to provide quality gates...
  • duskdozer 7mo ago
    AI reviews? Sounds like a waste of tokens!
• onion2k 7mo ago
  But you can’t just not review things! Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. The remain 10% of things like var naming, whitespace, and patterns can be checked with a linter instead of a person. If you can get the team to that level you can stop doing code reviews. You also need to build a team that you can trust to write the code you agreed you'd write, but if your reviews are there to check someone has done their job well enough then you have bigger problems.
  • loire280 7mo ago
    I've seen engineers I respect abandon this way of working as a team for the productivity promise of conjuring PRs with a coding agent. It blows away years of trust so quickly when you realize they stopped reviewing their own output.
    • onion2k 7mo ago
      Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to. Agents are getting really good, and if you're used to planning and designing up front you can get a ton of value from them. The main problem with them that I see today is people having that level of trust without giving the agent the context necessary to do a good job. Accepting a zero-shotted service to do something important into your production codebase is still a step too far, but it's an increasingly small step.
      • camillomiller 7mo ago
        >> Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to. I have been doing this to, and I've forgotten half of them. For me the point is that this usage scenario is really good, but it also has no added value to it, really. The moment Claude Code raises it prices 2x this won't be viable anymore, and at the same time to scale this to enterprise software production levels you need to spend on an agent probably as much as hiring two SWEs, given that you need at least one to coordinate the agents.
• riffraff 7mo ago
  > Code a simple bug fix 30 minutes > Get it code reviewed by the peer next to you 300 minutes → 5 hours → half a day Is it takes 5 hours for a peer to review a simple bugfix your operation is dysfunctional.
  • habinero 7mo ago
    People are busy, and small bugfixes are usually not that critical. If you make everyone drop everything to review everything, that is much more dysfunctional.
    • cindyllm 7mo ago
      [dead]
  • thi2 7mo ago
    Its rare that devs are on standby, waiting for a pr to review. Usually they are working on their own pr, are in meetings, have focus time. We talked a lot about the costs of context switches so its reasonable to finish your work before switching to the review.
  • karel-3d 7mo ago
    nobody will immediately jump on your code review
    • riffraff 7mo ago
      Sure, but five hours is a lot of time, and a small fix takes little to review. So, 1 hour? Sure. Two hours? Ok. But five hours means you only look at your teammates code once a day. It's ok for a process where you work on something for a week and then come back for reviews but then it's silly to complain about overhead.
  • ge96 7mo ago
    Hehe I'm waiting right now, should have been reviewed yesterday but I'm like alright, I'll just chill then.
• usr1106 7mo ago
  What makes me slower is the moment is the AI slop my team lead posts into reviews. I have to spend time to argue why that's not a valid comment.
• camillomiller 7mo ago
  >> Now you either get to spend 27 minutes reviewing the code yourself in a back-and-forth loop with the AI (this is actually kinda fun); or you save 27 minutes and submit unverified code to the code reviewer, who will still take 5 hours like before, but who will now be mad that you’re making them read the slop that you were too lazy to read yourself. Little of value was gained. This seems to check out, and it's the reason why I can't reconcile the claims of the industry about workers replacement with reality. I still wonder when a reckoning will come, though. seems long overdue in the current environment
  • steve_taylor 7mo ago
    I don't agree with this take in the article. One person with Claude Code can replace a team of devs. It resolves many issues, such as the tension between devs wanting to focus and devs wanting their peers to put aside their task to review their pull requests. Claude generates the code and the human reviews it. There's no delay in the back-and-forth unlike in a team of humans. There's no ego and there's no context switching fatigue. Given that code reviewing is a bottleneck, it's feasible that one person can do it by themselves. And Claude can certainly generate working code at least 10x faster than any dev.
    • wiseowise 7mo ago
      You’re talking from idealistic requirements - input - programming - output point. That’s not how the world operates. Egos are “important”, politics, bureaucracy, all of those are essential parts of the organizations. LLMs don’t change that, and without changing that there’s no chance at all. Previously coding was maybe 0.1 bottleneck, now it’s 0.07 bottleneck.
  • wiseowise 7mo ago
    > I still wonder when a reckoning will come, though. seems long overdue in the current environment Never. Until 1-10 person teams starts disrupt enterprises (legacy banks, payments systems, consultancies). “Why” would you ask? Because it’s a house of cards. If engineers get redundant, then we don’t need teams. If we don’t need teams, then we don’t need team leads/PMs/POs and others, if we don’t need middle management, then we don’t need VPs and others. All of those layers will eventually catch up to what’s going on and kill any productivity gains via bureaucracy.
• codemog 7mo ago
  This reads like a scattered mind with a few good gems, a few assumptions that are incorrect but baked into the author’s world view, and loose coherence tying it all together. I see a lot of myself in it. I’ll cover one of them: layers of management or bureaucracy does not reduce risk. It creates in-action, which gives the appearance of reducing risk, until some startup comes and gobbles up your lunch. Upper management knows it’s all bullshit and the game theoretic play is to say no to things, because you’re not held accountable if you say no, so they say no and milk the money printer until the company stagnates and dies. Then they repeat at another company (usually with a new title and promotion).
• lukaslalinsky 7mo ago
  Reviewing things is fast and smooth is things are small. If you have all the involved parties stay in the loop, review happens in the real time. Review is only problematic if you split the do and review steps. The same applies to AI coding, you can chose to pair program with it and then it's actually helpful, or you can have it generate 10k lines of code you have no way of reviewing. You just need people understand that switching context is killing productivity. If more things are happening at the same time and your memory is limited, the time spent on load/save makes it slower than just doing one thing at the time and staying in the loop.
  • rafaelmn 7mo ago
    Honestly if I'm just following what a single LLM is doing I'm arguably slower than doing it myself so I'd say that approach isn't very useful for me. I prefer to review plan (this is more to flush out my assumptions about where something fits in the codebase and verify I communicated my intent correctly). I'll loosely monitor the process if it's a longer one - then I review the artifacts. This way I can be doing 2/3 things in parallel, using other agents or doing meetings/prod investigation/making coffee/etc.
• simianwords 7mo ago
  I don’t agree that AI can’t fix this. It is too easy to dismiss. With AI my task to review is to see high level design choices and forget reviewing low level details. It’s much simpler.
• superlopuh 7mo ago
  In my experience a culture where teammates prioritise review times (both by checking on updates in GH a few times a day, and by splitting changes agressively into smaller patches) is reflected in much faster overall progress time. It's definitely a culture thing, there's nothing technically or organisationally difficult about implementing it, it just requires people working together considering team velocity more important than personal velocity.
  • threatofrain 7mo ago
    Let's say a teammate is writing code to do geometric projection of streets and roads onto live video. Another teammate is writing code to do automated drone pursuit of cars. Let's say I'm over here writing auth code, making sure I'm modeling all the branches which might occur in some order. To what degree do we expect intellectual peerage from someone just glancing into this problem because of a PR? I would expect that to be the proper intellectual peer of someone studying the problem, it's quite reasonable to basically double your efforts.
    • servo_sausage 7mo ago
      This is an unusually low overlap per topic; probably needs a different structure to traditional prs to get the best chance to benefit from more eyes... Higher scope planning or something like longer but intermittent partner programming. Generally if the reviewer is not familiar with the content asynchronous line by line reviews are of limited value.
    • pm215 7mo ago
      If the team is that small and working on things that are that disparate, then it is also very vulnerable to one of those people leaving, at which point there's a whole part of the project that nobody on the team has a good understanding of. Having somebody else devote enough time to being up to speed enough to do code review on an area is also an investment in resilience so the team isn't suddenly in huge difficulty if the lone expert in that area leaves. It's still a problem, but at least you have one other person who's been looking at the code and talking about it with the now-departed expert, instead of nobody.
• halo 7mo ago
  In my experience, good mature organisations have clear review processes to ensure quality, improve collaboration and reduce errors and risk. This is regardless of field. It does slow you down - not 10x - but the benefits outweigh the downsides in the long run. The worst places I’ve worked have a pattern where someone senior drives a major change without any oversight, review or understanding causing multiple ongoing issues. This problem then gets dumped onto more junior colleagues, at which point it becomes harder and more time consuming to fix (“technical debt”). The senior role then boasts about their successful agile delivery to their superiors who don’t have visibility of the issues, much to the eye-rolls of all the people dealing with the constant problems.
• ychompinator 7mo ago
  [dead]
• DeathArrow 7mo ago
  I totally agree with his ideas, but somehow he seems just stating the obvious: startups move better than big orgs and you can solve a problem by dividing it in smaller problems - if possible. And that AI experimentation is cheap.
• PunchyHamster 7mo ago
  > I know what you're thinking. Come on, 10x? That’s a lot. It’s unfathomable. Surely we’re exaggerating. See this rarely known trick! You can be up to 9x more efficient if you code something else when you wait for review > AI projectile vomits Fuck engineering, let's work on methods to make artificial retard be more efficient!
  • wiseowise 7mo ago
    > See this rarely known trick! You can be up to 9x more efficient if you code something else when you wait for review Context switch alone would kill any productivity gains from this. And I’m not even touching on conflicting MRs and interdependencies yet.
• pu_pe 7mo ago
  Nice piece, and rings true. I also think startups and smaller organizations will be able to capture better value out of AI because they simply don't have all those approval layers.
  • beepbooptheory 7mo ago
    I do not think you have comprehended the blog. > you can’t overcome latency with brute force Curious what rang true to you if not the main point?
    • jerf 7mo ago
      The approval tree grows logarithmically as the size of the company grows. A startup can win initially because they may have zero or one level to get to production. That's part of how they manage to get inside the OODA loop of much bigger companies. The flip side of that, and why the software world is not a complex network of millions of tiny startups but in fact has quite a few companies where log(organization) >= 2, is that there are a lot of tasks that are just larger than a startup, and the log of the minimum size organization that can do the job becomes 2 or 3 or 4. There is certainly at least the possibility that AI can really enhance those startups even faster, but it also means that they'll get to the point that they need more layers more quickly, too. Since AI can help much, much more with coding than it can with the other layers (not that it can't help, but at the moment I don't think there's anybody else in the world getting the advantages from AI that programmers are getting), it can also result in the amount of time that startups can stay in the log(organization)=1 range shrink. (Pardon the sloppy "log(organization)" notation. It should not be taken too literally.)
• nfw2 7mo ago
  from article: 1. Whoa, I produced this prototype so fast! I have super powers! 2. This prototype is getting buggy. I’ll tell the AI to fix the bugs. 3. Hmm, every change now causes as many new bugs as it fixes. 4. Aha! But if I have an AI agent also review the code, it can find its own bugs! 5. Wait, why am I personally passing data back and forth between agents 6. I need an agent framework 7. I can have my agent write an agent framework! 8. Return to step 1 the author seems to imply this is recursive when it isn't. when you have an effective agent framework you can ship more high quality code quickly.
  • nananana9 7mo ago
    I've been begging left and right, and I've yet to see a single example of this agent-written high-quality quickly-shipped code.
    • duskdozer 7mo ago
      I'm guessing a lot of the high-x productivity boost is from a cycle of generating lots of code, having bug reports detected or hallucinated from that code, and then generating even more code to close out those reports, and so on
    • wiseowise 7mo ago
      OpenClaw! You just need to slightly change the definition of “good code”. The point of code is to ultimately bring money. The guy got hired by OpenAI and who gives a shit what happens to the “project” next. Mission accomplished.
    • munksbeer 7mo ago
      There are examples littered around threads on HN. What happens is when people provide the examples, the goalposts get moved. So people have stopped bothering to reply to these demands.
    • nfw2 7mo ago
      what do you mean exactly? you are asking random people to share their company's code with you?
• afc 7mo ago
  Waiting for a few days of design review is a pain that is easy to avoid: all we need is to be ready to spend a few months building a potentially useless system.
• alkonaut 7mo ago
  I think this makes an assumption early on which is that things are serialized, when usually they are not. If I complete a bugfix every 30 minutes, and submit them all for review, then I really don't care whether the review completes 5 hours later. By that time I have fixed 10 more bugs! Sure, getting review feedback 5 hours later will force me to context switch back to 10 bugs ago and try to remember what that was about, and that might mean spending a few more minutes than necessary. But that time was going to be spent _anyway_ on that bug, even if the review had happened instantly. The key to keeping speed up in slow async communication is just working on N things at the same time.
  • joshmoody24 7mo ago
    I made a queuing theory calculator for this: https://joshmoody.org/blog/number-of-agents/#number-of-agents-optimizer https://joshmoody.org/blog/number-of-agents/#number-of-agent... Although you'll have to mentally replace the word "agent" with "PR" for it to make sense in this context. The math is the same. It all boils down to how much those context switches costs you. If it's a large cost, then you can get a huge productivity boost by increasing review speed. In the "show calculations" section, the amount of wasted time caused by context switching is the delta between the numbers in the phrase "T_r adjusted from 30.0 to 35 minutes". That number is increases as context switching cost and "average agent time" (AKA "average PR review time") goes up.
  • oktcho 7mo ago
    Not sure, but there might be a misunderstanding here: The value of your bug fix is cashed out only when it reaches the customer, not when you have finished implementing it. There is a cost of delay for value to reach the customer, and we want that delay to be as short as possible. So it doesn't matter if you fix 10 bugs because your 10th bug is going to reach production 5x10 hours (that's an exageration, but you get the point) after you had fixed it (which is why the article mentions latency and not touch time) You can tell me "yes but I also participate in the code review effort in parallel). Yes, but then you are not fixing 10 bugs, you are fixing less and reviewing more, and reviews take longer than implementation (especially with LLMs now in the loop). It's because of the pretty counter-intuitive Little's Law : the more in-progress you have in parallel, the slower it will get for each item to be completed.
• trigvi 7mo ago
  Excellent article. Based on personal experience, if you build cutting edge stuff then you need great engineers and reviewers. But for anything else, you just need an individual (not a team) who's okay (not great) at multiple things (architecting, coding, communicating, keeping costs down, testing their stuff). Let them build and operate something from start to finish without reviewing. Judge it by how well their produce works.
• presentation 7mo ago
  I broadly agree with this, it really is all about trust. Just, as a company scales it’s hard to make sure that everybody in the team remains trustworthy – it isn’t just about personality and culture, it’s also about people actually having the skill, motivation, and track record of doing good work efficiently. Maybe AI‘s greatest value will be to allow teams to stay small, which reduces the difficulty of maintaining trust.
  • kkl 7mo ago
    It’s also the case that someone you trust makes an honest mistake and, for example, gets their laptop stolen and their credentials compromised. I do trust my team, and want that to be the foundation to our relationship, but I also recognize that humans are infallible and having guardrails (eg code review) is beneficial.
• entrustai 7mo ago
  [dead]
• dominicrose 7mo ago
  Managers are expected to say that we should be productive yet they're responsible for the framework which slows down everyone and it's quite clear that they're perfectly fine with this framework. I'm not saying it's good or bad because it's complicated.
  • mablopoule 7mo ago
    A few years ago there was a thread about "How complex systems fail" here on HN[1], and one aspect of it (rule 9) is about how individuals have to balance between security and productivity, and being judged differently depending on the context (especially being judged after-the-fact for the security aspect, while being judged before the accident for the productivity aspect). The linked page in the thread is short and quite enlightening, but here is the relevant passage: > Rule 9: Human operators have dual roles: as producers & as defenders against failure. > The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense against failure role is emphasized. At either time, the outsider’s view misapprehends the operator’s constant, simultaneous engagement with both roles. [1] https://news.ycombinator.com/item?id=32895812 https://news.ycombinator.com/item?id=32895812
• janpmz 7mo ago
  A lot of this goes away when the person who builds also decides what to build.
  • nananana9 7mo ago
    That's great, but if I hire a random person from this thread and let them decide, chances are they would build an agent orchestrator.
• ChrisMarshallNY 7mo ago
  Communication overhead is the #1 schedule killer, in my experience. Whenever we have to talk/write about our work, it slows things down. Code reviews, design reviews, status updates, etc. all impact progress. In many cases, they are vital, and can’t be eliminated, but they can be streamlined. People get really hung up on tools and development dogma, but I've found that there’s no substitute for having experienced, trained, invested, technically-competent people involved. The more they already know, the less we have to communicate. That’s a big reason that I have for preferring small meetings. I think limiting participants to direct technical members, is really important. I also don’t like regularly-scheduled meetings (like standups). Every meeting should be ad hoc, in my opinion. Of course, I spent a majority of my career, at a Japanese company, where meetings are a currency, so fewer meetings is sort of my Shangri-La. I’m currently working on a rewrite of an app that I originally worked on, for nearly four years. It’s been out for two years, and has been fairly successful. During that time, we have done a lot of incremental improvements. It’s time for a 2.0 rewrite. I’ve been working on it for a couple of months, with LLM assistance, and the speed has been astounding. I’m probably halfway through it, already. But I have also been working primarily alone, on the backend and model. The design and requirements are stable and well-established. I know pretty much exactly what needs to be done. Much of my time is spent testing LLM output, and prompting rework. I’m the “review slowdown,” but the results would be disastrous, if I didn’t do it. It’s a very modular design, with loosely-coupled, well-tested and documented components, allowing me to concentrate on the “sharp end.” I’ve worked this way for decades, and it’s a proven technique. Once I start working on the GUI, I guarantee that the brakes will start smoking. All because of the need for non-technical stakeholder team involvement. They have to be involved, and their involvement will make a huge difference (like a Graphic UX Designer), but it will still slow things down. I have developed ways to streamline the process, though, like using TestFlight, way earlier than most teams.
• yason 7mo ago
  One thing that often gets dismissed is the value/effort ratio of reviews. A review must be useful and the time spent on reviewing, re-editing, and re-reviewing must improve the quality enough to warrant the time spent on it. Even long and strict reviews are worth it if they actually produce near bugless code. In reality, that's rarely the case. Too often, reviewing gets down into the rabbithole of various minutiae and the time spent to gain the mutual compromise between what the programmer wants to ship and the reviewer can agree to pass is not worth the effort. The time would be better spent on something else if the process doesn't yield substantiable quality. Iterating a review over and over and over to hone it into one interpretation of perfection will only bump the change into the next 10x bracket in the wallclock timeline mentioned in this article. In the adage of "first make it work, then make it correct, and then make it fast" a review only needs to require that the change reaches the first step or, in other words, to prevent breaking something or the development going into an obviously wrong direction straight from the start. If the change works, maybe with caveats but still works, then all is generally fine enough that the change can be improved in follow-up commits. For this, the review doesn't need to be thorough details: a few comments to point the change into the right direction is often enough. That kind of reviews are very efficient use of time. Overall, in most cases a review should be a very short part of the development process. Most of the time should be spent programming and not in review churn. A review serves as a quick check-point that things are still going the right way but it shouldn't dictate the exact path that should be used in order to get there.
• TheChelsUK 7mo ago
  That’s because most teams are doing engineering wrong. The handover to a peer for review is a falsehood. PRs were designed for open source projects to gate keep public contributors. Teams should be doing trunk-based development, group/mob programming and one piece flow. Speed is only one measure and AI is pushing this further to an extreme with the volume of change and more code. The quality aspect is missing here. Speed without quality is a fallacy and it will haunt us. Don’t focus on speed alone, and the need to always be busy and picking up the next item - focus on quality and throughput keeping work in progress to a minimum (1). Deliver meaningful reasoned changed as a team, together.
  • burnt-resistor 7mo ago
    I've seen speed without quality in a single founder shop where they piled up tech debt so high, velocity for anything was glacial and they still wouldn't stop to refactor or clean up. The best balance of individual initiative-velocity vs. peer review culture I've seen was at Facebook.
• wei03288 7mo ago
  [dead]
• rainmaking 7mo ago
  That's exactly why I think vibecoding uniquely benefits solo and small team founders. For anything bigger, work is not the bottleneck, it's someone's lack of imagination. https://capocasa.dev/the-golden-age-of-those-who-can-pull-it-off https://capocasa.dev/the-golden-age-of-those-who-can-pull-it...
  • ap99 7mo ago
    Yes there's more red tape the larger you get but there's also working product(s) that when they're broken you stop making money. See recent Amazon outages caused by vibe/slop/movefast coding practices with little review.
• orwin 7mo ago
  > Now you either get to spend 27 minutes reviewing the code yourself in a back-and-forth loop with the AI (this is actually kinda fun); or you save 27 minutes and submit unverified code to the code reviewer, who will still take 5 hours like before, but who will now be mad that you’re making them read the slop that you were too lazy to read yourself. That's me. I'm the mad reviewer. Each time I ranted against AI on this site, it was after reviewing sloppy code. Yes, Claude Opus is better on average than my juniors/new hires. But it will do the same mistakes twice. I _need_ you to fucking review your own generated code and catch the obvious issues before you submit it to me. Please.
• swiftcoder 7mo ago
  > The job of a code reviewer isn't to review code. It's to figure out how to obsolete their code review comment, that whole class of comment, in all future cases, until you don't need their reviews at all anymore Amen brother
• jtbetz22 7mo ago
  [flagged]
  • dominotw 7mo ago
    building software is no easy that now that every comment on HN has turned into a growth hacking sales pitch.
  • zingar 7mo ago
    Great point! We’ve been shifting quality left in human teams for decades now, and there’s still territory there that few (no?) teams have explored. AI is probably where that unexplored terrain becomes worthwhile to explore.
• zingar 7mo ago
  This is a profound point but is review really the problem or is it the handoff that crosses boundaries (me to others, our team to other team, our org to outside our org)?
• gebalamariusz 7mo ago
  Well, this all makes sense for application code, but not necessarily for infrastructure changes. Imagine a failed Terraform merge that deletes the production database but opens the inbound at 0.0.0.0/0, and you can't undo it for 10 minutes. In my opinion, you need to pay attention to the narrow scope specific to a given project.
  • furryrain 7mo ago
    Try to imagine a deployment/CI system where that isn't possible. That's what the post is asking. * Maybe you don't have privileges to delete the database * Maybe your CI environments are actually high fidelity, and will fail when there is no DB * Maybe destructive actions require further review * Maybe your service isn't exposed to the public internet, and exposing to 0.0.0.0/0 isn't a problem. * Maybe we engineer our systems to have trivial instant undo, and deleting a DB triggers an undo Our tooling is kind of crappy. There's a lot we can do.
• rigorclaw 7mo ago
  [flagged]
• laughing_mann 7mo ago
  https://vekthos.com/papers/cognitive-sight-theory.pdf https://vekthos.com/papers/cognitive-sight-theory.pdf Solution: Feed this paper to the llm and ask it to solve your problem. Then contact me with your experience. XD
• nottorp 7mo ago
  Are we starting to need a BuSab for programming?
• sltr 7mo ago
  about a year ago I shared this on /r/AskProgramming: "...a Pull Request is a delivery. It's like UPS standing at your door with a package. You think, "Nice, the feature, bugfix, etc has arrived! And because it's a delivery, it's also an inspection. A Code Review. Like a freight delivery with a manifest and signoff. So you have to be able to conduct the inspection: to understand what you're receiving and evaluate if it's acceptable as-is. Like signing for a package, once you approve, the code is yours and your team's to keep." The metaphor has limits. IRL I sign immediately and resolve issues post-hoc with customer service. The UPS guy is not going to stand on my porch while I check if there's actually a bootable MacBook in the box. The vast majority of the time, there's no issue. If that were the same with code, teams could adopt a similar "trust now and defer verification" approach. The article has a section on Modularity but never defines it. I wrote a post a few weeks ago on modularity and LLMs which does provide a definition. [1]. [1] https://www.slater.dev/2026/02/relieve-your-context-anxiety-with-modular-thinking/ https://www.slater.dev/2026/02/relieve-your-context-anxiety-...
• teeray 7mo ago
  Code reviews are a volunteer’s dilemma. Nobody is showered with accolades by putting “reviewed a bunch of PRs” on their performance review by comparison with “shipped a bunch of features.” The two go hand-in-hand, but rewards follow marks of authorship despite how much reviewers influence what actually landed in production. Consequently, people tend to become invested in reviewing work only once it’s blocking their work. Usually, that’s work that they need to do in the future that depends on your changes. However, that can also be work they’re doing concurrently that now has a bunch of merge conflicts because your change landed first. The latter reviewers, unfortunately, won’t have an opinion until it’s too late. Fortunately, code is fairly malleable. These “reviewers” can submit their own changes. If your process has a bias towards merging sooner, you may merge suboptimal changes. However, it will converge on a better solution more quickly than if your changes live in a vacuum for months on a feature branch passing through the gauntlet of a Byzantine review and CI process.
  • surajrmal 7mo ago
    Or the reviewer feels responsible for the output of the code from the person they are reviewing or the code they are modifying. For instance a lead on the team gets credit for the output of the team Also, wanting to catch bugs on review before they make your on call painful can be a large motivation.
  • ndriscoll 7mo ago
    I've always encouraged everyone more junior to review everything regardless of who signs off, and even if you don't understand what's going on/why something was done in a particular way, to not be shy to leave comments asking for clarification. Reviewing others' work is a fantastic way to learn. At a lower level, do it selfishly. If you're aiming for a higher level, you also need to review work. If you're leading a team or above (or want to be), I assume you'll be doing a lot of reviewing of code, design docs, etc. If you're judged on the effectiveness of the team, reviews are maybe not an explicit part of some ladder doc, but they're going to be part of boosting that effectiveness.
  • bee_rider 7mo ago
    It’s weird that the two tasks that most programmers would agree are most important (reviewing code and deleting code) are not heavily rewarded.
• cm2012 7mo ago
  This is very true in marketing and advertising as well. A campaign where the channel manager can just test ads within a general framework will do ten times better than a campaign that has to go through review processes.
• ferguess_k 7mo ago
  These are just made up numbers. In our team, PR review is always 1 minute -- we never review, just approve, and let production reviews. /s
• ddactic 7mo ago
  [dead]
• drob518 7mo ago
  Overall, this is pretty accurate. Of course, it’s a range at every level, say 5x-15x. Large companies trend toward 15x and startups toward 5x, which is why startups out-execute large companies. Also, they just skip some levels of review because, for instance, the CEO is sitting in a code review meeting. But yea, the average is close.
• frandroid 7mo ago
  For all the people talking about 5 hour PR review delays... This reminds me of some teams that rotate the "fire extinguisher/emergency bug fixer" duty every day/week/sprint to a different developer. One could rotate a dedicated "first review duty" person. That developer would be in charge of focusing on rapidly starting PR reviews as their priority, with option to request other reviewers if necessary. Spreading the duty around would make people be respectful of the reviewer because if they send unreviewed slop to the reviewers, it's likely that people will send them slop too.
• maxothex 7mo ago
  [dead]
• kkl 7mo ago
  > The job of a code reviewer isn't to review code. It's to figure out how to obsolete their code review comment, that whole class of comment, in all future cases, until you don't need their reviews at all anymore. Making entire classes of issues effectively impossible is definitely the ideal outcome. But, this feels much more complicated when you consider that trust doesn't always extend beyond the company's wall and you cannot always ignore that fact because the negative outcomes can be external to the company. What if I, a trusted engineer, run `npm update` at the wrong time and malware makes its way into production and user data is stolen? A mistake to learn from, for sure, but a post-mortem is too late for those users. I'm certainly not advocating for relying on human checks everywhere, but reasoning about where you crank the trust knob can get very complicated or costly. Occasionally a trustworthy human reviewer can be part of a very reasonable control.
  • apenwarr 7mo ago
    Japanese manufacturing addressed this too! There’s a whole branch of Deming’s work around supply chains and how it’s often worth working with “more expensive” suppliers when their quality is consistently high, because compensating for low quality inputs to your own work is far more expensive.
• Nijikokun 7mo ago
  > only >> recenlty << started happening can't believe I was baited into reading this slop /jk good post actually, and a fair point I do think many people will argue that you can just not review things though.
• SmashngKbds 7mo ago
  This was well written and it hit hard. It brought clarity to an uneasy collection of gut feels, anecdotal evidence, and fundamental beliefs like nothing else. What I'm feeling might even be categorized as an epiphany. I've always liked Tailscale as a product and now I might be a fan of their CEO too. Who knew? I'll be sharing this post widely. Avery - if you're on here, thanks for writing this!
  • apenwarr 7mo ago
    I’m glad you liked it!
• upsuper 7mo ago
  I hope the author can specify a language for the page, like <html lang="en">. On a system using Chinese as the first language, all the curly quotes are rendered in full width, making sentences looking terrible.
• tmatsuzaki 7mo ago
  If we keep reviewing using the same process as before, it will slow things down. Also, since the output is massive, I think we should narrow down the points we focus on when reviewing.
• gwern 7mo ago
  The 10x claim reminds me of various scaling laws in anthropology/sociology, especially the much-debated Haire cube-root scaling law (eg https://gwern.net/doc/sociology/1959-haire.pdf https://gwern.net/doc/sociology/1959-haire.pdf https://gwern.net/doc/economics/1983-stephan.pdf https://gwern.net/doc/economics/1983-stephan.pdf ). I wonder if one could give a derivation from queuing theory where you have an argument along the lines of 'in indefinitely many layers of queues of queues, the total delay is minimized at 90% load per queue which yields a 10x scale-free slowdown'?
  • gwern 7mo ago
    After some chatting with GPT-5.4 Pro, I think the 10x claim might simply be because in the >90% load region, you get the famous unbounded delays. And with realistic loss functions like absolute or squared error (consider that in a queue of queues, delays would add) and distributions like Poisson, you'd encounter massively increased losses if you pushed too far towards 100% load. Without extremely detailed accurate statistics of the sort almost no one has, it'd be hard to distinguish 'by eye' 90% from 95%, say, and you'd just see '10x' everywhere you looked. (And in a pyramid of queues like many layers of reviews, each layer will wind up being about equally loaded, because otherwise you would get a big benefit from adding/removing capacity, so each layer will slowly be optimized towards its breaking point, yielding the 10x everywhere.)
• bfivyvysj 7mo ago
  I've been banging on a drum for the past decade that the industry needs to switch to asynchronous review. You allow self review and optional external review of code but the default is that the engineer can ship to production without a review block. Then you either do post merge review: have a review column in jira or whatever where people are assigned to review and can complete on their own schedule in a non disruptive and non blocking way. This also avoids piling reviews onto whoever has the best rubber stamp. Or You switch to a quarterly system review meeting where you as a group go over and suggest improvements to make in the codebase holistically. I've seen both of these work extremely well and with AI you can basically automate the review process to the point it's pretty much pointless having a human review step. The only other way to avoid the issue of people sitting on thumbs waiting for review is to have everyone prioritize reviewing code ahead of producing new code. This works but is incredibly disruptive to the reviewer and has side effects like review bombing on the largest rubber stamp reviewer.
• luxuryballs 7mo ago
  [dead]
• tomasz-tomczyk 7mo ago
  Yes, reviewing things make things slower. Not reviewing them produces horrible results. There's a balance to be found and it depends on the team/org. I hope we shift engineers closer to users than ever before. Get them to understand user's needs and the actual product more - they'll write better plans and prompts. Review the plans. Code review becomes less of a thing when the team's on the same page, so regularly align on what the goals are. Accept post-merge code reviews. Things slip, normalise coming back and saying "actually, we should have done this differently". It's not a bad thing, you're learning!