Chapter 5

Chapter 5

Preventing AI-Generated Technical Debt

Making Sure Faster Development Does Not Become Tomorrow’s Maintenance Problem

AI introduces another source of technical debt because software can now be created faster than engineers can fully reason about everything being created.

A developer making an architectural mistake manually may introduce the mistake once, while an AI workflow operating from the same mistaken assumption can reproduce it across dozens of components, and an agent may potentially reproduce it across hundreds. The objective of Chapter 5, therefore, is not to discourage AI-generated software or reduce the speed and productivity it can provide. It is to establish an engineering system in which AI can create software rapidly without allowing the rate of software generation to outrun the organization’s ability to understand, govern, and maintain what it creates.

Technical Debt Is Not the Same as Bad Code

Imagine, for example, that an application already contains an established mechanism for accessing customer information and an AI assistant generates a new feature that creates a second mechanism.

The same problem can occur when AI introduces unnecessary dependencies, creates duplicate abstractions, produces excessive code, invents new naming conventions, implements business rules differently from existing components, or solves a local problem in a way that conflicts with the broader architecture. The important question during AI-assisted development, therefore, is not merely “Does this work?” but also “What does accepting this make the next change harder to understand or more expensive to perform?” That second question forces the organization to look beyond immediate correctness and consider the future engineering consequence of accepting the implementation, which is where technical debt becomes visible.

AI Has a Local View of a System That Has a Long History

A mature system represents years of decisions. Some decisions are visible in architecture documentation or engineering standards. Others are embedded in naming conventions, dependency patterns, test structures, deployment practices, database design, security controls, operational procedures, and business rules. Still others exist primarily in the experience of engineers who have worked with the application long enough to know why certain things are done a particular way. When an AI system receives a task, it operates from the context available to it.

If that context includes only the file currently being edited and the developer’s request, the AI may produce a solution that is perfectly reasonable within that local view but inconsistent with the larger system. Even when AI has repository-wide access, access does not automatically create understanding. A large codebase may contain obsolete patterns, transitional architecture, experimental code, historical exceptions, and duplicated implementations. The AI can see them without necessarily knowing which ones represent current engineering intent.

This creates a problem that becomes more significant as AI receives greater authority: AI can reproduce what exists without knowing what should continue to exist.

That distinction will become central in Chapter 6. Before AI can consistently make strong engineering decisions, it needs a way to know which architecture, standards, business rules, and patterns the organization considers authoritative.

For Chapter 5, the practical implication is immediate: when reviewing AI-generated work, engineers should pay particular attention to whether the solution fits the intended system, not merely whether it resembles something already found in the repository.

The Copy-and-Amplify Problem

This creates a feedback loop:

AI generates a pattern → the pattern enters the codebase → the codebase becomes context → AI sees the pattern as precedent → AI generates more of it.

• Is this the approach we want future engineers and
• AI systems to imitate?
• Does it reflect the current architecture rather than a historical exception?
• Is the implementation simpler than necessary, or more complicated?
• Does it introduce a new way to solve a problem the application already solves?
• Would we intentionally use this implementation as an example for the next ten similar changes?

That last question is particularly useful. If the answer is no, the code may work, but it probably should not become precedent.

AI Can Make Overengineering Cheap

The danger is subtle because generated complexity can look like engineering maturity, even though a large amount of well-structured code is not automatically better than a small amount of straightforward code. Every abstraction creates something future engineers must understand, every extension point creates behavior that may need to be tested, and every dependency introduces another relationship the application must maintain. AI changes the economics of writing code, but it does not eliminate the economics of owning code, which leads to an important principle for AI-assisted development: generation cost is approaching zero in some activities, but ownership cost is not. The engineering organization should therefore become more deliberate about asking whether generated code needs to exist at all, rather than assuming that code is valuable simply because AI can produce it quickly.

• Can the same outcome be achieved with less code?
  Does the implementation introduce abstractions required by the current problem or abstractions for hypothetical future problems?

• Is AI recreating functionality already available in the platform or application?
• Are new dependencies genuinely necessary?
• Is the solution optimized for clarity or for apparent sophistication?
• Will an engineer unfamiliar with the generation process understand why the structure exists?

One of the most valuable instructions an organization can give both developers and AI systems may simply be: Prefer the smallest implementation that satisfies the engineering requirement and protected outcomes. Simplicity becomes increasingly valuable as generation becomes easier.

