AI-Assisted Software Engineering: The Changing Nature of Developer Work, Wellbeing, Identity and Long-Term Capability

Introduction

AI coding assistants are changing software engineering at a level deeper than tooling. The attraction is obvious: developers can generate, transform, test and explain code much faster. But software engineering was never just the production of source code. It is a socio-technical system that depends on judgement, learning, collaboration, ownership and the development of people.

That raises a leadership question:

If AI changes the amount of code developers personally write, what happens to the capabilities, motivation, identity and wellbeing that have historically been developed through writing and working with code?

The evidence so far supports neither “AI is bad for developers” nor “AI simply makes developers more productive.” What it does show is that AI changes the distribution of work, and that its effect on measured productivity is far less settled than most organisations assume. Developers write less and review, direct and correct more. The net effect on output, and the toll it takes, depends on the task, the codebase and how the tools are used.

The central leadership principle:

AI should increase human leverage without reducing human capability, and leaders should not assume leverage exists until they’ve measured it.

Where it matters, claims are flagged as one of three kinds:

• Direct evidence: findings from named, checkable empirical studies.
• Interpretation / synthesis: conclusions drawn by connecting findings across sources.
• Hypothesis: plausible risks or opportunities for which the evidence is still developing.

1. Productivity Is Not the Same Thing as a Healthy Engineering System

One of the easiest mistakes in the AI era is to equate increased output with increased productivity, or to assume AI produces a time saving at all.

Accelerate (Forsgren, Humble & Kim, 2018) frames technology performance through system-level delivery measures rather than individual output: deployment frequency, lead time for changes, change failure rate, and time to restore service. Its argument is that delivery performance emerges from the whole system, and maximising one person’s local activity does little for it.

Will Larson’s An Elegant Puzzle (2019) treats developer velocity the same way. Producing pull requests or commits faster doesn’t necessarily get useful software to customers faster. The bottleneck moves elsewhere. Larson also emphasises organisational slack: teams running near 100% utilisation lose the capacity to absorb constraints, react to incidents, or improve architecture. He treats slack as an investment in resilience.

A necessary caveat. Both books predate the current generation of coding assistants, and we can’t take it as given that useful output is going up. METR’s 2025 randomised controlled trial followed 16 experienced open-source developers through 246 real tasks in their own mature repositories. When they were allowed to use AI tools, tasks took 19% longer. Beforehand, the developers forecast a 24% speedup. Afterwards, they still believed they had been 20% faster (Becker et al., 2025). The slowdown held up across the study’s robustness checks.

AI does help in some settings, and some later studies show real gains (see section 4). But a claim like “AI gives us a 30% improvement” needs to be measured locally, not assumed.

Leadership implication. The questions to ask, in order:

1. Are we measuring whether AI is saving time on our tasks, in our codebase, or assuming it from vendor claims and individual perception?
2. If it is, where is the bottleneck now, and how should we invest the recovered capacity?

2. The Nature of Developer Work Is Changing

Direct Evidence: The Creation-to-Verification Shift

Annie Vella and Kelly Blincoe’s longitudinal study (University of Auckland, 2026) tracked professional software engineers across two questionnaires six months apart (158 eligible participants at the first time point, 101 at the second, 95 matched across both, spanning 28 countries).

Key findings:

• 82% of participants reported spending less time writing code by the second time point.
• Five of six measured development activities (designing, writing, refactoring, testing, debugging) showed reduced time; reviewing was the only activity that increased, and only slightly.
• The balance between creation-oriented and verification-oriented work shifted measurably towards verification (p = 0.006, moderate effect).

Vella names this new category supervisory engineering work, comprising three activities:

• Directing: specifying intent, crafting prompts, managing context, and codifying standards into reusable agent instructions.
• Evaluating: reading AI-generated output and deciding what to accept, modify, or reject.
• Correcting: fixing errors, integrating output into existing code, and maintaining consistency.

Accountability for what ships sits alongside these, though it is not part of Vella’s taxonomy.

Interpretation

The complexity of software development doesn’t vanish. It moves from writing code to judging it. Vella’s data also shows that the “obvious” reallocation, freed-up coding time flowing into design and architecture, did not occur. Time compressed across nearly everything, design included.

3. The Productivity–Experience Paradox

Vella’s study also found a tension. Productivity perceptions held stable and positive (84% of participants reported improvement at both time points). Over the same six months, the proportion of the matched cohort reporting negative developer experience nearly doubled, from 14% to 27%.

This is the productivity–experience paradox: conventional engineering metrics can look healthy while a developer’s subjective experience of flow, agency, and satisfaction with the work erodes.

Leadership risk. If speed of output becomes the dominant metric, leaders may optimise away the psychological and environmental conditions that make software engineering sustainable. A developer completing tickets faster is not automatically a developer who understands the domain more deeply, feels connected to the codebase, or is building architectural intuition.

