No matter how much code you create, it's zero value until you ship. Writing code, building features, moving tickets, they're all vanity metrics. None of it matters until users can do something they couldn't do before.
With AI you can produce more code faster than ever before. And it doesn't matter. I bet you're still shipping at about the same speed as before aren't you?
We can see this in the data! You can feel it by looking around. Everyone talks about using AI, burning tokens, and doing work, but you rarely see people talk about getting more done at a company level.
Evidence on AI productivity
AI productivity gains are marginal at best. Studies show 4% average bump across 1300 firms in Europe, 0.8% higher output across 6000 executives surveyed globally, 0.4% to 1.3% higher economic output across rich countries, and so on.
Even though individual productivity is up with folks spending 3h/week less on email, writing code 50% faster, finishing 26% more coding tasks, closing 15% more support requests, and doing biz consulting 25% faster.
All this hype and churn and not much to show for it all. What gives [name|]?
I think it's the theory of constraints. Just because individual pieces move faster doesn't mean the whole system can get more done.
Theory of constraints
Theory of constraints is the managementy version of Amdahl's law. In a series of books through the 80's and 90's, Goldratt proposed that "Your factory can't move faster than its slowest part".
Sounds obvious right?
And I bet your company is not optimized for this insight at all :) Lemme know if this sounds familiar:
You're producing more code than ever, you're drowning in pull requests and code review, your eyes glaze over long-ass documents and code comments and PR descriptions full of words that say nothing, you wait hours and days for people to look at your code, you have long async conversations in the comments smeared across days, and by the time you finally merged your code, you've produced 10 more PRs and got tagged on 20 others?
You ship maybe 1 to 2 changes per day. Am I close?
Here's what happens.
Review is the bottleneck
Writing code used to be hard and releasing even harder. You need a lot of review to make sure that one quarterly release is good.
A bunch of engineers write code. Their code gets reviewed, tested, and approved. This slows you down but that's okay – you can work on the next feature while your current work gets reviewed. You don't expect to ship until The Next Deploy.
Modern DevOps and continuous integration changed the calculus. Releases became fast, measured in minutes. Instead of trying to catch mistakes, we make them easy to find and fix.
A bunch of engineers write code. You then review, test, and approve. Ship to prod as soon as you get a chance.
To make reviews faster, we add linters and automated test suites. Shift left to try and catch mistakes before wasting time on review. Best is when your editor can show squiggly lines before you even make a commit!
A quick linting step makes review faster and more valuable!
Reviews focus on higher level issues and waste less time on code consistency and obvious bad patterns. Slowing down the influx of PRs makes code review faster, which directly leads to more releases.
Then you add AI.
You produce lots of code, the code passes linters and all your tests, now code review is swamped. Shipping speed has not increased. You are drowning in work in progress, which kills your progress.
Why even code review?
Evidence for code review is mixed. I think it's largely a head-fake to trick senior engineers into mentoring juniors and it's a way to force domain modeling conversations.
Code review does not catch bugs or security issues and only indirectly leads to better code (but 95% better). Want to catch bugs? Test your code.
You should think of code review as a socio-technical practice that improves the long-term health of your software, increases everyone's familiarity with the code, and reduces post-release defects. This happens indirectly because better more familiar code is easier to work with. We know this empirically.
If you need SOC2 compliance, the standard mandates at least 2 humans have to see every line of code that hits production. Code review :)
Anatomy of a good code review
I treat pull requests as a quality gate.
- PRs are a convenient place to run all your tests and linters and ensure everything passes before you can merge
- Ask for videos and screenshots of working features in every pull request, which forces everyone to test their code. I find a lot of issues while recording these videos.
- Run a preview deploy so you can try and validate the UX before merging. You have to hold working software in your hands to know if it's good.
- Do codebase gardening by nudging folks into better patterns and look for common problems or challenges that we can fix at a platform or system level. You're looking for desire paths in your architecture. We always find reusable atoms when folks in different parts of the codebase solve similar problems in a similar way.
- Look for domain model violations where people ask for opposing functionality and engineers lack the context to push back
Code review is not the place to nitpick code style and it's best to discuss architecture before you write the code.
Use code review to force testing, encourage shared standards, disseminate knowledge, and look for missing tools. Have context of the goal before you review, avoid long async debates and get in a room together if there's much to discuss. Aim to approve with comment and don't be a blocker. Teach others.
How do we fix the code review bottleneck?
Goldratt says that when you find the bottleneck, you have to subdue the rest of your process to the bottleneck. Spend less time generating code and more time reviewing the code you already have. Yes that means everyone on the team. Work one PR at a time and get projects to done done.
Amdahl's Law states that speeding up the nonparallelizable portion of your code is the single highest leverage programming activity you can do. Make the bottleneck fast, everything gets fast.
Many online say "Don't look at the code". I think that's wrong. Yes we don't review our compiled code so why review generated code?
Generated code remains a mix of artisanal crafting and prompt->code transformation. If we stop looking at code, we're gonna have to start reviewing our prompts and design docs. The problem just moves up a layer. And people used to review compiled code until compilers got good.
At large companies, staff+ engineers already spend most of their time reviewing design and architecture docs instead of the code.
What about automated code review?
My thought when starting this article was to automate more of the code review. Use LLMs as fancy linters that can give feedback at a similar level I would give, but I think that loses something. Teaching between mentor and protege is a personal affair, offloading that to a machine feels almost offensive.
Code review is the highest leverage activity you can do as a senior+ engineer. You can steer the entire codebase, shape how people build software for the rest of their lives, and find opportunities for improved tooling and abstractions.
Many of my most impactful projects came from reading lots of code and noticing patterns. Oh this common operation isn't easy enough, oh that abstraction I built is mostly a problem, oh this domain concept is starting to diverge in meanings, oh ...
Code review works when everyone's an active participant. Don't treat this as a rubber stamp, it's some of the highest impact work you can do.
Don't be a blocker. Teach others. Explain your reasoning so your ideas can spread. There's nothing more rewarding than watching somebody else write the exact comment you would to a new member of the team.
Feedback from an expert is how you learn taste.
Cheers,
~Swizec
PS: I'm still gonna try to see if an LLM can do a good first pass so I'm not always leaving the same comments. There's a very obvious learning period when someone joins and learns The House Style
Scaling Fast book free preview
Enter your email to receive a sample chapter of Scaling Fast: Software Engineering Through the Hockeystick and learn how to navigate hypergrowth without burning out your team.
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️