{"slug": "writing-code-isn-t-the-bottleneck-anymore-reading-is", "title": "Writing code isn't the bottleneck anymore, reading is", "summary": "Writing code is no longer the bottleneck in software development; reading and reviewing AI-generated code is, according to a developer's account. The author argues that while AI can generate 50,000 lines of code quickly, production-grade projects require careful review, which is harder for AI-generated code than for human-written code. The key takeaway is that teams should focus on accountability and code readability to avoid outages and long-term slowdowns.", "body_md": "# Writing code isn't the bottleneck anymore, reading is\n\nThis week I was working on one non-critical feature that seemed simple at first sight. 50k lines of code later, it seemed to work as expected. 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. But for a production-grade project, the risk of an outage is too big to skip reading the code. Unfortunately, reviewing 50k lines of AI-generated code is much harder than reviewing 50k lines written by a human.\n\nWe’re now obsessed with how much code we can create fast. But is it the right thing to optimize for?\n**The biggest bottleneck of implementation quietly shifted from producing code to reading code.**\nFortunately, we don’t need to invent how to make code more readable: software engineering has had solutions for that for decades.\n\n### The next bottleneck: creating code that we can be accountable for\n\nMany people no longer read the code that they ship. So why should we care about good coding practices and code quality if agents don’t? Keeping our code readable is still critical for one reason: it helps us overcome our biggest bottleneck, the human.\n\nWhen 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. 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.\n\nWe can review less code than before.\nIt may be tempting to skip review entirely, but that’s throwing the baby out with the bathwater.\nThe 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.**\nJudging by how many outages big companies had recently, this goal is not obvious to everyone.\n\nIt’s a well-known pattern: **new techniques and tools make top-performing teams even faster, while low performers get slower.**\nIt happened with the cloud and with microservices. The pragmatic teams shipped faster, while low performers got stuck in never-ending migrations.\nThe 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.\n\nYou can generate 100k lines of code and burn thousands of dollars on tokens in one day.\nThat means nothing until you’re sure it works, doesn’t break other things, and solves the problem it should.\nIn 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.**\n\nYou generated a new feature, and after a couple of iterations you believe it’s ready. What now? You have a couple of options for how to find out if it works as expected:\n\n- 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.\n- 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.\n- Read and understand the damn code.\n\nThe third option is the safest, but unfortunately the hardest one.\n\nMaybe we saved a lot of time we would spend on writing code, but now we have a harder task: reviewing it.\nThe volume of code generated by agents is much bigger than what people used to write by hand.\nWhat’s worse, **reviewing code written by an agent is much harder than reviewing code that you have written by hand.**\n\nAfter spending hours reading and fixing the code, you start thinking “Maybe writing it by hand would be faster…”. 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. What helps here is making the agents’ code more readable.\n\nThe good news is that we don’t need to reinvent the wheel.\n**Creating readable code is something that software engineers have been trying to figure out for several decades.**\nGood practices exist to help us extend code faster. But we often miss the one part that matters most for review: readability.\n\n### Not all software is the same\n\nWe have always been big advocates of Domain-Driven Design and [Clean Architecture](https://academy.threedots.tech/knowledge/clean-architecture/)\nin the Go community.\nWe have seen how they helped us to rescue many projects.\nTo our surprise, promoting them used to trigger pushback from many people saying “it’s overengineering and Go code should be simple”.\nAnd they have been right: **Using DDD and Clean Architecture leads to overengineering…\nand so does skipping them.** It all depends on the kind of project you apply them in and on how well you understand them.\n\nWhen we talked to skeptics who advocate for “Simple Go”, we quickly figured out that their opinion often came from a single poorly implemented project. Usually, the people who built that project had no idea how to use those tools. Or this project was just a simple CRUD that didn’t need any sophisticated techniques. Any tool, when wrongly used, does more harm than good.\n\n**What works for prototypes, CRUDs, and side projects doesn’t work for production-grade complex projects.**\nOn the other hand, prototypes and simple code will suffer from many ceremonies that production-grade critical software needs.\nThe difference matters more than ever with AI-assisted coding.\n\n### Not reading generated code is also fine\n\nI don’t read every piece of AI-generated code. **One type of code I often don’t review at all is the presentation layer (frontend, for example).**\nAs long as it looks good and works as expected, I don’t care about the implementation.\nThere is one important precondition to make it happen: the frontend should be a thin presentation layer without overcomplicated logic, with a sane API behind it.\nWhen you have complex frontend state with GraphQL under the hood, such a strategy is much riskier.\nThis is where any kind of layered architecture helps us: we separate the boring code from the critical code, so we don’t need to spend the same mental effort on all of it.\n\nNext time you hear someone say they never read generated code, check what kind of code they write. Most of the time it may be presentation-heavy non-critical software. It can be a sane strategy, as long as you apply it deliberately to one part of the project.\n\n### The more things change, the more they stay the same\n\nMany software engineers now face an existential crisis: **did everything we learned over the years become obsolete?**\nIf someone spent years learning languages, frameworks, and vim motions, then it’s true: those skills are much less relevant now.\n\nEven if we see more and more examples of agents doing impressive work, it’s mostly in scenarios with a clear feedback loop that agents can “brute-force”.\n**The challenge starts when success criteria are unclear.**\nThat describes most of the business software we create.\n\nI also see arguments like “software is dead, my girlfriend just vibe coded in a weekend what I used to write in half a year”.\nEven if it may be true, we come back to the same point: not all software is the same.\n**Shipping a PoC in a weekend is light years from building production-grade software with many users.\nIf that PoC became popular, it would take a team of engineers to develop it and keep it working (and making money).**\n\nAn expert product engineer decides what to build and why, not only how. If that’s you, your knowledge of what code to write is still valid and in demand.\nPart of this job was always taking accountability for the changes we ship. It doesn’t matter if the code was written by hand or generated by an agent: **you ship it, you own it.**\nNot much has changed. Taking accountability was always the area where the best job offers were sitting.\n\n**Good coding practices were never for the machines.** Compilers never cared about them, and agents may work slightly better with clean code, but they are fast enough without it. **Good practices were always for you, the person accountable for what you ship.**\n\nThe one thing that changed is that we, as software engineers, now have to figure out how to collaborate with agents to create code efficiently. In the next posts, we’ll show you how we do it.", "url": "https://wpnews.pro/news/writing-code-isn-t-the-bottleneck-anymore-reading-is", "canonical_source": "https://threedots.tech/post/understanding-code-is-bottleneck/", "published_at": "2026-08-13 11:00:47+00:00", "updated_at": "2026-08-13 11:10:59.259217+00:00", "lang": "en", "topics": ["artificial-intelligence", "generative-ai", "ai-tools", "developer-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/writing-code-isn-t-the-bottleneck-anymore-reading-is", "markdown": "https://wpnews.pro/news/writing-code-isn-t-the-bottleneck-anymore-reading-is.md", "text": "https://wpnews.pro/news/writing-code-isn-t-the-bottleneck-anymore-reading-is.txt", "jsonld": "https://wpnews.pro/news/writing-code-isn-t-the-bottleneck-anymore-reading-is.jsonld"}}