More Code Is Not More Productivity

The organization should instead begin valuing code avoided by asking whether AI identified existing functionality that could be reused, revealed a simpler implementation, helped remove duplication, made conventional automation possible instead of requiring a new AI workflow, or reduced the amount of custom software the organization needs to maintain. These outcomes may produce very little visible code while creating substantial long-term value. This is another reason the productivity model from Chapter 2 focused on successful engineering outcomes rather than AI activity, because the purpose of software engineering is not to produce code; the purpose is to produce and maintain systems that solve useful problems.

AI Technical Debt Often Begins With Missing Context

Suppose AI repeatedly introduces dependencies the architecture team does not want. The organization can continue asking reviewers to remove them. It can add increasingly forceful instructions to prompts. Or it can ask why the AI believes those dependencies are appropriate. Perhaps the repository contains several historical examples. Perhaps the approved dependency policy exists only in an internal document the AI never receives. Perhaps developers themselves do not consistently know the policy. Perhaps the standard is not enforced anywhere. The AI mistake has exposed a knowledge-distribution problem.

The same may occur when AI:

• Violates architectural boundaries.
• Misinterprets business terminology.
• Creates inconsistent error handling.
• Uses outdated framework patterns.
• Ignores application-specific security requirements.
• Duplicates existing functionality.
• Generates incorrect data-access behavior.
• Creates tests that miss important business conditions.
• Produces documentation inconsistent with the current system.

Repeated correction should trigger the question introduced earlier: Are engineers continually correcting AI for something the organization already knows? If the answer is yes, the long-term solution is usually not to rely on humans to keep making the same correction because the knowledge needs to move into the engineering system where it can be applied consistently. Depending on the issue, that might mean creating an automated rule, adding a test or architecture check, providing approved AI context, improving documentation, adding a repository instruction, or establishing a clearer engineering standard. Chapter 6 will focus specifically on creating that knowledge layer and making organizational knowledge available where AI-assisted workflows can actually use it.

For now, repeated AI corrections should be captured as Technical Debt Signals because they show the organization where future debt is likely to accumulate if the underlying cause remains unresolved. Rather than viewing each correction as an isolated AI mistake, the organization can use repeated corrections to identify patterns and determine where the engineering environment itself needs to become stronger, preventing the same issue from being generated, reviewed, corrected, and potentially accepted again.

Create the AI Technical Debt Signal Register

• Repeated architectural deviations.
• Duplicate functionality.
• Unnecessary abstractions.
• Excessive code generation.
• New dependencies where existing
• capabilities would suffice.
• Inconsistent error handling.
• Incorrect or duplicated business rules.
• Weak or misleading tests.
• Outdated implementation patterns.
• Generated code engineers have difficulty explaining.
• Documentation that appears complete but is inaccurate.
• Repeated security corrections.
• Repeated performance corrections.
• Code that passes immediate validation but becomes difficult to change later.

For each recurring signal, record:

• What behavior is appearing?
• Where is it occurring?
• How frequently is it appearing?
• How difficult is it to detect?
• What future engineering cost could it create?
• What information or control appears to be missing?
• Can the problem be prevented automatically?
• Should it become a standard, context item, automated validation rule, or workflow change?
• Who owns the corrective action?

This register turns technical debt prevention into a learning mechanism rather than simply a cleanup exercise, allowing the organization to use recurring problems as evidence for improving the engineering environment that produced them. The objective is not simply to identify and remove poor AI-generated code after it appears, but to understand why the problem was generated, capture what the organization learned from correcting it, and incorporate that knowledge into standards, context, validation, or other engineering controls so that the next generation of AI-assisted work is less likely to produce the same problem.

Prevention Must Happen Before the Pull Request

This creates a layered prevention model:

• Before generation: Give AI the right context and boundaries.
• During generation: Keep the task and authority appropriately scoped.
• After generation: Validate automatically wherever the outcome can be defined.
• During human review: Focus human attention on judgment, architecture, business meaning, and consequences automation cannot reliably determine.
• After adoption: Observe maintenance behavior and feed recurring problems back into standards, context, and controls.

