The bottleneck isn't writing code anymore. It's understanding it. | Three Dots Labs blog
search icon
Type something to search..<br>to navigate<br>to select
ESC to close
The bottleneck isn't writing code anymore. It's understanding it.
Robert Laszczak<br>Co-founder of Three Dots Labs.<br>Creator of Watermill.<br>Author of Go With The Domain.
This week I was working on one non-critical feature that seemed simple at first sight.<br>50k lines of code later, it seemed to work as expected.<br>In a side project, or a service where “nobody will be upset if it’s dead and kills everything around”, it would be ready to ship.<br>But for a production-grade project, the risk of an outage is too big to skip reading the code.<br>Unfortunately, reviewing 50k lines of AI-generated code is much harder than reviewing 50k lines written by a human.<br>We’re now obsessed with how much code we can create fast. But is it the right thing to optimize for?<br>The biggest bottleneck of implementation quietly shifted from producing code to reading code.<br>Fortunately, we don’t need to invent how to make code more readable: software engineering has had solutions for that for decades.<br>The next bottleneck: creating code that we can be accountable for<br>Many people no longer read the code that they ship.<br>So why should we care about good coding practices and code quality if agents don’t?<br>Keeping our code readable is still critical for one reason: it helps us overcome our biggest bottleneck, the human.<br>When you write code by hand, you have the entire context of what you implemented. With agent-generated code, you have to rebuild that context, and it’s easy to get overwhelmed.<br>You miss bugs that nobody would ever write by hand. You also lose the edge cases you would have found while writing the code yourself.<br>Coding got faster. Review didn’t.Coding got faster. Review didn’t.We can review less code than before.<br>It may be tempting to skip review entirely, but that’s throwing the baby out with the bathwater.<br>The last block in the diagram is “successful delivery” for a good reason: our goal is not just to ship, but to ship working things that don’t break other things and won’t slow us down in the long term.<br>Judging by how many outages big companies had recently, this goal is not obvious to everyone.<br>It’s a well-known pattern: new techniques and tools make top-performing teams even faster, while low performers get slower.<br>It happened with the cloud and with microservices. The pragmatic teams shipped faster, while low performers got stuck in never-ending migrations.<br>The same will happen with AI. Teams with high friction between idea and implementation won’t see the same performance gain. And if you invest in AI in the wrong places, you may even end up slower.<br>You can generate 100k lines of code and burn thousands of dollars on tokens in one day.<br>That means nothing until you’re sure it works, doesn’t break other things, and solves the problem it should.<br>In other words, it doesn’t matter how much code you can generate, what matters is how much of it you can take accountability for and whether it solves a real problem.<br>You probably see PRs like this too often nowYou generated a new feature and after a couple of iterations you believe it’s ready.<br>What now?<br>You have a couple of options for how to find out if it works as expected:<br>Just create a PR without reading the code and let the reviewer check the feature…and wait for your team to hate you for submitting slop-PRs.<br>Just read the tests and pray that AI agents didn’t forget any edge cases, that they covered all side effects, and that previous features are also protected against regressions.<br>Read and understand the damn code.<br>The third option is the safest, but unfortunately the hardest one.<br>Maybe we saved a lot of time we would spend on writing code, but now we have a harder task: reviewing it.<br>The volume of code generated by agents is much bigger than what people used to write by hand.<br>What’s worse, reviewing code written by an agent is much harder than reviewing code that you have written by hand.<br>After spending hours reading and fixing the code, you start thinking “Maybe writing it by hand would be faster…”.<br>Writing by hand sounds like a comfortable solution, but even counting the hours you spend polishing the agent’s code, you would not be faster.<br>What helps here is making the agents’ code more readable.<br>The good news is that we don’t need to reinvent the wheel.<br>Creating readable code is something that software engineers have been trying to figure out for several decades.<br>Good practices exist to help us extend code faster. But we often miss the one part that matters most for review: readability.<br>Not all software is the same<br>We have always been big advocates of Domain-Driven Design and Clean Architecture in the Go community.<br>We have seen how they helped us to...