Engineers shape how generative AI enters their work, but only when their workflow, their autonomy, and their governance leave them room to do so.
Last week I gave the opening keynote at I4CS 2026, whose motto this year is “People Empower Technology.” The phrase is an aspiration, and I spent the talk testing it against the evidence my research has gathered over the past two years. I drew the talk together as an evidence-based review of where my own work on adoption now stands (Russo, 2026). The short version is that the motto is true with a condition attached. People do empower technology when they can. The “when they can” is the part the industry keeps skipping, and it is the part that decides whether an AI rollout produces capability or resentment.
The dominant narrative still treats adoption as a property of the tool. Ship a more capable model, the reasoning goes, and uptake follows. If engineers resist, the tool was not good enough, or the people were not ready. This framing is comfortable for vendors and convenient for executives, because it locates the problem anywhere except in the organization doing the deploying.
The data points the other way. Adoption is a property of the system the tool enters, not of the tool itself. Across a program of studies on generative AI in software engineering, the variables that predict whether engineers take up a tool and keep using it are the ones that describe their working conditions rather than the ones that describe the model. This is a more demanding finding than it first appears, because conditions are something leadership controls, and capability is something it merely purchases.
The condition the acceptance model missed
For thirty years, the technology acceptance model has told us that perceived usefulness is the engine of adoption. If people believe a tool will help them perform better, they use it. The model has held up well enough across decades of information-systems research that it has become a default assumption, rarely re-examined.
It does not hold for generative AI in software engineering, at least not at this stage of integration. In a convergent mixed-methods study, I surveyed software engineers across three levels of analysis (individual, technological, and social), grounded in the technology acceptance model (Davis, 1989), diffusion of innovation theory (Rogers, 2003), and social cognitive theory (Bandura, 1986). A first questionnaire with 100 engineers established the baseline. Qualitative analysis using the Gioia methodology (Gioia et al., 2013) produced the Human-AI Collaboration and Adaptation Framework, and a PLS-SEM validation with an independent sample of 183 engineers confirmed its structure, 283 practitioners in total (Russo, 2024).
The central result cut against the literature the study was built on.
At this stage of AI integration, compatibility with existing development workflows, not perceived usefulness, is what drives adoption. A tool that fits how engineers already work will get adopted regardless of how sophisticated it is; one that disrupts established routines will be resisted, no matter how capable.
Read that as a claim about agency. Compatibility is the workflow condition for empowerment. When a tool slots into the rhythm an engineer has already built, she retains control over her own process and folds the tool into it on her terms. When the tool demands that she reorganize her work around it, the tool is now directing her, and she pushes back, exactly as the agency reading predicts. Perceived usefulness, the thing the model told us to optimize, turns out to be downstream of whether the engineer keeps her hand on the wheel.
Two further results from the same study sharpen the point. Self-efficacy and prior experience with AI tools mattered more at the individual level than general enthusiasm about AI’s potential, which is to say that the engineers who already felt competent to interrogate the output were the ones who engaged, not the ones most excited by the hype. And at the social level, peer usage and community norms influenced willingness to engage, but social influence by itself did not sustain adoption over time. Enthusiasm and peer pressure get a tool in the door. Only compatibility keeps it in use.
Why mandates remove the condition they need
If compatibility drives adoption, the blanket mandate is the intervention most likely to fail, because a mandate is a bet that usefulness can be ordered into existence regardless of fit. Two companion studies test the edges of this, and both point the same way.
The first asked whether culture changes the picture. Working with 188 software engineers, Lambiase and colleagues tested whether Hofstede’s cultural dimensions moderate the UTAUT2 adoption relationships (Lambiase et al., 2026). The expectation, reasonable enough, was that adoption dynamics would vary by cultural context. They did not, in the statistical sense. Habit and performance expectancy emerged as the primary drivers of large-language-model adoption, and cultural values did not significantly moderate the process. Habit is the operative word. Adoption that lasts is adoption that has become routine, and routine is something an engineer builds, not something a policy installs.
The second study looked at how engineers adopt across different tasks rather than in general. Surveying 188 engineers, Lambiase and colleagues found that task-specific adoption is influenced by distinct factors, some of which negatively affect adoption when considered in isolation (Lambiase et al., 2025). Engineers do not trust AI uniformly across their work. They extend it to some tasks and withhold it from others, and the pattern is specific enough that a single organizational rule cannot capture it.
Put the two findings together, and the mandate trap is visible. A blanket adoption mandate, organizational or policy-driven, assumes uniform uptake across people, cultures, and tasks. The evidence says uptake is heterogeneous on all three axes. The mandate, therefore, forces a single answer onto a question that has many correct ones, and the predictable result is nominal compliance paired with quiet evasion. A mandate strips exactly the autonomy that agency runs on. Tell an engineer they must use a given tool for a given task, and you remove their judgment from the one place it is most informative: which task she actually trusts the tool with.
None of this counsels against encouraging adoption. The point is about the mechanism. The cultural-values study named two levers that work, showing engineers a real performance benefit and giving habits room to form, and both run with the grain of how people take up a tool. A mandate runs against it.
What erodes when the conditions are absent
Agency has a half-life. When the workflow and autonomy conditions are absent, the cost does not arrive as a sudden refusal. It arrives as a slow erosion of the capacities that made the engineer valuable in the first place, and the clearest place to watch this is creativity.
As routine coding is increasingly automated, human creativity becomes the differentiating factor, and the open question is whether AI widens or narrows it. With colleagues across several institutions, we set a research agenda around this question using the 4P framework of creativity (Jackson et al., 2025). Person asks how reliance on AI changes creative self-efficacy. Product asks whether AI expands or narrows the solution space an engineer considers. Process asks whether AI accelerates genuine exploration or quietly replaces it. Press asks how team norms around AI shape creative freedom. The honest state of the evidence is that we do not yet know the answers, and that the answers are not guaranteed to be favorable.
The reason this belongs in a discussion of agency is the Press dimension. Whether AI broadens or narrows an engineer’s creative range depends heavily on the norms the team sets around it, which is to say on the conditions leadership creates. A team that treats AI as one voice among several, to be argued with, preserves the exploration that creativity depends on. A team that treats AI output as the default answer to be edited lightly has already narrowed the solution space before anyone has thought about the problem. The tool is identical in both cases. The condition is not.
This is where the sustainability concern becomes concrete rather than rhetorical. Short-term productivity gains that erode developer skill and the team’s capacity for creative work are not gains at all once the horizon extends past a few quarters. The capacity you are spending is the capacity that distinguishes your engineering organization from any other organization with a license to the same model.
Governance as the condition you can design
The studies describe what is happening. The question of what to do about it is normative, and that is the work the Copenhagen Manifesto was written to do. It grew out of the Copenhagen Symposium on Human-Centered Software Engineering AI, held at Aalborg University in November 2023, and it was written by 35 researchers from institutions worldwide (Russo et al., 2024). It is organized around four principles for human-centered AI in software engineering: responsibility, transparency, inclusivity, and sustainability.
The principles are informed by the evidence without being deducible from it, and the relationship is worth stating precisely because it is easy to overclaim. If compatibility drives adoption, then responsible deployment has to respect existing workflows rather than override them. If habit predicts adoption more strongly than culture moderates it, governance still ought to be inclusive, precisely because the empirical picture is incomplete and the cost of getting it wrong is borne unevenly. If automation threatens creative capacity, then practices have to be sustainable enough to preserve it. The manifesto is a normative synthesis of what the evidence suggests, not a deductive conclusion from it, and I would rather say that plainly than dress a set of values as a theorem.
Governance, understood this way, is the condition leadership has the most direct power to set. Workflow compatibility is partly a property of the tool market. Individual self-efficacy accrues slowly. But the rules a team operates under, who decides which tasks use AI, how output is treated, what gets measured, are designed, not inherited. They are the most tractable of the three conditions, and they are the one most organizations leave to default.
A 30-minute adoption-readiness drill
Before the next tool rolls out, run this with the team that will use it. It shows whether the conditions for agency are in place before you commit the budget.
1. Name the workflow it touches (5 min). Write down the exact sequence of steps the tool inserts itself into. If no one can describe the current workflow precisely, you are not ready to judge compatibility.
2. Score the fit, not the features (5 min). Ask one question: does this tool fit the steps we just wrote down, or does it ask us to change them? A tool that requires reorganizing the workflow starts at a deficit no capability can repay.
3. Map the tasks (5 min). List the tasks the tool could touch and mark, per task, whether the team currently trusts AI with it. Expect disagreement. The disagreement is the data.
4. Check the mandate reflex (5 min). Ask whether the rollout plan assumes everyone will use the tool the same way for the same tasks. If it does, you are about to test the mandate trap on your own team.
5. Locate the creative surface (5 min). Identify the one task in the list where the team’s creative judgment matters most, and decide explicitly whether the tool is allowed to produce the default answer there or only to offer options.
6. Set the rule, then write it down (5 min). Agree on who owns the answer to “which tasks, treated how,” and record it. An unwritten governance rule is an absent governance rule.
Next moves
For the Builder
Audit your own flow before you adopt anything. If a tool fights the sequence you have already optimized, the tool loses, regardless of its benchmark scores; trust that instinct, because the evidence backs it. Keep a record, even informal, of which tasks you genuinely trust AI with and which you do not, and revisit it monthly as your competence with the tool changes. Protect at least one task where you do the creative work unaided. Not for nostalgia; that task is where your judgment gets formed. When a tool is mandated for a task you do not trust it with, document your reasoning and circulate it rather than complying silently; forcing the question into the open is itself useful information for the people above you.
For the Manager
Stop scoring tools by their feature lists and start scoring them by their fit with your team’s existing workflow, because that is what predicts whether the tool will still be in use in six months. When you pilot a change, expect uptake to vary by person and by task, and treat that variation as signal rather than as a problem to standardize away. Resist the blanket mandate even when it is handed to you, and translate any central directive into a task-level operating note your team can actually apply; if you cannot translate it, that is information to send back upward. Frame AI to your team as filling several roles (assistant, advisor, reference) rather than as a single-purpose productivity booster, because the diverse mental model is the one the evidence associates with better outcomes.
For the Roadmap Owner
Treat adoption as an organizational design problem, not a procurement problem. Do not price your roadmap on assumed automation gains; price it on augmentation, with the understanding that compatibility, not capability, governs whether the gains materialize. Build governance as a federation: set the risk frame and the non-negotiables centrally, delegate task-level translation to engineering leaders, and hold them accountable for the quality of that translation rather than for uniform compliance. Add a sustainability line to your engineering scorecard that tracks whether your AI strategy is preserving or spending the skill and creative capacity your competitive position rests on, and review it on the same cadence as your delivery metrics.
Closing thought
The I4CS motto assumes people can still direct technology. The evidence says they can, but only inside conditions that someone has to build, and that someone is usually not the engineer. The most useful question a leader can ask this quarter is not which model to buy. It is whether those three conditions of workflow, autonomy, and governance hold for the tools already in the building. Which of the three is weakest in your organization right now, and who owns fixing it?
Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.
If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.
danielrusso.org/advisory (Öffnet in neuem Fenster)
References
Bandura, A. (1986). Social foundations of thought and action: A social cognitive theory. Prentice-Hall.
Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319–340.
Gioia, D. A., Corley, K. G., & Hamilton, A. L. (2013). Seeking qualitative rigor in inductive research: Notes on the Gioia methodology. Organizational Research Methods, 16(1), 15–31.
Jackson, V., et al. (2025). The impact of generative AI on creativity in software development: A research agenda. ACM Transactions on Software Engineering and Methodology, 34(5), 1–28.
Lambiase, S., Catolino, G., Palomba, F., Ferrucci, F., & Russo, D. (2026). Investigating the role of cultural values in adopting large language models for software engineering. ACM Transactions on Software Engineering and Methodology, 35(1), 1–43.
Lambiase, S., Catolino, G., Palomba, F., Ferrucci, F., & Russo, D. (2025). Exploring individual factors in the adoption of LLMs for specific software engineering tasks. arXiv preprint arXiv:2504.02553.
Rogers, E. M. (2003). Diffusion of innovations (5th ed.). Free Press.
Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1–49.
Russo, D. (2026). People empower technology, when they can: Evidence-based perspectives on generative AI adoption in software engineering. In K. Kirchner et al. (Eds.), I4CS 2026, CCIS 3007 (pp. 1–6). Springer.
Russo, D., et al. (2024). Generative AI in software engineering must be human-centered: The Copenhagen Manifesto. Journal of Systems and Software, 216, 112115.
Datum
23.06.2026