Paper deep dive
The Psychological Costs of Artificial Intelligence Adoption in Software Engineering
Adam Alami, Elda Paja, Abhishek Tiwari
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 94%
Last extracted: 9/4/2026, 3:14:42 AM
Summary
This study investigates the psychological costs experienced by software professionals during organizational AI adoption. Through a case study of a large software development company, the authors identify five key costs: accountability anxiety, craft identity disruption, meaning and satisfaction erosion, cognitive and workload intensification, and uncertainty distress. The paper argues that AI adoption is a human transition requiring management of these psychological burdens, rather than just a technological implementation.
Entities (14)
Relation Signals (11)
Adam Alami â authored â The Psychological Costs of Artificial Intelligence Adoption in Software Engineering
confidence 99% · The Psychological Costs of Artificial Intelligence Adoption in Software Engineering ADAM ALAMI... Authorsâ addresses: Adam Alami
Elda Paja â authored â The Psychological Costs of Artificial Intelligence Adoption in Software Engineering
confidence 99% · ELDA PAJA... Authorsâ addresses: Elda Paja
Abhishek Tiwari â authored â The Psychological Costs of Artificial Intelligence Adoption in Software Engineering
confidence 99% · ABHISHEK TIWARI... Authorsâ addresses: Abhishek Tiwari
Artificial Intelligence â causes â Psychological Costs
confidence 95% · AI is a disruptive force... Historically, technological disruptions have caused psychological and social strains... we sought to understand the psychological costs software professionals experience
GitHub Copilot â isexampleof â Artificial Intelligence
confidence 95% · Recent advances in generative Artificial Intelligence (AI) have produced commercial products such as... GitHub Copilot
Software Professionals â experience â Uncertainty Distress
confidence 92% · We found that software professionals experience... and uncertainty distress.
Software Professionals â experience â Accountability Anxiety
confidence 92% · We found that software professionals experience accountability anxiety
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Artificial intelligence (AI) is increasingly used to augment software engineering (SE) workflows. While code generation remains the main use case, organizations are actively seeking AI integration in other practices such as test cases generation and code reviews. Organizational AI adoption strategies seem to focus on tangible outcomes such as productivity. However, AI is a disruptive force, introduced into settings where role identity, team norms, and the sources of job satisfaction were well established before the recent advances in generative AI. Historically, technological disruptions have caused psychological and social strains in workplaces, ranging from anxiety and eroded meaning to deskilling and disrupted professional identities. The assumption that AI for SE is cost-free may not be accurate. Therefore, in this study we sought to understand the psychological costs software professionals experience during organizational AI adoption. We carried out a case study in a large software development services company, one year after the company launched its AI adoption. We collected qualitative data through meetings and semi-structured interviews (N = 21). We found that software professionals experience accountability anxiety, craft identity disruption, meaning and satisfaction erosion, cognitive and workload intensification, and uncertainty distress. Practitioners manage these costs through practices that restore control, mitigate them through protective and identity-preserving adaptations, or absorb them, carrying what neither can resolve. We contribute to AI-human collaboration in SE by repositioning AI adoption as a human transition, not only a technological and organizational one.
Tags
Links
- Source: https://arxiv.org/abs/2609.03456v1
- Canonical: https://arxiv.org/abs/2609.03456v1
Trouble viewing inline? Open PDF directly â
Full Text
158,026 characters extracted from source content.
Expand or collapse full text
The Psychological Costs of Artificial Intelligence Adoption in Software Engineering ADAM ALAMI, University of Southern Denmark, Denmark ELDA PAJA, IT University of Copenhagen, Denmark ABHISHEK TIWARI, University of Southern Denmark, Denmark Artificial intelligence (AI) is increasingly used to augment software engineering (SE) workflows. While code generation remains the main use case, organizations are actively seeking AI integration in other practices such as test cases generation and code reviews. Organizational AI adoption strategies seem to focus on tangible outcomes such as productivity. However, AI is a disruptive force, introduced into settings where role identity, team norms, and the sources of job satisfaction were well established before the recent advances in generative AI. Historically, technological disruptions have caused psychological and social strains in workplaces, ranging from anxiety and eroded meaning to deskilling and disrupted professional identities. The assumption that AI for SE is cost-free may not be accurate. Therefore, in this study we sought to understand the psychological costs software professionals experience during organizational AI adoption. We carried out a case study in a large software development services company, one year after the company launched its AI adoption. We collected qualitative data through meetings and semi-structured interviews (N = 21). We found that software professionals experience accountability anxiety, craft identity disruption, meaning and satisfaction erosion, cognitive and workload intensification, and uncertainty distress. Practitioners manage these costs through practices that restore control, mitigate them through protective and identity-preserving adaptations, or absorb them, carrying what neither can resolve. We contribute to AI-human collaboration in SE by repositioning AI adoption as a human transition, not only a technological and organizational one. CCS Concepts:âą Software and its engineeringâ Programming teams. Additional Key Words and Phrases: Artificial Intelligence, Software Engineering, LLM-Assisted Software Engineering, Human-AI Collaboration, Human and Social Aspects of Software Engineering ACM Reference Format: Adam Alami, Elda Paja, and Abhishek Tiwari. 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering. 1, 1 (September 2026), 43 pages. https://doi.org/10.1145/n.n 1 INTRODUCTION Recent advances in generative Artificial Intelligence (AI) have produced commercial products such as Claude Code 1 , Codex 2 , and GitHub Copilot 3 , which perform software engineering (SE) tasks traditionally carried out by humans [25]. Although these tools are most visibly associated with code 1 https://claude.com/claude-code 2 https://openai.com/index/openai-codex/ 3 https://github.com/features/copilot/ Authorsâ addresses: Adam Alami, adal@cs.aau.dk, University of Southern Denmark, The Maersk Mc-Kinney Moller Institute, 6400, SĂžnderborg, Denmark; Elda Paja, elpa@itu.dk, IT University of Copenhagen, Rued Langgaards Vej 7, 2300 Copenhagen S, Denmark; Abhishek Tiwari, abti@mmmi.sdu.dk, University of Southern Denmark, The Maersk Mc-Kinney Moller Institute, Odense, Denmark. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. © 2026 Association for Computing Machinery. X-X/2026/9-ART $15.00 https://doi.org/10.1145/n.n , Vol. 1, No. 1, Article . Publication date: September 2026. arXiv:2609.03456v1 [cs.SE] 3 Sep 2026 2Alami, et al. generation, the Large Language Models (LLMs) underlying them are multi-task systems capable of supporting a broader range of SE activities, including those that have been traditionally entrusted to humans in a collaborative setting like code review [5,18]; for example, Claude Code had released a code review feature [8] 4 . The promise of productivity gains [50] across this widening span of tasks, amplified by intense industry discourse, is driving adoption in SE organizations [26,37]. For example, The Stack Overflow Developer Survey 2025 (49,000+respondents across 177 countries) reports that 84% of developers use or plan to use AI tools in their development process, up from 76% in 2024 [40]. according to the DORA report (âState of AI-assisted Software Development 2025â), t the organizational level âAI adoption has become nearly universal,â 90% of respondents use AI in their workflows and more than 80% claim âproductivityâ increase[17]. However, this technological shift is assumed to carry no or few costs. History has taught us that such assumptions rarely hold. When mechanization transformed coal mining in the 1950s, Trist and Bamforth documented not only productivity disruptions but psychological consequences for the miners, including anxiety, loss of meaning, and the breakdown of role identities tied to the previous way of working [44]. Bravermanâs analysis of automation argued that technologies introduced in the name of efficiency systematically degraded and deskilled the work of those who had mastered the displaced craft [15]. When computerization reached professional work, Zuboff showed that workers experienced the loss of action-centered skill as a crisis of competence and identity, even as the technology augmented what they could do [51], and Barleyâs study of computed tomography in radiology demonstrated that a new technology reorders expertise, status, and professional self-understanding, not merely tasks [12]. Across these historical episodes, the pattern is consistent: technological transitions that reconfigure how work is done impose adaptation burdens on those who perform the work, and these burdens are psychological as much as they are workflow-related. There is little reason to assume that AI adoption in SE will be different. These historical parallels motivate our investigation of whether AI adoption generates comparable psychological consequences for software practitioners. Early evidence on human-AI collaboration in SE suggests that many of the dynamics documented during previous technological transitions are already emerging in AI-assisted SE. AI appears to reshape how practitioners reason about responsibility, expertise, collaboration, and their own role in the development process. For example, Alami et al. reported that introducing LLM-assisted code review disrupts collective accountability by shifting responsibility to the individual instead of the collective level [5]. Subsequent studies further found that AI-generated reviews elicit different emotional, cognitive, and behavioural responses than reviews written by peers, altering how practitioners engage with feedback and collaborate during code review [2,4]. Studies of AI-assisted programming report that developers continuously negotiate trust in AI-generated code, devote substantial effort to verification, and remain concerned about maintaining understanding and control over generated artifacts despite productivity gains [11,45]. Collectively, these findings suggest that the adoption of generative AI introduces changes that extend beyond task execution to the psychological and social experiences of software development. While these studies demonstrate that AI adoption influences how software engineers collaborate, reason, and engage with their work, the evidence remains fragmented and largely detached from the organizational context in which adoption unfolds. Existing work explains the conditions shaping adoption, technology-related strain, and developer well-being, but not what practitioners psychologically incur as organizational AI adoption is enacted in software engineering practice. Therefore, we propose to investigate: 4 https://code.claude.com/docs/en/code-review , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering3 RQ: What psychological costs do software practitioners experience during organizational AI adoption, and how do they manage these costs? Drawing on the scope of psychological phenomena outlined by the American Psychological Association, encompassing cognitive, emotional, motivational, and social processes [7], and consistent with Lazarus and Folkmanâs view of âstressâ as arising when individuals appraise environmental demands as exceeding their resources [30], we define psychological costs as the adverse cognitive, emotional, motivational, and social experiences that practitioners incur during organizational AI adoption. The term reflects how practitioners appraise and make sense of changes to their work, as distinct from the technical or organizational outcomes of adoption. To answer our RQ, we carried out a single case study in a large Danish software development company one year into their AI adoption. We collected data through semi-structured interviews (n=21), member checking (n=12), and meetings (n=5), with various stakeholders; further methodological details in Sect. 3. In the studied case, AI adoption refers to the organizational introduction of commercial generative AI tools, coding assistants, agentic tools, and conversational LLMs, into software teamsâ workflows. Adoption was actively promoted. The organization deployed extensive internal messaging, designated practitioners as âAI ambassadorsâ to accelerate uptake, and set expectations through an âAI maturity modelâ against which practitioners assess their usage. We describe the adoption context in detail in Sect. 3. We found that, as AI adoption was enacted in software engineering practice, practitioners experienced recurring psychological costs that the organizationâs adoption strategy had neither anticipated nor addressed. Our analysis identified five distinct costs: accountability anxiety, craft identity disruption, meaning and satisfaction erosion, cognitive and workload intensification, and uncertainty distress. Organizational conditions, notably adoption pressure and governance ambiguity, amplify these costs. Practitioners manage them through practices and adaptations ranging from deliberate oversight and skill-preservation routines to the reframing of professional identity, and, where these fall short, resigned adaptation. Although we found little evidence that practitioners opposed AI adoption itself, we found that adoption created psychological costs. Variations in adoption primarily reflected compliance constraints, uneven applicability across roles and use cases, and tensions between experimentation and business-as-usual demands. Psychological costs therefore did not arise from resistance to AI; they emerged as practitioners attempted to integrate AI while preserving accountability, competence, professional agency, and meaning in their work. We contribute: - How AI adoption becomes psychologically costly when enacted in SE practice. Our contribution lies in explaining how psychological costs emerge as organizational AI adoption is enacted in SE. Our model (Fig. 4.1) connects technological characteristics and organizational conditions to changes in practitionersâ accountability, effort, identity, and meaning, and to the responses through which they accommodate these changes. This explanation provides a diagnostic framework for identifying where burdens originate, where organizational arrangements intensify them, and which aspects of engineering work may require intervention. -Repositioning AI adoption in SE as a human transition, not only as a technological and organizational one. The AI adoption literature in SE has largely examined adoption through drivers, barriers, usability, and productivity outcomes. Our findings show that adoption is also, and simultaneously, a psychological transition in which practitionersâ , Vol. 1, No. 1, Article . Publication date: September 2026. 4Alami, et al. competence, identity, and relationship to their work are renegotiated. Historical accounts of earlier workplace technology shifts corroborate this pattern, but the contribution is to the SE adoption literature: models of AI adoption that omit the psychological dimension are incomplete, because the costs we document, may potentially shape adoption strategies. - Surfacing the unaccounted costs of AI adoption for adopting organizations. Practically, our study shifts the question from âhow do we accelerate AI adoptionâ to âwhat does adoption cost practitioners, and which organizational conditions intensify that cost.â The amplifying conditions we identify, maturity-model pressure, efficiency expectations, and unresolved governance, are organizational choices and therefore actionable: organizations can clarify governance boundaries, decouple adoption expectations from individual measurement, and recognize verification work as legitimate effort. The costs rooted in the disruption itself cannot be prevented by better change management only, but they can be supported; the managerial buffering we observed indicates what such support looks like in practice. -Psychological costs cannot be reduced to resistance to AI. Psychological costs coexist with acceptance of AI; they are consequences practitioners manage while adopting the technology, not evidence that they resist adopting it. We show that psychological costs arise among practitioners irrespective of their level of AI adoption (see Tbl. 2, from exploratory to agentic use. Where adoption remained limited, this primarily reflected compliance constraints, uneven use-case applicability, and tensions with business-as-usual work rather than opposition to AI itself. In the remainder of this paper, we review related work in Sect. 2, then, we present methodological design in Sect. 3. In Sect. 4, we report the findings, discuss their implications in Sect. 5 and trustworthiness in Sect. 6, and conclude the paper in Sect. 8. 2 RELATED WORK The literature increasingly shows that generative AI does not simply automate SE. It redistributes engineering effort toward prompting, evaluation, correction, integration, and accountability. Yet most studies examine adoption at the individual level; not the assumptions built into organizational adoption strategies when those strategies encounter practice. We identified three streams of related works: AI adoption in SE, Technostress, and well-being in GenAI. 2.1 AI adoption in SE Russo [37] provides a central account of the complexity of generative-AI adoption in SE. Its importance lies in moving beyond a narrow performance framing; adoption depends on how practitioners evaluate usefulness and fit, but also on trust, facilitating conditions, organizational support, and the surrounding work system. This makes adoption a relational accomplishment between the technology, engineering practices, and organizational arrangements, not a simple decision to deploy a tool [37]. The multiple-case reported by Kemell et al. extends this organizational view [28]. The cross-case variation shows that organizations differ in maturity, constraints, objectives, risk tolerance, and implementation pathways. Such variation cautions against universal maturity models that imply a single linear route from experimentation to pervasive or agentic use [28]. Barke et al. show that programmers do not interact with code-generating systems in a single, stable mode [11]. Their work alternates between using AI for acceleration and using it as a source , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering5 of exploration, with substantial attention devoted to interpreting suggestions and maintaining task control. This finding undermines the idea that generated code simply replaces human production effort [11]. Zakharov et al. further show that developers attribute different roles to AI-powered development tools and that these role perceptions shape their adoption of the technology [49]. Whereas this work examines the roles practitioners assign to AI, we examine the corresponding changes practitioners experience in their own professional role and identity as AI assumes activities previously central to software production. Vaithilingam et al. identify an expectationâexperience gap; users may perceive value even when measured task outcomes do not show corresponding improvement [45]. This distinction is methodologically important. Perceived productivity is consequential, it shapes continued adoption, but it cannot be treated as equivalent to task performance, code quality, or organizational value [45]. Liang et al.âs large-scale survey found that a primary reason developers decline AI coding assistants is the feeling of losing control over their code, alongside frustration with output that does not meet functional or quality expectations [31]. Recent evidence sharpens the argument of the shift of SE towards verification. Fan et al. explicitly examine verification load and fatigue [19], while Vella and Blincoe describe a longitudinal shift from creation toward âsupervisory engineering workâ: directing, evaluating, and correcting AI output [46]. Fortes et al. similarly show that AI-assisted development may enhance perceived productivity by offloading routine work, while also disrupting cognitive engagement and introducing interaction and verification demands [20]. Together, these studies show that engineering effort is redistributed rather than displaced. We extend this evidence by explaining how verification becomes psychologically costly when practitioners must reconstruct sufficient understanding to remain accountable for AI-generated work. Existing research explains what shapes AI adoption and how developers use and experience AI. We extend this literature by examining organizational AI adoption from the standpoint of practitioners who enact it in software engineering practice. Our case study reveals what adoption demands from practitioners and how its consequences reshape their work, roles, and professional identities. Our conceptual lens repositions AI adoption from an uptake outcome to a human transition whose costs are carried by the practitioners who enact it in SE reality. 2.2 Technostress Technostress research examines stress created by technology-related demands such as overload, complexity, uncertainty, intrusion, insecurity, and continual change [9,34]. GenAI can operate simultaneously as a resource and a demand. It can reduce monotony, accelerate information access, support ideation, and increase perceived competence. The technostress tradition does not imply that technology is inherently stressful [42]. Stress emerges through the relationship between environmental demands, personal and collective resources, and appraisal [9,27,35,42]. The same GenAI capability may be experienced as a challenge that enables mastery, a hindrance that obstructs valued work, or a threat to competence, control, or employment. Classic technostress creators remain relevant but take new forms. Techno-overload appears when AI increases expected throughput or creates more output to inspect. Techno-complexity concerns the expertise required to prompt, evaluate, integrate, and govern probabilistic outputs. Techno-uncertainty [9,42] intensifies because models, interfaces, compliance, and capabilities change rapidly. Techno-insecurity [35] includes fears of replacement, devaluation, or falling behind. Techno-invasion [9,35] arises when continuous learning and experimentation extend beyond ordinary work boundaries. More recently, Kwon et al. identified seven AI-induced technostressors , Vol. 1, No. 1, Article . Publication date: September 2026. 6Alami, et al. across professional settings and documented the coping strategies professionals use in response [29]. This work demonstrates that AI introduces stressors and coping needs beyond established technostress categories; however, it remains occupation-general and organizes the phenomenon around stressors and coping, rather than examining how organizational adoption reshapes the accountability, agency, identity, and meaning attached to software engineering work. Our construct of psychological costs builds on both established technostress research and emerging work on AI-induced stressors and coping, but differs in its analytical focus. Technostress primarily explains how technology-related demands are appraised and translated into strain. Psychological costs instead capture what practitioners expend, lose, or place at risk while adapting to AI-mediated changes in their SE work. In the context of SE, these costs include not only stress arising from technological demands, but also intensified verification effort, accountability anxiety, displaced professional agency, disrupted craft identity, and eroded meaning. They may therefore arise across levels of AI adoption, from exploratory to agentic use, and coexist with acceptance, enthusiasm, and perceived productivity benefits. Technostress is intentionally technology, and occupation-general; it explains demands that can arise across users, technologies, and work settings. Our conceptual lens is deliberately specific to SE. Generative AI does not merely introduce another demanding technology into software work; it assumes activities through which practitioners exercise expertise, authorship, and professional agency. AI is potentially disruptive not only to work processes but also to professional identity. Psychological costs therefore explain what software practitioners expend, lose, or struggle to preserve as AI participates in producing the artifacts for which they remain professionally responsible. Although there are conceptual parallels between our findings and technostress, our contribution lies in explaining how AI technology, engineering obligations, and organizational adoption conditions interact to produce psychological costs in SE, providing a basis for identifying where organizational intervention may be directed (see Sect. 5 for further discussion). 2.3 Well-being in GenAI in SE Era Well-being research provides a broader lens than technostress for examining how GenAI affects practitioners. Workplace well-being encompasses not only the absence of strain, but also positive functioning, satisfaction, engagement, autonomy, competence, relatedness, professional growth, and meaningful work [10,38,39]. This distinction is important because practitioners may avoid stress while still experiencing a loss of agency, professional fulfillment, or connection to their work. Emerging SE research questions the fieldâs dominant emphasis on whether GenAI improves developer productivity. Guizani et al. argue that this narrow framing can conceal consequences for developersâ cognitive load, stress, burnout, workâlife balance, and professional development [21]. They call for GenAI research to evaluate sustainable productivity; whether productivity gains can be maintained without undermining the people responsible for producing and assuring software. Brandebusemeyer et al. provide empirical support for moving beyond productivity assessment [14]. Their mixed-methods field study shows that developers generally value GenAI for monotonous, repetitive, and structured tasks and perceive improvements in efficiency and workload. However, these benefits depend on the task, interaction mode, and quality of the generated output. AI interaction can itself create cognitive load, while combining code suggestions and chat-based interaction within the same task may diminish their benefits. Developer experience is therefore shaped not simply by whether GenAI is used, but by how its capabilities fit the work being performed [14]. These studies establish GenAI as a potential resource and a potential demand in SE. It may reduce repetitive effort, overcome task blockages, and improve satisfaction. At the same time, it can introduce oversight labor, verification fatigue, continuous-learning pressure, and escalating , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering7 expectations regarding output and pace [14,21]. Productivity gains and well-being gains must therefore be examined as related but distinct outcomes. These streams of work explain important but separate parts of the phenomenon. AI-adoption research identifies the conditions shaping uptake and use; technostress explains how technology- related demands become strain; and well-being research evaluates whether AI-supported work remains psychologically sustainable. What remains insufficiently explained is what software practitioners incur as an organizational adoption strategy is enacted through SE practice. Therefore, psychological costs identify the intensified effort, accountability anxiety, disrupted agency, threatened craft identity, and erosion of meaning that AI adoption may produce. These costs may remain concealed when adoption is evaluated through usage, acceptance, or productivity, even when developers remain satisfied with GenAI and recognize its benefits. Our contribution is therefore not another account of whether developers accept AI or whether AI impacts negatively or positively their well-being, but an explanation of what organizational AI adoption demands from software practitioners, why those demands arise in SE work, and how practitioners carry them. 3 METHODS We adopted a holistic single case study design [48]. The case is a large Danish software development company, approximately one year into an organization-wide AI adoption at the time of the study. Our rationale for a single case design follows Yinâs âcommon caseâ logic [48]; the objective is to capture the circumstances and conditions of an everyday situation, here, an organization undergoing AI adoption, because of the insights it can provide into the phenomenon as it unfolds across the software industry. The case also offered a unique empirical access; the organization permitted inquiry into the lived experience of its practitioners during, rather than after, the transition, allowing us to study psychological costs and practitionersâ responses as they were being experienced and formed, not retrospectively reconstructed [48]. The single case serves to develop and ground constructs and mechanisms that can be examined in other settings, consistent with case study research traditions [36, 48]. 3.1 Case Selection and Recruitment The case was recruited through AI4SE 5 , a Danish research project on AI adoption in SE, in which several companies partner with the University of Southern Denmark (SDU) and other research institutions. Recruitment occurred during the formation of the project consortium. This constellation aligned the interests of both parties; the organization sought insights into its adoption effort, while our objective was to study the practitioner experience of AI adoption as it unfolds. The company joined the project, in part, to gain knowledge from the experiences of other consortium participants and contributes with its own experience. 3.2 Case Description The case, hereafter SoftHouse (a pseudonym), is a large, long-established Danish software development company. SoftHouse develops, maintains, and continuously evolves software products for critical and highly regulated domains, alongside offering bespoke software development services. Several of its products are well-established systems underpinning services in public health, government administration, and taxation; some have been in operation for over two decades and undergo continuous modernization efforts. The companyâs products are operating in over 50 countries. The company also continuously seeks to expand into new domains, such as asset and 5 https://portal.findresearcher.sdu.dk/da/projects/human-centered-adoption-of-artificial-intelligence-for-software-e/ , Vol. 1, No. 1, Article . Publication date: September 2026. 8Alami, et al. public infrastructure security. Development effort is typically concentrated on evolving existing products; implementing new features upon customer requests, or innovating products in response to market demands and shifts. SoftHouse operates in markets where reliability, security, and regulatory compliance are contractual and legal obligations rather than aspirations; its customers include public institutions and private organizations for whom software failure carries safety, legal, or societal consequences. This positioning shapes SoftHouseâs engineering culture; quality assurance, traceability, and accountability for delivered software are deeply institutionalized, enforced through a multi-layered compliance regime combining external legislation governing data, certifications governing process maturity, and internal audits governing output conformance. Organizationally, SoftHouse is structured into âbusiness units,â each specialized in a specific business domain (e.g., health, taxation). Each business unit is, in turn, organized into projects mandated to deliver specific scopes, ranging from feature development on existing products to the development of entirely new products. SoftHouseâs workforce comprises 1,200 employees, the majority of whom are software practitioners; software engineers (50% of its workforce), testers and test managers, architects, product owners, project managers, and technical leads. SoftHouse is also a proud agile organization. It rolled out Scrum across its development over two decades ago, and agile ways of working are deeply embedded in how teams plan, deliver, and collaborate. The AI adoption examined in this study thus entered an organization with mature, long-institutionalized development practices and a strong sense of how software should be built. AI Adoption and Its Context. SoftHouse launched an organization-wide AI adoption initiative in January 2025, approximately one year before our study started. The initiative introduced commercial generative AI tools into practitionersâ workflows. The first product rolled out at the enterprise level was GitHub Copilot, which was abandoned three months later due to what the organization described as âquality issues;â software engineers reported âcode quality issuesâ and an âoverall dissatisfaction with the product.â It was replaced by Claude Code and Claude Desktop. The adoption was supported rather than prescribed. The integration of AI into SE workflows was not mandated; projects were encouraged to experiment and share what they learned, locally and at the enterprise level. SoftHouse established a dedicated AI program with enterprise-wide oversight of the adoption, led by an appointed program director. Each project was assigned AI ambassador, practitioners whose role was to promote AI adoption and facilitate knowledge sharing within and across projects. However, individuals assigned to these roles did not necessarily have prior experience with AI or its adoption into SE. The organization further set up a dedicated knowledge hub to consolidate and disseminate learning, and deployed extensive internal messaging; participants described AI as a recurring subject of company briefings and meetings. It also introduced an AI maturity model defining levels (i.e., 1â5, novice to agentic-AI) of AI-assisted practice, from novice use to advanced agentic use, against which practitioners assess their own usage, with organizational ambitions for practitioners to reach the upper levels. At the time of the study, the internal governance of AI use was still taking form. Rules governed data classification, online access, and the delegation of credentials to agentic tools, while a comprehensive internal AI policy remained under development. Permitted AI use also varied across projects, as customer and domain requirements imposed constraints in some engagements; for example, prohibition of commercial cloud-based tools in some clientâs projects. Practitioners therefore encountered the adoption under heterogeneous conditions; organizationally championed and infrastructurally supported, yet not prescribed, and bounded by evolving internal rules and project-specific restrictions, either driven by domain-specific compliance or customerâs requirements on how to use AI. One year in, the initiative had not met the organizationâs original , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering9 expectations, i.e., âachieving 50% adoption rate among software engineers,â prompting SoftHouse to seek avenues to reinvigorate its adoption strategy, including its participation in the research project through which this study was conducted. Experiment-and-Share as an AI Adoption Strategy. SoftHouse did not define or prescribe how AI should be integrated into SE workflows, instead, they pursued what we characterize as an experiment-and-share strategy; practitioners and projects were encouraged to experiment with AI within their respective compliance boundaries, build competence through use, and share what they learned, locally within projects and across the enterprise. A senior manager (Tbl. 2 documents our sample) described the approach as deliberately phased: âwe throughout phases has been trying to both experiment, to build competence, to also assess maturityâ (P13). The AI maturity model served as the assessment instrument within this strategy, while the AI accelerators and the knowledge hub constituted its diffusion mechanisms; experimentation was expected to happen within projects, and its lessons to be consolidated centrally and shared across the enterprise. In some settings, this took organized forms; participants described working groups tasked with determining âhow do we actually do this, how are we going to work going forward with these toolsâ (P14). Two considerations underpinned this strategy. First, the heterogeneity of SoftHouseâs compliance landscape made uniform prescription impractical; what is permitted varies by domain, customer, and product, and the organization must remain, in P13âs words, âvery specific on where do we apply and how much are we allowed to apply in these different domainsâ (P13). In the most sensitive domains, AI use is categorically restricted or confined to isolated configurations, such as locally hosted models. Second, the strategy reflected a leadership stance that combined conviction about AIâs gains with a commitment to human oversight: âwe very much believe in keeping humans in the loop ... but on the other hand we really also foresee that there is productivity and efficiency gains with the use of AIâ (P13). Expected gains were also tied to the organizationâs growth trajectory; leadership anticipated that AI-enabled productivity would allow the organization to scale differently than in the past. The strategy, however, operated within a field of competing external expectations. While compliance obligations demanded restraint, customers, partners, and competitors pressed for speed; P13 described the resulting position: âwe need to be aligned with compliance and security, but on the other hand we have competitors, we have customers, we have partners saying, well, why donât you guys just give it full speedâ (P13). The experiment-and-share strategy was, in this sense, the organizationâs mechanism for advancing adoption under conditions in which neither mandating nor prohibiting AI use was available to it. The interviewsâ data show mixed results. From an adoption perspective, some practitioners achieved agentic level adoption (e.g., P7 and P14). Others (e.g., P19) met rigid compliance requirements, allowing them to use only locally hosted models; the experiment failed due to âlimited computation powerâ (P19). Knowledge sharing also experienced mixed results. However, where adoption remained limited seems to be primarily a reflection of compliance constraints, uneven use-case applicability, and tensions with business-as-usual work rather than opposition to AI itself (see sect. 4). Knowledge sharing also experienced mixed results. Where sharing was locally scaffolded, it functioned; participants described front runners mentoring colleagues through team-level adoption (P16), and the accelerators relaying use cases and reassurance across projects (P11). Elsewhere, the strategyâs sharing premise met friction of three kinds. First, what was shared did not always transfer across roles; as a test engineer explained, âthe ones[experiments] that were shared across a lot of us werenât really relevant for my roleâ (P10), leaving practitioners outside the development track without usable guidance. Second, sharing was socially costly; some practitioners withheld , Vol. 1, No. 1, Article . Publication date: September 2026. 10Alami, et al. Jan. 2026Feb. 2026Mar. 2026 Aug. 2026 May 2026 Initial meeting CIO, CTO & AI program director: background and context understanding 20 th of Jan. 2026 Participant recruitment Study communicated via AI program director; 20 practitioners volunteered, plus the AI Program Director N=21 Semi-structured interviews Interviews with the 20 participants Context understanding: four meetings with the AI program director, between Jan. and end Feb. 2026 Member checking: feedback meetings with participants Data analysis Commenced in March and completed in May 2026 Data analysis completed May 2026 Fig. 3.1. Chronological overview of the data collection and analysis process (January 2026âAugust 2026). their experiences for fear of judgment, perceiving a high barrier to exposing their AI practices to colleagues (P1). Third, governance ambiguity suppressed sharing at its source; practitioners hesitated to disclose experiments conducted in unclear regulatory territory, âI am very hesitant at sharing thisâ (P14), precisely the experiences the strategy depended on circulating. The strategyâs central premise, that locally discovered lessons would be shared, thus held unevenly; knowledge flowed where roles were similar, psychological safety was sufficient, and permissibility was clear, and stalled where any of the three was absent. 3.3 Participants and Data Collection Table 1. Overview of stakeholder meetings held for background and context understanding. ID Meetingâs purposeAttendeesDateDuration M1Background and context understandingCTO, CIO, and AI program directorJan. 2026One hour M2AI adoption program details (follow-up 1)AI program directorJan. 202630 mins M3AI adoption program details (follow-up 2)AI program directorFeb. 202630 mins M4Adoption progress: further details (follow-up 3)AI program directorFeb. 202630 mins M5Adoption progress: further details (follow-up 4)AI program directorFeb. 202630 mins We collected data through two complementary means; Fig. 3.1 documents the data collections and analysis timeline. First, to build an understanding of the adoption context, we held meetings with key stakeholders, including the AI program director and other senior managers. These meetings informed our reconstruction of the adoptionâs history, structure, and governance (Sect. 3.2) and were documented through audio recording and transcription. Second, to capture practitionersâ experiences of the adoption, we conducted semi-structured interviews with practitioners across roles (Tbl. 2). Participants were recruited through the AI program director. She approached project managers, communicated the study and its intent, and relayed our call for participants; twenty one practitioners volunteered to participate, including the AI program director. The participants were known to the AI program director and first author. Although managers communicated the recruitment, practitioners , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering11 were asked to contact the AI program director directly. Therefore, participants are anonymous to the organization except the AI program director and the first author. We sought a population representative of the organizationâs practitioner composition across roles and experience levels. Our sample reflects this diversity; half of the participants are software engineers, with the remainder spanning testing, project management, architecture, and technical leadership roles. Table 2 documents the participants, their roles, and tenure. Participation was voluntary, and participants were assured anonymity toward both the research audience and their own organization; no information on who participated, declined, or withdrew was shared back to the organization. The data collected was not shared with any party in the organization; only the final results (see Sect. 3.8). The resulting sample reflects the practitioner composition of SoftHouseâs delivery organization. Almost half of the participants (10/21) are software engineers spanning seniority levels from junior to lead, complemented by architects (3), testing roles (3), senior program managers (2), AI program director, and heads of business units (2), providing perspectives from both the practitioner and delivery-leadership levels. The sample comprises five women and sixteen men. Participantsâ tenure at SoftHouse ranges from 1 to 23 years (median 9.5), predominantly with practitioners socialized into the organizationâs engineering practices long before the AI adoption. Their professional experience in the software industry ranges from two to 40 years (median 20); nineteen of the 21 participants have a decade or more in the industry, meaning the sample is dominated by practitioners whose professional identities and skills were formed well before the emergence of generative AI, the population for whom the transition under study carries the highest stakes (see Sect. 6 for threats to validity discussion). All interviews were conducted online using MS Teams or in person and in English. All meetings and interviews were audio recorded, then transcribed. Interviews lasted on average 50 minutes. Although we designed an interview guide, its purpose was to steer the conversation while allowing fluidity, prompting interviewees to elaborate based on their responses. Table 3 documents key parts of the interview guide. The interviews generated approximately 290 pages (in average, 14 pages each) of transcription and 17 hours and 40 minutes of audio. Table 1 documents our meetings. Data collection, including transcriptions and managing the relationship with SoftHouse were carried out by the first author. 3.4 Confidentiality and Access Constraints The case study was carried out under a confidentiality agreement. The company requested full anonymity, including the non-disclosure of its name, precise geographical location, identifiable business units, and specific operational details that could enable indirect identification. To preserve confidentiality, contextual descriptions were deliberately reduced; only analytically relevant characteristics are retained. The company permitted the use of anonymized interview and meeting quotations. Quotations were therefore edited for ensuring anonymity, without altering meaning. Identifiers such as proprietary system names, internal terminology, business unit names, or references to specific brands, products, or partners were removed or generalized. 3.5 Data Analysis We analyzed the interview transcripts inductively as soon as they became available, following Miles et al. [32] guidelines. Accordingly, we conducted a First Cycle analysis, in which we selected âchunksâ of data pertinent to our RQ and assigned them codes [32]. Coding proceeded interview by interview, and codes were written in descriptive, participant-grounded language, staying close to , Vol. 1, No. 1, Article . Publication date: September 2026. 12Alami, et al. Table 2. Interview participants. âMâ refers to man and âWâ to woman. âSEâ refers to Software Engineers, âBUâ to Business Unit, and âPMâ to Program Manager. âTenureâ refers to years in SoftHouse at the time the AI adoption was initiated; âExp.â refers to total years of professional experience in the software industry. (*) indicates participants who took part of member checking. IDRoleTenure Exp. AI ToolsSE ActivitiesAdoption Level a P1(W)Test Manager 1025Claude DesktopTesting, test managementIA P2(M)Senior SE510Claude CodeCoding, code reviewDO P3(M)Senior SE1020Claude CodeCoding, testing, requirements tracing AG P4(M) Lead Architect 1040Claude DesktopTest design, requirements & release documentation IA P5(M) Lead Architect 1025 Claude Desktop, Claude Code Architecture,adoption facilitation DO P6(M)(*)Lead SE715Claude CodeProcess automationIA P7(M)(*)Lead SE1012Claude Code, CodeScene Coding, architecture, code review AG P8(W)(*)Head of BU826Claude DesktopContent generationIA P9(M)(*) Test Engineer 716Claude Desktop, Claude Code Testing,process experimentation DO P10(W)Test Engineer 510 Claude Desktop, Claude Code TestingIA P11(M)Senior PM1240 Claude Desktop, Claude Code Projectmanagement, documentation IA P12(M)(*)Senior SE310Local LLM, Claude CodeCoding, code review, scriptingCF P13(M)(*)Head of BU2335Claude DesktopDocuments generationIA P14(M)(*)SE1212ClaudeCode,custom agents Coding, debugging, testing, agent development AG P15(W)(*) Senior PM530Claude DesktopDocument generationIA P16(M)(*)Senior SE1014 Claude Desktop, Claude Code Coding, code review, team leadership IA P17(M) Principal Architect 1030Claude Desktop Architecture,prototyping, documentation DO P18(M)(*)Lead SE920Claude Code Coding,performance optimization, code analysis DO P19(M)Lead SE830Claude CodePlatform engineering, coding, code review EX P20(M)(*)Junior SE12Claude CodeFull-stack coding, prototypingIA P21(W)(*)AI Program Director 1235Claude DesktopDocument generationIA a Adoption levels, as described in the interviews: IA = integrated assisted use (routine assistance inside daily work, such as completion, drafting, and structured prompting; the practitioner still authors most output); DO = delegated use with human oversight (substantial tasks handed to AI tools, governed by plan review, and verification practices); AG = agentic with human-in-the-loop (automated multi-step workflows with human gates); EX = Exploratory, but constrained, adoption is reduced by compliance, and client requirements. participantsâ own wording; in-vivo codes were retained where participantsâ phrasing captured the phenomenon directly. The first author carried out the first iteration of analysis. In the Second Cycle that followed, we synthesized the First Cycle codes into âPattern Codesâ [32]. In this integrative activity, we identified patterns across the earlier cycle codes by recognizing recurring themes that linked different codes together, whether through similarity or complementary contributions to a cohesive construct [32]. Each First Cycle code was mapped to the subtheme it evidences, and we documented this mapping, including the analytical decisions it required. Through this process, the Pattern Codes progressively organized into the structure that frames our findings (see Fig. 4.1); the sources of psychological costs, the organizational conditions surrounding , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering13 Table 3. Key parts of the interview guide relevant to this studyâs RQ. Introduction Can you please introduce yourself ? (Include educational background, current role in the company, and years of experience in software development.) How did you experience AI adoption at SoftHouse? How did you become involved with AI in your work? What were your initial perceptions when the AI adoption was introduced? Section I: Experiencing the AI adoption Can you take me through how you use AI in your workflows today? How did your usage evolve since the adoption started? How do you feel about this change to your work and your role? How are you copping with the change, whether technical or non-technical? Do you have any concerns related to AI in your work? (Probed across levels: personal, professional, and product/deliverable.) Probing questions: Probing focused on the felt experience behind reported practices and concerns. Examples: What is behind that concern? Is it about the quality of your work, your professional reputation, or your job? How did that make you feel? How do you experience being responsible for code you did not write yourself How do others around you (colleagues, your team) experience this change? How this particular concern arise? For example, is it your own feelings, your peersâ judgment, or how the organization does things? Section I: Navigating the adoption How do you stay in control of what the AI produces? How do you avoid becoming complacent? How do you manage within the constraints that apply to your project (e.g., security, compliance, client restrictions)? Have concerns like these been raised with you, or by you, in your team? How were they addressed? Probing questions: Probing focused on concrete practices, their rationale, and their perceived effectiveness. Examples: Can you walk me through how you review or verify AI output? Why do you do it that way? What would happen if you did not? Do you do anything to maintain your own skills? To what extent do these practices resolve the concern for you? Conclusion Based on your experience of this AI adoption, how would you summarize the main takeaways? Is there anything else you would like to share about your experience? the adoption, the psychological costs practitioners experience, and the responses through which they manage them (Sect. 4). This structure was an analytical outcome of the Second Cycle rather than a framework imposed on it; the layers emerged as we examined how Pattern Codes related to one another, particularly the recurring distinction in the data between conditions that produce experiences and conditions that intensify them. Table 4 documents examples of our analysis outcome. Once we finalized the list of Pattern Codes, we sought to identify the relationships among them. Through an iterative process of comparison, we revisited the coded data to examine how Pattern Codes interacted, co-occurred, and formed broader explanatory relationships. Consistent with Miles et al.âs conclusion drawing and verification activities, we iteratively examined alternative interpretations of the relationships among Pattern Codes and revisited the original interview excerpts to ensure that the emerging model remained empirically grounded [32]. This process revealed that the Pattern Codes did not represent independent themes but rather different components of a coherent process. Specifically, participants consistently described how , Vol. 1, No. 1, Article . Publication date: September 2026. 14Alami, et al. Table 4. Examples of pattern codes, their sub-themes, and supporting evidence from the data Pattern codes Sub-themesSupporting evidence from the data AI Disruption Fast Pace & Emerging Technology âwe cannot catch upâ (P15). âWe dealing with an emerging technology which is moving very fast. So, we have to continue learningâ (P1). Organizational AI Adoption Perceived adoption pressureâevery meeting is about AI ... I canât remember a company briefing or anything that was not about AIâ (P12). Governance ambiguity âitâs[compliance obligation] clashing with what the organization want us to doâ (P19). Psychological Costs Craft identity disruptionâI did not go to university to do thisâ (P11). Meaning and satisfaction erosion âthe scare for your job to become really boring, so that instead of building and creating stuff you are basically reviewing stuff, which nobody likesâ (P1). Accountability anxietyâif we werenât responsible for the code it produced, it would be a lot fasterâ (P19). Responses ManageâI code without AI often to maintain my skillsâ (P3). Mitigate âwe strip a lot of the data and ... feed it very little and use it like a more or less more advanced Google searchâ (P12). characteristics of AI disruption and organizational AI adoption created conditions that gave rise to psychological costs, while simultaneously describing a range of responses through which they sought to manage, mitigate, or absorb these costs. We progressively refined these relationships into the conceptual model shown in Fig. 4.1. The first author led the analysis effort, and the second author reviewed the coding and provided feedback. 3.6 Unit of Analysis The unit of analysis in this study is practitionerâs experience of the organizational AI adoption, bounded within one organization. The adoption initiative provides the case boundary. This definition allowed us to examine how software practitioners experience AI adoption in SE practices and workflows within a specific organizational context. This choice aligns directly with our research question, which seeks to understand the psychological costs practitioners experience and the practices through which they manage them. While the organizational AI adoption initiative constitutes the case boundary, it serves as the contextual setting rather than the object of analysis. Defining the unit of analysis at the practitioner level enabled us to examine how individuals interpreted, experienced, and responded to AI adoption while accounting for the shared organizational conditions within which these experiences were situated. 3.7 Saturation We sought meaning saturation, because our goal was explanatory understanding rather than simply cataloging codes [22]. We monitored saturation throughout the analysis by iteratively comparing newly analyzed interviews with the evolving Pattern Codes and their meanings, and underlying supporting evidence [6,33]. We assessed whether additional interviews contributed substantively with new insights into the emerging sub-themes, Pattern Codes, or the relationships between them [22]. As analysis progressed, subsequent interviews consistently reinforced and elaborated the existing conceptual structure without requiring new Pattern Codes or revisions to the emerging model (see Fig. 4.1). At that point, we concluded that sufficient analytical depth had been achieved for , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering15 Table 5. Examples of empirical evidence supporting the relationships in the conceptual model. RelationshipVerbRepresentative empirical evidence AI Disruptionâ Organizational AI AdoptionShapesParticipants described organizational AI adoption as reflecting the pace and discourse of the broader AI disruption. Examples included AI maturity targets mirroring industry narratives (P15), pervasive organizational AI messaging (P12), and governance struggling to keep pace with rapidly evolving technologies (P15, P19). AI Disruptionâ Psychological CostsGives rise to Participants reported psychological costs directly associated with AI itself, including identity disruption (P11), job-loss anxiety (P1), loss of authorship, reduced flow, and concerns over deteriorating understanding of their code (e.g., P6, P18 & P19). Organizational AI Adoptionâ Psychological Costs Amplifies Organizational AI adoption strategy intensified existing concerns through adoption pressure, productivity expectations, governance ambiguity, and conflicting organizational messages regarding AI use (P12, P19). Psychological Costsâ ResponsesElicit Practitioners described adaptive responses tailored to specific costs, including oversight and verification practices to manage accountability (P19), deliberate manual coding to preserve skills (P3), identity reframing toward software delivery rather than coding (P10), and conservative AI use under governance uncertainty (P12). AccountabilityanxietyâCognitiveload intensification Translates into Tomeettheiraccountabilityexpectations, practitioners became invested in verification labor; reviewing AI output line by line because they remain answerable for it (P12), analyzing generated solutions before standing behind them (P2), and applying heightened scrutiny to AI-authored contributions in peer review (P16). The mechanism was stated directly; absent responsibility for the produced code, the work âwould be a lot fasterâ (P19). Note. The relational verbs reflect participantsâ accounts and the patterns identified in the qualitative analysis; they are intended to preserve the explanatory meaning of the empirical data. They do not imply causal inference or causal effects and should be interpreted within the qualitative design of the study. the purposes of this study. Although all participants had been recruited before data collection commenced, we remained open to further recruitment had subsequent analysis revealed important conceptual gaps or insufficient development of the emerging findings. Meaning saturation was not reached uniformly across the analytical categories. By the twelfth analyzed interview, all Pattern Codes except those concerning psychological costs were stable in their meanings and relationships. The psychological cost pattern gained conceptual depth and saturation at the eighteenth interview. Interviews analyzed after each respective saturation point (12 (all Pattern Codes) and 18 (Psychological Costs)) provided additional supporting evidence but did not alter the Pattern Codes or their relationships within the model. , Vol. 1, No. 1, Article . Publication date: September 2026. 16Alami, et al. 3.8 Member Checking We carried out member checking [13] interviews with participants. We emailed all informants who participated in the interviews, and twelve accepted to provide feedback (marked with (*) in Tbl. 2). Prior to the interviews, participant received a 15-page report documenting the findings of this paper and other insights related to the organizationâs AI adoption strategy. The report served as pre-reading for the interviews. During the member checking interviews, we asked participants to comments on all reported findings. Participants were asked to read the complete report before attending an individual member- checking interview. Using a semi-structured protocol, we discussed all findings in the report, including each psychological cost and the relationships represented in the conceptual model. For each finding, participants were asked whether it reflected their experience, whether any interpretation appeared inaccurate or overstated, and whether relevant experiences were missing. Feedback was provided orally during the interviews, audio recorded and transcribed. Participants generally regarded the findings relatable and consistent with their experiences. Their feedback did not require changes to our interpretations, new Pattern Codes or changes to the modelâs relationships, but it provided us with additional explanatory material. Table 6 documents a few examples of the feedback we received in these interviews. Table 6. Examples of comments from member checking interviews Participant Feedback P6âI like how these psychological costs validate my experienceâ (P6). P7âI agree largely with what has been said in the reportâ (P7). P12âSome of your findings have been talked about in the corridors and during lunches, but we never openly confronted themâ (P12). P20âSome of the findings were expected, the report crystallizes them wellâ (P20). 4 FINDINGS Our findings show that organizational AI adoption is experienced as more than the introduction of a new technology. Rather, participants experienced AI as a disruptive force that reshapes how they perceive their work, their professional identity, responsibilities, and their future within software engineering. Across the interviews, practitioners consistently articulated a set of psychological costs that emerged not only from adopting AI tools in their workflows, but also from the broader organizational AI adoption through which this technology is introduced and when AI is enacted in SE practice. Participants described how characteristics of AI, including its rapid technological evolution, role-altering capability, and unknown risks, shapes how organizational AI adoption takes form, setting its tempo, its expectations, and its ambiguities. Both forces then converge on the practitioner, but not symmetrically. The disruption itself gives rise to a set of psychological costs, while the organizational adoption context amplifies them. These costs, in turn, elicited a range of responses through which practitioners sought to manage, mitigate, or absorb their psychological impact. Figure 4.1 presents the conceptual model that emerged from the analysis and serves as the organizing framework for the remainder of this section. It illustrates how AI characteristics (e.g., evolutionary, unknown risks) give rise to distinct psychological costs and how practitioners respond through adaptive practices. The conceptual model in Figure 4.1 is presented as an integrated explanation of practitionersâ experiences. To make the underlying mechanisms analytically transparent, the following sections examine each psychological cost individually, tracing how , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering17 sdu.dk #sdudk The Maersk Mc-Kinney Moller Institute The Maersk Mc-Kinney Moller Institute AI Disruption Organizational AI Adoption Psychological Costs Response Accountability anxiety Craft identity disruption Meaning and satisfaction erosion Uncertainty distress Cognitive load intensification Fast Pace & Emerging Technology Unknown Risks Perceived Adoption Pressure Governance Ambiguity Epistemic Uncertainty Pre-existing standards Mitigate Manage Absorb amplifies gives rise to elicit shapes Role-altering capability Translates into Fig. 4.1. Conceptual Model of Psychological Costs of AI Adoption for Software Practitioners. specific characteristics of AI disruption give rise to that cost, how organizational AI adoption amplifies it, and how practitioners respond. These analyses reconstruct the integrated model presented in Fig. 4.1. 4.1 Uncertainty Distress Our participants described AI not as another software engineering tool, but as the beginning of a technological shift whose trajectory was difficult to comprehend. Unlike previous technological changes that could be evaluated against established engineering practices, AI was perceived as moving too quickly, carrying uncertain implications for software work, and accompanied by widespread societal narratives about its transformative potential, e.g., âwe are working with technology that is moving just as fast as AI models areâ (P19). Participants described struggling to keep pace with a technology that appeared to change faster than they could develop stable working practices. For example, new modelsâ capabilities, and features emerged continuously, making it difficult to determine whether todayâs learning efforts would remain valuable tomorrow. P4 explained: âI need some more hours in trying to keep up with Claude and what is happening, because a lot of things is happening. New models are coming out, new versions of the model ... I try to use some of the free time I get to try to keep up with the AI technology, because itâs really moving fastâ (P4). P2 highlighted the implications of this rapid technological evolution: âexperiment and tell us what you think would be no longer a valid strategy nowâ (P2); implying that the organizational adoption strategy of âexperiment-and-shareâ is not sustainable when the technology is a moving target. This characteristic of AI may suggest that our participants experienced AI adoption in an environment where knowledge becomes perishable. Unlike previous software technologies, where , Vol. 1, No. 1, Article . Publication date: September 2026. 18Alami, et al. sdu.dk #sdudk The Maersk Mc-Kinney Moller Institute The Maersk Mc-Kinney Moller Institute AI Disruption Organizational AI Adoption Psychological Costs Uncertainty distress Fast Technological Pace Epistemic Uncertainty amplifies gives rise to shapes Perceived Adoption Pressure Fig. 4.2. Conceptual Pathway Leading to Uncertainty Distress. expertise could stabilize into established practices, AI continually invalidates emerging routines before they mature. Consequently, adaptation becomes an ongoing behavioural requirement rather than a temporary transition associated with learning a new tool. Psychologically, this left practitioners unable to form stable expectations about the value of their knowledge, the adequacy of their skills, and the trajectory of their professional development. As uncertainty became persistent rather than transient, it evolved from an informational challenge into a source of uncertainty distress. P7 reflected on his worry: âItâs a bit uncertain for me. I worry, how can I establish a consistent workflow in this volatilityâ (P7). Consistent with our definition of psychological costs, uncertainty distress arose when practitioners appraised the persistent uncertainty surrounding AI adoption as exceeding their psychological resources to predict, prepare for, and adapt to future changes. This pathway is illustrated in Fig. 4.2. Uncertainty distress is given rise by the rapid pace of AI evolution and was further amplified by epistemic uncertainty and perceived adoption pressure within the organization. Nobody knew what best practices are and for some workflows like testing, practitioners struggled to identify proper use cases. When P9 was asked whether she benefited from the organizational strategy âexperiment-and-share,â she reflected: âthe ones[experiment results] that were shared across a lot of us werenât really relevant for my role. I think, in general, itâs hard to find the really good use cases in testing ... I donât think I found any use cases that, test wise, make my work more efficientâ (P11). Practitioners in our sample seem to perceive AI adoption pressure as an amplifier of their uncertainty distress. While managers largely framed the AI maturity initiative as evidence of successful organizational adoption, practitioners experienced it as a source of uncertainty. P13 described how employees progressively advanced through the organizationâs AI maturity levels, observing that âa lot of them has moved to step 3 and 4. Some of them also to 5 running full agentic mode... I have one developer stating that I havenât wrote one single line of code the past month. So itâs really getting under the skin on the developersâ (P13). Similarly, P15 characterized the initiative as encouraging practitioners to âclimb the ladder of AIâ (P15), reflecting an organizational aspiration toward increasingly sophisticated AI use. However, from practitionersâ perspective, this emphasis on advancing AI maturity introduced uncertainty. P1 stated: âItâs very offensive and uncomfortable now of course with all the measuring of peopleâs AI maturity and that itâs all over the news that this is causing people to be fired in a big way Iâm sure everybody is also motivated to use AI by fearâ (P1). This assessment process seems to be perceived as a pressure mechanism; P19 explained: â ... so they defined maturity levels, and up to a , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering19 level 5, which is using agents to do basically what needs to be done. So theyâre pushing us to evaluate us. They are pushing us towards a certain level in the department. So they want people to be at level 4 where you are working with AI in a certain wayâ (P19). Rather than reducing uncertainty, the maturity assessment introduced new uncertainties about what constituted successful AI adoption and whether failing to progress would carry professional consequences. In doing so, organizational expectations became another source of uncertainty beyond the technology itself. In sum, the evolutionary and fast-pace nature of AI, coupled with the absence of stable organizational knowledge, and perceived adoption pressure, prevented practitioners from forming reliable expectations about how to invest in their competence and organize their work. This left them in a persistent state of anticipation and vigilance, continuously reassessing their preparedness for an uncertain future. The psychological cost therefore lies not in uncertainty itself, but in the sustained cognitive and emotional effort required to work with uncertainty that cannot be resolved. The âcostâ materialized because practitioners expended their psychological resources trying to anticipate change, protect their professional competence, and make decisions without stable reference points. Consequently, uncertainty ceased to be a temporary feature of technological change and became an enduring source of psychological strain during organizational AI adoption. 4.2 Accountability Anxiety sdu.dk #sdudk The Maersk Mc-Kinney Moller Institute The Maersk Mc-Kinney Moller Institute AI Disruption Organizational AI Adoption Psychological Costs Accountability anxiety Unknown Risks Governance Ambiguity Pre-existing standards amplifies gives rise to shapes Fig. 4.3. Conceptual Pathway Leading to Accountability Anxiety. AI seems to introduce accountability anxiety to our participants, e.g., ânot being able to fully vouch for the resultâ (P7). This psychological effect appears to stem from the participantsâ professional confidence to take responsibility for the AI outputs. P2 explained: âI have a task right now, where I have to make our, uh, the Kotlin that shares the Android native and the iOS native ... it needs to receive notifications. And that needs to hook into the native code on the platform. I have absolutely no idea how to do that other than I know I need to connect to something on Android and something on iOS. But it has removed the stress of knowing that I have to do that tomorrow. Because Iâl make AI analyze, I mean, Claude, make a deep analysis on how to do it and propose solutions for it. The problem with that is, and that gives me the anxiety of, is that even working? Can I stand behind it?â (P2). This accountability anxiety seems to originate from the unknown risks associated with integrating AI-generated outputs into production systems. P8 explained: âIf you get an AI to develop a feature, , Vol. 1, No. 1, Article . Publication date: September 2026. 20Alami, et al. and you donât know how it took the requirements and broke it down to stories, and you cannot tell the audit team how that happened ... I think there are some risks laying aroundâ (P8). P2 further explained this dual paradox, AI reduces his âloadâ while introducing accountability anxiety: âIt eases the load, but it increases the anxiety of doing something wrongâ (P2). Accountability is also systemic at SoftHouse, where it is embedded in a culture of trust and professional responsibility. The organizational culture promotes a shared sense of accountability, i.e. âwe trust youâ (P9). Rather than reducing responsibility, this trust places practitioners in the role of organizational gatekeepers, responsible for ensuring the quality and integrity of software before deployment. As a result, employees internalize organizational trust as a personal obligation to exercise sound professional judgment, making the trust relationship bidirectional. P6 explained: âI think itâs because at SoftHouse, we have this, we trust you until everything else is proven wrong. So they put trust on us. They trust us to do our work and trust us to be the gatekeepers, you could sayâ (P6). This trust-by-default stance creates a paradox: while AI reduces technical workload, it simultaneously increases the burden of personal judgment, as practitioners must now verify opaque AI outputs without clear organizational guardrails. In the absence of clear rules, the organizationâs trust-by-default stance converts every practitioner into their own compliance officer; it transfers the liability judgment onto the individual. One year into the AI adoption, the organization is still lacking clear governance guidelines for AI use; P19 stated: âif they[SoftHouse] want to push the AI to the level of the maturity level that they want or envision us to be at, they need to provide us with the compliance guardrails that makes it possibleâ (P19). Such ambiguity appears to amplify practitionersâ anxiety for their accountability. P11 summarized this situation: âcompliance concerns have been holding back people, what actually was allowed ... they could use AI, but they were uncertain if they actually did something that could pose a security or other compliance concern ... I have heard people say: I donât know what Iâm allowed to do, so I donât do anything, to not run the risk that I do something I was not allowed to doâ (P11). SoftHouse has high affinity for high standards, quality, and adherence to compliance requirements. P1 stated: âSoftHouse is a very process-strong house. And you can say that the commitment to delivering quality is very, very strong with usâ (P1). When P18 was asked about the objections he hears in his team, he replied: âpeople have been mostly concerned about quality they have been concerned to be pushed to use tools which did not provide quality since people really are committed to delivering quality ... they are scared to be pushed to produce poor qualityâ (P18). This evidence may suggest that quality at SoftHouse is an organizational objective translated into a professional norm that practitioners appear to internalize as part of their identity and responsibility. Consequently, their concerns were that relying on AI could compromise the quality standards for which they are accountable. Figure 4.3 illustrates this pathway. Unknown risks associated with AI-generated outputs gave rise to accountability anxiety, while both governance ambiguity and SoftHouseâs pre-existing quality and compliance standards amplified this psychological cost. Because practitioners remained expected to satisfy these established standards despite relying on AI, they experienced heightened responsibility to verify, justify, and ultimately stand behind AI-assisted decisions. AI seemed to constrain practitionersâ ability to determine, understand, and justify how solutions were produced, while leaving their professional accountability unchanged. The psychological cost therefore lies in the depletion of agency resources (i.e., being in control of their work) required to exercise professional responsibility. Practitioners were expected to stand behind AI-assisted decisions despite experiencing diminished control over the reasoning, provenance, and rationale underlying those decisions. , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering21 4.3 Cognitive load intensification sdu.dk #sdudk The Maersk Mc-Kinney Moller Institute The Maersk Mc-Kinney Moller Institute AI Disruption Organizational AI Adoption Psychological Costs Accountability anxiety Unknown Risks Governance Ambiguity Pre-existing standards amplifies gives rise to shapes Cognitive load intensification Translates into Fig. 4.4. Conceptual Pathway Leading to Cognitive Load Intensification. To meet their accountability expectations, our participants reported expending additional resources verifying, questioning, and justifying AI-generated outputs to fulfill their professional obligations. P12 explained: âI have to do more work. And it hasnât eased my cognitive load, actually. Itâs made me ... I have to work harder, I feel like, with AI. Because now you can do more, so you feel like you need to do more ... I need to look through the result line by line, Iâm accountable for itâ (P12). Here, cognitive load intensification arose when practitioners appraised AI-assisted work as requiring greater cognitive effort than their available mental resources could comfortably sustain (i.e., âwork harderâ ). AI shifted practitionersâ effort from producing code to verifying, evaluating, and justifying AI-generated outputs to meet their accountability obligations. As illustrated in Fig. 4.4, accountability anxiety translated into cognitive load intensification by requiring practitioners to continually verify, question, and justify AI-generated outputs before they could confidently stand behind the work they produced in collaboration with AI. 4.4 Craft Identity Disruption sdu.dk #sdudk The Maersk Mc-Kinney Moller Institute The Maersk Mc-Kinney Moller Institute AI DisruptionPsychological Costs Craft identity disruption gives rise to Role-altering capability Fig. 4.5. Conceptual Pathway Leading to Craft Identity Disruption. The accountability question touches on something deeper than quality checking. P2 is asking whether AI-assisted work is authentically his own in a professional sense: âCan I stand behind it once it has made it?â (P2). His description of his own practice carries the same tension: âI asked AI and then I analyzed it and it seems like a good wayâ (P2); the ownership he can claim is evaluative , Vol. 1, No. 1, Article . Publication date: September 2026. 22Alami, et al. rather than generative (i.e., âI did not build it, I evaluated itâ); he endorses the solution, but did not author it. As illustrated in Fig. 4.5, identity seems to be disrupted by AI performing the core activities that defined our practitionersâ professional selves. This role-altering capability was echoed across almost all participants, e.g. P2 stated: âItâs very powerful, very powerful. I can make big, big, big tasks with itâ (P2) and âAI is relieving my workload by summarizing large files faster than humanly possibleâ (P12). This shift disrupted the meaning underlying the identity of software practitioners in our sample; they are questioning what their expertise now amounted to: âthen you just have to prompt ... I did not go to university to do thisâ (P11). This role-altering capability fundamentally challenged how practitioners understood their professional identity; this was more prominent among software engineers, testers, and architects to varying degrees (see Sect.4.6). For many participants, software engineering was not simply an occupation but an important source of self-definition, where producing code and other software artifacts represented both professional competence and personal accomplishment. As AI increasingly assumed the generative aspects of software development, practitioners described a growing disconnect between the work they performed and the work that had previously defined them. P7 (a software engineer) reflected on this shift: âI find it difficult to separate myself as a person from the work that I do... being a software engineer who writes code is sort of who I was, and now Iâm a software engineer who prompts an AI and then reads the codeâ (P7). P17 (a software architect) sees a drastic shift in his role, âIâm a technical guy ... it[AI]âs taking away all the fun parts ... And now Iâm just a prompt monkey ... I really love the fact that I can actually still revisit and validate at code level. I donât have that luxury when I work with AI toolsâ (P17). Rather than merely changing tasks, AI altered the basis upon which practitioners experienced authorship, craftsmanship, and professional pride. P12 further described how âthe final product feels like something I didnât make anymore because itâs written by some machineâ (P12). In this sense, practitioners no longer questioned only the value of their technical expertise; they questioned whether the work they now performed remained authentic to the professional identity they had spent years developing. For testers, the disruption took a different form: rather than losing generative work, they experienced the worth and standing of their role being renegotiated. P10, an automation test engineer, pushed back against efficiency as the measure of AIâs value in her role, âmostly I think the purpose should be to strengthen the quality of testsâ (P10), repositioning the tester as the human checkpoint whose importance grows as developers delegate more of their work upstream. P1, a test manager, was blunter about the roleâs standing during the transition: âa tester is easier to fire than an architectâ (P1); she declined to experiment with more advanced AI integrations at work, protecting her professional standing by judging that the consequences of a mistake would fall harder on her role than on others. This disruption extended beyond the present into practitionersâ anticipated professional future. P7 worried that prolonged reliance on AI would erode the very skills that once distinguished him professionally, wondering âif we lose access to these things ... will I still be good at it?â (P7). Similarly, P1 anticipated a future in which software engineering would shift from creating software to supervising AI-generated work, describing concerns that the profession would become âreally boringâ (P1) and expressing fears of âskill atrophyâ (P1) that might ultimately leave practitioners unable even to critically review AI-generated solutions. Our analysis suggests that craft identity disruption reflects the erosion of a coherent professional self rather than simply changes in job tasks. As AI assumed activities that practitioners regarded as the essence of software engineering, they experienced increasing difficulty maintaining continuity between who they had become through years of practice and who their work now required , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering23 them to be. The psychological cost therefore lies in the sustained effort required to reconstruct a professional identity whose traditional foundations, craftsmanship, authorship, and technical mastery, have become increasingly constrained. Consistent with our definition of psychological costs, practitioners appraised these changes as threatening valued aspects of their professional identity while exceeding their psychological resources to preserve a coherent sense of who they are as software professionals. 4.5 Meaning and Satisfaction Erosion sdu.dk #sdudk The Maersk Mc-Kinney Moller Institute The Maersk Mc-Kinney Moller Institute AI DisruptionPsychological Costs Meaning and satisfaction erosion gives rise to Role-altering capability Fig. 4.6. Conceptual Pathway Leading to Meaning and Satisfaction Erosion. As illustrated in Fig. 4.6, the role-altering capability of AI appears to challenge our participantsâ professional identity, thereby reshaping the meaning and satisfaction practitioners derive from their work. P16 vividly explained: âI felt a certain pride at being good at coding myself at one point, and now it feels a little bit like the mechanical parts that I enjoyed of using shortcuts well, navigating the code base well. All of these things that I worked on quite hard are not that important anymoreâ (P16). P7 echoed a similar sentiment: âI always thought the real part of the work was producing the code. Thatâs what we deliver, and thatâs what the customer wants, thatâs what they use, and thatâs how we identify ourselves. If something doesnât work, itâs because thereâs something wrong in the code usually ... I think I just made it a very intimate part of myself, and being a software engineer who writes code is sort of who I was, and now Iâm a software engineer who prompts an AI and then reads the codeâ (P7). This sentiment was felt among almost all software engineers in our sample, e.g., â... the final product feels like something I didnât make anymore. and thatâs a weird experience sometimes when you are used to owning the entire process and now the actual thing that you deliver, isnât written by me anymore. Itâs written by some machine that understood maybe part of what was in my head at some point.â (P14). Our analysis suggests that meaning and satisfaction erosion seems to reflect more than a change in work activities; it reflects a change in how software engineers experience the intrinsic value of their work. Activities that previously provided a sense of craftsmanship [3,5], accomplishment, and personal fulfillment became increasingly delegated to AI, leaving practitioners with a diminished sense of ownership over the outcomes they delivered. Rather than deriving satisfaction from creating software, software engineers in our sample appear to increasingly describe evaluating, reviewing, and approving software created by AI. The psychological cost therefore lies in the gradual erosion of work as a source of meaning, accomplishment, and professional fulfillment. Aligned with our definition of psychological cost, software engineers appraised this transformation as diminishing the motivational and emotional rewards they associated with developing software, requiring them to reconcile a profession they once found deeply meaningful with one that seems no longer to provide the same sense of purpose and satisfaction. This erosion was not uniform across roles; it concentrated where the displaced activity had been the roleâs craft (i.e., software code and other artifacts part of the software product). Testers, whose craft is evaluative rather than generative, described the shift toward verification as an intensification , Vol. 1, No. 1, Article . Publication date: September 2026. 24Alami, et al. of their role rather than its hollowing; P10 reported unchanged enjoyment of AI-assisted work, âWhen make the test strategy for a feature. It[AI] ensures that we actually get to the stuff we wanted to test. So when I do a test implementation, AI helps me identify the gap in my tests, it complements my effort ... And I really like working with it. I donât have any resistance against it. I think itâs niceâ (P10). Architects presented the mirror case; they were among the most enthusiastic adopters, as AI extended their generative reach: âI suddenly had a developer in my back pocketâ (P17); referring to Claude Code being the âdeveloperâ becoming available to assist in prototype development. An enthusiasm other participants attributed to architects prototyping without developer pushback, âthey donât have a developer saying no to themâ (P12). Psychological Costs of Organizational AI Adoption in SE. In response to our RQ (i.e., psychological costs), practitioners experienced five psychological costs: uncertainty distress, accountability anxiety, cognitive load intensification, craft identity disruption, and meaning and satisfaction erosion. These costs may reflect the depletion of psychological resources required to adapt to organizational AI adoption while continuing to enact their professional role. Our findings suggest that organizational AI adoption is not experienced solely as a technological or organizational change, but also requires adaptation at the human level, as practitioners renegotiate their professional responsibilities, identity, the meaning of their work, and their relationship with AI. 4.6 Role-based Analysis Our analysis shows that the psychological costs are uneven across the roles we covered in our data collection; while some costs are felt evenly, others are rather role-specific. To examine how psychological costs vary across roles, we complemented our thematic analysis with a role-based magnitude assessment [32]. For each psychological cost, we determined the number of participants within each role whose interviews contained at least one First Cycle code mapped to that cost. We then expressed this as the prevalence, how widespread a cost is within a role in our sample. Table 7 documents this analysis. Three properties of this system should be noted. First, it counts participants, not coded segments; a participant who voiced a cost repeatedly and one who voiced it once contribute equally, which guards against differences in interview length and participant expressiveness. Second, the qualitative prevalence in this sample supports no statistical comparison across roles; we report the underlying fractions so readers can assess the evidence directly. In our sample, software engineers have the highest fractions for four psychological costs. One possible interpretation is that the psychological impact of AI adoption is associated with the extent to which a role depends on directly creating software artifacts as the primary expression of professional expertise. Software engineers enact their professional agency through writing, shaping, and owning code. As AI increasingly performs these activities, engineers experience greater disruption to the mechanisms through which they exercise competence, derive meaning, and demonstrate professional value. In contrast, roles whose primary responsibilities involve coordination, architectural decision-making, governance, or organizational oversight appear less directly affected because AI augments rather than substitutes the activities through which these practitioners enact their professional role. We interpret these role-based patterns as suggesting that psychological costs may be more pronounced when AI displaces activities central to practitionersâ professional agency. In other words, it could be that AI use alone may not predict psychological costs; but also how much AI replaces the activities through which practitioners exercise their professional agency. However, for testers and architects, such patterns do not materialize to the same extent. For both roles, the representation in , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering25 Table 7. Prevalence of psychological costs by role. Prevalence is the share of a roleâs participants whose interviews contained at least one First Cycle code. Codes expressing costs only as reported speech about others were not counted toward the reporting participant. RolePsychological costPrevalence Senior Management (n=5) Accountability anxiety2/5 Craft identity disruption0/5 Meaning and satisfaction erosion0/5 Cognitive load intensification0/5 Uncertainty distress3/5 Software Architecture (n=3) Accountability anxiety0/3 Craft identity disruption1/3 Meaning and satisfaction erosion1/3 Cognitive load intensification1/3 Uncertainty distress0/3 Testing (n=3) Accountability anxiety1/3 Craft identity disruption0/3 Meaning and satisfaction erosion1/3 Cognitive load intensification0/3 Uncertainty distress3/3 Software Engineers (n=10) Accountability anxiety10/10 Craft identity disruption10/10 Meaning and satisfaction erosion10/10 Cognitive load intensification7/10 Uncertainty distress10/10 our sample is low. In addition, for testing AI support is complementary, yet, uncertainty distress is notably high. This aligns with our earlier finding that testers struggle to identify stable, efficient use cases for AI in their workflows, leaving them in a state of persistent epistemic uncertainty despite the technology being complementary rather than substitutive. For architects, the agency displacement could be negligible, as architectural decision-making remains a human task, at least in the context of SoftHouse. Finally, for senior management, accountability anxiety and uncertainty distress are highly prevalent. This can be explained by their direct ownership of the AI adoption initiative and the organizational pressure to demonstrate successful implementation. Role-Based Variation in Psychological Costs. Psychological costs were not experienced uniformly across the roles in the scope of our study. Our findings suggest that their prevalence is associated with agency displacement, which we define as the extent to which AI assumes the activities through which practitioners traditionally exercise professional judgment, expertise, and ownership. Among Software Engineers, whose professional agency is strongly enacted through designing and producing software, AI appeared to displace a substantial portion of these activities and was associated with the broadest range of psychological costs. By contrast, for Software Architects, AI primarily augmented rather than substituted their core responsibilities, corresponding to comparatively limited experiences of craft identity disruption and meaning erosion. For Testers, AI also complemented rather than displaced their work, yet the absence of stable and role-relevant AI use cases was associated with pronounced uncertainty distress. Finally, Senior Management experienced elevated accountability , Vol. 1, No. 1, Article . Publication date: September 2026. 26Alami, et al. anxiety and uncertainty distress, reflecting their responsibility for leading organizational AI adoption while navigating its uncertain trajectory. 4.7 Responses to Psychological Costs We also observed that participants respond to these costs in different ways of dealing with them in their everyday practices. Although participants described a wide variety of responses, these did not differ merely in their form but in the function they served. We therefore organized them according to how practitioners related to the psychological costs they experienced rather than according to the specific behaviors themselves. Managed responses comprised practices that enabled practitioners to continue working alongside AI while keeping psychological costs under control. Mitigated responses reduced practitionersâ exposure to particular psychological costs or limited their potential impact. In contrast, absorbed responses reflected situations in which practitioners perceived the psychological cost as unavoidable and continued to work while consciously living with its consequences. This functional organization highlights that practitioners did not simply react to AI adoption; they responded differently depending on whether they believed a psychological cost could be controlled, reduced, or had to be endured. These responses illustrate that practitionersâ experiences of AI adoption include ongoing adjustments in how they define, negotiate, and enact the boundaries of AI-human collaboration. Our analysis shows that these responses are efforts to preserve valued psychological resources: agency (being in control), competence (being capable), and professional identity (being the kind of engineer they value being). Table 8 documents the psychological resources being protected by the responses and their corresponding costs. Agency. Practitioners seem to attempt preserving their agency by managing the extent to which AI could influence their work while retaining themselves as the decision maker. Rather than accepting AI outputs at face value, they described deliberately being in charge of the decision process through verification, review, and staged delegation. P2 explained that every AI-generated solution was followed by an âanalysisâ before adoption: âI analyzed it and it seems like a good wayâ (P2). Similarly, P12 explained, âI need to look through the result line by line, Iâm accountable for itâ. When uncertainty exceeded acceptable levels, practitioners shifted from managing to mitigating the cost by limiting AIâs involvement altogether. P9, for example, rejected direct integrations outright, stating âMCP integration is so far a no-go. I wonât do that, because I wonât get firedâ (P9), while P12 removed sensitive data before using cloud-based AI tools. These accounts show that preserving agency did not mean rejecting AI, but regulating its role so that practitioners retained sufficient control to exercise professional judgment. Competence. Responses aimed at preserving competence reflected practitionersâ concern that prolonged dependence on AI could gradually erode their own technical capability. Rather than allowing AI to replace the learning process, participants deliberately created opportunities to continue exercising their skills. P7 described beginning each day with a period of manual coding because âif you donât use it, you lose itâ (P7), treating coding itself as a practice that required continual maintenance. Similarly, P10 intentionally attempted solutions before consulting AI to preserve independent reasoning, while P20 deliberately limited delegation because âif you use it too much, you will forget some of the skillsâ (P20). P18 went even further by dedicating specific time in his coding effort to â ... manual coding without AIâ (P18). These responses suggest that practitioners viewed competence as something that required deliberate preservation through continued engagement with core engineering activities. This could also be an investment in maintaining agency through preserving skills required to validate AI outputs. , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering27 Table 8. Psychological resources preserved through practitionersâ response patterns, the costs addressed, the responses enacted, and illustrative evidence. Psychological Resource Preserved Response Pattern Psychological Cost(s) Addressed Responses Agency (being in control) Manage Accountability anxiety Cognitive load intensification Oversight and comprehension-preserving practices: 1. staying in the loop; 2. prior codebase knowledge as oversight prerequisite;3. complexity-based delegation triage; 4. plan and diff review; 5. baseline testing before accepting changes;6. deliberate deceleration; 7. code-level verification (e.g., âline-by-line verificationâ) Mitigate Uncertainty distress Risk containment and exposure limitation: 1. self-imposed limits pending explicit permission; 2. discontinuation of unsanctioned experiments;3. data stripping before cloud tool use; 4. partitioning work into safe and gray zones; 5. declining write-capable integrations Competence (being capable) Mitigate Uncertainty distress Skill preservation practices: 1. deliberate periodic manual coding ritual; 2. self-then-AI sequencing (own draft before AI toprotect learning);3. AI delegation moderation (boilerplate only, retainingbusiness logic heavy work); Professional Identity (being the kind of engineer they value being) Mitigate Craft identity disruption Identity reframing: 1. role redefinition toward orchestration; 2. relocating professional worth from writing code todelivering software;3. positioning the human as guardian of architecturalintegrity; 4. reframing SE as problem solving rather than coding Absorb Craft identity disruption Meaning and satisfaction erosionCognitive load intensification Resigned adaptation and compensation: 1. loss of enjoyment endured; 2. enjoyment displaced outside paid work;3. continuing to work within the new conditions without resolution; 4. capitulation to AI adoption Methodological note: We employed a multi-level functional analysis to conclude this mapping. First, First Cycle coding identified granular practices (e.g., line-by-line verification). Second, we aggregated these practices according to their intended function (i.e., manage, mitigate, and absorb). Third, we traced each functional pattern to the psychological resource it aimed to preserve (agency, competence, or professional identity). Finally, we linked each response pattern to the specific psychological cost(s) it addressedby examining which resource was threatened and whether the responseâs function directly countered that costâs mechanism. , Vol. 1, No. 1, Article . Publication date: September 2026. 28Alami, et al. Professional Identity. Preserving professional identity proved considerably more complex because, unlike agency or competence, identity could not always be restored through changes in work practices. Some practitioners mitigated identity disruption by redefining what it meant to be a software engineer. P10 distinguished between âdelivering software, not delivering codeâ (P10), relocating professional worth from code production to solving customer problems. Others repositioned themselves as orchestrators of AI or guardians of architectural integrity, with P19 describing the uniquely human contribution as âseeing the missing parts in a solution or a setupâ (P19). However, several participants perceived the loss as irreversible and instead absorbed its psychological consequences. P19 acknowledged that losing the enjoyment of coding was ânot a nice feelingâ (P19). Likewise, when asked how he dealt with the increased mental burden of AI-assisted work, P7 replied simply, âI donât. I just keep goingâ (P7). These accounts may suggest that when practitioners could no longer preserve valued aspects of their professional identity, they continued working by accepting the psychological costs as part of the evolving nature of software engineering rather than expecting them to disappear. These responses may also suggest that practitioners sought to preserve different psychological resources depending on the nature of the psychological cost they experienced. Agency was primarily preserved by changing how work was performed, enabling practitioners to retain control, oversight, and professional judgment while collaborating with AI. Competence was preserved by changing how learning occurred, deliberately maintaining opportunities to exercise and maintain technical expertise independently of AI. Professional identity, however, proved less amenable to behavioral adjustment. Practitioners appear to either reconstruct what it meant to be a software engineer or practitioner in AI-assisted software engineering or, when such reconstruction was not possible, continued working while accepting enduring losses to craftsmanship, meaning, and satisfaction. Managing Psychological Costs. Practitioners responded to psychological costs by preserving three core psychological resources: agency (being in control), competence (being capable), and professional identity (being the kind of engineer they value being). These resources, however, required different forms of response. To preserve agency, practitioners primarily managed costs by regulating AIâs role through practices such as staged delegation, deliberate oversight, and line-by-line verification, enabling them to remain in control. To preserve competence, they mitigated psychological costs by deliberately maintaining opportunities to exercise their own skills, for example through manual coding rituals and limiting AI-generated first drafts. Professional identity, however, proved less amenable to behavioral adjustment. Practitioners either mitigated identity disruption by redefining what it meant to be a software engineer (e.g., from producing code to orchestrating software development) or absorbed enduring losses to craftsmanship, meaning, and enjoyment when such reconstruction was no longer possible. 5 DISCUSSION AND IMPLICATIONS We commence this section by discussing our contribution, then the theoretical and practical implications of our findings. 5.1 Contribution Our study contributes an explanatory and diagnostic model of psychological costs during organizational AI adoption in SE. Our findings overlap with established technostress concerns, including uncertainty, overload, threatened competence, and reduced satisfaction [9,35]. Recent SE research also recognizes the verification demands and continued human responsibility , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering29 accompanying GenAI use [27]. Our contribution lies in explaining how these demands become psychological costs through their interaction with engineering obligations, professional identity, and organizational adoption conditions. Table 9 positions the identified psychological costs in relation to their closest technostress constructs and specifies the explanatory contribution of our model. Our model (Fig. 4.1) distinguishes characteristics of AI, organizational conditions that give raise and intensify the resulting costs, and responses through which practitioners attempt to preserve agency, competence, and professional identity. These relationships explain how AI adoption inherent conditions translate into human burdens. For example, the model distinguishes accountability pathway from changes to professional identity and meaning. When AI assumes activities through which practitioners previously experienced authorship, mastery, and accomplishment, effective tool use may coexist with diminished professional fulfillment. This distinction matters because the difficulty concerns the significance of the work being transformed, not necessarily practitionersâ ability to perform it. Technical proficiency, accountable control, and professional fulfillment are related but distinct aspects of adaptation. This explanatory detail provides a basis for diagnosis. Governance ambiguity directs attention to permissible use and organizational guidance; burdensome verification directs attention to assurance practices and the resources allocated to them; disrupted identity and meaning direct attention to work design and opportunities to exercise valued expertise. Distinguishing these pathways helps identify which conditions an intervention needs to address and why a response appropriate to one cost may leave another unresolved. Although the effectiveness of such interventions requires evaluation, the model provides an empirical basis for identifying where changes to AI adoption and engineering work may reduce practitionersâ psychological costs. The diagnostic framework in Table 10 is an analytical translation of our explanatory model. We derive the diagnostic questions from the conditions associated with the emergence or intensification of each psychological cost and the responses through which practitioners attempt to manage it. Organizational conditions and work arrangements that can be changed become intervention targets, from which we infer potential responses. This translation connects the explanation of how costs arise to the identification of where organizational action may be directed. During AI adoption strategy design, the framework can help practitioners and managers examine anticipated demands and plan appropriate support. Throughout change management, it can guide recurring assessment of emerging costs, practitionersâ adaptations, and whether organizational responses alleviate costs or introduce additional demands. The framework and proposed responses are implications of the analysis whose practical effectiveness requires evaluation. 5.2 Theoretical Implications Theoretically, we interpret the findings through the lenses of Conservation of Resources (COR) theory [23,24] and Self-Determination Theory (SDT) [16]. Although neither COR nor SDT guided the coding or analysis, both theories offer explanatory power for interpreting the psychological costs that emerged inductively. Accordingly, we use them to position our findings within existing theoretical frameworks, examine their alignment with these theories, and identify how our findings extend current theoretical understanding. , Vol. 1, No. 1, Article . Publication date: September 2026. 30Alami, et al. Table 9. Psychological costs of AI adoption in SE and correspondence with technostress and additional explanatory value from our study. Psychological cost Closest technostress correspondence Additional explanatory value for AI adoption in SE Uncertainty distress Techno-uncertainty; partial overlap with techno-complexity and techno-insecurity [35, 42]. Distress does not necessarily arise from insecurity or perceiving AI itself as threatening. Our findings showthat practitioners must establish workable practices and understand their changing professional role whiletechnological capabilities evolve rapidly, actionable knowledge remains limited, and organizationalexpectations press for further adoption. The model explains how these conditions jointly make adaptation psychologically demanding. Beyond identifying techno-uncertainty, it locates the cost in the tension between expectations to progress and the conditions needed to establish stable practice. This makes organizational expectations and learning conditions relevant intervention targets alongsidetechnological change. Accountability anxiety Role ambiguity and technology-related strain; partialcorrespondence [9, 27]. Anxiety can arise even when responsibility is unambiguous; practitioners know they remain accountable butcannot confidently understand, validate, or justify the outputs for which they must answer. Our model identifies the gap between retained accountability and the perceived ability to discharge it, withgovernance ambiguity and established quality obligations intensifying that gap. Beyond identifying role ambiguity or technology-related strain, this explanation shows why clarifying who is responsible may beinsufficient. Practitioners also need conditions that enable them to exercise that responsibility. Cognitive loadintensification Techno-overload andtechno-complexity, and associatedstrain [35, 42], partialcorrespondence. Cognitive demands arise partly from practitionersâ efforts to manage accountability anxiety. Verificationrequires them to reconstruct sufficient understanding of delegated work to assess and endorse it. Our model therefore explains how mechanisms used to verify AI-generated work create additional cognitivedemands; practitioners must understand the generated solution, assess its correctness, and justifyaccepting it. This directs attention to the scope of delegated work and the time and support required for meaningful verification. Craft identitydisruption Techno-insecurity; partialcorrespondence through threats toexpertise and professionalstanding [35]. The cost concerns continuity of professional identity, extending beyond fears of replacement or skillobsolescence. Practitioners may retain valuable expertise while losing opportunities to enact it throughactivities that previously defined their professional selves. Our model connects AIâs substitution of these activities to the effort required to reconstruct professional identity. Beyond identifying techno-insecurity, it distinguishes possessing competence from being able to express that competence in professionallymeaningful ways. This may explain why training or employment reassurance may leave the underlyingidentity disruption unresolved. Meaning andsatisfaction erosion Reduced job satisfaction: anoutcome rather than a technostresscreator [35]. Reduced satisfaction can arise because AI assumes activities that previously provided enjoyment, ownership,and accomplishment, even when practitioners recognize its usefulness. Our model connects changes in the composition of engineering work to changes in its intrinsic rewards. Beyond identifyingdissatisfaction as an adverse outcome, it explains what has become less rewarding and why. This distinguishes reducing strain from restoring fulfillment; making AI-assisted work easier or less stressful doesnot necessarily restore the meaning derived from the activities it replaces. Note: Correspondences identify related stressors or outcomes rather than equivalent constructs. Proposed intervention points require empirical evaluation; they are not prescribed recommendations but opportunity for reflection. , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering31 Table 10. A diagnostic framework for identifying intervention points during AI adoption in software engineering. Psychological cost Diagnostic questions Intervention target Potential response to evaluate Uncertainty distress Can practitioners identify useful AI applicationsfor their role and establish workable learningpriorities? Do adoption expectations account fortechnological instability and uneven applicability? Learning conditions andadoption expectations Provide protected learning time and guidancerelevant to particular roles. Calibrate adoptionexpectations to applicable use cases, complianceconstraints, and delivery obligations. Accountabilityanxiety Are practitioners expected to approve outputsthey cannot adequately understand or validate? Are permissible use, assurance responsibilities, and escalation routes sufficiently clear? Governance and assurancearrangements Clarify permissible use and assurance responsibilities. Establish review criteria, access toappropriate expertise, and escalation routes forunresolved quality or compliance concerns. Cognitive loadintensification What cognitive effort is required to understand, verify, and correct generated outputs? Is this effort recognized in workload and productivityexpectations? Work allocation and scopeof delegation Allocate capacity for verification. Bound delegatedtasks and generated changes so they remainreviewable. Assess the combined effort ofgeneration, evaluation, and correction. Craft identitydisruption Which activities enable practitioners to expressprofessional expertise and ownership? Whatopportunities remain to exercise these capabilitiesas AI assumes parts of the work? Whatpsychological and professional support dopractitioners need during adoption? What careeradvices are available to practitioners? Professional agency androle design Involve practitioners in redesigning their roles.Preserve meaningful decision authority andopportunities to exercise, develop, anddemonstrate valued expertise. Meaning andsatisfaction erosion Which activities provide interest, accomplishment,and enjoyment when AI replaces traditional work?How has AI changed access to these activities, anddoes the revised work provide comparable sourcesof fulfillment? Task composition andsources of fulfillment Review the balance of creative, routine,craftsmanship values, and evaluative work.Preserve opportunities for valued problem solvingand assess fulfillment alongside productivity. Note: Apply the questions to practitionersâ specific tasks and working conditions. Costs and intervention targets may overlap. , Vol. 1, No. 1, Article . Publication date: September 2026. 32Alami, et al. While COR theory explains how individuals experience stress when valued psychological resources are threatened, depleted, or require continued investment to protect them [23], SDT explains how the satisfaction of basic psychological needs shapes motivation, well-being, and functioning of individuals [16]. Both theories provide complementary interpretations for understanding how organizational AI adoption both threatens practitionersâ psychological resources and alters the motivational foundations of their work. Environmental circumstances demands, threats, and change threaten or deplete Resources objects, conditions, personal characteristics, energies Individuals strive to obtain, retain, protect, and foster resources valued by threat of loss âą actual loss âą failed gain after investment (losses loom larger than gains: primacy of loss) Stress resource investment (protect against loss, recover from loss, gain resources) Fig. 5.1. An aggregated view of Conservation of Resources theory [23]. Conservation of Resources Theory. CORâs core concept is that âstressâ occurs when âpeople strive to retain, protect, and build resources and that what is threatening to them is the potential or actual loss of these valued resourcesâ [23]. Our definition of psychological costs is compatible with COR because the adverse cognitive, emotional, motivational, and social experiences identified in our findings (e.g., accountability anxiety) consistently emerged when practitioners perceived valued psychological resources (e.g., agency) to be threatened, depleted, or requiring sustained investment to protect. In this sense, COR does not redefine the psychological costs identified in our study; rather, it provides a theoretical explanation for why these experiences arise. As depicted by Fig. 5.1, COR theory posits that individuals are fundamentally motivated to obtain, retain, protect, and foster the resources they value, encompassing objects, conditions, personal characteristics, and energies. Psychological stress occurs when environmental circumstances, such as demands, threats, or changeâthreaten or deplete these resources. Specifically, stress is triggered by the threat of loss, actual loss, or a failure to gain resources after investment, with resource losses being disproportionately more impactful than equivalent gains (the primacy of loss). In response to this stress, individuals must engage in resource investment to protect against further depletion, recover from existing losses, and ultimately build new resources [23]. Table 11 documents the mapping of COR theory constructs to our studyâs findings. Our conceptual model aligns closely with this foundational framework. Specifically, the dual forces of AI disruption and organizational adoption represent the environmental circumstances and demands that alter the practitionersâ work environment. The five psychological costs we identified operationalize the stress that occurs when these environmental demands threaten or deplete practitionersâ cognitive energies, professional conditions, and personal characteristics. In response, practitioners engage in resource investment through adaptive practices (managing, mitigating, and absorbing) aimed , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering33 at protecting and recovering their most valued psychological resources: agency, competence, and professional identity. This study makes four key theoretical contributions, to COR in the context of SE, by mapping the psychological costs of AI adoption to Conservation of Resources (COR) theory. First, we extend CORâs concept of environmental stressors by modeling AI adoption as a dual-force disruption, where intrinsic technological uncertainties are actively amplified by extrinsic organizational pressures. Second, we specify the precise valued resources threatened in AI-mediated knowledge work, identifying the depletion of agency, competence, and professional identity as the core mechanisms of psychological cost. Third, we introduce agency displacement as a critical boundary condition, demonstrating that the severity of resource loss is contingent upon the extent to which AI substitutes a roleâs core generative activities. Finally, we expand CORâs resource investment typology by identifying absorption as a distinct adaptive response, revealing that when resource loss (e.g., to professional identity) is perceived as irreversible, practitioners cope through resigned accommodation rather than active resource recovery. Self-Determination Theory. Self-Determination Theory (SDT) explains human motivation and well-being through the satisfaction of three basic psychological needs: autonomy, competence, and relatedness [16]. According to SDT, these needs are innate psychological nutriments that sustain psychological growth, integrity, and well-being, and their frustration is associated with diminished motivation and psychological functioning [16]. Autonomy refers to experiencing oneâs actions as self-endorsed and congruent with oneâs values and sense of self [16]. SDT proposes that supporting autonomy fosters intrinsic motivation, enhances performance, and promotes psychological well-being [16]. Competence refers to the need to feel capable of effectively interacting with and influencing oneâs environment, and achieving valued outcomes through oneâs own abilities [16]. SDT argues that opportunities to develop and demonstrate competence are fundamental to intrinsic motivation and sustained engagement [16]. Relatedness refers to the need to feel connected to, valued by, and supported by others [16]. According to SDT, intrinsic motivation and psychological well-being are more likely to flourish in environments that foster secure interpersonal relationships and a sense of belonging [16]. Table 12 suggests that our findings align closely with the central propositions of SDT [16]. The psychological costs experienced during organizational AI adoption can be interpreted as reflecting the frustration of practitionersâ basic psychological needs, mainly autonomy and competence. Autonomy was undermined when practitioners no longer experienced themselves as the originators of their work or were unable to confidently stand behind AI-assisted work and decisions. Competence was frustrated by the rapid evolution of AI, the continual obsolescence of emerging expertise, and the additional cognitive effort required to verify AI-generated outputs. By comparison, evidence relating to relatedness was less pronounced. While governance ambiguity and role-specific uncertainty sometimes weakened practitionersâ sense of organizational support, the dominant experiences observed in this study concerned autonomy and competence rather than interpersonal connectedness. Our findings demonstrate SDTâs explanatory value in the context of organizational AI adoption in SE. We identified concrete software engineering practices through which autonomy and competence become frustrated during AI-assisted work, including diminished authorship, accountability without explainability, perishable expertise, and concerns over skill atrophy. Furthermore, the response patterns observed in our study, such as manual coding rituals, staged AI delegation, and identity reframing, can be interpreted as practitionersâ attempts to re-establish autonomy and competence while adapting to AI-assisted software engineering. Our findings also broaden SDT application by showing how autonomy and competence are renegotiated during organizational AI adoption. , Vol. 1, No. 1, Article . Publication date: September 2026. 34Alami, et al. Table 11. Mapping of Psychological Costs of AI Adoption to Conservation of Resources (COR) Theory. COR Theory Construct Study Finding Manifestation in AI Adoption Resource Type Affected Environmental Circumstances (demands, threats, change) AI Disruption Fast technological pace, unknown risks, role-altering capability Conditions, Personalcharacteristics, Energies Organizational AI Adoption Perceived adoption pressure, governance ambiguity, epistemic uncertainty, pre-existingstandards Stress (threat of loss, actual loss, failed gain) Uncertainty distress Threat of skill obsolescence, inability to formstable expectations Personal characteristics, Energies,Conditions Accountability anxiety Actual loss of control over work products, threatto professional judgment Cognitive load intensification Depletion of mental resources required for verification Energies Craft identity disruption Actual loss of authorship and generative work Personal characteristics, Conditions Meaning and satisfaction erosion Failed gain after investment, loss of intrinsicrewards Personal characteristics, Conditions Resource Investment (protect, recover, gain) Manage responses Oversight practices, staged delegation, verification Energies, Personal characteristics Mitigate responses Risk containment, skill preservation, identityreframing Absorb responses Resigned adaptation, acceptance of losses Resource Conservation Goal Preservation of psychological resources Agency (control), Competence (capability),Professional Identity Objects, Conditions, Personal characteristics , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering35 Table 12. Mapping of Psychological Costs and Responses to Self-Determination Theory (SDT). SDT Construct Study Finding Interpretation in the Lens of SDT Autonomy (The need to feel volitional, in control, and the originator of oneâsactions) Accountability anxiety AIâs opaque reasoning thwarts autonomy by stripping practitionersof the ability to fully understand, justify, or self-endorse the workthey are held accountable for. Craft identity disruption The shift from âauthorâ to âevaluatorâ undermines the sense ofpersonal authorship and volition, making practitioners feel like âprompt monkeysâ rather than originators of their work. Meaning and satisfaction erosion When generative work is delegated to AI, practitioners lose theintrinsic motivation derived from self-directed creation, leading toa sense of alienation from their own work. Competence (The need to feel effective, capable, and able to master oneâsenvironment) Uncertainty distress The perishable nature of AI knowledge and rapid technologicalevolution thwart competence by continuously invalidatingemerging routines before mastery can be achieved. Cognitive load intensification The heavy cognitive burden of line-by-line verification depletesmental energy, reducing the practitionerâs perceived efficacy andcapacity to perform their role effectively. Fears of skill atrophy Prolonged reliance on AI threatens the practitionerâs belief in theirlong-term capability, creating anxiety that their core technicalmastery will degrade over time. Relatedness (The need to feel connected, supported, and valued within asocial context) Governance ambiguity & Adoption pressure The organizationâs âtrust-by-defaultâ culture paradoxically isolatespractitioners, transferring compliance liability onto the individual without providing supportive, clear guardrails or shared best practices. Epistemic uncertainty (e.g., Testers) When organizational âexperiment-and-shareâ strategies yieldresults irrelevant to specific roles, practitioners feel disconnectedfrom the broader teamâs learning process and undervalued in theirspecific contributions. , Vol. 1, No. 1, Article . Publication date: September 2026. 36Alami, et al. 5.3 Boundary Conditions of the Findings Different psychological costs may have different boundary conditions [47], reflecting the organizational setting, the stage of adoption, and the relationship between AI and engineering work. Our purpose is to qualify the analytical transferability of the proposed explanation [47]. The conditions discussed below are informed by the case; their effects have not been independently established. The significance of activities assumed by AI. Agency displacement, craft identity disruption, and meaning erosion may depend on how practitioners value the activities delegated to AI. These costs may be particularly salient when AI assumes activities through which practitioners express expertise, authorship, and accomplishment. These costs may be weaker when work carries little personal significance. The relevant boundary therefore concerns practitionersâ relationships with particular activities, and not occupational roles or adoption levels alone. Accountability relative to assurance capacity. The relationship between delegated software production and accountability anxiety may depend on practitionersâ capacity to discharge their retained responsibilities. At SoftHouse, established quality obligations and regulated domains made assurance particularly consequential. However, regulation is not necessarily a prerequisite; comparable tensions may arise wherever practitioners remain responsible for software they cannot adequately understand, validate, or justify. Where outputs remain reviewable and practitioners have sufficient expertise, time, and support, delegation may not produce the same anxiety or verification burden. This boundary concerns the relationship between responsibility and the conditions for exercising it. Adoption expectations relative to learning conditions. The uncertainty pathway may depend partly on whether organizational expectations accommodate the difficulty of establishing workable practices. In our case, practitioners navigated rapid technological change, limited actionable knowledge, and uneven applicability while continuing to meet delivery obligations. These conditions may produce different experiences where adoption expectations reflect applicable use cases, compliance constraints, and available learning capacity. Technological uncertainty may persist in such settings, but the additional pressure to demonstrate progress need not take the same form. Accordingly, uncertainty distress should not be interpreted solely as insecurity or a perception of AI as threatening. Future developments in AI products may resolve some current limitations and make previously unsuitable use cases viable, reducing some sources of uncertainty while introducing new demands for learning and adaptation. Discretion over AI use. Some responses identified in the model depend on practitioners retaining discretion over how work is performed. Bounded delegation, deliberate verification, and preserving opportunities for manual work require some influence over task allocation and working practices. AI adoption at SoftHouse was encouraged but not mandated, although organizational expectations still exerted pressure. Where AI use is tightly prescribed, these responses may be less available. The observed patterns of managing, mitigating, and absorbing costs should therefore not be assumed to transfer unchanged to those settings. Where organizational prescriptions restrict practitionersâ ability to limit delegation or retain manual work, they constrain practices through which costs were managed or mitigated in our case. For example, preserving competence through manual coding depends on having opportunities to continue that activity. Practitioners facing tighter restrictions may therefore require alternative responses. The categories of managing, mitigating, and absorbing costs may remain applicable, but the practices through which they are enacted and their relative prominence may differ. Our study does not establish how practitioners respond when these choices are constrained. , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering37 The stage of adoption. Our explanation reflects experiences approximately one year after the adoptionâs launch, while governance and working practices were still developing. As usable knowledge and assurance arrangements become more established, some sources of uncertainty may diminish. Meanwhile, further delegation may introduce different demands on verification, professional identity, and meaning. Our model therefore does not imply that costs inevitably decline with experience or increase with adoption. Our snapshot cannot establish which relationships persist, weaken, or change over time; these temporal boundaries require longitudinal investigation. 5.4 Practical Implications & Future Research While our findings identify a spectrum of psychological costs associated with organizational AI adoption, we focus our practical implications on two related implications: agency displacement, and the verification tax. We prioritize these themes for two reasons. First, they directly challenge the dominant industry narrative that frames generative AI predominantly as a productivity multiplier, revealing instead the hidden cognitive and professional costs of AI-supported SE work. Second, they explain the root cause of practitioner behaviours in AI-human collaboration other than âresistance to change,â but as a rational response to the psychological and professional challenges. Our findings suggest that successful organizational AI adoption depends not only on deploying increasingly capable AI systems but also on understanding how AI redistributes human work and challenges identity in SE. While agency displacement draws attention to the extent to which AI assumes activities through which practitioners exercise professional judgment and professional identity, the verification tax highlights the additional cognitive and engineering effort required for practitioners to remain accountable for their work when AI-assisted. Agency Displacement. We found that psychological costs are not uniform, but probably proportional to the degree of agency displacement, i.e., the extent to which AI substitutes the core generative activities through which practitioners exercise their expertise. The greater this displacement, the greater the psychological costs experienced by practitioners. Software engineers, whose professional identity is deeply tied to authoring code, experience the highest displacement. The psychological costs of AI adoption seem to be proportional to the degree to which AI replaces the core activities through which a practitioner exercises their professional agency. It shows that the psychological costs we observed maybe not resistance to change, but a rational and a human response to the displacement of the specific tasks that define a roleâs professional worth. The Software Craftsmanship movement argues that software engineering is more than producing functional code; it is a professional craft emphasizing mastery, continuous learning, pride in workmanship, and responsibility for quality [1]. Sundelin et al. demonstrates that professional identity in software engineering is deeply tied to specific generative activities, such as writing clean code, refactoring, test-focused development, and participatory architecture [41]. Our study shows that when AI systems assume these core activities, they do not merely automate tasks; they can challenge professional identity, and established norms of craftsmanship. These findings help explain how AI adoption challenges professional identity and craftsmanship standards. Implication: Our findings suggest that successful organizational AI adoption should be evaluated not only by the extent to which AI augments software development, but also by the extent to which it preserves opportunities for practitioners to exercise meaningful professional agency and craftsmanship qualities. Our findings also suggest that a single AI adoption strategy is unlikely to be equally effective across software engineering roles. Because the degree of agency displacement varies by role, organizations should tailor AI integration accordingly. Implication: AI adoption for software engineers, should give more attention to preserving opportunities to engage in creative and , Vol. 1, No. 1, Article . Publication date: September 2026. 38Alami, et al. generative activities, whereas adoption strategies for architects or testers may focus more on augmenting decision making. Future Research: Future work should develop agency displacement as an empirical construct by identifying measurable dimensions, validating instruments, and examining how different levels of displacement relate to psychological costs, job satisfaction, and long-term adoption outcomes across software engineering roles. Verification Tax. For software engineers, AI adoption seems to shift accountability from production and quality to verification. While AI reduces the manual effort of writing code, it drastically increases the cognitive burden of verifying, justifying, and taking accountability for AI-generated outputs. AI introduces a significant âverification taxâ by shifting software engineersâ cognitive load from production to evaluation. Conceptually, the verification tax does not represent a sixth psychological cost, but rather the direct synthesis of the accountability anxiety and cognitive load intensification identified in our findings. It captures the specific cognitive and professional toll exacted when practitioners are required to bridge the gap between their retained accountability for AI outputs and their diminished control over their generation. As they remain fully accountable for AI-generated outputs, they expend intense mental resources to verify, justify, and debug opaque code. If engineers cannot understand how the AI arrived at a solution, the cognitive load of verifying it becomes unsustainable. Software engineers do not verify code because they finished writing it; they verify code while they are writing it. Software engineers are traditionally educated to solve problems through an integrated cognitive process in which understanding the problem, designing a solution, writing code, and verifying correctness evolve together. By externalizing code generation, AI compresses this process into predominantly post hoc verification, requiring practitioners to evaluate solutions without having participated fully in the reasoning that produced them. This raises important questions for AI adoption in software engineering, and education. Implication: In industry practice, the existence of a verification tax dictates that the productivity gains of AI cannot be measured solely by code generation speed. Organizations must explicitly account for the increased cognitive load of code verification in capacity planning and sprint estimates. Future Research. AI tool builders must prioritize verification and provenance-tracking features to reduce the mental burden of validating opaque outputs, ensuring that the engineerâs shift toward evaluation remains a sustainable and safe engineering practice. Our findings also draw attention to software engineering education to preserve the fundamental competencies through which students develop the ability to reason about, construct, and verify software, as meaningful verification is only possible when engineers possess sufficient conceptual and technical understanding to critically evaluate AI-generated solutions. At the same time, AI- assisted development introduces a new class of verification skills, including evaluating AI reasoning, identifying subtle errors, assessing generated code against architectural intent, and deciding when AI outputs can or cannot be trusted, that deserve explicit attention in future curricula. Implication: Curricula needs to address âAI-assisted verification,â teaching them how to critically evaluate, debug, and trace the reasoning of machine-generated code. Furthermore, pedagogical approaches should seek to understand how manual coding rituals promote skills or how âself-then-AIâ sequencing may assist students develop the foundational cognitive links between problem understanding and solution validation before relying on automation. Future Research. Future educational research should therefore investigate how these emerging verification competencies can be developed without compromising the foundational skills upon which effective verification depends. , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering39 6 RESEARCH TRUSTWORTHINESS Meaning Saturation. We established trustworthiness through meaning saturation [22]. We monitored saturation throughout the iterative analysis by continuously comparing new interview excerpts and Second Cycle Pattern Codes meaning against the evolving codes in prior iterations. Data collection was considered sufficient when additional interviews no longer expanded the conceptual properties of the identified themes or their relationships within the emerging model [22]. Saturation was assessed across software engineering roles rather than within individual participant groups to ensure that the conceptual model captured the breadth of practitionersâ experiences across the organization. Aware of our design choice of treating software practitioners as a single cohort, we carried out a magnitude analysis (see Tbl. 7) to understand the variation across roles. Because saturation was assessed at the sample level, we do not claim meaning saturation within individual roles, particularly those represented by only three participants. Accordingly, the magnitude analysis is descriptive, and the observed role-based patterns are treated as exploratory rather than conclusive. Member Checking. Member checking was conducted to establish the reliability of our findings. We provided participants with our interpretations and sought their feedback [13,43], see Sect. 3.8. 7 LIMITATIONS AND TRADE-OFFS We treated âsoftware practitionersâ as a single cohort when studying AI adoption. Although this design carried limitations, our contribution provides a nuanced, role-contingent results. This treatment also yielded findings, we would not have otherwise. For example, the definition of agency displacement might not have been possible if we had only focused on software engineers. Our findings are necessarily situated in the organizational context of SoftHouse. Its regulated domains, strong quality and accountability culture, mature engineering practices, and experiment- and-share strategy may have shaped how psychological costs were experienced and which organizational conditions amplified them. We therefore do not claim that the prominence of individual costs or the observed role patterns will transfer unchanged to other organizations. However, context dependence is intrinsic to explanatory case research [48]. Our aim is analytical; by describing the case context and distinguishing AI-related sources from organizational amplifiers, we enable readers to assess the transferability of the proposed constructs and relationships to other settings. Our sample is not balance on software roles; it is skewed towards software engineers. While this design choice reflects SoftHouse software practitioners population, it may have introduced an internal threat to validity. Some findings are role-specific, i.e., verification tax. We may have also missed the opportunity to reveal richer findings for the other roles, i.e., senior management, architects, and testers. The study captures a cross-sectional âsnapshotâ (data collected at a single and specific point in time) of practitionersâ experiences at a specific point in time (i.e., one year into the AI adoption). However, AI and its adoption are evolving; the technology and organizational policies are moving targets. Therefore, the psychological costs and the the practitionersâ responses (Manage, Mitigate, Absorb) may likely evolve. A cross-sectional design cannot determine the long-term trajectory of these costs and responses. For example, it remains unknown whether practitioners who currently âabsorbâ the loss of generative joy will eventually experience long-term burnout or attrition, or whether the feared âskill atrophyâ will actually materialize and impact code quality over a 3-to-5- year period. This limitation is an opportunity for future studies to track developers over a long period to observe how their psychological resources deplete or recover, and how their adaptive responses evolve as AI tools become more explainable and integrated. , Vol. 1, No. 1, Article . Publication date: September 2026. 40Alami, et al. Nineteen of the 21 participants had more than ten years of professional experience. This strengthened the study because experienced practitioners could compare AI-mediated work with well-established engineering practices, professional identities, and accountability norms. However, their over-representation may have foregrounded costs associated with disrupted expertise and craft identity. Less-experienced practitioners, whose skills and professional identities are still developing, may experience AI adoption differently. We did not conduct a gender-based analysis to identify gender specific patterns in our data. This is due to low representation of women in our sample. Future research may consider a gender-base design to investigate AI adoption impact on software professionals. 8 CONCLUSION Artificial intelligence is rapidly becoming an integral part of software engineering practice, yet organizational AI adoption has largely been viewed through the lenses of productivity, efficiency, and technical capability. This study shows that such a perspective imaybe not always complete. Through an in-depth case study of organizational AI adoption, we identified five psychological costs experienced by software practitioners: uncertainty distress, accountability anxiety, cognitive load intensification, craft identity disruption, and meaning and satisfaction erosion. We further showed that these costs are shaped jointly by the disruptive characteristics of AI and the organizational conditions through which AI is introduced, and that practitioners respond by managing, mitigating, or absorbing these costs to preserve valued psychological resources. Beyond identifying these psychological costs, our findings contribute two concepts that help explain the human experience of AI adoption in software engineering. Agency displacement explains why psychological costs vary across software engineering roles, highlighting that the extent to which AI assumes the activities through which practitioners exercise their expertise influences how AI adoption is experienced. Verification tax reveals that while AI reduces the effort required to generate software artifacts, it simultaneously increases the cognitive effort required to understand, justify, and remain accountable for them. Together, these concepts re-position AI for SE from what AI can generate to what software practitioners must continue to do to remain responsible engineers. Our findings suggest that successful organizational AI adoption should not be evaluated by productivity gains or technical augmentation only. Rather, it should also consider how AI reshapes the human experience of software engineering, including practitionersâ agency, competence, professional identity, and capacity to exercise responsible engineering judgment. By bringing psychological costs into the study of AI adoption, we hope this work contributes to a more human- centered understanding of how AI can augment software engineering without diminishing the role of the people who practice it. GENERATIVE-AI USE Paperpal 6 was used throughout the writing process and solely for text improvements. The draft was produced independently by the first author. First, the âGrammarâ feature of Paperpal was used to fix grammar issues and proofreading. Subsequently, the âRewriteâ feature with the âImprove fluencyâ option checked was used to enhance the final text. The re-generated text from the tool was adopted after the first author verified the edits and accepted or rejected the suggestions as deemed appropriate. Once the paperâs text became available, the second and third authors reviewed the text without tooling assistance. 6 https://edit.paperpal.com/ , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering41 ACKNOWLEDGMENTS We are thankful to participating organization and to all interviewees who generously shared their time, experiences, and insights. This study would not have been possible without their openness, and willingness to reflect honestly on their AI adoption journey. This work is supported by the Innovation Fund Denmark for the project AI4SE1DK (4354-00006B). REFERENCES [1] 2009. Manifesto for Software Craftsmanship. https://manifesto.softwarecraftsmanship.org/. Accessed: July 2026. [2]Adam Alami, Nathan Cassee, Thiago Rocha Silva, Elda Paja, and Neil A Ernst. 2025. Engagement in Code Review: Emotional, Behavioral, and Cognitive Dimensions in Peer vs. LLM Interactions. arXiv preprint arXiv:2512.05309 (2025). [3]Adam Alami and Neil Ernst. 2024. Understanding the building blocks of accountability in software engineering. In Proceedings of the 2024 IEEE/ACM 17th International Conference on Cooperative and Human Aspects of Software Engineering. 153â163. [4]Adam Alami and Neil Ernst. 2025. Human and Machine: How Software Engineers Perceive and Engage with AI-Assisted Code Reviews Compared to Their Peers. In 2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE). IEEE, 63â74. [5] Adam Alami, Victor Vadmand Jensen, and Neil A Ernst. 2025. Accountability in code review: The role of intrinsic drivers and the impact of llms. ACM Transactions on Software Engineering and Methodology (2025). [6]Khaldoun M Aldiabat and Carole-Lynne Le Navenec. 2018. Data saturation: The mysterious step in grounded theory methodology. The qualitative report 23, 1 (2018), 245â261. [7]American Psychological Association. Accessed: July 2026. How Does the APA Define âPsychologyâ? (Accessed: July 2026). [8] Anthropic. 2026. Code Review. https://code.claude.com/docs/en/code-review. Claude Code Documentation, accessed: 2026-08-26. [9]Ramakrishna Ayyagari, Varun Grover, and Russell Purvis. 2011. Technostress: Technological antecedents and implications1. MIS quarterly 35, 4 (2011), 831âA10. [10]Arnold B Bakker and Evangelia Demerouti. 2007. The job demands-resources model: State of the art. Journal of managerial psychology 22, 3 (2007), 309â328. [11]Shraddha Barke, Michael B James, and Nadia Polikarpova. 2023. Grounded copilot: How programmers interact with code-generating models. Proceedings of the ACM on Programming Languages 7, OOPSLA1 (2023), 85â111. [12]Stephen R. Barley. 1986. Technology as an Occasion for Structuring: Evidence from Observations of CT Scanners and the Social Order of Radiology Departments. Administrative Science Quarterly 31, 1 (1986), 78â108. [13] Linda Birt, Suzanne Scott, Debbie Cavers, Christine Campbell, and Fiona Walter. 2016. Member checking: a tool to enhance trustworthiness or merely a nod to validation? Qualitative health research 26, 13 (2016), 1802â1811. [14]Charlotte Brandebusemeyer, Kerim Zunic, Thomas Zimmermann, Tobias Schimmer, and Bert Arnrich. 2026. Developersâ Experience with Generative AI Beyond Productivity AssessmentâInsights from an Empirical Mixed-Methods Field Study. arXiv preprint arXiv:2607.02337 (2026). [15] Harry Braverman. 1998. Labor and monopoly capital: The degradation of work in the twentieth century. nyu Press. [16]Edward L Deci and Richard M Ryan. 2012. Self-determination theory. Handbook of theories of social psychology 1, 20 (2012), 416â436. [17]DORA. 2025. State of AI-assisted Software Development. Technical Report. Google Cloud. https://dora.dev/dora-report- 2025/ Accessed: July 2026. [18] Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M Zhang. 2023. Large language models for software engineering: Survey and open problems. In 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE). IEEE, 31â53. [19]Guangrui Fan, Dandan Liu, Lihu Pan, and Rui Zhang. 2026. When Help Hurts: Verification Load and Fatigue with AI Coding Assistants. In Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems. 1â25. [20]Luciane Fortes, Guilherme Vaz Pereira, Andre Coelho, Rafael Prikladnicki, and Karina Kohl. 2026. The Productivity Paradox of AI-Powered Development. IEEE Software (2026). [21]Mariam Guizani, Maduka Subasinghage, Sherlock Licorish, and Sofia Ouhbi. 2026. At What Cost? Software Developersâ Well-Being in the Age of GenAI. In Proceedings of the 34th ACM International Conference on the Foundations of Software Engineering. 1326â1330. [22] Monique M Hennink, Bonnie N Kaiser, and Vincent C Marconi. 2017. Code saturation versus meaning saturation: how many interviews are enough? Qualitative health research 27, 4 (2017), 591â608. , Vol. 1, No. 1, Article . Publication date: September 2026. 42Alami, et al. [23]Stevan E Hobfoll. 1989. Conservation of resources: a new attempt at conceptualizing stress. American psychologist 44, 3 (1989), 513. [24] Stevan E Hobfoll. 2011. Conservation of resources theory: Its implication for stress, health, and resilience. The Oxford handbook of stress, health, and coping 127 (2011), 147. [25]Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large language models for software engineering: A systematic literature review. ACM Transactions on Software Engineering and Methodology 33, 8 (2024), 1â79. [26]Victor Vadmand Jensen, Adam Alami, Anders Rysholt Bruun, and John Stouby Persson. 2025. Managing expectations towards AI tools for software development: a multiple-case study. Information Systems and e-Business Management 23, 4 (2025), 869â901. [27]Dharneeka Jeyam, Anna Wiedemann, Gerhard Schwabe, and Kadircan GĂŒney. 2026. âStill in the Loopââ: Coping with Technostress in DevOps Teams and the Impact of GenAI. In Proceedings of the IEEE/ACM 48th International Conference on Software Engineering: Software Engineering in Practice. 590â600. [28]Kai-Kristian Kemell, Matti Saarikallio, Anh Nguyen-Duc, and Pekka Abrahamsson. 2025. Still just personal assistants?â A multiple case study of generative AI adoption in software organizations. Information and Software Technology 186 (2025), 107805. [29] Heesung Kwon, Jeesun Oh, Suyoun Lee, Sunok Lee, and Sangsu Lee. 2026. Investigating AI-induced Technostress and Coping Strategies of Professionals. In Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems. 1â16. [30] Richard S Lazarus. 1984. Stress, appraisal, and coping. Vol. 464. Springer. [31]Jenny T. Liang, Chenyang Yang, and Brad A. Myers. 2024. 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. ACM, 1ĂąÄĆ13. https://doi.org/10.1145/3597503.3608128 [32]Matthew B Miles, A Michael Huberman, and Johnny Saldaña. 2014. Qualitative data analysis: A methods sourcebook. 3rd. Thousand Oaks, CA: Sage. [33] Janice M Morse. 2004. Theoretical saturation. Encyclopedia of social science research methods 3 (2004), 1122â3. [34] Mohammed Mubarkoot, Jörn Altmann, Myung Jin Lee, and Morteza Rasti-Barzoki. 2026. Workarounds in Software Engineering: The Impact of Technostress and the Moderating Roles of Neutralization, Autonomy, and Behavioral Control. Information and Software Technology (2026), 108145. [35]TS Ragu-Nathan, Monideepa Tarafdar, Bhanu S Ragu-Nathan, and Qiang Tu. 2008. The consequences of technostress for end users in organizations: Conceptual development and empirical validation. Information systems research 19, 4 (2008), 417â433. [36] Per Runeson and Martin Höst. 2009. Guidelines for conducting and reporting case study research in software engineering. Empirical software engineering 14, 2 (2009), 131â164. [37]Daniel Russo. 2024. Navigating the complexity of generative ai adoption in software engineering. ACM Transactions on Software Engineering and Methodology 33, 5 (2024), 1â50. [38]Richard M Ryan and Edward L Deci. 2000. Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being. American psychologist 55, 1 (2000), 68. [39] Carol D Ryff. 1989. Happiness is everything, or is it? Explorations on the meaning of psychological well-being. Journal of personality and social psychology 57, 6 (1989), 1069. [40] Stack Overflow. 2025. 2025 Developer Survey: AI. https://survey.stackoverflow.co/2025/ai/. Accessed: July 2026. [41] Anders Sundelin, Javier Gonzalez-Huerta, Krzysztof Wnuk, and Tony Gorschek. 2022. Towards an Anatomy of Software Craftsmanship. ACM Transactions on Software Engineering and Methodology 31, 1, Article 5 (2022), 49 pages. https://doi.org/10.1145/3468504 [42] Monideepa Tarafdar, Qiang Tu, Bhanu S Ragu-Nathan, and TS Ragu-Nathan. 2007. The impact of technostress on role stress and productivity. Journal of management information systems 24, 1 (2007), 301â328. [43]David R. Thomas. 2017. Feedback from research participants: Are member checks useful in qualitative research? Qualitative Research in Psychology 14, 1 (2017), 23â41. https://doi.org/10.1080/14780887.2016.1219435 [44]Eric Lansdown Trist and Kenneth W Bamforth. 1951. Some social and psychological consequences of the longwall method of coal-getting: An examination of the psychological situation and defences of a work group in relation to the social structure and technological content of the work system. Human relations 4, 1 (1951), 3â38. [45]Priyan Vaithilingam, Tianyi Zhang, and Elena L Glassman. 2022. 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. 1â7. [46]Annie Vella and Kelly Blincoe. 2026. The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study. arXiv preprint arXiv:2605.23135 (2026). [47] Robert K Yin. 2013. Validity and generalization in future case study evaluations. Evaluation 19, 3 (2013), 321â332. , Vol. 1, No. 1, Article . Publication date: September 2026. The Psychological Costs of Artificial Intelligence Adoption in Software Engineering43 [48] Robert K Yin. 2018. Case study research and applications. Vol. 6. Sage Thousand Oaks, CA. [49]Ilya Zakharov, Ekaterina Koshchenko, and Agnia Sergeyuk. 2025. Ai in software engineering: Perceived roles and their impact on adoption. In Proceedings of the 33rd ACM International Conference on the Foundations of Software Engineering. 1305â1309. [50]Albert Ziegler, Eirini Kalliamvakou, X Alice Li, Andrew Rice, Devon Rifkin, Shawn Simister, Ganesh Sittampalam, and Edward Aftandilian. 2024. Measuring github copilotâs impact on productivity. Commun. ACM 67, 3 (2024), 54â63. [51] Shoshana Zuboff. 1988. In the age of the smart machine: The future of work and power. Basic Books, Inc. , Vol. 1, No. 1, Article . Publication date: September 2026.