Technical Debt Risks in AI-Assisted Software Development: Insights from Practitioners

Technical Debt Risks in AI-Assisted Software Development: Insights from Practitioners Nazia Jahan∗ , Nafisa Alam∗ , Sourov Debnath, Arafat Rahman, S. M. Waesh Ahmed, Md Farhad Alam Bhuiyan

arXiv:2611.15310v1 [cs.SE] 11 Nov 2026

Penta Global Limited Dhaka, Bangladesh {nazia.jahan, nafisa.alam, sourov.debnath, arafat, waesh.ahmed, farhad.alam}@pentabd.com

Abstract—AI coding assistants increasingly support software development, raising concerns about technical debt associated with AI-generated code and development practices. We investigate these concerns through a sequential mixed-methods study involving 137 survey respondents and 20 follow-up interviews with software professionals in Bangladesh. Drawing on ten established technical debt dimensions, we examine perceived risks, contributing circumstances, maintenance consequences, validation practices, and developer understanding. Respondents expressed the strongest concerns about People Debt (73.0%), Management Debt (70.1%), and Architecture Debt (68.6%), suggesting that risks extend beyond code quality. Participants associated ambiguous requirements, insufficient project context, and unrequested AIgenerated changes with architectural inconsistencies, rework, and maintenance difficulties. Their experiences revealed contrasting outcomes: AI assistance supported refactoring, maintainability improvements, and testing, but also introduced rework and context misalignment. Although 89.8% reported regularly verifying AI-generated code, participants expressed concerns about AI dependence, reduced code understanding, and review effort. They also emphasized the need for stronger architectural awareness, requirements clarification, and validation support in coding assistants. Our findings suggest that managing technical debt risks requires attention to project context, implementation decisions, and developer understanding alongside generated code quality.

I. I NTRODUCTION Developers increasingly use generative artificial intelligence (GenAI) in software development [1], [2] for code generation, debugging, testing, refactoring, and documentation [2]. AI coding assistants help developers implement features, explore solutions, and modify existing systems. Barke et al. [3] identified exploration and acceleration as distinct modes of interaction with code-generating models, while Sergeyuk et al. [2] documented their use across development activities and highlighted concerns about reliability, project context, and developer control. As developers delegate increasingly complex tasks to AI assistants, these tools can generate substantial code changes with limited human intervention, raising concerns about additional review, integration, and long-term maintenance costs [4]. Technical debt (TD) refers to design or implementation constructs that are expedient in the short term but set up a ∗ These authors contributed equally to this work.

Mia Mohammad Imran Department of Computer Science Missouri University of Science and Technology Rolla, MO, USA imranm@mst.edu

technical context that can make future changes more costly or impossible [5]. Caglayan et al. proposed ten TD types: Architecture, Requirements, Configuration, Design, Documentation, Infrastructure, Management, People, Code, and Test debt [6]. AI-generated code can contain maintainability problems such as code smells, duplicated code, and missing documentation [7], [8]. Such problems may become technical debt when they persist in the codebase and make later changes more costly [9], [4], [8]. However, not every AI-generated code problem constitutes technical debt, as developers may revise or fix such problems before they create lasting maintenance liabilities [9], [10], [8]. Investigating these risks therefore requires examining implementation problems alongside their development circumstances and consequences. Technical debt risks also extend beyond individual code artifacts to the context in which developers use AI assistants. AI assistants may generate code that addresses the immediate prompt without the project-level context it needs, such as unstated requirements [1], [2]. Developers decide which tasks to delegate, how to specify their requirements, and how thoroughly to validate generated changes [2], [3], [10]. These decisions, combined with the speed and volume of AIgenerated code, can affect how well developers understand the implementation, how much review effort it requires, and how maintainable it remains [11], [12], [13]. Prior studies have examined code-quality problems in AIgenerated programs [14], TD in AI-enabled systems [15], and TD risks in AI-assisted development and vibe coding [16], [17], [4], [18], [8]. Repository studies primarily identify technical debt indicators in software artifacts, offering limited insight into the development decisions and circumstances behind them. Existing practitioner research also provides limited evidence connecting technical debt dimensions with developers’ experiences and practices [15], [18]. To address these gaps, we conduct a sequential mixedmethods study involving surveys and interviews with software development professionals in Bangladesh. We examine ten TD dimensions proposed by Caglayan et al. [6] in relation to development decisions, maintenance consequences, mitigation practices, and developer understanding, guided by the following five research questions:

RQ1: What types of technical debt do developers perceive as risks in AI-assisted software development? • RQ2: What circumstances and development decisions contribute to problematic AI-generated implementations, and how can these introduce technical debt? • RQ3: What consequences do developers experience from problematic AI-generated implementations, including those that create technical debt? • RQ4: How do developers validate AI-generated code and manage or mitigate potential technical debt risks? • RQ5: How does AI-assisted development influence developers’ learning, work practices, understanding, and decisionmaking? •

Our study comprises a survey of 137 software professionals, followed by interviews with 20 participants recruited from the survey respondents. We integrate quantitative survey results, thematic analysis of open-ended responses, and interview findings to examine perceived TD risks, contributing circumstances, maintenance consequences, and developer practices in AI-assisted software development. Practitioners perceived TD risks across all ten dimensions, with People Debt (73.0%) and Management Debt (70.1%) receiving the highest agreement. Respondents identified ambiguous requirements and AI overreliance as prominent concerns, while qualitative accounts linked insufficient project context to rework and maintenance difficulties. Participants reported contrasting experiences, including improvements in refactoring, maintainability, and testing alongside rework, context misalignment, and maintenance challenges. Although most participants verified AI-generated code, manual review (78.1%) remained more common than automated testing. Participants also reported learning benefits alongside concerns about AI dependence and reduced code understanding. Our study makes three major contributions: Socio-technical perspective: We characterize practitioners’ concerns about AI-associated technical debt across software quality, development processes, team coordination, and developer knowledge. • Pathways to technical debt: We provide empirical evidence linking unclear requirements, insufficient project context, and unrequested AI-generated changes to architectural inconsistencies, rework, and maintenance difficulties. • Developers’ insights: We identify practical challenges in delegating, reviewing, and maintaining AI-generated code, alongside developers’ approaches to validation and preserving implementation understanding. •

The survey and interview instruments, study data, annotation guidelines, and supporting materials are available at [19]. II. R ELATED W ORK A. Technical Debt in Software Engineering Research increasingly recognizes technical debt as a multidimensional, socio-technical phenomenon rather than a problem confined to source-code quality. Studies have established

classifications of TD types, indicators, and management strategies [20], [21], [22]. Caglayan et al. consolidated 120 indicators across ten dimensions [6]. Their taxonomy provides the foundation for our study. Empirical studies revealed how technical, organizational, and human factors contribute to technical debt. Ernst et al. identified architectural decisions as a major source of technical debt [23], while Macia et al. demonstrated the limitations of code-level indicators in detecting architectural problems [24]. Ahmad et al. highlighted the interplay between social, process, and people debts [25]. Practitioner studies exposed organizational and process causes [26], shortcomings in management tools [27], and gaps in decision traceability [28]. Recent work connected these challenges to stakeholder perspectives, team practices, and organizational structures, showing how technical debt emerges and persists through interactions between people and software systems [29], [30]. B. AI-Assisted Software Development Research on AI coding assistants highlights productivity gains alongside challenges involving developer control and code quality. Cui et al. reported that developers with access to GitHub Copilot completed more tasks [31], while Barke et al. identified acceleration and exploration as distinct interaction modes [3]. However, Vaithilingam et al. observed difficulties understanding, modifying, and debugging generated code [11]. Broader surveys revealed concerns about trust, requirements compliance, insufficient project context, and the boundaries of task delegation [1], [2]. Mu et al. showed that asking clarifying questions before code generation improved the correctness of solutions for ambiguous requirements [32]. Verification and maintenance research exposed additional challenges. Tang et al. examined developers’ validation and repair behaviors [33], while Tabarsi et al. documented practices involving code inspection, output checking, and testing [10]. Empirical evaluations identified correctness, maintainability, and security weaknesses in generated implementations [34], [14], [35], [36]. Studies of downstream consequences reported contrasting findings: Xu et al. [13] associated AI adoption with increased rework and review effort, whereas Borg et al. [37] found no significant differences in subsequent maintenance performance. These results suggest that productivity gains, verification demands, and maintenance outcomes vary with development practices and contexts. C. Technical Debt in AI-Assisted Development Recent research examined technical debt risks associated with AI-assisted software development (Table I). Ehsani et al. identified code, design, and documentation debt alongside emerging concerns involving rapid integration and provenance [16]. Moreschini et al. highlighted governance and maintainability challenges [38]. Gosu et al. found that existing approaches mainly addressed debt identification and repayment using prompt-based models, with limited support for broader technical debt management activities and human collaboration [39].

