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.

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.

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.

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. The underlying argument is that software delivery performance emerges from the characteristics of the whole system, not from maximising an individual’s local activity.

Will Larson’s An Elegant Puzzle (2019) treats developer velocity the same way. Increasing the rate at which pull requests or commits are produced doesn’t necessarily increase the rate at which useful software reaches customers; bottlenecks simply move elsewhere. Larson also emphasises organisational slack: teams running near 100% utilisation lose the capacity to absorb constraints, react to incidents, or improve architecture. Slack is an investment in resilience, not waste.

A necessary caveat. Both books predate the current generation of coding assistants, and we can’t assume the rate of useful output is going up at all. 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 6). But a claim like “AI gives us a 30% improvement” needs to be measured locally, not assumed.

Leadership implication. The right sequence of questions is now:

1. Are we actually 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 the “obvious” reallocation (freed-up coding time flowing into design and architecture) did not occur. Time compressed across nearly everything, including design, rather than shifting to it.

3. The Productivity–Experience Paradox

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

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, leadership risks optimising 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. Developer Experience Is More Than Removing Friction

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 underlying research basis for “preserve the struggle” 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). Indiscriminately automating away developmental, learning, and judgement friction removes exactly the struggle through which engineers build durable mental models of the systems they maintain.

5. 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. 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 is passive AI use, not AI use in general.

Contextual Counter-Evidence

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 honest summary is that the maintainability question is not yet settled, and any claim that AI-generated code is safe (or unsafe) for long-term maintenance “by default” is overstating the current evidence in either direction.

6. 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 this. 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.

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

Self-Determination Theory (Deci & Ryan) holds that motivation and wellbeing depend on three basic psychological needs:

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. 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 actually 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. The middle loop is where domain knowledge, architectural judgement and careful verification stop AI-generated technical debt from reaching production.

10. Strategic Task Allocation: What to Automate

To maintain team capability while leveraging AI speed:

• 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. Researchers are arriving at similar language: “comprehension debt” (Ahmad, 2026) describes 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 outcomes, 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. 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 into architecture, testing, slack, and capability, not as mandatory output-volume increases.
• 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. The skill-formation evidence is consistent: comprehension holds up when engineers interrogate AI output and degrades when they accept 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.