Korva is a scroll of the internet’s best ideas.
Almost all code is AI-written, still reviewed
Writing versus reviewing
Nobody writes the initial code by hand anymore, maybe sometimes. The bottleneck has shifted from the person who writes the code to the person who reviews it. A proposal inside Glean would have eliminated code reviews, as many companies have done, letting code go straight into the repositories.
Glean kept reviews. AI can write a million lines of code, but that becomes incredibly hard to maintain, understand, and manage over time, and AI tools for refactoring and security are not that perfect right now. The person who writes the code does the first review, so the team is still faster than before because the writing is so much quicker.
Measuring the gain
Measuring the gain is harder. Lines of code are way up and features ship at a greater pace, but Glean also has a larger and more tenured team, which makes the causes hard to separate. Many companies report that coding speed has increased significantly while product shipping speed has not, since coding is a small part of shipping a product.
Customer support is easier to measure. A support agent who resolved 10 cases a day can now resolve 12, because much of the job is reading knowledge and summarizing it for customers.
Why does reviewing code limit how fast teams move?
Reading unfamiliar code takes real effort, because the reviewer has to reconstruct what it is meant to do and what it might break. Michael Fagan introduced formal code inspections at IBM in the 1970s and showed that finding defects before testing was cheaper than fixing them later. Review also spreads knowledge of the code across the team. When code is produced faster, the number of changes waiting for review grows at the same rate.
Why doesn't faster coding mean faster shipping?
Amdahl's law, named for computer architect Gene Amdahl, says that speeding up one part of a process improves the whole only in proportion to that part's share. If coding were a fifth of the time needed to ship a product, making it instant would cut the total by at most a fifth. The rest includes design, testing, review, deployment, and learning from customers. Those stages are untouched by faster typing.
Why does code nobody understands become a problem?
Computer scientist Peter Naur argued in his 1985 essay Programming as Theory Building that a program's real value lies in the understanding held by the people who wrote it. Code can run correctly while no one knows why it was written the way it was. When a bug or a change request arrives, the team must recover that understanding before touching anything. The more code there is, the longer that recovery takes.
More from 20VC with Harry Stebbings