4. Verification Is Work, and It Has a Cognitive Cost

A 2026 CHI study, “When Help Hurts: Verification Load and Fatigue with AI Coding Assistants” (N = 60, three Python tasks), gives the clearest available measurement of that cost. AI assistance, pooled across interaction styles, reduced self-reported workload by 18.2 points on the NASA-TLX scale and cut task time by 22% versus no-AI, while also improving correctness. The same study built a behavioural “verification-load” index from compile and test failures, churn, pauses and context switches. That index partially explained rising stress and fatigue over repeated use.

So AI does not simply trade creation effort for an equal amount of verification effort. On a single task it can be a clear win. Over weeks of sustained use, the verification load adds up to a fatigue tax.

5. Developer Experience Is More Than Removing Friction

Developer experience (DevEx) is often oversimplified as the elimination of operational friction. AI excels at removing mechanical friction, but not all friction in engineering is wasteful.

Friction Category	Example	Recommended Action
Mechanical	Boilerplate, repetitive syntax, structural transformations	Automate
Tooling	Slow build pipelines, flaky CI environments	Eliminate
Information	Missing documentation, ambiguous API specs	Resolve
Coordination	Unclear ownership, approval bottlenecks	Streamline
Developmental	Working through complex domain boundaries	Preserve
Learning	Wrestling with an unfamiliar algorithm or pattern	Preserve
Reflective	Root-cause analysis during post-mortems	Preserve
Judgement	Evaluating architectural trade-offs	Preserve

The research basis for the “Preserve” rows is Robert Bjork’s concept of desirable difficulties in learning science: certain kinds of effort that slow performance in the short term measurably improve retention and transfer of skill (Bjork, 1994). Automate away developmental, learning, and judgement friction indiscriminately and you remove the struggle through which engineers build durable mental models of the systems they maintain.

6. Learning and the Capability Paradox

Engineers have always built intuition by trying something, watching it fail, debugging it and fixing it. AI shortens that loop dramatically. That is good for speed, but it can skip the struggle where real understanding forms.

Direct Evidence: Skill Formation Under AI Assistance

Anthropic’s 2026 randomised controlled trial on AI and skill formation had 52 software engineers learn a new library, split between AI-assisted and unassisted conditions. Both groups completed the task in similar time, but the AI-assisted group scored 17 percentage points lower on a follow-up comprehension quiz (50% vs. 67%), with the largest gaps in debugging and smaller but still significant drops in conceptual understanding.

The effect depended on how AI was used. Participants who asked conceptual questions and used AI to check their own reasoning scored close to the unassisted group. Those who passively delegated (“just make it work”) scored worst. Academic work on this same phenomenon has begun calling it comprehension debt (Ahmad, 2026).

That changes the leadership takeaway: the risk lies in passive AI use.

Contextual Counter-Evidence

On the code itself, rather than the people writing it, a separate controlled experiment points the other way. In “Echoes of AI” (Borg et al., 2026), 151 participants, mostly professional developers, extended a Java web application with and without AI assistance. In a second phase, new developers evolved the resulting code. Measured by the CodeHealth metric, the AI-assisted code was no harder to read and no more complex.

That sits in tension with large-scale industry telemetry: GitClear and GitKraken’s 2026 analysis of over 600 million real-world code changes found rising code duplication (+81%) and increased short-lived code churn as AI adoption grew (LeadDev, 2026). The likely reconciliation is methodological: a bounded, single-application controlled experiment measures something different from longitudinal telemetry across thousands of repositories and teams with varying review discipline.

The maintainability question is not yet settled. Any claim that AI-generated code is safe (or unsafe) for long-term maintenance “by default” overstates the current evidence.

7. Autonomy, Competence, and Relatedness (SDT Perspective)

Self-Determination Theory (Deci & Ryan) holds that motivation and wellbeing depend on three basic psychological needs. AI can help or harm each:

1. Autonomy: Positive: developers can prototype independently and unblock themselves on syntax. Risk: if management converts tool efficiency into tighter deadlines, autonomy collapses into an imposed production quota.
2. Competence: Positive: AI can act as a tutor, explaining unfamiliar APIs. Risk: over-reliance prevents developers from mastering underlying principles, consistent with the comprehension-debt evidence above.
3. Relatedness: Positive: teams use AI to aggregate domain knowledge and onboard faster. Risk: if developers consult AI instead of pairing with peers, knowledge transfer and team cohesion degrade.

8. Identity and the Evolution of Craftsmanship