Table I. R ELEVANT AI- RELATED TECHNICAL DEBT STUDIES (2024–2026). Study Ehsani et al. [16] Moreschini et al. [38] Gosu et al. [39] Liu et al.† [8] Niemeyer et al. [17]

Data Source 104 studies (includes gray literature) 61 studies 29 studies 302.6k commits 1,091 repositories

Mujahid et al. [40] Brahmi et al. [41] Xu et al.† [13] Bakke et al. [46] Recupito et al. [15] Kara et al.† [44]

6,540 code comments 525 code comments 2,755 repositories 23 teams Survey (53) Interview (18)

Mertala Ivanisevic‡ [18] Our Study

&

Survey (61); interview (7) Survey (137); interview (20)

Research Focus Existing TD types, proposed new TD types, TD causes, and mitigation in AI-assisted development TD types and challenges from DevOps to GenAI GenAI for identifying and repaying TD Persistence of issues in AI-authored commits Code, design, and architecture debt after GenAI adoption SATD [45] associated with AI-generated code SATD generated by AI coding agents Productivity, rework, and maintenance burden GenAI-assisted refactoring to reduce TD Code and architecture debt in AI-enabled systems Proposed ten TD categories in GenAI-enabled systems TD risks in vibe coding Ten TD dimensions, causes, consequences, and practices in AI-assisted development among professionals

Note: †Preprint; ‡Thesis

Empirical studies revealed persistent quality issues in AIauthored commits [8], while Niemeyer et al. reported different patterns of code, design, and architecture debt across project sizes [17]. Studies of self-admitted technical debt (SATD) identified postponed testing, incomplete adaptation, and requirements and design concerns [40], [41]. These findings established evidence of maintenance risks in generated artifacts, while other researchers provided complementary evidence on technical debt risks in vibe coding [18], [42]. Storey’s Triple Debt Model further connected code-level problems with developer understanding and implementation rationale [12], while Avgeriou et al. emphasized human responsibility and oversight in technical debt management [43]. Our Research Positioning. Unlike studies that synthesized existing evidence [16], examined repository-level indicators [4], [8], [17], or focused on vibe coding [18], our study investigates technical-debt risks through software professionals’ everyday experiences with AI-assisted development. Building on prior practitioner research [15], [44], [18], we examine ten established technical-debt dimensions alongside contributing development circumstances, maintenance consequences, mitigation practices, and developer understanding. III. M ETHODOLOGY We adopt a sequential mixed-methods design [47], [48], beginning with an online survey followed by semi-structured interviews. We analyze closed-ended survey responses using descriptive statistics and apply thematic analysis [49] to openended responses. We use the survey findings to develop the interview protocol and recruit participants for follow-up interviews. Finally, we analyze interview accounts to further explore the experiences, implementation decisions, and development practices identified through the survey. A. Survey Design We develop a 35-question survey and distribute through Google Forms. The survey comprised 32 closed-ended and three open-ended questions across five areas: participant background (Q1-Q4), AI-tool usage (Q5-Q8), attitudes and practices (Q9-Q12), technical debt risks and experiences (Q13Q32), and open-ended experiences (Q33-Q35). It took approx-

Table II. S URVEY QUESTIONS AND RESPONSE TYPES . ID Question or statement AI-tool usage Q5 Do you use AI tools for software development? Q6 Which AI tools or agents do you use regularly? Q7 How often do you use AI tools while developing software? Q8 For what purposes do you use AI tools? Attitudes and practices Q9 How helpful are AI tools in your daily development work? Q10 How much do you trust AI-generated code without modification? Q11 How often do you verify AI-generated code before using it? Q12 Have AI tools helped you learn new concepts or technologies? Architecture debt Q13 AI-generated solutions may negatively affect long-term system architecture. Q14 Which architecture-related issues have you experienced from AI-generated code? Code debt Q15 AI-generated code often increases difficult-to-maintain or low-quality code. Q16 Which code-related problems have you experienced from AI-generated code? Configuration debt Q17 AI-generated solutions may introduce configuration or dependency management issues. Q18 Which configuration-related issues have you noticed? Design debt Q19 AI tools sometimes suggest solutions that conflict with good software design principles. Q20 Which design-related issues have you noticed in AI-generated code? Documentation debt Q21 AI-assisted development may lead to incomplete or low-quality documentation. Q22 What documentation problems have you experienced with AI-generated content? Infrastructure debt Q23 AI-generated solutions may introduce infrastructure or operational inefficiencies. Q24 Which infrastructure-related problems have you experienced? Management debt Q25 Heavy reliance on AI tools may create management or workflow-related challenges within software teams. Q26 Which management-related issues have you observed due to AI-assisted development? People debt Q27 AI-assisted development may negatively affect collaboration, learning, or developer skill growth. Q28 Which people-related challenges have you experienced due to AI-generated code? Requirements debt Q29 AI-generated solutions may fail to fully reflect actual business requirements. Q30 In which situations do AI tools fail most regarding requirements? Test debt Q31 Developers may rely on AI-generated code without proper testing. Q32 How do you usually validate AI-generated code before production use? Open-ended questions Q33 Describe a situation where AI tools helped reduce technical debt and improved software quality in your development work. Q34 Describe a situation where AI-generated code or AI-assisted development introduced technical debt or caused problems in your software project. Q35 What improvements would you like to see in AI coding assistants to reduce the risk of AI-generated technical debt?

Type YN† MS† SS† MS L5† L5 L5 L4† L5 MS L5 MS L5 MS L5 MS L5 MS L5 MS L5 MS

L5 MS

L5 MS L5 MS OE† OE OE

†Note: YN = Yes/No; SS = single selection; MS = multiple selection; L5 = five-point Likert scale; L4 = four-point Likert scale; OE = open-ended.

imately 25-30 minutes to complete the survey. Table II presents the survey questions and response formats. Participant Background and AI-Tool Usage. Questions Q1Q4 collected participants’ gender, professional roles, software development experience, and frequently used programming languages. Questions Q5-Q8 examined whether participants used AI tools for software development, which tools they used, how frequently they used them, and their purposes. Participants selected one response for gender, role, experience, AI use, and usage frequency. They could select multiple programming languages, AI tools, and usage purposes. Attitudes and Development Practices. Questions Q9-Q12 examined perceived helpfulness, trust in AI-generated code without modification, verification frequency, and learning benefits. Q9 offered five categories ranging from Very helpful to Not helpful at all, while Q10 offered five categories ranging from Completely trust to No trust at all. Q11 measured verification frequency using Always, Often, Sometimes, Rarely, and Never. Q12 measured learning benefits using Significantly, Somewhat, Rarely, and Never. We treated the questions as ordered response in Likert scales.

Technical Debt Related Questions. Q13-Q32 examine ten technical debt dimensions from the taxonomy of Caglayan and Ozcan-Top [6]: Architecture, Code, Configuration, Design, Documentation, Infrastructure, Management, People, Requirements, and Test debt. For each dimension, we pair a fivepoint agreement statement with a multiple-selection follow-up question. We develop the follow-up options by drawing on technical debt indicators and classifications [6], [22], [21], [50], [51], [52] and adapting them to AI-assisted development [16]. This approach allows us to cover established technical debt problems while incorporating AI-specific concerns, including overreliance on generated solutions, dependence on AI tools, and reduced understanding of generated code. The agreement statements capture participants’ perceptions of potential technical debt risks, while the follow-up questions examine issues they experience or observe, including duplicated code, architectural inconsistencies, dependency conflicts, and requirement mismatches, as well as their practices for validating AI-generated code. Participants can select multiple predefined options, choose “None” if none apply, or select “Other” to provide a free-text response. Open-Ended Questions. We ask the participants to describe their experiences beyond the predefined response options in three open-ended questions. Q33 explored situations in which AI tools helped reduce or manage technical debt, Q34 examined problems participants encountered during AI-assisted development, and Q35 collected suggestions for improving AI coding assistants. These questions allowed participants to describe implementation circumstances, consequences, and potential improvements in their own words. B. Survey Participants Recruitment and Eligibility. We recruited software development professionals working in Bangladesh through voluntary, non-probability sampling. We distributed the Google Forms survey through social media and professional networks, including LinkedIn, Facebook, and Discord, using public posts and direct sharing. The survey was conducted from June 6 to June 16, 2026. Respondents provided informed consent before completing the questionnaire. We received 137 responses. We refer the survey participants as S1-S137. Demographic and Professional Background. Table III summarizes participants’ gender, software development experience, and professional roles. Practitioners with three to five years of experience constituted the largest group (40.1%). Backend developers (28.5%) and full-stack developers (21.9%) represented the most common roles. We grouped less frequent roles under “Other roles.” C. Interview Design We develop an eight-question semi-structured interview protocol (Table IV) to explore the issues identified in our survey analysis in greater depth. The protocol covers AItool usage and task delegation (I-Q1–I-Q2), changes beyond the requested scope (I-Q3), handling of ambiguous requirements (I-Q4), implementation intent (I-Q5), learning with

