{"slug": "ai-helps-us-write-code-faster-so-why-arent-projects-moving-faster", "title": "AI Helps Us Write Code Faster. So Why Aren’t Projects Moving Faster?", "summary": "Despite AI accelerating code generation, software projects are not moving faster due to new bottlenecks like code review and cognitive debt. The Triple Debt Model—technical, cognitive, and intent debt—explains why understanding the system lags behind the ability to change it. AI-generated code increases cognitive debt as engineers struggle to build mental models of changes, and intent debt accumulates when design rationale is not recorded.", "body_md": "We can generate code faster than ever.\n\nFeatures 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.\n\nOn paper, software teams should be moving at an incredible speed.\n\nBut that is often not what happens.\n\nThe 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.\n\nAnyone who has used coding agents in a real business environment has probably noticed this contradiction:\n\nAI accelerates code generation, but it does not automatically accelerate software development.\n\nIn 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.\n\nThe problem is not necessarily the quality of the generated code.\n\nThe problem is that our ability to understand the system is no longer keeping up with our ability to change it.\n\nA 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.\n\nTogether, they form the **Triple Debt Model**.\n\nMost developers are already familiar with technical debt.\n\nWe 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.\n\nThe decision helps us move faster today, but makes future changes more expensive.\n\nThe Triple Debt Model argues that technical debt is only one dimension of software health.\n\nThere are two other forms of debt that become especially important when AI generates a growing percentage of the code.\n\nTechnical debt is the structural mess we already know how to identify:\n\nIt makes the system harder to modify, but it is usually visible.\n\nWe can inspect it. Static-analysis tools can detect parts of it. Tests can expose it. Refactoring can reduce it.\n\nAI is also reasonably good at helping with this type of debt. It can find duplication, suggest cleaner abstractions, add tests, and refactor repetitive code.\n\nUnfortunately, clean code does not guarantee a healthy project.\n\nCognitive debt accumulates when the team’s understanding of the system erodes.\n\nThe application may still work. The code may even look clean. However, fewer people can confidently explain how the important parts fit together.\n\nThis can happen naturally as a system grows, but AI can accelerate it.\n\nAn 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.\n\nWhat may never happen is the slower process of building a mental model:\n\nThe code enters the repository, but the corresponding understanding never fully enters the team.\n\nDo this repeatedly and the project slowly becomes something that engineers operate without truly understanding.\n\nIntent debt appears when the reasoning behind a system is not recorded.\n\nThe 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.\n\nFor example, imagine finding an unusual caching mechanism in a critical module.\n\nIs 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?\n\nWithout the original context, both humans and AI agents are forced to guess.\n\nThat missing context is intent debt.\n\nIt can live in many places:\n\nIntent 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.\n\nBefore AI-assisted development, producing code required a significant amount of human effort.\n\nThat 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.\n\nCoding agents remove part of that friction.\n\nThat is useful, but some of the removed friction was also where learning happened.\n\nA 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.\n\nThe team appears to be moving faster because more code reaches production.\n\nAt the same time, cognitive and intent debt may be accumulating underneath that velocity.\n\nThis creates a dangerous trade:\n\nWe reduce the cost of producing code while increasing the cost of understanding and safely changing it later.\n\nAt first, the trade looks extremely profitable. Features ship faster and backlogs shrink.\n\nThe cost appears later, when the system needs to be debugged, extended, migrated, or redesigned.\n\nThe slowdown rarely happens through one dramatic failure.\n\nIt usually appears through small changes in team behaviour.\n\nReading code is difficult.\n\nReading 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:\n\nThese are useful checks, but they are not the same as understanding the change.\n\nOver 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.\n\nThe pull request is approved, but no one has fully absorbed the new behaviour.\n\nAn advanced coding agent needs more than access to the repository.\n\nIt needs to understand the goal of the system and the constraints that shaped it.\n\nSuppose an agent discovers two services performing similar work. From the code alone, merging them may look like an obvious improvement.\n\nWhat 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.\n\nWithout that context, the agent can produce a technically elegant solution that is completely wrong for the business.\n\nThis is where intent debt becomes particularly dangerous.\n\nAgents are very capable of optimizing the implementation they can see. They are much less reliable when the real objective was never recorded.\n\nAs shared understanding disappears, code review changes.\n\nInstead of discussing whether a solution is appropriate, reviewers first have to reconstruct how the relevant part of the system works.\n\nA seemingly simple pull request leads to questions such as:\n\nThe review takes longer, but the answers remain uncertain.\n\nEventually, the safest response becomes: “Let’s not change it yet.”\n\nThat is the moment when a productive codebase starts becoming a fragile one.\n\nUnlike a failing test, cognitive debt does not produce a clear error message.\n\nYou have to look for it in the way the team works.\n\nEvery mature project has difficult areas.\n\nThe stronger warning sign is when developers avoid a module not because the code is obviously bad, but because nobody knows what might break.\n\nThe module has become a black box. Changes are delayed, wrapped in additional conditions, or assigned only to the one person believed to understand it.\n\nA project becomes fragile when critical design decisions exist only in someone’s memory.\n\nYou may hear phrases such as:\n\nThis is not only a staffing risk. It is evidence that the system’s intent has not been externalized.\n\nLarge AI-generated pull requests can look complete while being difficult to reason about.\n\nReview comments become vague:\n\nWhen both the author and reviewer are uncertain, review becomes a ceremony rather than a transfer of understanding.\n\nA team with a strong mental model can usually predict the approximate impact of a change.\n\nWhen simple modifications regularly break unrelated functionality, it suggests that the actual dependency structure is no longer understood.\n\nThe problem may involve technical debt, but repeated surprise is also a strong signal of cognitive debt.\n\nIt is tempting to respond by adding another agent.\n\nOne agent writes the code. Another reviews it. Perhaps a third checks the architecture and generates documentation.\n\nThese tools can help, but they do not automatically restore shared understanding.\n\nAn 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.\n\nThe 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.\n\nThe pipeline may look efficient.\n\nThe team’s ability to reason about the system may still be declining.\n\nFor years, software teams have treated code as the main output of development.\n\nIn an AI-assisted environment, that is no longer enough.\n\nEvery meaningful change should also preserve or improve the team’s understanding of the system.\n\nThat does not mean documenting every line of code. It means recording the information that cannot be reliably reconstructed from the implementation:\n\nPull requests should not only prove that the code works. They should make the intent of the change visible.\n\nArchitecture Decision Records, focused design notes, meaningful test names, short diagrams, and clear pull-request descriptions become more valuable—not less—when agents are involved.\n\nThe goal is not to slow development down for the sake of process.\n\nThe goal is to prevent short-term coding speed from destroying long-term development speed.\n\nAI is changing the economics of software development.\n\nProducing code is becoming cheaper. Understanding code is not.\n\nThat difference explains why teams can generate more code without seeing the same improvement in overall project efficiency.\n\nTechnical 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.\n\nToday, high cognitive debt may feel like a small drag on the engineering team.\n\nTomorrow, it can become a system that nobody feels safe modifying.\n\nThe 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.\n\nIn 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.", "url": "https://wpnews.pro/news/ai-helps-us-write-code-faster-so-why-arent-projects-moving-faster", "canonical_source": "https://dev.to/swrzalek/ai-helps-us-write-code-faster-so-why-arent-projects-moving-faster-49jo", "published_at": "2026-06-27 08:40:00+00:00", "updated_at": "2026-06-27 09:03:54.029560+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-agents", "large-language-models", "ai-research"], "entities": ["Margaret-Anne Storey", "Triple Debt Model"], "alternates": {"html": "https://wpnews.pro/news/ai-helps-us-write-code-faster-so-why-arent-projects-moving-faster", "markdown": "https://wpnews.pro/news/ai-helps-us-write-code-faster-so-why-arent-projects-moving-faster.md", "text": "https://wpnews.pro/news/ai-helps-us-write-code-faster-so-why-arent-projects-moving-faster.txt", "jsonld": "https://wpnews.pro/news/ai-helps-us-write-code-faster-so-why-arent-projects-moving-faster.jsonld"}}