AI-accelerated coding can speed delivery but also increases software instability and technical debt

TL;DR: I ran an experiment with AI-augmented development. In one month we produced 400k+ lines of code, 150 features, 240 fixes and 50 refactors, then the entropy accelerated and the velocity collapsed. What normally takes years of accumulated technical debt across multiple teams happened in weeks. Hi there, my name is Takah, I'm a Principal Software Engineer from Brazil. In the past months I've been conducting a few experiments on how to adapt our SDLC and explore new ways of working with AI, both enabling non-engineers to code in our repos and also enhancing every guard-rail, guideline and common market standards to support this type of workflow. What Is Software Entropy? But let's circle back to the title of this article: what is Software Entropy? First of all, what is entropy? I'll freely give one interpretation that entropy, borrowed from thermodynamics, is the natural tendency toward disorder or uncertainty in a system, and what is exactly software entropy? I'd say its the natural tendency of any given software and system to disorder, when new features are being added, new modules, new fixes, quick-wins, a hacky solution to fix or deliver something in time, or to prevent another incident, regardless of the most architectural pre-definition and future-proof hexagonal multi-flexible, composable and any other blazingly fast buzzword you wanna add, it's impossible to predict and prevent all use-cases beforehand, that's why entropy always end up happening. Software entropy is not a bug, it's a fundamental property of any system that grows. The question is never if it will happen, its how fast, and whether you have the mechanisms to manage it. What Does AI Have to Do With Software Entropy? And what AI has to do with Software Entropy? Like i said one of the experiments i did was me a Software engineer and 2 other designers, which we had the challenge of developing a whole new experience of a chat and we wanted to leverage the AI ecosystem at its maximum. So first, before any line of code, i aligned the scope, contracts, and overall architecture of the project: Tech stack Repository setup, code structure, architectural guidelines AI guidelines: agents, skills, context files for testing, styling, developing new features, feature-branches And after the initial setup we had, and helping them setup their own setup with claude, our internal ai-proxy, repository, vpns, etc we started developing. And at the beginning it was awesome. The guidelines and setup were satisfactory, features seemed to be right, we were adding one feature after another with autonomy, tests, coverage, and apparently following the project guidelines. But whats the problem? The Turn: Week Three After 3 weeks we had a codebase with more than 400k lines, dozens of features, animations, micro-interactions that would maybe take several sprints to be made if they were handcrafted by a team of engineers. But at this moment things started to break down: Each feature velocity started to decline New behaviours that interacted with previous states started to skyrocket race-conditions One new feature broke 3 other working ones A simple feature that previously took a few hours now took days And we had to circle back and analyze what was happening. The guidelines and guard-rails that were previously added were not enough, because even with a strict guideline saying to our models and setup: "Use X technology or Y Architecture or Z state management tool in this way," the probabilist nature of LLMs still were delusional. We had several features that reimplemented different state machines, did full animations, sound, charts from scratch while it was already solved in a sibling part of the application, and one of the signs were the codebase growth, it was exponentially growing in number of lines and files. To give you a sense of the scale, in roughly one month we accumulated: 150 features added 240 fixes applied 50 refactors performed, with refactors as large as removing more than 50k lines of code in a single one And I'm not alone in this, the data from 2026 tells the same story across the industry. The 2025 DORA State of AI-assisted Software Development report found that a 25% increase in AI adoption is associated with a 7.2% decrease in delivery stability, because AI allows developers to generate code much faster and it often leads to larger batch sizes, which are slower to review and more prone to creating system instability. New Relic's 2026 State of AI Coding report, which surveyed 200 technology leaders, found that while 94% of them rate AI-generated code as higher quality at review time, 78% report more incidents once it ships and 82% experienced at least one production failure tied to AI-generated code in the past six months. They call this agent debt, the rapid accumulation of unvetted architectural logic that triggers production incidents down the line. And a systematic review of 34 studies covering 2,847 developers found that technical debt principal increased by 1.8 person-days per 1,000 AI-generated lines of code, with the debt ratio doubling within 6 months without mitigation. The Fix: Tightening the Guard-Rails To fix that we had to do several fixes, refactors, and with each fix and refactor to strictly tighten the guard-rails, tests, and add custom deterministic tools to truly ensure that the code was following each guideline. In practice this meant: AI guard-rails in agents: direct instructions, specific skills and context files that enforced architectural patterns Deterministic tools: lint rules, pipeline validations and custom checks that verified architectural conformance before merge Strict refactoring cycles: regular mandatory refactoring capacity to reduce the debt principal Expert oversight: a specialized developer actively enhancing the guidelines, understanding what to use, what not to use, how to fix, and correcting the AI to follow new strict rules In the end result the AI usage was a success, within a month we developed something that would take months to be made handcrafted, but at what cost? If a specialized developer was not present enhancing the guidelines, understanding what to use, what not to use, how to fix, and actively enhancing its guard-rails this codebase was doomed to failure. Or maybe a full refactor or depriorization due to the effort of maintaining it. The Exponential Decline of the Codebase So whats my conclusion? All that happening within a month its the same thing i saw happening during years of a codebase, it normally takes months of multiple developers, teams, and technical debts accumulated to reach the same level of entropy and disorder where each new feature was breaking 3 others. What I'm calling the exponential decline of the codebase is not just a metaphor, its what happens when the rate of entropy generation outpaces the rate of human oversight by an order of magnitude. The IEEE Computer Society puts it bluntly: "Standing between such problematic AI output and other downstream disasters? Software engineers. The value of engineers with the software lifecycle knowledge needed to guide and oversee AI assistants and their output is immeasurable." The arXiv paper "Beyond the 'Diff'" defines agentic entropy as "a systemic drift that traditional code diff-based and HCXAI methods fail to capture, as they address local outputs rather than global agentic behaviour," and notes that "functional checks (e.g., confirming that the code runs) can thus mask deeper architectural violations and security gaps, producing an illusion of rapid progress while drift accumulates beneath the surface." The AI era is awesome, but without proper follow-up and deep specialized people understanding whats being written and which software engineering strategies, architecture and design patterns to follow, it will exponentially increase the software entropy. Gartner predicts that by 2029, 60% of organizations will adopt smaller software engineering teams at scale, up from 15% in 2026. But smaller teams with AI does not mean no engineers, it means engineers with different skills, architects, overseers, guard-rail builders. The ACM Technology Policy Council's TechBrief on vibe coding warns that it "often skips over core engineering practices that ensure systems are secure, reliable, and maintainable," and their lead author Simson Garfinkel says it directly: "It's making developers dramatically more effective, but it's also introducing security vulnerabilities, increasing technical debt, and producing code that can be difficult to maintain." A Reflection for Engineering Leaders If you're a manager, head of engineering, VP or CTO reading this, i want you to reflect on a few things: How are you aspiring your org to be? Are you designing for a future where AI does the coding and engineers do the oversight, or one where engineers use AI as a tool while retaining architectural ownership? Where are your gaps? Do you have mechanisms to detect software entropy as it accumulates, deterministic guard-rails and not just guidelines, engineers who can recognize when the AI is drifting from architectural intent? Whats your oversight model? The data from New Relic shows that 62% of technology leaders report their teams trust AI-generated code enough to ship it to production without line-by-line manual verification, is that a risk you're willing to take? My Disclosure on AI In that way, i don't dislike Agentic Coding, neither the idea of non-engineers coding, my conclusion is that the current state of ai tools are not ready yet to be driven by full Ai enthusiasts, software engineers are going to exist, this is the new normal we should not fear Ai we should embrace these new tools and understand how we could be more productive and have more time to focus in new strategies, features, design patterns, career, our mental and physical health and our familly not only delivering more value to our shareholders. The illusion that a single person with AI can replace a team of engineers is just that, an illusion. What we experienced in one month is what happens when you remove the expertise from the loop. The entropy accelerates, the velocity collapses, and the cost compounds. Software engineers are still necessary, the question is, are we building organizations that know how to use them?