Table III. S URVEY PARTICIPANT CHARACTERISTICS (N = 137). AI-tool use for software development Yes (included in analysis) 137 (100% of 137) Gender: Male: 129 (94.2%); Female: 8 (5.8%) Experience n (%) Role Less than one year 10 (7.3%) Backend developer One to two years 28 (20.4%) Full-stack developer Three to five years 55 (40.1%) Data/ML engineer Six to ten years 32 (23.4%) QA/Test engineer More than ten years 12 (8.8%) Frontend developer Other roles

n (%) 39 (28.5%) 30 (21.9%) 20 (14.6%) 11 (8.0%) 10 (7.3%) 27 (19.7%)

Table IV. S EMI - STRUCTURED INTERVIEW QUESTIONS . I-Q1

I-Q2 I-Q3 I-Q4 I-Q5

I-Q6

I-Q7

I-Q8

Question Which AI coding tools do you currently use? Free or paid versions? Do you primarily use conversational tools for specific questions or code snippets, or agentic tools that can access and modify larger portions of your codebase? At what point in a task do you decide to hand over control to an AI agent instead of doing the work yourself? What usually influences that decision? Can you describe a scenario where an AI agent made changes beyond your instructions? What additional changes did it make, and how did you handle them? How does AI typically respond to ambiguous requirements, business rules, or edge cases? Does it seek clarification or proceed based on assumptions? When asking an AI agent to implement a task, how do you make sure it understands what you want and why? Can you remember a situation where you or another developer later had to change AI-generated code but did not know the original reason behind the implementation? What happened? When working with unfamiliar concepts or technologies, how do you use AI? Do you first seek explanations before implementation, or delegate the implementation directly? What influences your approach? Before accepting AI-generated changes into your project, how do you decide that the code is “good enough” to keep? When you accept a suggestion or solution from an AI agent, do you usually verify that it is correct before using it? If so, how do you verify it? Based on your experience, what is the most significant overlooked risk or problem associated with AI-assisted software development?

Table V. D EMOGRAPHICS OF THE INTERVIEW PARTICIPANTS . Gender: Male: 19 (95%); Female: 1 (5%) Participant role Experience P1 Data/ML Engineer 3–5 yrs P3 Full-stack Developer 3–5 yrs P5 QA/Test Engineer 3–5 yrs P7 Full-stack Developer 10+ yrs P9 Frontend Developer 3–5 yrs P11 Frontend Developer 3–5 yrs P13 Full-stack Developer 1–2 yrs P15 Frontend Developer 3–5 yrs P17 Backend Developer 6–10 yrs P19 Frontend Developer 1–2 yrs

P2 P4 P6 P8 P10 P12 P14 P16 P18 P20

Participant role QA/Test Engineer Backend Developer Backend Developer QA/Test Engineer Data/ML Engineer Data/ML Engineer Mobile App Developer Frontend Developer Backend Developer Backend Developer

Experience 3–5 yrs 1–2 yrs 10+ yrs 3–5 yrs 3–5 yrs 1–2 yrs 3–5 yrs 3–5 yrs 10+ yrs 6–10 yrs

unfamiliar technologies (I-Q6), validation practices (I-Q7), and overlooked risks (I-Q8). We ask the core questions to all interviewees and use follow-up questions to explore their experiences in greater depth. The wording of some questions varies with the flow of each conversation. Participant Recruitment. We invite interview participants from the survey respondents based on their reported experiences and willingness to participate, while seeking diversity in professional roles and software development experience. Of the respondents who expressed willingness to participate in a follow-up interview, we recruit 20 participants for the interview study (Table V). We obtain separate consent for interview participation and audio recording. We identify interview participants as P1-P20 throughout the study. Interview Conduct. Five authors conduct 20 interviews between September 1 and 10, 2026, either in person or remotely via Zoom and Google Meet. The interviews last approximately 10-30 minutes and take place in Bangla or English, depending on participants’ preferences. With participants’ consent, we record the interviews for subsequent transcription and qualitative analysis. We generate initial transcripts manually and with YouTube’s automatic captions for private uploads [53]. We then translate the transcripts into English using Claude

Table VI. Q33 THEMES : R EPORTED AI- ASSISTED TECHNICAL DEBT REDUCTION AND SOFTWARE QUALITY IMPROVEMENTS . R ESPONSES MAY CONTAIN MULTIPLE THEMES .

Table VIII. Q35 THEMES : S UGGESTED IMPROVEMENTS TO AI CODING ASSISTANTS FOR REDUCING TECHNICAL DEBT RISKS . R ESPONSES MAY CONTAIN MULTIPLE THEMES .

Theme Refactoring Productivity

Theme Architectural Awareness Risk Identification

Code Quality Maintainability Test Generation Code Generation

&

Code Comprehension Code Review Architecture Design Debugging Documentation Legacy System Maintenance Planning Prototyping Performance Optimization Code Migration Miscellaneous

Definition Restructuring existing code without changing its behavior. Increasing development output while reducing time and effort. Improving code quality attributes, including readability, consistency, reliability, and ease of maintenance. Generating test cases/test scripts to verify software behavior. Generating source code, boilerplate, or scripts from specifications or prompts. Understanding the structure, behavior, and logic of the code. Examining source code to identify defects and recommend improvements. Defining system structure, components, interfaces, and their interactions. Identifying, diagnosing, and correcting software defects. Creating and updating documentation and code comments. Modifying and maintaining existing legacy software systems. Defining requirements, decomposing tasks, and organizing development activities. Developing preliminary implementations to evaluate ideas/feasibility. Improving execution speed, resource utilization, and computational efficiency. Adapting software to different languages, frameworks, or platform versions. Generic responses not covered by other themes.

n 46 37 36

Coding Best Practices 31 31 25 18

Testing Support Requirements Understanding Output Reliability

18 18 17 15 14 6 6

Explainability Clarification Requests Code Reuse Automated Code Validation Developer Skill Development Security Validation Human Oversight

5 Structured Planning 8 Debt Detection

Table VII. Q34 THEMES : R EPORTED TECHNICAL DEBT AND PROBLEMS INTRODUCED BY AI- ASSISTED DEVELOPMENT. R ESPONSES MAY CONTAIN MULTIPLE THEMES . Theme Rework Maintainability Context Misalignment Architectural Inconsistency Overengineering Incorrect or Hallucinated Output Software Reliability AI Overreliance Code Duplication Review Overhead Performance Testing Debugging Difficulties AI Tool Limitations Domain-Specific Knowledge Gaps Security Dependency Management Team Coordination Infrastructure Legacy System Migration Miscellaneous

Definition Additional effort to rewrite, refactor, correct, or revert AIgenerated code. Code that is difficult to understand, modify, or maintain. Generated code that overlooks project requirements, constraints, or context. Violations of established architecture, design conventions, or coding standards. Introduction of unnecessary complexity, abstractions, components, or functionality. Incorrect, fabricated, or irrelevant AI-generated code or information. New bugs, regressions, or runtime failures caused by AIgenerated code. Excessive AI reliance leading to cognitive dependence and weakened developer knowledge and skills. Repeated code or logic across functions, files, or modules. Extra effort to review and validate AI-generated code. Inefficient code causing slow execution, excessive resource use, or performance bottlenecks. Missing, inadequate, or unreliable tests, or AI actions that disrupt test suites. Challenges in debugging AI-generated code due to limited context and added complexity. Constraints and shortcomings of specific AI tools, models, and versions. Limited understanding of specialized domains, technologies, and their requirements. Vulnerable code or suggestions of unsafe practices. Version incompatibilities, dependency conflicts, or unnecessary dependencies. Inconsistent AI-use practices among the team members. Incorrect, broken, or oversized infrastructure configurations. Incorrect transformations during legacy migrations or upgrades. Generic responses not covered by other themes.

n 33 26 23 22 21 20 18 16 15 11 9 8 7 5 5 4 4 4 2 2 14

Opus 5.5 [54]. In each step, tw authors independently check the transcripts and English translations against the original recordings and correct any inaccuracies. D. Quantitative Data Analysis We use descriptive statistics to analyze the 137 valid survey responses. For each question, we calculate response frequencies and percentages using the number of valid responses as the denominator. We report Likert-scale distributions across their original response categories and exclude missing or

Context Management

Change Scope Control Documentation Cost & Accessibility