Each layer reduces the burden on the next. A weak organization may depend almost entirely on the human reviewer, while a more mature AI engineering system attempts to prevent known mistakes before the reviewer ever sees the change. That is how AI development can become faster without simply making review harder, and it leads directly to the next question we need to answer in Chapter 5: What exactly should the organization validate before AI-generated work is allowed to become part of the software it will own?

Validate What You Can Before Asking a Human to Judge It

A developer writing a feature manually may notice a warning or question a design decision while spending several hours inside the implementation. An AI system can produce the same volume of code in minutes. If the organization relies entirely on the developer to inspect everything afterward, some of the productivity improvement disappears into verification. Worse, as the volume grows, verification quality may decline. The objective is therefore to create a validation path through which AI-generated work must travel before it becomes accepted engineering work. That path should answer a straightforward question: What can the engineering system prove about this change before a human has to decide what cannot be proven automatically?

For a production code change, that might include whether the software builds, existing tests pass, required new tests exist, prohibited dependencies were introduced, security rules were violated, formatting and static-analysis requirements are satisfied, repository policies are followed, and architectural constraints that can be expressed programmatically remain intact. Passing those checks does not prove that the implementation is correct. It removes known questions from the human review. That distinction is important. Automated validation should make human judgment more focused, not create the illusion that human judgment is unnecessary.

Create an AI Change Validation Gate

A validation gate might include:

• Build and compilation validation.
• Existing automated test execution.
• Requirements for appropriate new or modified tests.
• Static analysis.
• Security and vulnerability scanning.
• Dependency validation.
• Architecture or layering rules.
• API or schema compatibility checks.
• Infrastructure policy checks.
• Code complexity thresholds where useful.
• Repository and branching requirements.
• Human review for decisions that cannot be validated deterministically.

An important principle applies here: AI-generated code should not automatically be subjected to lower standards because it was generated quickly, nor should it automatically be subjected to arbitrary higher standards merely because AI created it. The software will eventually become part of the same system, be maintained by the same organization, and create the same consequences as code produced manually.

What may legitimately differ is the validation emphasis. If the organization’s evidence shows that AI repeatedly creates a particular type of problem, the validation workflow should adapt to that evidence. A team experiencing repeated unnecessary dependency introduction should strengthen dependency controls. A team seeing architectural drift should strengthen architecture validation. A team finding weak AI-generated tests should improve the way test effectiveness is evaluated. Validation should respond to observed failure patterns.

Do Not Let AI Be Its Own Only Reviewer

If the same model receives the same context, assumptions, and incomplete information that produced the original implementation, it may reproduce the same reasoning during review. A missing business rule remains missing. An undocumented architectural requirement remains invisible. A mistaken assumption can appear consistent because both generation and review begin from the same mistaken premise. The organization should therefore think in terms of independent evidence, not simply a second AI interaction.

Independent evidence might come from:

• Deterministic automated tests.
• Static analysis.
• Security tooling.
• Architecture rules.
• Authoritative business requirements.
• A separate validation workflow.
• A model given a deliberately different review role and context.
• Another engineer.
• Production or preproduction observation.

Using a second model can sometimes strengthen review, but model diversity should not be confused with truth. Two AI systems can agree and still be wrong if both lack the same critical information. The most reliable validation generally combines AI reasoning with evidence produced outside the reasoning process.

Tests Become More Important—and More Complicated

Suppose the requirement contains an undocumented exception known to experienced employees. AI generates the implementation without the exception and then generates tests based on the implementation it just created. The tests pass perfectly. The engineering system has demonstrated internal consistency, not business correctness. This is why important tests need some connection to an independent statement of expected behavior. That statement might come from acceptance criteria, business rules, historical defect cases, executable specifications, contract tests, approved examples, or existing behavior that has been intentionally preserved. The stronger the independent definition of expected behavior, the more valuable automated testing becomes as an AI control.

This does not mean AI should not generate tests. AI can be exceptionally useful for doing so. It means the organization should distinguish between tests that demonstrate the generated code behaves as AI expects, and tests that demonstrate the generated code behaves as the organization expects. Those are not always the same thing.

Watch for Tests That Increase Coverage Without Increasing Confidence

Coverage can rise while confidence remains largely unchanged. Organizations using AI heavily for test generation should therefore pay attention to the quality of the test portfolio, not only its size or coverage percentage.

Useful questions include:

