A team accepts several small AI-assisted changes. Each looks manageable on its own. Months later, similar helpers behave differently, a dependency has no clear owner, and a routine change requires tracing several versions of the same rule. The maintenance problem is visible in the work the team must now perform, not merely in whether a model helped write the original code.
Calling everything technical debt can make the problem less actionable. A defect, a deliberate shortcut, a missing operating owner, and duplicated business logic may require different decisions. The team needs to identify what future work the issue creates and which obligation it is willing to carry. Removing all assisted code is not a meaningful plan; ignoring its maintenance implications is not one either.
This guide follows a hypothetical set of notification-service changes that accumulated through several pull requests. It uses invented artifacts and proposed criteria, not a real team's measured result. The output is a maintenance-obligation register with a consequence, evidence, owner, and disposition for each issue.
The task differs from a bounded refactor. A refactor asks whether a proposed change preserves or deliberately changes behavior. This page asks which accepted obligations the team should retain, reduce, or retire across the code it already owns.
Describe the maintenance obligation before labeling the debt
Start with a future task or failure. A duplicated retry rule matters because the next provider change requires several investigations or because the differences can produce inconsistent behavior. An unowned dependency matters because somebody must evaluate an update or replacement. A vague label such as messy AI code does not identify either obligation.
Classify the issue sufficiently to choose an action. It may be a defect requiring correction, a deliberate shortcut the team accepts for now, an undocumented contract, or unused behavior that can be retired. Categories can overlap, but the register should state the consequence and owner rather than forcing every issue into one debt score.
The origin of a change can help explain how it was prepared, but it is not a substitute for inspection. Human-written code can create the same obligations. Assisted code can be clear and well supported. Review the actual accepted behavior, evidence, and maintenance path. This makes the work fairer to authors and more useful to maintainers: the question is what the team must understand or do next, not whether a label makes the code suspicious.
A hypothetical maintenance review: several useful changes, one confusing service
A service has accumulated helpers for message formatting, retries, delivery status, and provider errors. Different engineers accepted the changes through ordinary review, with varying amounts of AI assistance. A new requirement exposes duplicated rules and uncertain ownership. The team examines the accepted code without presuming that every assisted change is a mistake.
The review uses approved repository material and synthetic events. It does not rewrite the service automatically or change production configuration. These issues enter the register because they create specific maintenance or failure obligations that can be investigated.
The case is hypothetical; its acceptance conditions are proposed local decisions, not measured project results or industry benchmarks.
Three retry rules
Three helpers apply different retry conditions to the same provider response. Each change had a local rationale, but a new error type requires maintainers to understand all three before deciding what should happen. Inspect a call-site map and the approved provider-error policy.
The case accepts this part only when the retained retry behavior has an explicit owner and a consistent reviewed rule where consistency is required. It rejects the proposal when a future change depends on unexplained differences between duplicated rules.
Next, compare the three behaviors and decide which differences are intentional. The review asks: Which difference exists for a real requirement rather than an accidental local draft? This requires maintenance analysis. Count the effort spent tracing call sites and reviewing the behavior map in the experiment.
Unowned dependency
A helper package simplified one patch, but no team accepted responsibility for compatibility and update decisions. Its presence creates an obligation even if the current code behaves correctly. Inspect the dependency record and a named acquisition and maintenance owner.
The case accepts this part only when the dependency has an accepted purpose, review path, and operating owner. It rejects the proposal when the team cannot explain who evaluates a required update or replacement.
Next, review the package purpose and assign or remove the obligation through the normal process. The review asks: Who must act when this dependency no longer meets the service need? This requires dependency ownership. Count the effort spent reviewing acquisition history and replacement options in the experiment.
A comment that describes a different version
The generated comment explains an earlier interface shape. A maintainer following it could preserve an assumption the current code no longer implements. Inspect the current interface contract and a documentation-to-code comparison.
The case accepts this part only when consequential documentation matches the reviewed current behavior or states its unresolved status. It rejects the proposal when stale explanation is treated as authoritative evidence for a new change.
Next, verify the contract and revise the explanation with its source. The review asks: Which source makes this description trustworthy today? This requires source verification. Count the effort spent checking documentation against actual consumers in the experiment.
Similar names, different status meanings
Two status helpers use the word delivered for different events: provider acceptance and confirmed downstream delivery. The ambiguity makes support and analytics changes harder to review. Inspect a status-definition table and the consuming workflow requirements.
The case accepts this part only when each status has a reviewed meaning and consumers use it consistently. It rejects the proposal when one label hides distinct events with different operating consequences.
Next, agree the meanings with consumers and plan a bounded compatibility change. The review asks: What observation does this status claim has actually occurred? This requires semantic design. Count the effort spent mapping status use and reviewing compatibility in the experiment.
Tests tied to implementation shape
Several tests assert private helper calls rather than the behavior needed by consumers. A safe consolidation might break the suite while an incorrect business result still passes. Inspect a requirement-to-test map and independently established output examples.
The case accepts this part only when the checks protect the approved behavior and expose consequential regression. It rejects the proposal when test success depends on helper structure without checking the required result.
Next, add independent behavior checks before consolidating the helpers. The review asks: Which test should survive if the implementation changes but the contract does not? This requires verification judgment. Count the effort spent reviewing assertions and preparing behavior fixtures in the experiment.
Dead path with a hidden consumer
One rarely used branch appears removable from the main application trace. An operational recovery script may still depend on its output, so deletion cannot be justified by the common path alone. Inspect a consumer inventory including the recovery workflow.
The case accepts this part only when removal accounts for reviewed consumers and a supported replacement where required. It rejects the proposal when a low-frequency but necessary recovery path loses its contract.
Next, ask the operating owner to verify the branch purpose and replacement. The review asks: Who uses this behavior when ordinary processing has already failed? This requires operational reasoning. Count the effort spent investigating rare consumers and reviewing recovery in the experiment.
A broad fix that enlarges the obligation
The assistant proposes replacing all helpers with a new abstraction. That may reduce duplication but add unfamiliar configuration, a dependency, and migration work that the team has not agreed to carry. Inspect an obligation comparison for a narrow repair and the proposed abstraction.
The case accepts this part only when the remediation reduces a stated burden without creating unaccepted new obligations. It rejects the proposal when a cleanup becomes an unreviewed platform redesign.
Next, compare the narrow repair with the larger abstraction before selecting scope. The review asks: Which future task becomes easier, and which new task appears? This requires remediation design. Count the effort spent estimating maintenance work and reviewing added scope in the experiment.
No proof that repair helped
The register marks an issue done when the consolidation merges. It does not examine whether the next representative change is easier to understand or whether operating uncertainty remains. Inspect a before/after maintenance exercise with the same reviewed task.
The case accepts this part only when closure includes evidence that the stated obligation was reduced or deliberately retained. It rejects the proposal when merge status substitutes for showing what burden changed.
Next, repeat a bounded maintenance task and document remaining limitations. The review asks: What work no longer needs to be repeated after this repair? This requires measurement and closure. Count the effort spent preparing the comparison and interpreting retained obligations in the experiment.
Build an inventory from real change and failure paths
Choose a bounded service or component and inspect the paths relevant to the next maintenance need. Include callers, tests, dependencies, status definitions, operating scripts, and consequential documentation. Do not begin with an automatic rewrite of every file. An inventory is meant to reveal obligations before changing them.
Use approved repository material. An assistant may help find candidate duplicates or summarize a supplied call-site map, but verify the findings. Similar names can conceal different requirements; different names can duplicate the same behavior. A generated summary can miss a rare consumer or invent a connection that is not present.
For each issue, retain the smallest evidence packet that supports the consequence. A call-site list and a consumer rule may be enough to discuss duplicated retries. A dependency record and missing owner may establish an acquisition gap. Avoid copying unnecessary secrets or customer material into the packet. The register should point to evidence and responsibilities, not become a second ungoverned store of internal data.
Do not lose the chronology. A difference that looks accidental today may have answered an earlier requirement. The original review, issue, or consumer note can clarify that history. If the history cannot be recovered, label the behavior unresolved and test its consequence. Inventing an origin story would make the register more readable while making the decision less reliable.
Prioritize by consequence and the next work the team must do
Ask which issue obstructs an approved upcoming change or creates a consequential failure risk. A duplicated rule in a rarely touched path may be less urgent than an ambiguous status used by support every day. That does not imply that rare paths are unimportant; a recovery branch may matter precisely when ordinary processing fails.
State the reason for the priority. A score is useful only when reviewers understand its inputs and limits. If the team assigns effort and consequence ratings, keep them as local judgments rather than measured facts. An assistant's numeric ranking can appear objective while simply restating uncertain assumptions.
Separate urgency from convenience. Engineers may choose a cleanup because it is easy to demonstrate, while the harder ownership issue remains. The register can make that choice explicit. If a dependency has no accepted maintainer, editing style around it will not resolve the obligation. Ask the relevant owner to decide whether the team will carry, transfer, or remove that work. A technically elegant remediation is incomplete when nobody accepts its operating responsibility.
Use the next planned change to make the priority concrete. Suppose the service needs to recognize a new provider error. The register can show which helpers must be reviewed, which policy owner must decide, and which fixtures must change. That is an inspectable maintenance burden. Saying the service has too much technical debt leaves those same decisions hidden.
If no near-term change is planned, examine an important recovery scenario or ownership obligation instead. The absence of frequent edits does not establish that the code has no consequence. Keep the chosen scenario and its limitations beside the priority so that another maintainer can challenge the rationale.
Choose retain, repair, consolidate, or remove with a reason
Retaining an obligation can be a deliberate decision when the consequence is understood and the cost of change is not justified now. Record the owner and the event that should trigger another review. The decision is weaker when retention simply means that nobody wanted to discuss it.
A narrow repair can clarify one status meaning or add an independent behavior check. Consolidation can reduce repeated maintenance when the behaviors should be the same. Removal can reduce obligation when consumers and recovery paths have been examined. Each action should answer the issue in the register, not merely increase the apparent amount of cleanup.
Compare added obligations. A new abstraction may make repeated logic easier to change but introduce configuration, dependency, and learning costs. In the notification case, the assistant's broad proposal needs a separate scope review. A bounded refactor can then verify the chosen change through the ordinary process. Keep the inventory decision distinct from implementation acceptance so that the team knows why the patch exists and what evidence should close the issue.
Verify repairs without using the cleanup to define correctness
Before changing duplicated behavior, establish which differences are intentional and which are not. Independently approved fixtures can protect the consumer contract while the implementation changes. A generated consolidation and generated tests may repeat the same mistaken assumption, so passing agreement alone is not enough.
For the status example, identify what event each status represents and which consumers depend on it. Review compatibility before renaming or merging meanings. For the recovery branch, ask the operating owner to confirm how it is used. These checks may reveal that deletion is inappropriate or that a replacement is required.
NIST SP 800-218 offers general secure development practices that can inform the review, testing, and lifecycle context. NIST's generative AI risk profile discusses voluntary evaluation and risk-management concerns. Neither source certifies the cleanup or supplies a technical-debt score. The local register's closure condition should state what was reduced and what remains, supported by the actual review evidence.
Measure reduced maintenance work and new obligations honestly
Choose a representative maintenance exercise connected to the issue. If the burden concerns duplicated retry rules, compare how the reviewed change would be made before and after consolidation. If it concerns ambiguous status meaning, examine whether the next consumer can use the documented contract without repeating the investigation. Do not use the number of deleted lines as the only measure.
Record remediation preparation, review, testing, migration, and ongoing operating work. A cleanup can reduce one burden while adding another. Make that exchange visible. If the team deliberately retains an obligation, report it as retained rather than claiming every register row was solved.
DORA's qualitative analysis describes engineers' experiences with generation, checking, and maintenance-related tasks. It is observational and does not establish that AI causes a particular amount of debt. METR's 2026 update similarly does not provide a universal current productivity estimate for remediation. The local evidence supports a bounded maintenance decision, not a company-wide claim about the quality of all generated code.
Make ownership and engineering learning part of the repair
Ask the maintainer to explain why the obligation exists, what a future change would require, and what evidence closes it. This practice turns hidden knowledge into an inspectable contract. It can also show where learning is needed: domain semantics, dependency review, failure recovery, or design of independent checks.
A junior engineer can investigate one call-site map and verify a consumer. A senior engineer can review whether a proposed abstraction reduces the right burden. A manager can help obtain ownership instead of treating all maintenance as spare-time cleanup. These are different forms of work and deserve explicit assignment.
If you are considering a role change, use the case to examine whether you want to own long-term service quality, bounded implementation, architecture, or team coordination. A dislike of unexplained cleanup may signal a need for better scope rather than a need to abandon engineering. Test the interpretation through a concrete assignment or conversation. No inventory can tell you which career is permanently safe, but it can make your next choice less dependent on a general story about AI.
A 30-day plan for one maintenance-obligation register
In the first week, select one service and a relevant upcoming change. Build the bounded inventory and attach evidence to each issue. Ask consumers and operating owners to confirm the consequential paths. Do not automatically treat unfamiliar generated code as debt or familiar code as safe.
In the second week, prioritize obligations and choose retain, repair, consolidate, or remove with an owner. Define closure and reversal conditions before proposing a broad patch. In the third week, perform the permitted remediation through normal review and testing. Keep behavior changes distinct from mechanical cleanup and review any newly added dependencies.
In the fourth week, repeat the representative maintenance exercise and record what burden changed. Close only the issues whose stated condition is established; retain unresolved ones with an owner and a trigger. Decide whether the method helps enough to repeat elsewhere. Choose one learning action, such as tracing a recovery consumer or explaining a status contract, so that the investigation improves the team's understanding as well as its code.
A debt handoff that tells the next maintainer what to do
The register should let a future maintainer understand the issue without repeating the entire investigation. The following hypothetical notes illustrate that handoff. They do not establish that any cleanup worked or that a particular package was appropriate. A real register should attach the actual evidence and accepted owner.
Preserve the reason for retaining an obligation. A deadline or low consequence can be a legitimate reason, provided the trigger for reconsideration is visible. Likewise, preserve why a consolidation was rejected. The next team may face different requirements, and the record should help them reason about the change rather than inherit an unexplained prohibition.
Three retry rules handoff. Attach a call-site map and the approved provider-error policy to the maintenance-obligation register. Write the unresolved review question: Which difference exists for a real requirement rather than an accidental local draft? The next person should be able to perform this action: compare the three behaviors and decide which differences are intentional.
A comment that describes a different version handoff. Attach the current interface contract and a documentation-to-code comparison to the maintenance-obligation register. Write the unresolved review question: Which source makes this description trustworthy today? The next person should be able to perform this action: verify the contract and revise the explanation with its source.
Tests tied to implementation shape handoff. Attach a requirement-to-test map and independently established output examples to the maintenance-obligation register. Write the unresolved review question: Which test should survive if the implementation changes but the contract does not? The next person should be able to perform this action: add independent behavior checks before consolidating the helpers.
A broad fix that enlarges the obligation handoff. Attach an obligation comparison for a narrow repair and the proposed abstraction to the maintenance-obligation register. Write the unresolved review question: Which future task becomes easier, and which new task appears? The next person should be able to perform this action: compare the narrow repair with the larger abstraction before selecting scope.
Compare your options
| Case issue | Evidence to retain | Acceptance condition | Reason to stop |
|---|---|---|---|
| Three retry rules | a call-site map and the approved provider-error policy | the retained retry behavior has an explicit owner and a consistent reviewed rule where consistency is required | a future change depends on unexplained differences between duplicated rules |
| Unowned dependency | the dependency record and a named acquisition and maintenance owner | the dependency has an accepted purpose, review path, and operating owner | the team cannot explain who evaluates a required update or replacement |
| A comment that describes a different version | the current interface contract and a documentation-to-code comparison | consequential documentation matches the reviewed current behavior or states its unresolved status | stale explanation is treated as authoritative evidence for a new change |
| Similar names, different status meanings | a status-definition table and the consuming workflow requirements | each status has a reviewed meaning and consumers use it consistently | one label hides distinct events with different operating consequences |
| Tests tied to implementation shape | a requirement-to-test map and independently established output examples | the checks protect the approved behavior and expose consequential regression | test success depends on helper structure without checking the required result |
| Dead path with a hidden consumer | a consumer inventory including the recovery workflow | removal accounts for reviewed consumers and a supported replacement where required | a low-frequency but necessary recovery path loses its contract |
| A broad fix that enlarges the obligation | an obligation comparison for a narrow repair and the proposed abstraction | the remediation reduces a stated burden without creating unaccepted new obligations | a cleanup becomes an unreviewed platform redesign |
| No proof that repair helped | a before/after maintenance exercise with the same reviewed task | closure includes evidence that the stated obligation was reduced or deliberately retained | merge status substitutes for showing what burden changed |
Write one maintenance obligation and its closure condition
Choose an accepted piece of code that creates a specific future burden. Use the worksheet to define the obligation and action. It is a decision aid, not a universal debt score or authorization for a sweeping rewrite.
A reflection tool for planning your next step, rather than a predictive score.
- Name the future change or failure that makes the issue matter.
- Attach the relevant code, consumer, dependency, or operating evidence.
- Classify the obligation without relying on the code's origin label.
- Identify the owner who can accept, change, or remove it.
- Compare a narrow action with any broader proposal.
- Establish independent behavior checks and reversal conditions.
- Repeat a representative maintenance task after the change.
- Record what was reduced, retained, or newly introduced.
The hypothetical maintainer selects the three retry helpers. They map the call sites and ask which differences the provider-error policy requires. The register does not assume consolidation is correct. It states the consequence of leaving differences unexplained and the evidence needed to choose the action.
The engineer also notices that they postpone ownership conversations by volunteering for another visible code cleanup. They choose to ask who will carry the dependency obligation before writing a replacement. That action addresses a professional behavior the technical register alone cannot resolve.
If you repeatedly stay busy while avoiding a decision about the responsibility you want to own, examine that pattern and choose an action that tests a different way of working. AI and the Andes Retreat is a five-day seminar in Peru's Sacred Valley for 8-15 participants, with no plant medicine. It offers space to examine the decisions, behavior, and actions shaping your life. You can bring a question about your professional direction and choose an action to test afterward. It is not a coding course or a promise about hiring, income, or career security.
Your working notes
Use this page while you think. Your notes stay in this browser tab; download them before you close it.
What does this question change for you?
A practical answer can change how you work. It can also leave a personal decision unresolved: what to learn, what to stop postponing, or which responsibility to take next. Name that decision before collecting another prediction.
Work through your next decision. Your notes stay in the browser tab, and the exercise gives you no predictive score.
If a recurring pattern keeps preventing action, AI and the Andes Retreat offers five days of practical inquiry in Peru's Sacred Valley, followed by support and accountability. Read about the seminar and assess whether that work fits your question.
Frequently asked questions
Search research and audience discussions informed these questions. Some wording has been adapted to the task covered by this guide.
What is AI-related technical debt?
Describe the maintenance obligation rather than relying on the origin label. An assisted change may create duplicated rules, unsupported assumptions, weak checks, or unowned dependencies; ordinary code can create the same burdens. In the notification case, three retry helpers require repeated investigation before a future change. The register should name that consequence, its evidence, and its owner. Do not classify every generated line as debt or assume a human-written path needs no inspection.
How can AI-assisted development contribute to technical debt?
It can make it easier to accept more draft code than the team has fully understood or agreed to maintain. Evaluate the actual consequence rather than claiming this happens universally. In the notification case, locally plausible helpers leave divergent retry rules and unclear status meanings. Review independent behavior evidence and operating ownership before adding another abstraction. A bounded register can reveal an obligation; it does not establish that assistance caused all of the service's maintenance problems.
How can I use AI to reduce technical debt?
Use it to prepare candidate findings or a permitted evidence summary, then verify consumers and consequences before changing code. Choose retain, repair, consolidate, or remove with an accountable owner. In the notification case, similar retry helpers may have intentional differences, so compare them with the approved policy first. Establish independent checks and a closure condition. A generated cleanup is useful only if it reduces the stated burden without creating unaccepted new obligations.
Should an AI coding agent autonomously remediate technical debt?
Treat autonomy as a permission and acceptance decision separate from identifying the debt. Begin with a bounded proposal and normal review. In the notification case, a broad consolidation may alter rare recovery behavior or add a dependency, so it needs independent evidence and an owner. Do not grant merge or production authority because the agent can draft the patch. Review the action scope, reversal, and remaining obligations before considering any expanded automation.
How much technical debt is acceptable?
Decide through the consequence, owner, upcoming work, and cost of change rather than a universal amount. Retaining an understood obligation can be deliberate if its review trigger is visible. In the notification case, an unexplained retry difference may block a planned provider change, while another issue can remain with an accepted owner. Record the rationale and what would make it change. An assistant's score does not establish how much burden the organization should carry.
What are concrete examples of technical debt in AI-assisted code?
Examples to investigate include duplicated behavior, stale consequential documentation, tests tied to implementation shape, and dependencies without an owner. These are proposed categories, not claims that every assisted project has them. In the notification case, the register ties each to a future task or failure: changing retries, interpreting statuses, or replacing a package. Attach evidence and an accountable disposition. A list of code smells alone does not establish the maintenance consequence or priority.
How should I investigate whether technical debt increases AI tool costs?
Measure a defined task with its context, repeated preparation, corrections, and actual permitted tool-cost evidence. Do not assume duplicated code or poor documentation produces a particular token increase. In the notification case, unclear retry rules may require repeated investigation, but that burden needs observation. Separate attention, elapsed time, and cash cost in the record. A narrow comparison can inform remediation without establishing a universal relationship between debt, tokens, and engineering ROI.
How do I make a technical-debt concern useful to leadership?
Connect it to a specific future change, failure, or operating obligation and show the evidence. A label saying the service is messy leaves the decision hidden. In the notification case, explain which retry helpers must be investigated before adding a provider error and what a narrow repair would change. Offer an owner, priority rationale, and closure condition. Do not invent financial consequences to make the case more persuasive; retain unknown costs as unknown.
Should I change code-quality standards because AI helps write the code?
Review standards against the behavior and maintenance obligations they protect, not the code's origin alone. Some implementation conventions may be revised through the normal process, while permission, compatibility, and operating requirements still need evidence. In the notification case, a consolidation should preserve independently approved behavior and clarify ownership. Explain why a standard matters or why changing it is appropriate. Do not lower acceptance merely because generation is fast or preserve a convention without understanding its purpose.
What is the practical argument for code quality?
Make the argument through work someone must perform: understand a contract, change a rule, diagnose a failure, or carry an operating dependency. In the notification case, clear status meanings and independent checks reduce repeated investigation when requirements change. That is a maintenance proposition to examine, not a universal quantified saving. Tie a quality criterion to its consumer and acceptance evidence so that it serves the system rather than becoming an unexplained style preference.
Can linting and CI controls prevent poor AI-assisted changes from accumulating?
They can enforce the particular checks they implement, but they do not establish every requirement or maintenance obligation. Review what each control can reject and which decisions remain human. In the notification case, linting may not reveal that two delivered statuses mean different events or that a recovery consumer still needs a branch. Use controls alongside independent behavior and ownership evidence. Do not treat a green pipeline as proof that the accepted code carries no debt.
How should I measure AI-related technical debt?
Name the obligation and repeat a representative maintenance task before and after the proposed action. Record preparation, review, testing, migration, and any new responsibilities. In the notification case, compare what is required to update the approved retry rule rather than counting deleted lines. Close the issue only when its stated burden is reduced or deliberately retained. This guide does not verify a named measurement product; its worksheet makes the local evidence and limits inspectable.
How can I prevent technical debt when using AI to help write code?
Require a bounded behavior contract, independent checks, an owner, and an explanation of new dependencies before acceptance. Inspect the proposed change for obligations that future maintainers must carry. In the notification example, avoid accepting another retry helper without explaining why its behavior differs from existing consumers. Retain necessary differences deliberately. Prevention does not mean eliminating every compromise; it means making the burden and review trigger visible before fast generation makes an unexplained choice permanent.
Should I assume that maintenance is 80% of software lifetime cost?
Do not use that percentage as a premise without a source, definition, and context that match the decision. This guide does not verify the embedded number. For the notification example, estimate the relevant maintenance tasks and accepted operating obligations directly, keeping unknown costs visible. An external benchmark can prompt investigation, but it cannot establish this service's burden or an AI-related saving. State the time horizon and cost categories before using any comparison to prioritize remediation.
How should I categorize technical debt in an AI-assisted project?
Choose categories that help an owner decide what to do, and explain their limits rather than assuming a universal four-part taxonomy. The notification worksheet distinguishes behavior ambiguity, duplicated obligations, fragile verification, and unsupported dependencies as local investigation categories. Attach each item to a future task or failure, evidence, and disposition. Keep items together when they describe the same underlying burden. A category label does not establish severity, cause, or whether retaining the obligation is an acceptable decision.
How should I respond when a teammate repeatedly creates maintenance obligations?
Describe specific changes and the downstream work they create, then ask for an agreed acceptance and ownership process. Avoid inferring intent or competence from the code alone. In the notification case, show the retry difference, affected consumer, and investigation needed for the next change. Ask the accountable manager to resolve priorities rather than silently absorbing every repair. Keep the concern about inspectable work and responsibility, including your own uncertainty, instead of turning it into a personal accusation.
Who should own debugging and maintenance when AI agents generate code?
Name the service and change owners before accepting the code, including the people who can explain and verify its consequential behavior. A generation workflow does not assign ongoing maintenance responsibility automatically. In the notification case, an owner must understand provider errors, recovery, and retained dependencies even if an agent prepares future patches. Keep assistance within the approved action boundary. If nobody accepts the operating obligation, record that gap and narrow the commitment rather than assuming an agent will handle it later.
How should technical-debt work compete with feature work on the roadmap?
Present the specific obligation, consequences of deferral, proposed action, and competing work to the people who own priorities. Do not assume every cleanup deserves an immediate sprint or hide its effort. In the notification case, explain whether a retry ambiguity blocks an approved provider change or can remain with an accepted review trigger. Offer a narrow option and a deliberate retain option. Scheduling should make the tradeoff inspectable without invented savings or a guarantee that the repair pays for itself.
How can I distinguish a deliberate compromise from unexamined complexity?
Look for the accepted rationale, owner, consequences, and reconsideration condition rather than judging from a label or appearance. A dated ticket can help accountability but does not prove that the original choice was understood. In the notification case, a retained retry difference needs a reason tied to its consumer. If that reason is missing, investigate before calling it strategic. Document what remains unknown and who decides the disposition instead of assuming all rapid changes were either prudent or careless.
What should change when a prototype becomes a continuing product?
Revisit the operating, compatibility, verification, and ownership obligations before treating the prototype as an accepted foundation. Identify which assumptions were permitted for exploration and which now need evidence. In the notification case, a temporary provider helper may require a maintained error contract and recovery owner once other work depends on it. Propose a bounded improvement with a clear closure condition. Do not assume a full rewrite is necessary or promise that additional design work will produce a particular saving.
Sources and evidence
These guides were drafted with AI assistance and checked against the linked sources. Examples labeled hypothetical illustrate a decision; they are not participant stories or measured results.
Studies answer specific questions about particular people, tasks, and tools. Their dates and limits matter. A result about task assistance is not a forecast for an entire profession.
- NIST SP 800-218: Secure Software Development Framework
- NIST AI 600-1: Generative Artificial Intelligence Profile
- DORA: Balancing AI tensions: Moving from AI adoption to effective SDLC use
- METR: We are Changing our Developer Productivity Experiment Design
- O*NET: Software Developers
- How AI Impacts Skill Formation, preprint version 2
- Observed audience question: How to avoid technical debt in ai coding
Where the audience questions came from
These linked discussions and comments supplied questions and wording. They do not establish the truth of the replies, verified professional identities, or how common a concern is.
- Observed audience question: leadership doesn't really care about tech debt (why would they?
- Observed audience question: I don't want to give up on my standards, but, maybe they are too wired to the traditional coding world and should be heavily adjusted?
- Observed audience question: What was the argument for code quality before AI slop was a thing?
- Observed audience question: Unwarranted contributors, Slop code: You have a DX problem, where are your strong linting contracts, pre-commit hooks and CI guards to prevent poor code from even making it into a PR in the first place?
- Observed audience question: How to deal with teammate who keeps adding on to tech debt and boss who doesn't care?
- Observed audience question: Who will debug and maintain that pile of code?
- Observed audience question: How do you get tech debt into a sprint when product owns the roadmap?
- Observed audience question: Does anyone else have a hard line for distinguishing between "we chose speed" and "we were sloppy"?
- Observed audience question: But how can I handle the scenario of "this is now no longer an uncertainty and is clearly being built upon, we need to do it right" in a more organized fashion?
