Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every layer of review makes you 10x slower

apenwarr.ca

Post reply on HN
Print view View original

101–110 of 339 posts

Re: Every layer of review makes you 10x slower

#101

Post by nfw2 »

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.

Re: Every layer of review makes you 10x slower

#102

Post by hrmtst93837 »

sublinear wrote: post #9

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.

[flagged]

Re: Every layer of review makes you 10x slower

#104

Post by alkonaut »

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.

Re: Every layer of review makes you 10x slower

#105

Post by trigvi »

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.

Re: Every layer of review makes you 10x slower

#106

Post by christophilus »

onion2k wrote: post #64
camillomiller wrote: post #56

Earlier quoted context omitted.

>> 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 t…

I think Claude could raise it's prices 100x and people would still use it. It'd just shift to being an enterprise-only option and companies would actually start to measure the value instead of being "Whee, AI is awesome! We're definitely going really fast now!"

100x? You think people would pay $20k per month for Claude Code?

Codex is as good (or very nearly) as Claude code. Open source models continue to improve. The open source harnesses will also continue to improve. Anthropic is good, but it has no moat. No way could they 100x their prices.

Re: Every layer of review makes you 10x slower

#107

Post by alkonaut »

onion2k wrote: post #22

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 wh…

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement.

If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation.

Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.

Re: Every layer of review makes you 10x slower

#108

Post by steve_taylor »

camillomiller wrote: post #53

>> 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 r…

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.

Re: Every layer of review makes you 10x slower

#109

Post by layer8 »

hinkley wrote: post #66
onion2k wrote: post #22

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 wh…

These systems make it more efficient to remove the actively toxic members for your team. Beligerence can be passively aggressively “handled” by additional layers but at considerable time and emotional labor cost to people who could be getting more work done without having to coddle untalented assholes.

Sounds like there was a bad hiring process.

Re: Every layer of review makes you 10x slower

#110

Post by jamiemallers »

pdhborges wrote: post #95
Swizec wrote: post #31

Earlier quoted context omitted.

> You also need to build a team that you can trust to write the code you agreed you'd write I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for. The other side of this is building safety nets. Takes ~1…

> The other side of this is building safety nets. Takes ~10min to revert a bad deploy. Does it? Reverting a bad deploy is not only about running the previous version. Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?

[dead]
Post reply on HN