Miscellaneous

Definition Adhering to existing system architecture, design patterns, and coding conventions. Identifying and warning about uncertain, risky, or potentially problematic existing/generated code. Following established coding standards and principles for readable, modular, and maintainable code. Generating tests and identifying edge cases to verify code correctness. Correctly interpreting requirements, business rules, and developer intent. Ensuring accurate, consistent, and contextually relevant outputs while minimizing hallucinations. Explaining generated code, design decisions, and trade-offs. Seeking clarification when requirements or instructions are ambiguous or incomplete. Reusing existing components and preventing code duplication. Automatically checking generated code for correctness and quality before acceptance. Enhancing developer skills through learning, training, and effective use of AI tools. Identifying security vulnerabilities in the generated code. Maintaining developer control through review, validation, and guidance of AI-generated code. Outlining implementation steps and specifications before code generation. Identifying technical debt, unnecessary complexity, and maintainability concerns. Maintaining, retrieving, and effectively utilizing relevant project context to ensure continuity and consistency across tasks and interactions. Limiting modifications to the requested scope while preserving existing functionality. Generating and maintaining documentation for code changes. Minimizing token-related constraints and computational costs while improving the affordability and accessibility of AI tools. Generic responses not covered by other themes.

n 30 18 17 17 16 13 13 13 13 12 11 11 9 9 8 8

6 5 3

3

invalid answers only from the corresponding question. For multiple-selection questions, we count the respondents who select each option and calculate the corresponding percentages. Because respondents can select more than one option, the percentages for these questions can exceed 100% in total. E. Qualitative Data Analysis a) Open-Ended Survey Responses: We conduct an inductive thematic analysis [49] of responses to Q33-Q35. We exclude blank and non-substantive responses, retaining 118 responses for Q33, 109 for Q34, and 112 for Q35. Annotation Procedure. Two annotators (authors of this paper) independently examine the responses and assign initial codes to recurring concepts and experiences. They compare their codes, discuss differences, and group related codes into broader themes. Through eight discussion sessions, they refine theme definitions, resolve disagreements, and distinguish overlapping categories. Each annotator devotes approximately 120 person-hours to this process. We allow multiple codes per response when participants describe distinct experiences or concerns, so the combined theme frequencies may exceed the number of valid responses. Question-Specific Analysis. We develop themes independently for Q33, Q34, and Q35, which address technical debt reduction and software-quality improvements (Table VI), implementation problems and maintenance consequences (Table VII), and desired improvements to AI coding assistants (Table VIII), respectively.

b) Interview Data: Two authors review interview responses by question and compare participants’ experiences and practices. They identify recurring issues, group similar accounts, and record how many interviewees report each issue. We count each participant once per category and calculate percentages based on the number of respondents to the corresponding question. We examine these patterns alongside individual accounts to understand implementation problems, maintenance consequences, and developers’ validation and decision-making practices. F. Ethical Considerations We obtained informed consent for survey participation and separate consent for interviews and audio recording. Participation was voluntary, and participants could withdraw. We anonymize all responses to protect participants’ identities and maintain confidentiality. IV. R ESULTS A. RQ1: What types of technical debt do developers perceive as risks in AI-assisted software development? To answer RQ1, we examine practitioners’ perceptions of ten established technical debt dimensions alongside their experiences from open-ended survey responses and interviews. Table IX shows that respondents perceived technical debt risks across all ten dimensions, with the strongest concerns involving People Debt (73.0%), Management Debt (70.1%), and Architecture Debt (68.6%). In contrast, Documentation Debt (31.4%), Test Debt (20.4%), and Requirements Debt (16.1%) received the highest combined disagreement. Infrastructure Debt had the highest proportion of neutral responses (48.2%). The open-ended survey responses provided examples of implementation and maintenance problems associated with these dimensions. In Q34 (Table VII), 109 respondents provided valid accounts. The most frequent themes included Rework, Maintainability, and Context Misalignment, which we examine in RQ3 and RQ2, followed by Architectural Inconsistency (22, 20.2%), Overengineering (21, 19.3%), Incorrect or Hallucinated Output (20, 18.3%), and Software Reliability (18, 16.5%). S10 reported that AI introduced unnecessary components that required removal in a later release, while S107 described an AI-assisted refactoring that broke an existing business requirement. Respondents also reported Testing (8, 7.3%), Dependency Management (4, 3.7%), and Security (4, 3.7%) issues. For example, S63 described flaky tests that produced false-positive results, while S94 reported that an assistant deleted a failing unit-test suite. Interview participants described similar difficulties involving implementation scope, requirements, and code understanding. All 20 interviewees reported that AI made changes beyond their requests. P10, for example, requested a simple function but received an entire class with unnecessary file operations, so P10 discarded the solution and reimplemented it. When requirements lacked clarity (I-Q4), 11 interviewees reported that AI sometimes proceeded on assumptions rather than seeking clarification. P12 explained, “if I don’t explicitly

Table IX. R ESPONSES OF TECHNICAL DEBT DIMENSIONS IN AI- ASSISTED SOFTWARE DEVELOPMENT (N = 137). Q Q13 Q15 Q17 Q19 Q21 Q23 Q25 Q27 Q29 Q31

TD Dimension Architecture Debt Code Debt Configuration Debt Design Debt Documentation Debt Infrastructure Debt Management Debt People Debt Requirements Debt Test Debt

SD† 1.5% 2.2% 0.7% 1.5% 5.8% 0.7% 1.5% 0.7% 0.7% 13.1%

D† 8.0% 9.5% 7.3% 7.3% 25.5% 6.6% 5.1% 5.1% 15.3% 7.3%

N† 21.9% 23.4% 29.9% 27.0% 29.2% 48.2% 23.4% 21.2% 25.5% 16.1%

A† 43.1% 41.6% 47.4% 48.9% 24.8% 34.3% 43.8% 38.0% 42.3% 38.7%

SA† 25.5% 23.4% 14.6% 15.3% 14.6% 10.2% 26.3% 35.0% 16.1% 24.8%

†Note: SD = Strongly Disagree, D = Disagree, N = Neutral, A = Agree, and SA = Strongly Agree.

mention this, it generally starts making assumptions and proceeds with the implementation.” In addition, 16 interviewees (80.0%) reported difficulty recovering the rationale behind AIgenerated code (I-Q5), and 7 of them attributed this difficulty to missing comments or documentation. P20 connected this lack of understanding to maintainability: “It writes code its own way, so you can’t understand the code’s complexity: what it wrote and how.” People and management-related concerns also emerged from both sources. In Q34, 16 respondents (14.7%) described AI Overreliance, while 11 (10.1%) identified Review Overhead. S84 described difficulties modifying and debugging code they had accepted without fully understanding, while S118 reported that after AI introduced unrequested functions, “we lost the implementation knowledge.” Similarly, 11 of 20 interviewees (55.0%) named blind trust, overreliance, or reduced understanding, learning, or code ownership as the biggest overlooked risk (I-Q8). P4 pointed to “Reliability, blind faith, and the tendency of tools to agree with anything you say.” Takeaway. Respondents perceived technical debt risks across all ten dimensions, with the strongest agreement for People Debt (73.0%), Management Debt (70.1%), and Architecture Debt (68.6%). Their accounts highlighted rework, architectural inconsistencies, maintenance difficulties, and reduced understanding of AI-generated code.

B. RQ2: What circumstances and development decisions contribute to problematic AI-generated implementations, and how can these introduce technical debt? To answer RQ2, we examine the development circumstances and implementation decisions that relate to problematic AIgenerated solutions. Table X shows that respondents identified ambiguous requirements (59.1%), complex business logic (53.3%), and large-scale systems (43.1%) as situations in which AI struggled to reflect requirements. They also reported overreliance on AI-generated solutions (58.4%), reduced knowledge sharing (54.7%), and inconsistent development practices (51.1%). Qualitative accounts illustrated how insufficient project context influenced implementation decisions. In Q34 (Table VII), 23 respondents (21.1%) described Context Misalignment. S14 explained, “If you provide a direct prompt explaining the requirements only without any guidelines on system design, it will find a quick temporary solution with high coupling and

Table X. T OP FIVE REPORTED DEVELOPMENT CONDITIONS AND IMPLEMENTATION ISSUES IN AI- ASSISTED DEVELOPMENT (N = 137; MULTIPLE SELECTIONS ALLOWED ). Q14: Architecture-related issues Response Inconsistent architecture patterns Maintainability Tight coupling between components Difficult system integration Poor scalability Q26: Management-related issues Response Over-reliance on AI-generated solutions Reduced knowledge sharing within teams Inconsistent development practices across team members Unrealistic productivity expectations Reduced code review quality

% 58.4% 54.7% 51.1%