• Does the test represent meaningful expected behavior?
• Would the test fail if the important business rule were violated?
• Are failure and boundary conditions represented?
• Are tests overly coupled to implementation details?
• Is AI duplicating tests that already exist?
• Are mocks hiding integration behavior that matters?
• Are historical defects represented so they cannot silently return?
• Would an engineer trust these tests when making the next change?

This is another area where AI can provide assistance. It can analyze a test suite for duplication, missing boundaries, weak assertions, or uncovered conditions. But once again, AI analysis should support engineering evidence rather than substitute for it.

Technical Debt Can Exist in AI-Generated Tests

An AI system can create this problem very quickly because producing another test is inexpensive. The correct objective is not maximum test generation; it is the smallest maintainable set of tests that provides sufficient confidence in the behavior that matters. This mirrors the broader principle introduced earlier: generation is becoming inexpensive, but ownership remains expensive.

Review the Difference, Not the Volume

The agent should also surface deviations from expectation. If it needed to change files outside the predicted scope, use an alternative approach, suppress a warning, modify a test, or make an assumption because required information was unavailable, those facts deserve more reviewer attention than routine successful actions. This suggests a valuable design principle: Human review should be exception-oriented wherever the engineering system can reliably establish the expected path. The engineer should spend attention where something unusual happened, where judgment was required, or where the evidence is incomplete. This improves both productivity and review quality.

Technical Debt Should Have a Feedback Loop

Suppose AI repeatedly misinterprets the same business term. Correcting the implementation solves today’s feature, while adding the authoritative definition to reusable engineering context helps solve every future feature. Suppose generated code repeatedly crosses an architectural boundary. Reviewer comments correct the individual change, while an architecture rule, better context, or automated validation can prevent repetition.

The feedback loop should look like this:

AI-generated issue → Detection → Correction → Pattern recognition → Root cause → Engineering-system improvement → Future prevention

Measure Debt Signals, Not a Fictional Technical-Debt Number

Useful signals may include:

• Frequency of repeated AI correction categories.
• Architectural violations found during review.
• Duplicate implementations.
• Unnecessary dependency introductions.
• Rework associated with AI-assisted changes.
• Defects traced to incorrect generated assumptions.
• AI-generated tests requiring substantial later maintenance.
• Changes that pass initial validation but create difficulty during subsequent modification.
• Percentage of AI-assisted changes requiring significant structural correction.
• Recurring exceptions to established standards.

These indicators do not need to become executive dashboards immediately. Their first purpose is operational: help engineering leaders identify where AI workflows need improvement. Over time, trends become more meaningful than isolated counts. If architectural corrections fall after architectural context is added to the workflow, the organization has evidence that the change helped. If unnecessary dependencies continue appearing after a prompt update, prompting may not be the correct control. If maintenance issues cluster around a particular AI-assisted pattern, that pattern may need to return to experimentation. This is exactly the learning behavior the operating model is intended to create.

Know When the Right Answer Is Less AI

This is an important maturity distinction. Early AI adoption often asks: How can we use AI to do this? A mature AI engineering organization asks: What is the best mechanism for doing this? Sometimes the answer is a powerful reasoning model. Sometimes it is a smaller model. Sometimes it is an agent. Sometimes it is a human engineer. And sometimes it is fifty lines of ordinary software that will perform the task correctly for the next ten years. AI should earn its place in the architecture just like any other technology.

Technical Debt Prevention Starts With the Next Change

Each improvement affects the next change. That matters because software systems are built cumulatively. If AI-assisted work becomes cleaner and more consistent today, tomorrow’s AI receives a better codebase as context. Better examples produce better future suggestions, stronger tests create safer agent feedback, clearer architecture reduces ambiguity, and better documentation makes engineering knowledge more accessible. The feedback loop can work in both directions: poor engineering context can cause AI to amplify technical debt, while strong engineering context can cause AI to amplify engineering discipline. The organization’s job is to determine which direction the loop is moving—and deliberately move it toward the second.

The Chapter 5 Working Checklist

Look across AI-assisted changes, review findings, maintenance experience, and the Human Correction Records created earlier. Track recurring patterns such as:

• Architectural deviations.
• Duplicate implementations.
• Unnecessary abstractions.
• Excessive generated code.
• Unnecessary dependencies.
• Inconsistent business rules.
• Weak or misleading tests.
• Outdated patterns.
• Security corrections.
• Performance corrections.
• Generated code engineers cannot readily explain.
• Documentation inaccuracies.
• Changes that become unusually difficult to modify later.