Traditional software development lifecycles (SDLC) were designed around how fast people could type and coordinate. Sprints, manual quality gates, and review handoffs made sense when writing code was the slowest part of the job. With AI, developers can write, refactor, and document code faster than they could two years ago. What has not moved nearly as much is how fast the same organizations actually ship. Gartner research on AI in software engineering explains part of why. More than half of developers report that AI has improved their team’s output by 10% or less, and some see no improvement at all. The teams increasing output are applying AI across the whole SDLC, not only to the moment of writing code. When you give engineers a faster way to write code without changing anything else in the process, the result is that more code is waiting for manual reviews, which slows the path to production. This scenario is what pushed us to rebuild our own SDLC around AI rather than layer AI on top of it. Here is what that rebuild looks like, and where most teams lose the gains before they reach the business. KEEP IT LEAN FOR SMALL PROJECTS For smaller projects, an AI SDLC can be simple. Before using an AI tool, write clear requirements for each feature: what it should do, what it must not do, and how the team will know it works. AI can help draft and sharpen these requirements. Store them, along with the team’s coding standards, in the same system that tracks every change to the code. That way the AI reads them as rules on every task, and they stay current after kickoff. Then, give AI agents a narrow, well-defined scope to write and test code. A tight scope reduces the plausible-looking mistakes a model makes when it has too much room to guess. Assign a second agent or engineer to check each change against the same rules before a person signs off. The review works best when the reviewer has not watched the code being written, which keeps bias out. WHAT CHANGES AT AN ENTERPRISE SCALE Enterprise environments need a more robust version of the same AI SDLC because more people and more regulation are involved. On those engagements, we break business intent into three steps: A high-level goal turns into a feature spec A feature spec turns into individual execution tasks Every piece of code and every test case ties back to the requirement that justified it That traceability lets a team explain why a particular piece of logic exists and it gives a compliance team what it needs when an audit shows up months later. The same discipline applies to the systems the team already uses. When the AI workflow connects to ticketing tools, code repositories, and approval chains, nobody has to rebuild task lists and release packages by hand every time something ships. The person who approves a change should never be the person who generated it. That rule already applies to human engineers on any team I have run, and AI is not an exception. WHERE PROJECTS USUALLY FAIL Working with AI tools introduces a new risk they can produce code and documentation in minutes forcing engineers to rush code reviews rather than slowing down at the start of the process, where the real risk sits. The requirement and specification documents created at the beginning are the most critical part of the entire lifecycle because everything downstream inherits their mistakes. A vague or ambiguous requirement no longer produces just a vague result. It produces a fast, confident, wrong one, and by the time anyone notices, the AI has already built several more things on top of it. Closing that gap takes discipline. Engineers and product owners must treat time spent reviewing and refining a specification as work that saves time later. Spending two extra days getting a complex requirement document right is a good trade when the old alternative was weeks of meetings to reach the same alignment. Teams at Dreamix that have adopted this structured, disciplined review process ship roughly twice as fast, without giving up code quality. REBUILD THE PROCESS Updating a handful of tools inside an unchanged process does not produce the gains anyone is expecting. An AI SDLC means rebuilding the process itself around where the real bottleneck exists now, which is rarely the code anymore. Get the requirements and the review discipline right, and the speed AI offers will reach the business. Skip that part, and the speed just becomes a faster way to accumulate debt. Denis Danov is the CTO of Dreamix Ltd.