Q20: Design-related issues Response Temporary workaround implementations Overly long functions / classes Weak abstractions or design patterns Poor reusability Poor separation of concerns Q30: Requirements-related situations Response Ambiguous requirements Complex business logic Large-scale systems

48.9% 47.4%

Client-specific customization Multi-step workflows

% 53.3% 46.7% 36.5% 29.9% 29.2%

% 49.6% 40.9% 38.0% 38.0% 27.7% % 59.1% 53.3% 43.1% 40.1% 36.5%

lack of scalability.” P1 described a rushed project in which developers provided insufficient documentation and delegated implementation decisions to AI, resulting in unnecessary validation checks, functions, and repetitive API calls. P15 reported that AI modified intentional business-specific behavior, while P14 described how AI implemented subscription tiers without clarifying requirements: “it built various subscription layers on its own, and did the whole implementation on its own, without asking what features there would be, or what kind of things to keep, or what to keep in the free tier.” Development pressure and limited review capacity also influenced practitioners’ decisions. In Q26 (Table X), respondents reported unrealistic productivity expectations (48.9%) and reduced code review quality (47.4%). S12 described pushing AI-generated code without review because of deadline pressure. P11 reported generating approximately 65,000 lines of code in five days across numerous files, explaining, “Now, reviewing that code has been going on for two weeks, and I still haven’t been able to visit all of the files.” This experience illustrated how rapid generation could exceed developers’ review capacity. Respondents also identified architectural and design problems. In Q14, they reported inconsistent architecture patterns (53.3%), maintainability issues (46.7%), and tight coupling (36.5%). In Q20 (Table X), they reported temporary workarounds (49.6%), overly long functions or classes (40.9%), weak abstractions or design patterns (38.0%), and poor reusability (38.0%). These accounts connected unclear requirements, insufficient architectural guidance, deadline pressure, and limited review with implementation problems that may increase maintenance effort. Takeaway. Respondents identified ambiguous requirements (59.1%) and overreliance on AI-generated solutions (58.4%) as prominent concerns, alongside inconsistent architectural patterns (53.3%) and temporary workarounds (49.6%). Qualitative accounts linked insufficient project guidance, requirements misalignment, deadline pressure, and large volumes of generated code to implementation and review difficulties.

C. RQ3: What consequences do practitioners experience from problematic AI-generated implementations, including those that create technical debt? To answer RQ3, we examine technical problems that practitioners encountered during AI-assisted development and their

Table XI. T OP FIVE REPORTED PROBLEMS IN AI- ASSISTED DEVELOPMENT ACROSS CODE , CONFIGURATION , DOCUMENTATION , AND INFRASTRUCTURE (N = 137; MULTIPLE SELECTIONS ALLOWED ). Q16: Code-related problems Response Overly complex implementations Hard-to-maintain code Duplicated code Excessive unused code Poor readability Q22: Documentation-related problems Response Hallucinated or inaccurate information Generic / non-useful documentation Outdated explanations Missing documentation Inconsistent documentation

% 68.6% 46.0% 43.1% 31.4% 29.9% % 40.9% 33.6% 24.8% 22.6% 20.4%

Q18: Configuration-related problems Response Unnecessary dependencies Deprecated libraries / frameworks Version conflicts Compatibility issues across environments Incorrect environment configurations Q24: Infrastructure-related problems Response Security issues in infrastructure setup Scalability or reliability problems Poor monitoring / logging setup Cloud resource misconfiguration Inefficient deployment scripts

% 42.3% 37.2% 35.8% 29.2% 28.5% % 35.0% 26.3% 24.1% 21.9% 20.4%

maintenance consequences. Table XI summarizes the code, configuration, documentation, and infrastructure problems. In Q16 (Table XI), respondents most frequently reported overly complex implementations (68.6%), hard-to-maintain code (46.0%), and duplicated code (43.1%). Configuration issues included unnecessary dependencies (42.3%), deprecated libraries or frameworks (37.2%), and version conflicts (35.8%). Other concerns included inaccurate or hallucinated documentation (40.9%), generic or non-useful documentation (33.6%), security issues in infrastructure setup (35.0%), and scalability or reliability problems (26.3%). Open-ended responses highlighted debugging and maintenance challenges. In Q34 (Table VII), 26 respondents reported Maintainability issues, 15 reported Code Duplication, and 7 reported Debugging Difficulties. S1 described duplicated statemanagement logic that caused intermittent synchronization bugs over several weeks. S3 reported similar issues in a sixstage approval system: “If I need to change a value then I need to change 6 different places. The basic version was developed by AI which was a technical debt for me.” S90 described an AI-generated module with non-standard logic that the team spent two days debugging before rewriting it from scratch. P12 similarly noted that AI sometimes duplicated logic across files, requiring explicit instructions to create reusable functions. Rework emerged as a prominent consequence, which 33 respondents reported in Q34. S64 described inconsistent architectural patterns and excessive coupling in AI-generated service and database layers that required architectural refactoring. S17 reported incorrect dependency versions in an AIgenerated configuration file that disrupted development and required manual correction. Similarly, 80% (16/20) of interviewees reported corrective work ranging from architectural restructuring to removing unrequested changes. Three interviewees reported performance issues, and the unrequested changes that RQ1 reports also surfaced during validation. P2 described an AI-assisted implementation that slowed after deployment to another environment: “But it turns out that when I take it to another server–say it was on a training server and I move it to production–it becomes a bit slow there.” P4 described an unexplained modification during a Bootstrap migration: “Then during testing and review we saw that it made this unnecessary change, and we couldn’t really explain it.” Interviewees reported increased review burdens

(35%, 7/20), weakened code ownership (10%, 2/20), and production risks (20%, 4/20). P6 raised concerns about code ownership under heavy AI use, which “basically belongs to no one anymore.” P9 highlighted the risks of undetected issues reaching production: “when that comes back as a production issue, that becomes a much bigger problem. At that point, we’re the ones to blame.” Takeaway. Respondents most frequently identified overly complex implementations (68.6%), hard-to-maintain code (46.0%), and duplicated code (43.1%), alongside configuration, documentation, and infrastructure problems. Qualitative accounts revealed debugging, refactoring, and deployment issues, while interviews highlighted review burdens and weakened code ownership. These consequences indicated potential, but not necessarily persistent, technical debt.

D. RQ4: How do developers validate AI-generated code and manage or mitigate potential technical debt risks? To answer RQ4, we examine how practitioners validate AIgenerated changes and manage potential technical debt risks. Table XII shows that 89.8% of respondents reported always or often verifying AI-generated code before use. Manual code review was the most common validation method (78.1%), ahead of automated testing (46.0%) and documentation checks (45.3%). Respondents also reported writing additional tests (35.0%), conducting peer reviews (32.8%), and manually rewriting generated code (27.7%). However, 10.2% selected “rarely validate” in Q32 (data not present in Table XII), indicating differences in verification practices. These responses reflect reported practices rather than their effectiveness in preventing technical debt. Open-ended responses provided further evidence of practices for managing technical debt risks. In Q33 (Table VI), of 118 respondents, 46 (39.0%) described Refactoring, 36 (30.5%) described Code Quality & Maintainability improvements, and 31 (26.3%) described Test Generation. In Q35 (Table VIII), of 112 respondents, suggested improvements involved Architectural Awareness (30, 26.8%), Risk Identification (18, 16.1%), Testing Support (17, 15.2%), Automated Code Validation (12, 10.7%), and Human Oversight (9, 8.0%). S22 advocated incremental implementation: “instead of generating full feature at once, just write one step, and review it with the developer.” Interview participants described practices for controlling AI-generated changes before implementation. Fifteen interviewees (75.0%) provided detailed requirements, instructions, or project documentation, while 11 (55.0%) reviewed or refined AI-generated plans and six (30.0%) divided tasks into smaller steps. P12 described repeatedly reviewing plans to identify missing requirements and incorrect assumptions, explaining, “Only after the plan is finalized do I assign the actual implementation work.” Nine interviewees (45.0%) also restricted the files or scope that AI could modify. Participants also emphasized reviewing generated implementations. P16 explained, “Since my prompts are small, or are for specific tasks, the AI-generated code is also very small.

Table XII. R EPORTED VERIFICATION AND VALIDATION PRACTICES FOR AI- GENERATED CODE (N = 137; MULTIPLE SELECTIONS ALLOWED FOR Q32). Q11: Verification frequency Response % Always 55.5% Often 34.3% Sometimes 6.6% Rarely 2.9% Never 0.7%

Q32: Validation methods (Top 5) Response % Manual code review 78.1% Running automated tests 46.0% Cross-checking documentation 45.3% Writing additional tests 35.0% Peer review 32.8%

