Every layer of review makes you 10x slower
apenwarr.ca
apenwarr.ca
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.
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.
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.
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.
And no, it isn't ONLY because VC capital is being burned to subsidize cost. That is impossible for the dozen smaller providers offering service at that cost on OpenRouter who have to compete with each other for every request and also have to pay compute bills.
Qwen3.5-9B is stronger than GPT-4o and it runs on my laptop. That isn't just benchmarks either. Models are getting smaller, cheaper and better at the same time and this is going to continue.
1. The longer I work in this industry, the more it becomes clear that CxO's aren't great at projecting/planning, and default to copy-cat, herd behaviors when uncertain.
Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin. Probably wouldn't be a massively successful one, but good enough to survive 2 years and have millions in the bank for that, or get fired and get a golden parachute.
(half) joking - most likely I'm massively trivializing the role.
Having worked for a pretty decent CIO of a global business I'd say his main job was to travel about speak to other senior leaders and work out what business problems they had and try and work out, at a very high level, how technology would fit into that addressing those problems.
Just parroting latest technology trends would, I suspect, get you sacked within a few weeks.
If devs are expected to ship 10x faster (or else!), then they will find a way to ship 10x faster.
Ive had metrics rammed down my throat, Ive had AI rammed down my throat, Scrum rammed down my throad and Ive had various other diktats rammed down my throat.
95% of which slowed us down.
The only time ive been asked is when there is a deadline and it's pretty clear we arent going to hit it and even then they're interested in quick wins like "can we bring lunch to you for a few weeks?", not systemic changes.
The fastest and most productive times have been when management just set high level goals and stopped prodding.
Im convinced that the companies which seek developer autonomy will leave the ones which seek to maximize token usage in the dust in the next tech race.
I've often wondered about building some kind of automated "this codebase already has this logic" linter
Not sure how it would actually work, otherwise I'd build it. But it would definitely be useful
Maybe an AI tool could do something like that nowadays. "Search this codebase for instances of duplicated functions and list them out" sort of thing
At first glance this looks like it might be the halting problem in disguise (instead of the general function of the logic, just ask if they both have logic that halts or doesn't halt). I think we would need to allow for false negatives to even be theoretically possible, so while identical text comparison would be easy enough, anything past that can quickly becomes complicated and you can probably infinitely expand the complexity by handling more and more edge cases (but never every edge case due to the underlying halting problem/undecidability of code).
In Ruby we have the Flay gem, for example.
Perhaps kind of a pain to inject fixes in, have to rebase the outstanding work. But I kind of like this idea of the org having responsibility to do what review it wants, without making every person have to coral all the cats to get all the check marks. Make it the org's challenge instead.
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 ~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?
So, it makes sense if you have infinite testing budgets.
Personally, I prefer exhaustively testing the upgrade path, and investing in reducing the time it takes to push out a hot fix. Chicken bits are also good.
I haven’t heard of any real world situations where supporting downgrades of persistent formats led to best of class product stability.
Would love to hear of an example.
They might be an appropriate safeguard for a prototyping shop, but not for Delta.
It does. We’ve tried. No it’s not as easy as running the previous version.
I have written about this: https://swizec.com/blog/why-software-only-moves-forward/
> Takes ~10min to revert a bad deploy
A bad deploy can take way over that just in customer or partner management communication.
Wanna be treated like an adult? Cool. You'll also be held accountable like an adult.
That's cool. Expect to pay me for the availability outside work hours. And extra when I'm actually called
We pay people enough to care about the software they ship.
Don’t want to be called outside of work hours? Make sure your code works. Simple.
1. I don't care because the company at large fails to value quality engineering.
2. 90% of PR comments are arguments about variable names.
3. The other 10% are mistakes that have very limited blast radius.
It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable state, in which case there's no point delaying the project.
Regarding knowledge share, it's complete fiction. Unless you actually make changes to some code, there's zero chance you'll understand how it works.
My trust in my colleagues is gone, I have no reason to believe they wrote the code they asked me to put my approval on, and so I certainly don’t want to be on a postmortem being asked why I approved the change.
Perhaps if I worked in a different industry I would feel like you do, but payments is a scary place to cause downtime.
PR #515 - Reformat code from spaces to tabs
Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs.
The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.
Or for some, if it contains the value of a column in the db, it must have the same name as the column.
So yeah, instead of "UsualQuantityOrder", you get "UslQtyOrd" or "I_U_Q_O"... And you must maintain the comments to explain what the field is supposed to contain.
I have fixed this by forcing the issue and we get together as a team, set a standard and document it. If we can use tools to enforce it automatically we do that. If not you get a comment with a link to the style guide and told to fix it.
Style is subjective but consistency is not. Having a formal style guide which is automatically enforced helps with onboarding and code review as well.
I regularly review code that is way more complicated that it should.
The last few days I was going back and forth on reviews on a function that had originally cyclomatic complexity of 23. Eventually I got it down to 8, but I had to call him into a pair programming session and show him how the complexity could be reduced.
Or it didn't really matter that the function was complex if the structure of what's surrounding it was robust and testable; just let it be a refactor or bug ticket later.
If you're sure cyclomatic complexity should be minimized, I think you should put such rules in a pre-commit hook or something that runs before a reviewer ever sees the code. You should only have to help with that if someone can't figure out how to make it pass.
If you're not willing or politically able to implement that, you might be wasting time on your personal taste that the team doesn't agree with. Personally I'm pretty skeptical of cyclomatic complexity's usefulness as a metric.
the original function was full of mutable state (not required), full of special cases (not required), full of extra return statements (not required). Also had some private helper methods that were mocked in the tests (!!!).
All of this just for a "pure" function. Just immutable object in - immutable object out.
and yes, he was a junior.
This sort of comment is meaningless noise that people add to PRs to pad their management-facing code review stats. If this is going on in your shop, your senior engineers have failed to set a suitable engineering culture.
If you are one of the seniors, schedule a one-on-one with your manager, and tell them in no uncertain terms that code review stats are off-limits for performance reviews, because it's causing perverse incentives that fuck up the workflow.
I have been involved in enough code reviews both in a corporate environment and in open source projects to know this is an outlier. When code review is done well, both the author and reviewer learn from the experience.
https://blog.barrack.ai/amazon-ai-agents-deleting-production...
Then there are the people who program best in a fugue state and the idea of having to constantly break that to transform their thoughts into words and human interaction is anathema.
I say this as someone who just woke up in the wee hours of the morning when nobody else is around so I can get some work done (:
The biggest downside to me was that it forces a level of engagement exceeding the most heads down solo work I’ve done. I’d come home and feel mentally exhausted in a way I didn’t usually.
But. The design contract needs review, which takes time.
and it also works for me when working with ai. that produces much better results, too, when I first so a design session really discussing what to build. then a planning session, in which steps to build it ("reviewability" world wonder). and then the instruction to stop when things get gnarly and work with the hooman.
does anyone here have a good system prompt for that self observance "I might be stuck, I'm kinda sorta looping. let's talk with hooman!"?
After all, most people will be on their best behavior during an interview, and even a lengthy interview process is a very short period of time compared to working with someone for weeks or months.
The question is really "Will up-front design and pair programming cost more than not doing up-front design and pair programming?".
In my experience, somewhat counter-intuitively, alignment and pairing is cheaper because you get to the right answer a bit 'slower' but without needing the time spent reworking things. If rework is doubling the time it takes to deliver something (which is not an extreme example, and in some orgs would be incredibly conservative) then spending 1.5 times the estimate putting in good design and pair programming time is still waaaay cheaper.
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.
> Most of what's planned falls down within the first few hours of implementation.
Not my experience at all. We know what computers are capable of.
My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool.
The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.
Agile isn’t a good match for a business that can only think in terms of effort and not learning+value. That doesn’t make agile the problem.
To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable deliverable or something you could put on a management facing status report.
Each task was so time boxed, seniors would actively be upbraided in agile ceremonies for doing obvious next steps. 8 tickets sequentially like - Download the data. Analyze the data. Load a sample of the data. Load all the data. Ok now put in data quality tests on the data. OK now schedule the daily load of the data. OK now talk to users about the type of views/aggregations/API they want on the data. OK now do a v0 of that API.
It's sort of interesting because we have fully transitioned from the agile infantilization of seniors to expecting them to replace a team of juniors with LLMs.
You shouldn't put juniors in a strict short time box either. At least not for long.
People don't grow if they can't think about the results of their work. If if your juniors can't grow, you could as well not hire any.
Depending on the reality, either that company doesn't understand agile very well, or you didn't understand the importance of the small steps.
A plan is not made agile by being split into many small sequential steps; what would make this agile is learning from each step and being prepared to scrap steps 2-8 if step 1 turns out to be enough. Usually this attitude results in splits that make more sense and do add user value.
OTOH I've seen many experienced folks get tripped up because it's easy to get consumed and not evaluate work vs the customer value when you're in the middle of a big task.
For example on an internationalisation project a dev thought: "Every translation key is handled the same way in Rails, let me just do them all at once"; spent weeks with the appearance of no progress because they were working through many cases often slightly more complicated than imagined. They said out loud ~ "I'm not working just for the sake of a task board, the work needs to be done, let's be better than box ticking, it's all one logically consistent piece of work".
I had to interrupt to point out that most of the pages were either about to be deleted or were only needed later. Meanwhile we had tons of work that needed this person's attention on things that were of immediate importance.
It's also important to work in a way that a high number of PRs is not a penalty. It's a smell if we're motivated to reduce the number of PRs because shipping PRs feels difficult.
Sure there's a 3000 row excel file of requirements but during development the client still sees the product or slides outlining how the product works and you still had QA that had to test stuff as you made it. Then you make changes based on that feedback.
While Agile often feels like it's lost the plot. We're just going to make something and iterate it into a product people like versus figuring out a product people will like and designing towards it.
If you work in an environment where you definitely do know where you want the product to go, and the customer doesn't change their mind once they've seen the first working bits, then great. But I've never worked in that kind of environment.
A one page requirements document is like pulling teeth apparently.
However the value of agile is in the learning you do along the way that helps you see that the value is only in 10% of the work. So you’re not comparing 100% across two methodologies, you’re comparing 100% effort vs 10% effort (or maybe 20% because nobody is perfect).
Most of the time when I see unhappiness at the agile result it’s because the assessment is done on how well the plan was delivered, as opposed to how much value was created.
That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.
agile approaches are based on the quick implementations, redone as needed.
my favorite life cycle: 1> Start with requirements identification for the entire system. 2> Pick a subset of requirements to implement and demonstrate (or deliver) to the customer. 3> Refine the requirements as needed. 4> go to 2
The key is you have an idea of overall system requirements and what is needed, in the end, for the software you are writing. Thus the re-factoring, and re-design due to things not included in the sprint do not occur. (or occur less)
> Not my experience at all. We know what computers are capable of.
You must not work in a field where uncertainty is baked in, like Data Science. We call them “hypotheses”. As an example, my team recently had a week-long workshop where we committed to bodies of work on timelines and 3 out of our 4 workstreams blew up just a few days after the workshop because our initial hypotheses were false (i.e. “best case scenario X is true and we can simply implement Y; whoops, X is false, onto the next idea”)
Every single reply in this thread is someone sharing their subjective anecdotal experience..
There are so many factors involved in how work pans out beyond planning. Even a single one of us could probably tell 10 different stories about 10 different projects that all went differently.
There are costs to pouring out a cement foundation without thinking through how many floors your building is going to be in advance.
But when I hammer out the first 30 minutes of code, I have that info. And if we just spent four 2-hour meetings discussing this design, it's very common that I after 30 minutes of coding either have found 5 things that makes this design completly infeasible, or maybe 2 things that would have been so good to know before the meeting, that the 8 hours of meetings just should not have happened.
They should have been a single 2 hour meeting, followed by 30 minutes of coding, then a second 2 hour meeting to discuss the discoveries. Others might be much better than me of discovering these things at the design stage, but to me coding is the design stage. It's when I step back and say "wait a minute, this won't work!".
That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it.
The reason waterfall methodology falls flat so often is not long delivery times, but ending up with completely the wrong thing.
I don’t know. The faster you deliver the wrong thing, the sooner you can discover your mistake and pivot.
I haven't tried pair programming except in very ad-hoc situations, but doing it all the time sounds utterly exhausting. You're taking programming, then layering on top of it a level of constant social interaction over it, and removing the autonomy to just zone out a bit when you need to (to manage stress).
Basically, it sounds like turning programming into an all-day meeting.
So I think it's probably unpopular because most software engineers don't have the personalty to enjoy or even tolerate that environment.
But it's something you have to work at which is definitely part of the barrier. Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit."
I don't need to try pair programming because I know how that level of constant social interaction makes me feel.
> Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit."
No, what you're doing is sort of like if you're raving about the beach, and I say I don't like bright sun, and you insist I need to try the beach to have an opinion on if I like it or not.
IMHO, social interaction is anything where you interact with other people.
> It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone.
That's very black and white thinking. I like talking to other people, but too much of it is draining. Every day spending all-day or even a half-day working directly with someone else? No thanks.
[edit] I’m not even anti-social, but the feeling of being watched while working is extremely draining. An hour of that is like four hours without it.
I find it depressing and dystopian that people are now excited about having a robot pair.
I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?".
Or, people on a different team whose microservice talks to mine when debugging an issue or fleshing out an API spec.
It's true that this isnt possible in plenty of organizations due to the culture, but lots of organizations are broken in all sorts of ways that set piles of cash on fire. This one isnt unique.
Not "pair programming doesnt work with non programmers doing pure programming" coz it doesnt make much sense why you'd even attempt to do that. They dont care and they will get in the way.
Doing this often settles the design direction in a stable way early on. More than that, it often reveals a lot of the harder questions you’ll need to answer: domain constraints and usage expectations.
Putting this kind of work upfront can save an enormous amount of time and energy by precluding implementation work on the wrong things, and ruling out problematic approaches for both the problem at hand as well as a project’s longer term goals.
I cannot write a realistic non-hand-wavy design document without having a proof of concept working, because even if I try, I will need to convince myself that this part and this part and that part will work, and the only way to do it is to write an actual code, and then you pretty much have code ready, so why bother writing a design doc.
Some of my best (in terms of perf consequences) design documents were either completely trivial from the code complexity point of view, so that I did not actually need to write the code to see the system working, or were written after I already had a quick and dirty implementation working.
You don’t have to choose what flavor of DDD/Clean/… you want to drink, just use some method that keeps domains and use cases separate from implementation.
Just with shapes and domain level tests, the first pass on a spec is easier (at least for me) and I also found feedback was better.
I am sure there are other patterns that do the same, but the trick is to let the problem domain drive, not to choose any particular set of rules.
Keeping the core domain as a fixed point does that for me.
> Most of what's planned falls down within the first few hours of implementation.
hell in one sentence
You conveniently brushed this under the rug of pair programming but of the handful of companies I've worked at, only one tried it and just as an experiment which in the end failed because no one really wanted to work that way.
I think this "don't review" attitude is dangerous and only acceptable for hobby projects.
> You get things like the famous Toyota Production System where they eliminated the QA phase entirely.
> [This] approach to manufacturing didn’t have any magic bullets. Alas, you can’t just follow his ten-step process and immediately get higher quality engineering. The secret is, you have to get your engineers to engineer higher quality into the whole system, from top to bottom, repeatedly. Continuously.
> The basis of [this system] is trust. Trust among individuals that your boss Really Truly Actually wants to know about every defect, and wants you to stop the line when you find one. Trust among managers that executives were serious about quality. Trust among executives that individuals, given a system that can work and has the right incentives, will produce quality work and spot their own defects, and push the stop button when they need to push it.
> I think we’re going to be stuck with these systems pipeline problems for a long time. Review pipelines — layers of QA — don’t work. Instead, they make you slower while hiding root causes. Hiding causes makes them harder to fix.
If we hired two programmers, the goal was to produce twice the LOC per week. Now we are doing far less than our weekly target. Does not meet expectation.
IMHO / IME (over 20y in dev) reviewing PRs still has value as a sanity check and a guard against (slippery slope) hasty changes that might not have received all of the prior checks you mentioned. A bit of well-justified friction w/ ROI, along the lines of "slow is smooth, smooth is fast".
Code review benefits from someone coming in fresh, making assumptions and challenging those by looking at the code and documentation. With pair programming, you both take the same logical paths to the end result and I've seen this lead to missing things.
Welcome to working with real people. They go off the rails and ignore everything you’ve agreed to during design because they get lazy or feel schedule pressure and cut corners all the time.
Sideline: I feel like AI obeys the spec better than engineers sometimes sigh.
to move to the hyperspeed timescale you need reliable models of verification in the digital realm, fully accessible by AI.
I think that's why startups have such an edge over big companies. They can just build and iterate while the big company gets caught up in month-long review processes.
This is like, there's not going to be surprise on the road you'll take if you already set the destination point. Though most of the time, you are just given a vague description of the kind of place you want to reach, not a precise point targeted. And you are not necessarily starting with a map, not even an outdated one. Also geological forces reshape the landscape at least as fast as you are able to move.
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.
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.
I am not aware about the details - can you elaborate?
No team at Amazon should be larger than what two pizzas can feed (usually about 6 to 10 people).
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?
Well, we were making it a platform in small ways long before that edict from Bezos. But because it used to be only an online bookstore, the footprint was a lot smaller.
1. the external interface was ... HTTP
2. the pages were designed to be easily machine parsable
3. you could queue up search queries that amzn would run on its own hardware, and notify you of the results asynchronously.
Sure, this didn't look anything like the things Yegge is describing, but the idea that "it's a platform, dummies" was some new revelation is misleading.
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.
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.
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.
The code quality was much better than in my current workplace where the reviews are done in minutes, although the software was also orders of magnitude more complex.
Everyone was very highly paid, managers measured everything (including code review turnaround), and they frequently fired bottom performers. So, tradeoffs.
You do a lot of small changes (<100 loc) that get reviewed often. If it doesn't get reviewed often then the whole idea of continuous development breaks down.
Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc? After that 100 loc or maybe 200 take a break and review other people's code.
Plus you also have random meetings and stuff so your day already fragments itself so adding a code review in the time before a meeting or after is "free" from a fragmentation standpoint.
I have an issue at work that will likely be solved by a single line change. But figuring out which line it is is going to take awhile.
So it really doesn't matter when the review gets done. I mean, even a week and it's fine.
But some people will put up with a lot for half a million dollars a year.
My ideal system (for work) would be something like: after 2 days, ask for a review if the reviewer hasn't given it. After a week, warn them the PR will be auto-approved. After 2 weeks, auto-approve it.
At some moment I realized that reviews are holding things back most of all. I started to jump to review my team's code ASAP. I started to encourage others to go review things ASAP. It works even in relatively large companies, as long as your team has a reasonable size.
This can be learned, taught, and instilled.
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.
Amen brother
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.
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.
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.
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.
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.
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.
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!
(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.)
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.
The best balance of individual initiative-velocity vs. peer review culture I've seen was at Facebook.
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!
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.
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.
Usually at most 2-3 engineer have enough context to fully understand what your code is doing.
Most excellent.
Not saying this is a good situation, but it's quite easy to run into it.
> you can’t overcome latency with brute force
Curious what rang true to you if not the main point?
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.)
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.
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!
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.
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.
"...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-...
> 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.
We talked a lot about the costs of context switches so its reasonable to finish your work before switching to the 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.
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.
Generally if the reviewer is not familiar with the content asynchronous line by line reviews are of limited value.
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.
https://capocasa.dev/the-golden-age-of-those-who-can-pull-it...
See recent Amazon outages caused by vibe/slop/movefast coding practices with little review.
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.
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?
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.
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”
I know what they meant, and I also meant the thing I said instead. I have seen many, many people forge ahead on work that could have been saved by a bit more planning. Not overplanning, but doing a reasonable amount of planning.
Figuring out where the line is between planning and "just start trying some experiments" is a matter of experience.
I really like Churchill’s second famous quote: “What the fuck is software, lol”.
* 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.
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.
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).
Solution: Feed this paper to the llm and ask it to solve your problem. Then contact me with your experience. XD
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.
With AI my task to review is to see high level design choices and forget reviewing low level details. It’s much simpler.
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
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.
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.
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.
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.
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!
Context switch alone would kill any productivity gains from this. And I’m not even touching on conflicting MRs and interdependencies yet.
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.
You expect your calculator to always give correct answers, your bank to always transfer your money correctly, and so on.
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
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.
Hence my interest in sandboxes!
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
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.
We can use AI these days to add another layer.
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.
There are some strategies that help: a lot of the AI directives need to go towards making the code actually easy to review. A lot of it it sits around clarity, granularity (code should be committed primarily in reviewable chunks - units of work that make sense for review) rather than whatever you would have done previously when code production was the bottleneck. Similarly, AI use needs to be weighted not just more towards tests, but towards tests that concretely and clearly answer questions that come up in review (what happens on this boundary condition? or if that variable is null? etc). Finally, changes need to be stratified along lines of risk rather than code modularity or other dimensions. That is, if a change is evidently risk free (in the sense of, "even if this IS broken it doesn't matter) it should be able to be rapidly approved / merged. Only things where it actually matters if it wrong should be blocked.
I have a feeling there are whole areas of software engineering where best practices are just operating on inertia and need to be reformulated now that the underlying cost dynamics have fundamentally shifted.
Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk?
Lemme guess, you cargo culted some "best practices" to offload risk awareness, so now your code is organized in "too big to fail" style and matches your vendor's risk profile instead of yours.
I guess the answer (if you're really asking seriously) is that previously when code production cost so far outweighed everything else, it made sense to structure everything to optimise efficiency in that dimension.
So if a change was implemented, the developer would deliver it as a functional unit that might cut across several lines of risk (low risk changes like updating some CSS sitting along side higher risk like a database migration, all bundled together). Because this was what made it fastest for the developer to implement the code.
Now if AI is doing it, screw how easy or fast it is to make the change. Deliver it in review chunks.
Was the original method cargo culted? I think most of what we do is cargo culted regardless. Virtually the entire software industry is built that way. So probably.
Oh, for sure. Those people making electro-mechanical computers at the end of the 19th century certainly did that a lot.
I think GP is thinking in terms of being incentivized by their environment to demonstrate an image of high personal throughput.
In a dysfunctional organization one is forced to overpromise and underdeliver, which the AI facilitates.