# AI Helps Us Write Code Faster. So Why Aren’t Projects Moving Faster? > Source: > Published: 2026-06-27 08:40:00+00:00 We can generate code faster than ever. Features that once took several days can now be implemented in a few hours. Boilerplate disappears almost instantly. Tests, migrations, API clients, and entire components can be produced before we have finished describing the task. On paper, software teams should be moving at an incredible speed. But that is often not what happens. The code is produced faster, yet the project itself does not feel much faster. Pull requests become larger. Reviews take longer. Debugging becomes less predictable. Engineers spend more time trying to understand changes they did not write. Anyone who has used coding agents in a real business environment has probably noticed this contradiction: AI accelerates code generation, but it does not automatically accelerate software development. In many teams, code review is already becoming the new bottleneck. Adding another AI agent to review the output may help catch local issues, but it does not solve the deeper problem. The problem is not necessarily the quality of the generated code. The problem is that our ability to understand the system is no longer keeping up with our ability to change it. A recent paper by Margaret-Anne Storey gave me a useful framework for thinking about this. It describes software health through three connected forms of debt: technical debt, cognitive debt, and intent debt. Together, they form the **Triple Debt Model**. Most developers are already familiar with technical debt. We introduce a workaround because a deadline is approaching. We duplicate some logic because extracting the correct abstraction would take longer. We leave a poorly designed module in place because replacing it would be risky. The decision helps us move faster today, but makes future changes more expensive. The Triple Debt Model argues that technical debt is only one dimension of software health. There are two other forms of debt that become especially important when AI generates a growing percentage of the code. Technical debt is the structural mess we already know how to identify: It makes the system harder to modify, but it is usually visible. We can inspect it. Static-analysis tools can detect parts of it. Tests can expose it. Refactoring can reduce it. AI is also reasonably good at helping with this type of debt. It can find duplication, suggest cleaner abstractions, add tests, and refactor repetitive code. Unfortunately, clean code does not guarantee a healthy project. Cognitive debt accumulates when the team’s understanding of the system erodes. The application may still work. The code may even look clean. However, fewer people can confidently explain how the important parts fit together. This can happen naturally as a system grows, but AI can accelerate it. An agent can generate several hundred lines of code in a few minutes. A developer can verify that the tests pass, scan the implementation, and approve the change. What may never happen is the slower process of building a mental model: The code enters the repository, but the corresponding understanding never fully enters the team. Do this repeatedly and the project slowly becomes something that engineers operate without truly understanding. Intent debt appears when the reasoning behind a system is not recorded. The code shows us what the system does today. It rarely tells us what the team originally intended, which constraints shaped the design, or which outcomes must be preserved. For example, imagine finding an unusual caching mechanism in a critical module. Is it there because of a previous production incident? Is it protecting an external API with strict rate limits? Is it compensating for a temporary infrastructure limitation? Or is it simply an old implementation that nobody removed? Without the original context, both humans and AI agents are forced to guess. That missing context is intent debt. It can live in many places: Intent debt has always existed. The difference is that agents now make decisions at a speed and scale that greatly increases the cost of missing intent. Before AI-assisted development, producing code required a significant amount of human effort. That effort was not always efficient, but it forced developers to spend time thinking about the system. While implementing a feature, we naturally built some understanding of the surrounding modules, dependencies, and constraints. Coding agents remove part of that friction. That is useful, but some of the removed friction was also where learning happened. A developer can now describe a task, review the output, run the tests, and merge the result without ever constructing a complete mental model of the implementation. The team appears to be moving faster because more code reaches production. At the same time, cognitive and intent debt may be accumulating underneath that velocity. This creates a dangerous trade: We reduce the cost of producing code while increasing the cost of understanding and safely changing it later. At first, the trade looks extremely profitable. Features ship faster and backlogs shrink. The cost appears later, when the system needs to be debugged, extended, migrated, or redesigned. The slowdown rarely happens through one dramatic failure. It usually appears through small changes in team behaviour. Reading code is difficult. Reading a large amount of code that you did not write is even more difficult. When AI produces changes continuously, reviewers eventually begin to focus on surface-level signals: These are useful checks, but they are not the same as understanding the change. Over time, reviewers may stop asking whether the implementation fits the deeper design of the system. Authors may also struggle to explain the code because they guided its generation rather than constructing it themselves. The pull request is approved, but no one has fully absorbed the new behaviour. An advanced coding agent needs more than access to the repository. It needs to understand the goal of the system and the constraints that shaped it. Suppose an agent discovers two services performing similar work. From the code alone, merging them may look like an obvious improvement. What the agent may not know is that the services were intentionally separated because they have different security boundaries, deployment schedules, ownership models, or regulatory requirements. Without that context, the agent can produce a technically elegant solution that is completely wrong for the business. This is where intent debt becomes particularly dangerous. Agents are very capable of optimizing the implementation they can see. They are much less reliable when the real objective was never recorded. As shared understanding disappears, code review changes. Instead of discussing whether a solution is appropriate, reviewers first have to reconstruct how the relevant part of the system works. A seemingly simple pull request leads to questions such as: The review takes longer, but the answers remain uncertain. Eventually, the safest response becomes: “Let’s not change it yet.” That is the moment when a productive codebase starts becoming a fragile one. Unlike a failing test, cognitive debt does not produce a clear error message. You have to look for it in the way the team works. Every mature project has difficult areas. The stronger warning sign is when developers avoid a module not because the code is obviously bad, but because nobody knows what might break. The module has become a black box. Changes are delayed, wrapped in additional conditions, or assigned only to the one person believed to understand it. A project becomes fragile when critical design decisions exist only in someone’s memory. You may hear phrases such as: This is not only a staffing risk. It is evidence that the system’s intent has not been externalized. Large AI-generated pull requests can look complete while being difficult to reason about. Review comments become vague: When both the author and reviewer are uncertain, review becomes a ceremony rather than a transfer of understanding. A team with a strong mental model can usually predict the approximate impact of a change. When simple modifications regularly break unrelated functionality, it suggests that the actual dependency structure is no longer understood. The problem may involve technical debt, but repeated surprise is also a strong signal of cognitive debt. It is tempting to respond by adding another agent. One agent writes the code. Another reviews it. Perhaps a third checks the architecture and generates documentation. These tools can help, but they do not automatically restore shared understanding. An AI reviewer can identify a potential race condition or missing validation. It cannot recover a business constraint that was never documented. It cannot guarantee that the engineering team understands the resulting design. The risk is that we create a closed loop in which agents produce, review, explain, and approve changes while humans supervise the process from an increasing distance. The pipeline may look efficient. The team’s ability to reason about the system may still be declining. For years, software teams have treated code as the main output of development. In an AI-assisted environment, that is no longer enough. Every meaningful change should also preserve or improve the team’s understanding of the system. That does not mean documenting every line of code. It means recording the information that cannot be reliably reconstructed from the implementation: Pull requests should not only prove that the code works. They should make the intent of the change visible. Architecture Decision Records, focused design notes, meaningful test names, short diagrams, and clear pull-request descriptions become more valuable—not less—when agents are involved. The goal is not to slow development down for the sake of process. The goal is to prevent short-term coding speed from destroying long-term development speed. AI is changing the economics of software development. Producing code is becoming cheaper. Understanding code is not. That difference explains why teams can generate more code without seeing the same improvement in overall project efficiency. Technical debt still matters, but it is no longer the full picture. A codebase can be clean and well-tested while the team has lost the knowledge required to change it safely. It can contain detailed implementation documentation while still missing the reasons behind its most important decisions. Today, high cognitive debt may feel like a small drag on the engineering team. Tomorrow, it can become a system that nobody feels safe modifying. The teams that benefit most from AI will not simply be the ones that generate the most code. They will be the ones that find a way to generate code without losing their understanding of what they are building and why. In the next articles, I plan to explore practical frameworks and engineering processes that can help teams reduce cognitive and intent debt while still taking advantage of AI-assisted development.