So it’s not much of a hassle for me to review the code.” P16 manually inspected changes and tested their functionality, while three interviewees (15.0%) explicitly limited change size to facilitate review. Across the interviews, 14 participants (70.0%) tested generated code, nine (45.0%) checked architectural consistency, nine (45.0%) used another AI tool for crosschecking, six (30.0%) consulted documentation or conducted additional research, four (20.0%) examined edge cases, and five (25.0%) inspected repository changes or pull requests. When AI introduced unnecessary changes (I-Q3), 12 interviewees (60.0%) reverted, removed, or corrected them, while six (30.0%) tightened their prompts or scope instructions. P3 distinguished useful additions, such as overlooked edge cases, from unnecessary modifications and instructed AI to revert the latter. Takeaway. Most respondents (89.8%) reported always or often verifying AIgenerated code, with greater reliance on manual review (78.1%) than automated testing (46.0%). Interviewees described reviewing plans before delegation (11 of 20), testing generated code (14 of 20), and correcting unwanted changes (12 of 20). Our study does not measure the effectiveness of these practices in reducing technical debt.

E. RQ5: How does AI-assisted development influence developers’ learning, work practices, understanding, and decisionmaking? To answer RQ5, we examine how practitioners use AI for learning, delegate development tasks, and make technical decisions. Table XIII shows that 93.4% of respondents used AI multiple times a day, while 96.4% considered it helpful or very helpful. Common uses included code generation (86.9%), debugging (84.7%), code explanation (78.1%), and documentation (77.4%). Most respondents reported significant (64.2%) or some (32.1%) learning benefits. However, only 44.5% mostly or completely trusted unmodified AI-generated code. Respondents also identified over-dependence on AI tools (73.7%), reduced understanding of generated code (64.2%), and skill degradation (64.2%) as people-related challenges. Open-ended responses reflected both benefits and risks. In Q33 (Table VI), respondents highlighted gains in Productivity (37, 31.4%), Code Comprehension (25, 21.2%), and Debugging (18, 15.3%). In Q34 (Table VII), S132 reported declining hands-on problem-solving and skill development as team members increasingly relied on AI. In Q35 (Table VIII), respondents requested Explainability (13, 11.6%) and Developer Skill Development (11, 9.8%). S84, for example, wanted AI to explain code in simple language and identify potential issues to support learning.

Interview participants described how AI influenced their development decisions. P11 explained, “Before, I used to think about how to solve the problem. Now, the first thing that comes to my mind is how I can explain the problem to AI in a better way.” This account illustrated a shift toward preparing instructions and context for AI. When deciding what to delegate (I-Q2), four interviewees prioritized time savings, while four delegated coding tasks but retained control over business logic or major decisions. Participants also described learning strategies for unfamiliar tasks (I-Q6). Nineteen interviewees (95.0%) reported developing their understanding before delegating unfamiliar work, including 15 (75.0%) who asked AI for explanations and six (30.0%) who consulted documentation or other references. P3 explained, “if I have the concept clear beforehand, then whatever kind of issue comes up, I’ll be able to fix it easily.” P18 similarly described evaluating alternative approaches before implementation and emphasized, “I keep control of it. I do the R&D on it myself first, build a small project to try it out.” Three participants (15.0%) initially delegated unfamiliar tasks directly but later adopted a learning-first approach, while P18 allowed greater AI autonomy for simple applications. In contrast, P9 used AI to build a project in an unfamiliar technology stack and could verify its behavior but not its underlying code. P13 described increasing dependence on AI, acknowledging, “I mean, my level of human thinking has dropped a lot. Second, the dependency has become much greater.” P13 also reported occasionally pushing AI-generated code without adequate review. This account contrasted with the learning-first approach that P3 described and illustrated concerns about declining independent problem-solving. Although survey respondents identified over-dependence (73.7%) and skill degradation (64.2%) as risks, their responses do not establish measurable changes in developer ability. Takeaway. Most respondents reported significant learning benefits (64.2%), alongside concerns about over-dependence (73.7%) and reduced understanding of generated code (64.2%). Nineteen of 20 interviewees reported developing their understanding before delegating unfamiliar tasks, while interview accounts revealed contrasting experiences with AI dependence and independent problem-solving.

V. D ISCUSSION AND I MPLICATIONS A. Technical Debt Risks Beyond Code Quality Technical debt risks in AI-assisted development extend beyond code quality to encompass broader socio-technical concerns. The prominence of People Debt, Management Debt, and Architecture Debt (RQ1) suggests that a code-centric perspective alone is insufficient to capture these risks, aligning with research on the human and organizational dimensions of technical debt [6], [25]. Prior research also emphasized the role of human judgment in technical debt management and introduced concepts such as cognitive and intent debt [43], [12]. The contrasting experiences reported in Q33 and Q34 indicate that perceived improvements in refactoring, maintainability,

Table XIII. R EPORTED DEVELOPER PRACTICES , LEARNING , AND DECISION - MAKING IN AI- ASSISTED DEVELOPMENT (N = 137; MULTIPLE SELECTIONS ALLOWED FOR Q8 AND Q28). Response % Q10: Trust in unmodified code Completely trust 2.9% Mostly trust 41.6% Neutral 29.9% Slightly trust 19.0% No trust at all 6.6% Q12: Learning new concepts Significantly 64.2% Somewhat 32.1% Rarely 3.6% Never 0.0% Q9: Perceived helpfulness Very helpful 66.4% Helpful 29.9% Neutral 1.5% Slightly helpful 2.2% Not helpful 0.0%

Response Q7: AI-tool usage frequency Multiple times a day Once a day Several times a week Several times a month Rarely Q8: Purposes of AI-tool use (Top 5) Code generation Bug fixing / debugging Explaining code Writing documentation Brainstorming ideas Q28: People-related challenges (Top 5) Over-dependence on AI tools Reduced understanding of generated code Skill degradation / problem-solving reduction Reduced collaboration among team members Communication gaps during development

% 93.4% 1.5% 2.2% 1.5% 1.5% 86.9% 84.7% 78.1% 77.4% 72.3% 73.7% 64.2% 64.2% 59.9% 48.9%

and testing can coexist with rework, context misalignment, and maintenance difficulties, making the long-term implications of AI-assisted development difficult to assess. Such risks may not be immediately apparent in generated code but can arise through implementation decisions, coordination challenges, and subsequent maintenance. Interview accounts suggest that insufficient project context and unclear requirements can lead to implementations that conflict with existing architecture or business constraints. Prior research reported similar concerns [2], [32]. Interviewees also noted that rapid code generation can increase the effort needed to understand and validate changes. This aligns with prior studies reporting faster task completion [55] but greater review and rework effort [13]. Consequently, AI-assisted development may shift effort from implementation to review, correction, and maintenance, potentially offsetting productivity gains when developers poorly understand generated changes or when those changes conflict with project requirements. B. AI Delegation, Developer Judgment, and Maintenance The perceived learning benefits and concerns about AI dependence (RQ5) suggest that AI delegation can both support developers and reduce their engagement with implementation details. The contrasting practices of understanding unfamiliar concepts before delegation (P3) and verifying application behavior without fully understanding the code (P9) illustrate how developers may retain different levels of involvement in AI-assisted tasks. Prior research similarly identified changes in developers’ decision-making, cognitive engagement, and collaboration [56], as well as difficulties understanding and modifying generated solutions [11], [40]. These concerns suggest that the consequences of AI delegation depend not only on task completion but also on whether developers retain sufficient understanding to evaluate and modify the resulting implementation. Manual review, testing, and implementation planning (RQ4) remain important validation practices, consistent with prior research [10], [33]. However, difficulties understanding AI’s implementation decisions (RQ1) and maintaining unfamiliar generated code (RQ3) suggest that functional verification alone may not preserve sufficient knowledge for future mainte-