Engineering identity has historically been tied to craftsmanship: the tactile act of constructing systems, refactoring algorithms, and solving problems manually. As AI takes on more of the generation, that identity moves towards direction, evaluation and judgement. That isn’t a bad thing in itself, since professions move up levels of abstraction all the time. The leadership job is to make sure the new role still offers real mastery and pride in the work, and doesn’t shrink to supervising output the engineer doesn’t fully understand.

9. The Inner, Middle, and Outer Loops

Vella’s “three-loop model” (2026) gives leadership a concrete way to talk about where supervisory work lives:

+-----------------------------------------------------------------+
|                         INNER LOOP                              |
|               (Write -> Build -> Test -> Debug)                 |
|                   * Heavily AI-Automated *                      |
+-----------------------------------------------------------------+
                                |
                                v
+-----------------------------------------------------------------+
|                         MIDDLE LOOP                             |
|    (Direct AI -> Evaluate Output -> Correct Errors)             |
|              * The Critical Human Judgement Zone *              |
+-----------------------------------------------------------------+
                                |
                                v
+-----------------------------------------------------------------+
|                         OUTER LOOP                              |
|        (Commit -> Code Review -> CI/CD -> Observability)        |
|                  * System & Team Integration *                  |
+-----------------------------------------------------------------+

The middle loop is, by Vella’s own account, still largely unoptimised: engineers are assembling it from chat windows, terminal agents, and IDEs that weren’t designed for supervisory work. ThoughtWorks’ 2026 “Future of Software Development” retreat picked it out independently as a “first-mover concept” that “nobody in the industry has named yet,” so the idea has traction beyond one paper.

This is where engineering leadership should focus. It is the point at which domain knowledge, architectural judgement and careful verification stop AI-generated technical debt from reaching production.

10. Strategic Task Allocation: What to Automate

The friction table in section 5 translates into a rough split of tasks:

• Automate (High Machine Agency): standard boilerplate, routine syntax conversion, unit test scaffolding, basic documentation drafts.
• Shared / Collaborative (Human Orchestration + AI Speed): exploratory prototyping, complex refactoring strategies, initial root-cause diagnosis for obscure errors.
• Preserve for Humans (High Human Agency): core architecture and domain boundary design; threat modelling and security review; trade-off analysis and incident post-mortems; mentoring and junior developer growth.

11. Avoiding “Capability Debt”

Like technical debt, capability debt builds up quietly. An organisation keeps shipping software, but loses the human understanding it needs to evolve, debug and operate those systems later. Comprehension debt (section 6) is the same problem at the individual level.

Indicators of capability debt:

• Engineers can’t explain the internal mechanics of recently committed AI-generated modules.
• Code reviews focus on formatting rather than structural correctness.
• High variance in resolution time for complex incidents where AI tools can’t supply an answer.
• Junior engineers struggle to progress from execution to architectural design due to missing foundational practice.

12. A Balanced Engineering Scorecard

Judge AI adoption by commit volume or velocity alone and teams will optimise locally at the expense of system health. A balanced scorecard tracks delivery, quality and human capability together:

Dimension	Primary Focus	Recommended Metrics
System Delivery	Throughput & Speed	Lead time for changes, deployment frequency
System Stability	Reliability	Change failure rate, mean time to restore (MTTR)
Verification Load	Review Health	Review churn, time-in-review, post-release defect rate
Developer Experience	Sustainability	Qualitative flow-state surveys, friction indicators, SDT sentiment
Capability & Growth	Learning & Mentorship	Knowledge-sharing cadence, architecture comprehension checks
Business Outcomes	Value Delivered	Customer value metrics, system resilience, feature impact

Stability earns its own row. DORA’s 2024 report estimated that every 25% rise in AI adoption went with a drop of about 7% in delivery stability, and the 2025 report still found a stability cost (as summarised in LeadDev, 2026). Don’t assume stability moves in step with delivery speed.

13. Summary Leadership Principles

• Measure before you reinvest. Don’t assume AI has created spare capacity. METR’s data shows perceived and measured speed can point in opposite directions, so check locally before reallocating time.
• Leverage over replacement. Use AI to remove mechanical burden without eliminating developmental learning opportunities.
• Focus on system constraints. Treat any real velocity gains as capacity to reinvest in architecture, testing, slack, and capability. They are not a mandate for more output.
• Elevate the middle loop. Explicitly teach and evaluate prompt intent, context boundary definition, and output verification as core engineering competencies.
• Protect engineering mastery. Ensure senior engineers mentor juniors through complex problem-solving rather than delegating foundational understanding entirely to automated tools.
• Design for active, not passive, AI use. In Anthropic’s trial, comprehension held up when engineers interrogated AI output and dropped when they accepted it passively. That distinction is coachable, and worth making explicit in onboarding and review norms.

AI should make the organisation more capable, not merely more output-dense, and leadership shouldn’t take the “more output” part on faith either.