Do not record every isolated mistake. Look for patterns capable of creating repeated future cost.

2. Determine the Likely Cause

For each meaningful signal, ask:

• Is authoritative engineering context missing?
• Is the standard unclear?
• Does AI see obsolete examples and treat them as current practice?
• Is the task too broad?
• Is the selected model inappropriate for the work?
• Is the workflow missing independent validation?
• Is the problem deterministic enough that conventional tooling should prevent it?
• Is the engineering environment itself inconsistent?

Avoid assuming every recurring problem can be solved by improving the prompt.

3. Prevent Repetition at the Lowest Practical Level

Choose the most reliable prevention mechanism available. Consider:

• Conventional software.
• Automated tests.
• Static analysis.
• Architecture validation.
• Dependency rules.
• Repository policies.
• CI/CD controls.
• Approved AI context.
• Engineering standards.
• Better task boundaries.
• Human review where judgment remains necessary.

Prefer deterministic prevention when the requirement can be expressed reliably.

4. Establish the AI Change Validation Gate

For consequential AI-generated changes, define the validation required before acceptance. Include as appropriate:

• Build validation.
• Automated tests.
• Security scanning.
• Static analysis.
• Dependency checks.
• Architecture checks.
• Schema or API compatibility.
• Infrastructure policy.
• Required human review.
• Required approval.

Adjust the gate based on actual AI failure patterns rather than arbitrary suspicion of generated code.

5. Protect Test Quality

When AI creates or modifies tests:

• Confirm tests represent expected
• behavior, not merely generated implementation.
• Include meaningful boundary and failure conditions.
• Watch for excessive mocking.
• Identify duplicated tests.
• Examine weak assertions.
• Preserve historical defect cases where valuable.
• Avoid increasing test volume without increasing confidence.
• Consider the future maintenance cost of the test suite.

6. Protect Simplicity

For substantial AI-generated implementations, ask:

• Can this be done with less code?
• Is functionality being duplicated?
• Does an existing platform or application capability already solve the problem?
• Are new abstractions necessary now?
• Are new dependencies justified?
• Would this implementation be a good example for future AI-generated work?
• Can another engineer explain why the structure exists?

Treat unnecessary complexity as a cost even when generating it was inexpensive.

7. Create the Technical Debt Feedback Loop

For recurring issues, record:

• Issue detected.
• Immediate correction.
• Recurrence frequency.
• Likely root cause.
• Engineering-system change required.
• Owner.
• Implementation status.
• Evidence that the change reduced recurrence.

The objective is not merely to repair generated work but to improve future generation.

What You Should Have When Chapter 5 Is Complete

You should now have:

• An AI Technical Debt Signal Register.
• An AI Change Validation Gate for consequential generated work.
• A method for distinguishing generated code volume from engineering value.
• Explicit attention to simplicity and code avoided.
• Stronger validation of AI-generated tests.
• A feedback loop connecting recurring corrections to engineering-system improvements.
• A process for moving deterministic requirements out of prompts and into reliable tooling.
• A growing understanding of the information AI repeatedly lacks when making engineering decisions.

That last item takes us directly into Chapter 6. Throughout the first five chapters, the same problem has appeared in different forms. AI generates an implementation that conflicts with an architectural decision it was never given, an agent reaches a business rule that exists only in an experienced employee’s memory, a reviewer repeatedly corrects a pattern because the approved alternative is documented somewhere the AI cannot access, and different teams give their AI systems different versions of the same organizational knowledge.

At some point, improving the prompt is no longer the answer. The organization needs to decide what AI should know about its engineering environment, where that knowledge should come from, which sources are authoritative, how it stays current, and how an AI workflow receives the right information at the right time. That is the foundation of managed AI engineering.

• Introduction → AI engineering framework
• Chapter 1 → AI in software development
• Chapter 2 → AI developer productivity
• Chapter 3 → AI engineering standards
• Chapter 4 → AI agents in software development
• Chapter 5 → AI technical debt
• Chapter 6 → AI engineering context
• Chapter 7 → AI cost governance
• Chapter 8 → AI engineering operating model

If you have questions, please let us know.

Take a few minutes to complete the assessment and gain a clear, practical view of your organization’s AI readiness—and what to do next.