nance. Developers should therefore emphasize understanding implementation rationale alongside functional verification to preserve developer judgment, code ownership, and accountability [43]. C. Implications for Development Practices and Tools Ambiguous requirements and insufficient project context suggest that developers should clarify implementation intent and establish clearer implementation boundaries before delegating tasks to AI assistants. Coding assistants could retain project conventions, ask targeted questions, and present implementation plans for review [32]. To address unrequested changes and excessive review effort, tools could distinguish requested changes from optional improvements and support smaller, incremental modifications. Teams should also strengthen verification and preserve implementation rationale. Beyond checking functional correctness, developers should review generated code for architectural consistency, maintainability, and alignment with project requirements [33], [14]. To address difficulties recovering implementation rationale, coding assistants could record assumptions, design choices, and explanations alongside code changes to support future maintenance. These practices could address decision-traceability challenges and support humandriven technical debt management [28], [43]. D. Implications for Researchers and Future Studies The contrasting experiences with AI-assisted development warrant further investigation into the conditions under which AI reduces maintenance effort or introduces additional technical debt. Prior repository studies investigated technical debt indicators in AI-authored code [8], [17]. Future longitudinal studies could trace developers’ intentions, AI-generated modifications, code review decisions, and subsequent corrective work to distinguish temporary implementation problems from persistent technical debt. Researchers should also examine how AI delegation affects developer understanding, decision ownership, and knowledge transfer within teams, extending socio-technical perspectives on technical debt [25], [12], [56]. Future research should also empirically evaluate practices and tool capabilities intended to mitigate technical debt risks. Controlled studies could assess whether architectural awareness, requirements clarification, incremental implementation, and automated validation reduce unnecessary changes, architectural inconsistencies, and rework. Prior studies reported contrasting maintenance outcomes [13], [4], [37]. Comparing different delegation and verification strategies across project sizes, developer experience levels, and AI-tool configurations could help explain these differences and identify conditions that influence long-term maintainability. VI. T HREATS TO VALIDITY Construct Validity. We adopt ten technical debt dimensions from Caglayan et al. [6] and develop survey items using established indicators and concerns in AI-assisted development. However, these dimensions and predefined response

options may not capture all emerging risks and may influence participants’ selections. Participants may also interpret implementation problems as technical debt even when developers correct them before they create lasting maintenance costs. We address these concerns through open-ended questions (Q33-Q35) and follow-up interviews that capture experiences beyond predefined categories. Internal Validity. Our study relies on practitioners’ selfreported experiences, which may involve recall bias, subjective interpretations, and selective reporting. Participants may attribute implementation problems to AI even when existing codebase conditions, incomplete requirements, time pressure, or developer decisions contribute to the outcomes. We use follow-up interviews to examine these circumstances, although we cannot independently verify reported incidents or establish causal relationships. Researcher interpretation may also influence our qualitative findings. To improve consistency, two annotators rigorously examine open-ended responses, compare their codes, and resolve disagreements through discussion. Nevertheless, different researchers may interpret ambiguous responses differently. External Validity. Our study includes 137 survey respondents and 20 interview participants from the software industry in Bangladesh. We recruit participants through professional and social media networks, which introduces self-selection bias and may overrepresent practitioners with strong opinions or greater experience using AI coding assistants. Although participants represent different roles and experience levels, organizational practices, project characteristics, and AI-tool usage may differ across regions and environments, thus, we characterize participants’ perceptions and experiences. VII. C ONCLUSION Our findings reveal technical debt risks across all ten dimensions, with the highest agreement for People Debt, Management Debt, and Architecture Debt. Drawing on 137 survey responses and 20 interviews, we highlight the sociotechnical nature of these risks, the importance of developer judgment, understanding, and code ownership, and the need for mitigation practices. Practitioners identify ambiguous requirements, insufficient project context, AI overreliance, and review difficulties as prominent concerns. These findings emphasize that technical debt risks arise not only from generated code but also from the decisions and practices surrounding its development. We also identify a tension between developers’ intended improvements through refactoring, testing, and code-quality practices and their reported experiences of rework, context misalignment, and maintenance difficulties. As AI assistants assume greater implementation responsibility, managing technical debt risks requires more than verifying generated code. Developers and teams need to clarify requirements, preserve project context and implementation rationale, control generated changes, and retain sufficient understanding to maintain the resulting software.

R EFERENCES [1] J. T. Liang, C. Yang, and B. A. Myers, “A large-scale survey on the usability of AI programming assistants: Successes and challenges,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE). ACM, 2024, pp. 1–13. [2] A. Sergeyuk, Y. Golubev, T. Bryksin, and I. Ahmed, “Using AI-based coding assistants in practice: State of affairs, perceptions, and ways forward,” Information and Software Technology, vol. 178, p. 107610, 2025. [3] S. Barke, M. B. James, and N. Polikarpova, “Grounded Copilot: How programmers interact with code-generating models,” Proceedings of the ACM on Programming Languages, vol. 7, no. OOPSLA1, pp. 78:1– 78:27, 2023. [4] H. He, C. Miller, S. Agarwal, C. Kästner, and B. Vasilescu, “Speed at the cost of quality: How Cursor AI increases short-term velocity and longterm complexity in open-source projects,” in Proceedings of the 23rd International Conference on Mining Software Repositories. Association for Computing Machinery, 2026, pp. 181–193. [5] P. Avgeriou, P. Kruchten, I. Ozkaya, and C. Seaman, “Managing technical debt in software engineering (dagstuhl seminar 16162),” Dagstuhl Reports, vol. 6, no. 4, pp. 110–138, 2016. [6] D. Caglayan and Ö. Özcan-Top, “Revisiting technical debt types and indicators for software systems,” in Proceedings of the 39th ACM/SIGAPP Symposium on Applied Computing. ACM, 2024, pp. 834–841. [7] M. L. Siddiq, L. Roney, J. Zhang, and J. C. S. Santos, “Quality assessment of ChatGPT generated code and their use by developers,” in Proceedings of the 21st International Conference on Mining Software Repositories (MSR ’24). ACM, 2024, pp. 152–156. [8] Y. Liu, R. Widyasari, Y. Zhao, I. C. Irsan, J. Chen, and D. Lo, “Debt behind the AI boom: A large-scale empirical study of AI-generated code in the wild,” arXiv preprint arXiv:2603.28592, 2026. [9] W. Cunningham, “The WyCash portfolio management system,” in Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA ’92). ACM, 1992, pp. 29–30. [10] B. Tabarsi, H. Reichert, S. Gilson, A. Limke, S. Kuttal, and T. Barnes, “LLMs’ reshaping of people, processes, products, and society in software development: A qualitative exploration with early adopters,” Empirical Software Engineering, vol. 32, no. 1, p. 21, 2027. [11] P. Vaithilingam, T. Zhang, and E. L. Glassman, “Expectation vs. experience: Evaluating the usability of code generation tools powered by large language models,” in CHI Conference on Human Factors in Computing Systems Extended Abstracts (CHI EA). ACM, 2022, pp. 1–7. [12] M.-A. Storey, “From technical debt to cognitive and intent debt: Rethinking software health in the age of AI,” Queue, vol. 24, no. 2, 2026. [13] F. Xu, P. K. Medappa, M. M. Tunc, M. Vroegindeweij, and J. C. Fransoo, “AI-assisted programming decreases the productivity of experienced developers by increasing the technical debt and maintenance burden,” 2025. [Online]. Available: https://arxiv.org/abs/2510.10165 [14] Y. Liu, T. Le-Cong, R. Widyasari, C. Tantithamthavorn, L. Li, X.B. D. Le, and D. Lo, “Refining ChatGPT-generated code: Characterizing and mitigating code quality issues,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 5, 2024. [15] G. Recupito, F. Pecorelli, G. Catolino, V. Lenarduzzi, D. Taibi, D. Di Nucci, and F. Palomba, “Technical debt in AI-enabled systems: On the prevalence, severity, impact, and management strategies for code and architecture,” Journal of Systems and Software, vol. 216, p. 112151, 2024. [16] R. Ehsani, S. Rawal, Y. Cai, and P. Chatterjee, “Faster code, deeper debt? a multivocal literature review on technical debt and its early signs in LLM-assisted software development,” ACM Transactions on Software Engineering and Methodology, 2026. [17] J. Niemeyer and M. Wessel, “GenAI’s hidden cost: An empirical study of AI-induced technical debt,” in Proceedings of the 34th European Conference on Information Systems (ECIS), 2026. [Online]. Available: https://aisel.aisnet.org/ecis2026/isd pm/isd pm/7/ [18] V. Mertala and V. Ivanisevic, “Vibe coding and technical debt,” Master’s thesis, Mälardalen University, 2026. [Online]. Available: https://mdu.diva-portal.org/smash/get/diva2:2068035/FULLTEXT01.pdf [19] N. Jahan, N. Alam, S. Debnath, A. Rahman, S. M. W. Ahmed, M. F. A. Bhuiyan, and M. M. Imran, “Technical debt risks in AI-assisted software development: Insights from practitioners,” https://github.com/NaziaJahanMeem/

understanding-td-risks-in-ai-assisted-software-development, 2026, gitHub repository. [20] Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping study on technical debt and its management,” Journal of Systems and Software, vol. 101, pp. 193–220, 2015. [21] N. S. Alves, T. S. Mendes, M. G. De Mendonça, R. O. Spı́nola, F. Shull, and C. Seaman, “Identification and management of technical debt: A systematic mapping study,” Information and Software Technology, vol. 70, pp. 100–121, 2016. [22] N. Rios, M. G. de Mendonça Neto, and R. O. Spı́nola, “A tertiary study on technical debt: Types, management strategies, research trends, and base information for practitioners,” Information and Software Technology, vol. 102, pp. 117–145, 2018. [23] N. A. Ernst, S. Bellomo, I. Ozkaya, R. L. Nord, and I. Gorton, “Measure it? manage it? ignore it? software practitioners and technical debt,” in Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE). ACM, 2015, pp. 50–60. [24] I. Macia, J. Garcia, D. Popescu, A. Garcia, N. Medvidovic, and A. von Staa, “Are automatically-detected code anomalies relevant to architectural modularity? An exploratory analysis of evolving systems,” in Proceedings of the 11th Annual International Conference on AspectOriented Software Development (AOSD). ACM, 2012, pp. 167–178. [25] M. O. Ahmad and T. Gustavsson, “The pandora’s box of social, process, and people debts in software engineering,” Journal of Software: Evolution and Process, vol. 36, no. 2, p. e2516, 2024. [26] N. Rios, R. O. Spı́nola, M. Mendonça, and C. Seaman, “The practitioners’ point of view on the concept of technical debt and its causes and consequences: A design for a global family of industrial surveys and its first results from Brazil,” Empirical Software Engineering, vol. 25, no. 5, pp. 3216–3287, 2020. [27] J. P. Biazotto, D. Feitosa, P. Avgeriou, and E. Y. Nakagawa, “Understanding practitioners’ reasoning and requirements for efficient tool support in technical debt management,” Empirical Software Engineering, vol. 30, no. 5, p. 134, 2025. [28] L. Carvalho, J. P. Biazotto, D. Feitosa, and E. Y. Nakagawa, “How do practitioners manage traceability of technical debt in continuous software engineering?” in Proceedings of the 2026 ACM/IEEE International Conference on Technical Debt (TechDebt). ACM, 2026, pp. 70–75. [29] N. Riquet, X. Devroey, and B. Vanderose, “Debt stories: Capturing social and technical debt in the industry,” in Proceedings of the 2024 ACM/IEEE International Conference on Technical Debt (TechDebt). ACM, 2024, pp. 40–44. [30] J. B. Jørgensen, M. Jokumsen, M. D. Jørgensen, N. W. Mølgaard, and H. B. Christensen, “An experience report on technical debt and its socio-technical root causes in a large industrial company,” ACM/IEEE International Conference on Technical Debt (TechDebt), 2026. [31] K. Z. Cui, M. Demirer, S. Jaffe, L. Musolff, S. Peng, and T. Salz, “The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers,” Management Science, 2026, articles in Advance. [32] F. Mu, L. Shi, S. Wang, Z. Yu, B. Zhang, C. Wang, S. Liu, and Q. Wang, “ClarifyGPT: A framework for enhancing LLM-based code generation via requirements clarification,” Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 2332–2354, 2024. [33] N. Tang, M. Chen, Z. Ning, A. Bansal, Y. Huang, C. McMillan, and T. J.J. Li, “Developer behaviors in validating and repairing LLM-generated code using IDE and eye tracking,” in 2024 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), 2024, pp. 40–46. [34] N. Nguyen and S. Nadi, “An empirical evaluation of GitHub Copilot’s code suggestions,” in Proceedings of the 19th International Conference on Mining Software Repositories (MSR). ACM, 2022, pp. 1–5. [35] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, “Asleep at the keyboard? Assessing the security of GitHub Copilot’s code contributions,” in 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 754–768. [36] N. Perry, M. Srivastava, D. Kumar, and D. Boneh, “Do users write more insecure code with AI assistants?” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2023, pp. 2785–2799. [37] M. Borg, D. Hewett, N. Hagatulah, N. Couderc, E. Söderberg, D. Graham, U. Kini, and D. Farley, “Echoes of AI: Investigating the downstream effects of AI assistants on software maintainability,” Empirical Software Engineering, vol. 31, no. 6, p. 161, 2026.

[38] S. Moreschini, E.-M. Arvanitou, E.-P. Kanidou, N. Nikolaidis, R. Su, A. Ampatzoglou, A. Chatzigeorgiou, and V. Lenarduzzi, “The evolution of technical debt from DevOps to generative AI: A multivocal literature review,” Journal of Systems and Software, vol. 231, p. 112599, 2026. [39] S. Gosu, D. Feitosa, and P. Avgeriou, “The use of generative AI in technical debt management: A systematic literature review,” Information and Software Technology, vol. 199, p. 108257, 2026. [40] A. A. Mujahid and M. M. Imran, ““TODO: Fix the mess Gemini created”: Towards understanding GenAI-induced self-admitted technical debt,” in Proceedings of the 2026 ACM/IEEE International Conference on Technical Debt (TechDebt). ACM, 2026. [41] Z. Brahmi, A. Ouni, M. Sayagh, and M. A. Saied, “Characterizing selfadmitted technical debt generated by AI coding agents,” in Proceedings of the 23rd International Conference on Mining Software Repositories (MSR 2026). Association for Computing Machinery, 2026, pp. 852– 856. [42] A. Fawzy, A. Tahir, and K. Blincoe, “Vibe coding in practice: Motivations, challenges, and a future outlook – a grey literature review,” in Proceedings of the IEEE/ACM 48th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP ’26). Rio de Janeiro, Brazil: ACM, 2026, pp. 212–223. [43] P. Avgeriou, I. Ozkaya, C. Jaspan, C. Green, N. Ernst, Z. Codabux, and H. Koziolek, “Technical debt in the AI era,” IEEE Software, vol. 43, no. 4, pp. 14–18, 2026. [44] Y. Kara, T. T. Temizel, Ö. Özcan-Top, and D. Kapiyasheva, “A hierarchical view of technical debt in GenAI-enabled software systems based on empirical analysis,” SSRN Preprint, 2026. [Online]. Available: https://ssrn.com/abstract=6496455 [45] A. Potdar and E. Shihab, “An exploratory study on self-admitted technical debt,” in 2014 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2014, pp. 91–100. [46] I. M. Bakke, V. Stray, and Y. Lindsjørn, “Reducing technical debt with generative AI: A case study of AI-assisted refactoring,” International

Workshop on AI for Technical Debt Management in Agile Software Development (AI4TD), XP 2026, 2026. [47] J. A. Maxwell and D. M. Loomis, “Mixed methods design: An alternative approach,” in Handbook of Mixed Methods in Social and Behavioral Research, A. Tashakkori and C. Teddlie, Eds. Sage, 2003, pp. 241–271. [48] N. V. Ivankova, J. W. Creswell, and S. L. Stick, “Using mixed-methods sequential explanatory design: From theory to practice,” Field Methods, vol. 18, no. 1, pp. 3–20, 2006. [49] V. Braun and V. Clarke, “Using thematic analysis in psychology,” Qualitative research in psychology, vol. 3, no. 2, pp. 77–101, 2006. [50] A. Melo, R. Fagundes, V. Lenarduzzi, and W. B. Santos, “Identification and measurement of requirements technical debt in software development: A systematic literature review,” Journal of Systems and Software, vol. 194, p. 111483, 2022. [51] E. d. S. Maldonado and E. Shihab, “Detecting and quantifying different types of self-admitted technical debt,” in 2015 IEEE 7Th international workshop on managing technical debt (MTD). IEEE, 2015, pp. 9–15. [52] G. Suryanarayana, G. Samarthyam, and T. Sharma, Refactoring for software design smells. Elsevier, 2014. [53] Google, “Use automatic captioning,” https://support.google.com/ youtube/answer/6373554, 2026, youTube Help. Accessed: October 2026. [54] Anthropic, “Claude opus 5.5,” https://platform.claude.com/docs/en/ models/opus-5-5/overview, 2026, claude Platform Docs. Accessed: October 2026. [55] S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of AI on developer productivity: Evidence from GitHub Copilot,” arXiv preprint arXiv:2302.06590, 2023. [56] T. Tavantzis, S. Lambiase, and D. Russo, “Out of place in my own work: How generative AI displaces software engineers,” in 20th International Symposium on Empirical Software Engineering and Measurement (ESEM 2026), ser. Leibniz International Proceedings in Informatics (LIPIcs), vol. 394. Schloss Dagstuhl–Leibniz-Zentrum für Informatik, 2026, pp. 9:1–9:20.

Related documents

• Technical Debt Risks in AI-Assisted Software Development: Insights from Practitioners#1658642
• Ten simple rules for effective use of generative AI for code development in environmental science#676220
• A Methodology for Investigating AI Patterns Prevalence in Software Repositories#329161
• How Do Software Engineering Students Use Generative AI in Real-World Capstone Projects? An Empirical Baseline Study#138991
• The AI Era's Lines of Code? A Case Study on What an Engineer's Token Spend Measures#1646500