The human cost of AI in software teams: what I am seeing, and what we need to do about it

Let me describe something I have witnessed across multiple teams in the past six months, because I think it captures the central tension better than any statistic.

A senior developer, eight years of experience, deep knowledge of the system, someone colleagues used to come to with difficult architecture questions. Since the team adopted AI-assisted development, her output has doubled in terms of lines shipped. She is not slower. She is not struggling with the tools. But she told me, quietly, that she no longer feels like she is actually doing the work. She described it as watching herself code rather than coding. The AI does the implementation. She reviews, adjusts, accepts. The technical judgment she spent eight years developing, the judgment that made her valuable, feels like it is being exercised less and less with each sprint.

Two desks away: a mid-level developer who is running four AI agents simultaneously across different parts of a feature. He is switching between them constantly, reviewing outputs, correcting errors, re-prompting, abandoning one thread to attend to another. His task completion rate is impressive. His concentration is destroyed. By Thursday afternoon he described feeling like he could not remember what he had actually decided that week, only that he had been in constant motion.

And at the other end of the room: a junior developer who joined the team six months ago. She has never worked without AI tools. She ships code. The code often passes review. But when her tech lead asks her to explain a design choice, she struggles. Not because she lacks intelligence, but because the reasoning was done by the model, and she reviewed without fully interrogating. She is accumulating delivery experience without accumulating technical understanding. And she is beginning to feel, at twenty-three, that she is already falling behind.

These are not edge cases. I am seeing versions of these patterns in every team I work with. The productivity story is real. The human story underneath it is more complicated than most organisations are acknowledging.

The overwhelm that AI-native developers are experiencing is structurally different from the overload developers felt in previous eras. It is not the overwhelm of too many tickets or too large a backlog. It is the overwhelm of a fundamentally changed cognitive architecture around the work.

Traditional software development, even under pressure, had a rhythm. A developer would read a ticket, think, plan, implement, test, commit. The work moved forward in roughly linear fashion. There were context switches, yes, but they were bounded. You finished a thing, then started another thing.

AI-assisted development, at anything beyond surface level, operates differently. A developer might simultaneously have: a code generation session running on one feature, an AI reviewer providing feedback on a pull request from yesterday, a chat thread with an AI assistant debugging a production issue, and another agent generating test scaffolding for something else entirely. These are not sequential. They are parallel. And the developer is the coordination layer holding all of them together.

A 2025 study found that developers using AI tools actually take nineteen percent longer than developers working without them, despite believing they are twenty percent faster. The gap between perception and reality is nearly forty percent. Part of this is the cognitive overhead of managing AI outputs: reviewing generated code for correctness, debugging almost-right solutions, re-prompting when context is lost, and carrying the mental weight of uncertainty about which parts of the codebase were deeply understood and which were accepted on faith.

The tool proliferation problem compounds this. A new AI development tool launches, on average, multiple times per week. Organisations adopt them faster than individuals can meaningfully evaluate them. The developers I speak with who are least stressed about AI have made a different choice: they picked their stack and stopped evaluating new tools. But the organisational pressure to explore, adopt, and demonstrate fluency with the latest model or the latest agent framework does not respect that choice. FOMO is not just a consumer phenomenon. In engineering teams right now, it is a performance pressure.

What this produces, for many developers, is a state that feels like productivity but is actually fragmentation. They are busy. They are shipping. And they are exhausted in a way that sleep does not fix, because the exhaustion is not physical. It is cognitive and attentional.

Software development has always had a collaborative dimension that its popular image underrepresents. The pair programming session. The informal architecture discussion at a whiteboard. The junior developer leaning across and asking a senior colleague how to think about a problem. The code review conversation that taught something beyond the specific review comment. These moments of lateral learning were not incidental to professional development. They were central to it.

AI tools are, for many developers, replacing these interactions. Not deliberately, not as a policy, but as a natural consequence of having a highly capable, always-available, never-judgmental technical interlocutor available at the keyboard. Why interrupt a colleague with a question when Claude or Copilot will answer it immediately and without visible impatience?

The answer, of course, is that the colleague would have answered it differently. With context about this specific codebase. With a war story about the time the same approach caused a production incident three years ago. With a question back that would have pushed the asking developer to think harder rather than just receive an answer. With the kind of knowledge transfer that only happens in conversation between humans who share a history.

A 2025 survey found that thirty-eight percent of developers agree that AI tools have reduced the direct mentoring junior engineers receive from senior engineers. The senior developers I speak with are not less willing to mentor. They are less often asked. The juniors are asking the AI. The AI answers. The conversation that would have happened, that would have built relationship alongside knowledge, does not.

Code review is undergoing a similar shift. AI review tools handle the mechanical elements, the syntax issues, the pattern violations, the obvious security concerns, at a quality level that human reviewers cannot match for speed and at a cost that is essentially zero. This is genuinely useful. But the code review conversation was never only about finding defects. It was about shared understanding, about alignment on architectural direction, about the senior developer knowing what the junior was working on and how they were thinking about it. That conversation is getting shorter. In some teams, it has stopped.

The isolation is not always dramatic. It does not look like obvious loneliness. It looks like a developer who is equally or more productive than a year ago, but who, when I ask them who in their team they genuinely learn from, pauses before answering.

Imposter syndrome among developers is not new. What is new is that AI has created two entirely distinct forms of it, affecting different groups in opposite ways, and both are getting worse.

The first form affects experienced developers. These are people who spent years building deep technical capability. They learned how to reason about algorithms, how to diagnose obscure system behaviour, how to make architectural decisions under uncertainty. They earned their confidence through hard, slow, deliberate practice. And now they are watching that confidence get quietly eroded, not by failure, but by irrelevance. When the AI generates working code faster than they could have written it, the question that lands is not 'did I do this wrong?' but 'did I spend ten years learning something that no longer matters?'

One developer I worked with described it as watching themselves become a reviewer rather than a builder. 'I used to know why things were the way they were,' he said. 'Now I often only know what things are. The AI decided the why. I approved it.' The technical judgment is still being exercised, but in a narrower register, and the developer knows it. The skills are present. The opportunities to use them fully are diminishing.

The second form affects junior developers, and it works in the opposite direction. These developers are using AI tools to generate code that passes review and ships to production, before they have built the understanding that would let them write it themselves. They are accumulating a delivery record without accumulating the underlying capability. When they are asked to debug something unfamiliar, or to explain a design choice, or to work without AI access, the gap becomes visible, and the shame around it is significant.

Stack Overflow research in 2025 found a new anxiety category they called legitimacy questioning: developers asking themselves and each other 'are you a real coder, or are you using AI?' This question is poisonous in both directions. It implicitly devalues the genuinely skilled AI-assisted developer who has earned the judgment to direct these tools well. And it allows the developer using AI without understanding to avoid a reckoning with their own knowledge gaps.

The Anthropic research finding that cuts most sharply here is this: developers who learned to code with constant AI assistance showed a seventeen-point comprehension gap on debugging tasks compared to those who learned with hands-on manual coding. The gap is not in delivery capability. It is in depth of understanding. And depth of understanding is exactly what gets called upon when things go wrong.

Not everything I am seeing is difficult. I want to be honest about what AI does well for developers, because the people experiencing it well are experiencing something genuinely valuable.

When a developer has integrated AI tools thoughtfully, when they understand their limits and have built a disciplined workflow around them, the experience can be one of sustained, high-level focus that is rare in engineering work. Routine cognitive tasks, syntax recall, boilerplate generation, documentation, the first draft of a test suite, are absorbed by the AI. The developer operates at the architectural layer, at the layer of decisions about intent and design. They are not interrupted by the mechanical. They stay in the room of ideas for longer.

This is the state that psychologist Mihaly Csikszentmihalyi called flow, and it is genuinely productive and genuinely satisfying. The developers experiencing it are among the most engaged I encounter. They are not doing less technical work. They are doing more of the technical work that they find most meaningful.

The challenge is that flow in an AI-assisted context is fragile and conditional. It depends on clear intent, short feedback loops, and active review. When those conditions are not met, what appears to be flow is actually something else: a kind of productive dissociation where the developer is busy and shipping, but not genuinely engaged with the quality or the coherence of what is being built.

The patterns that break flow in AI-assisted development are specific and learnable: the correction spiral, where a developer keeps re-prompting an AI that cannot produce what they want because the specification is unclear; the review overload, where a large block of generated code lands and the developer does not know where to begin evaluating it; and the trust trap, where code that looks right is accepted without interrogation, and the error surfaces later, in production, where it is expensive.

The difference between the developers experiencing genuine flow and the developers experiencing productive dissociation is often not skill. It is reflective practice. The developer who pauses, who asks themselves what they actually understand about the code they just accepted, who treats the AI as a collaborator requiring supervision rather than an oracle requiring only approval, is the one who remains genuinely present in the work.

The term 'dark factory' comes from lights-out manufacturing: an industrial facility where robots operate without human presence, in the dark, because light is not needed when no humans are there. Applied to software development, it describes the direction of travel in the most AI-advanced engineering organisations: fully autonomous development pipelines where AI agents plan, implement, test, review, and deploy, with humans defining intent and validating outcomes rather than writing code.

I find it useful to think about this as a spectrum of five levels, not because teams should aspire to Level 5, but because understanding where a team sits on this spectrum is essential to understanding what the human experience inside it will be, and what is required to navigate it well.

Level 1 is AI-Assisted. Individual developers use AI tools, primarily code completion and chat interfaces, as personal productivity aids. The workflow is still fundamentally human. AI is a faster reference, a better autocomplete, an always-available rubber duck. The team's coordination, planning, and review practices are unchanged. Most organisations believe they are here when they have distributed Copilot licences.

Level 2 is AI-Augmented. AI is embedded in team workflows: code generation, automated testing, AI-assisted code review, and AI-generated documentation are all in regular use. The team is meaningfully faster. The coordination overhead has increased. Senior developers spend more time reviewing AI outputs and less time writing code. The junior developer experience begins to change in the ways described earlier in this article. This is where most technology organisations actually are.

Level 3 is AI-Orchestrated. AI agents coordinate significant parts of the delivery pipeline. A developer might describe a feature in a specification, and an orchestration layer breaks it into tasks, assigns them to specialised agents for implementation, testing, and review, and surfaces a pull request for human approval. The human role shifts toward specification quality and outcome validation. This is where the comprehension gap becomes a serious risk, and where team dynamics change most sharply.

Level 4 is AI-Directed. The AI system drives planning, sprint decomposition, implementation, and quality validation. Humans are involved primarily at the boundaries: defining business intent, approving significant architectural decisions, and reviewing final outputs. A small number of frontier engineering organisations are operating here. The human skills required are radically different: systems thinking, precise specification, and the judgment to evaluate whether a working solution actually serves its intended purpose.

Level 5 is AI-Autonomous, the true dark factory. Specialised AI agents collaborate in real time with no human in the implementation loop. Engineers exist to define business intent and govern the system. Anthropic has reported that Claude Code, their own coding agent, wrote approximately ninety percent of its own codebase. This level is not a destination most organisations should be targeting. It is a reference point for understanding where the trajectory leads, and what it demands of the humans who govern it.

The critical insight is not about which level is correct. It is that most organisations are moving up this scale without consciously managing the transition. They adopt tools at Level 1, find productivity gains, adopt more tools, and arrive at Level 3 behaviours without ever having made a deliberate decision about it, and without preparing their teams for what the human experience at that level actually requires.

The most important thing a leader can do is name what is happening. The psychological effects described in this article are not being talked about openly in most organisations, because they carry a stigma: to admit overwhelm is to seem unable to cope, to admit imposter syndrome is to seem unqualified, to admit isolation is to seem needy. Leaders who create permission for these conversations, who name them explicitly in team forums and one-to-ones, are doing something that no tool or process change can substitute for.

The second thing is to slow the adoption curve to a pace the organisation can genuinely absorb. This is a difficult position to hold in an environment of intense competitive pressure, but it is the responsible one. Rolling out AI tools to an entire engineering organisation in a quarter, without training, without workflow design, without support structures, does not accelerate development. It increases cognitive load, widens skill gaps, and creates the conditions for the burnout and attrition that erode the productivity gains within two or three quarters.

Leaders also need to separate individual output metrics from team health metrics. A developer who has doubled their code output while quietly experiencing significant distress, who is three months from burning out, is not a development success story. Velocity measures tell you about the past. Wellbeing measures, honestly gathered and genuinely acted on, tell you about the future.

Specifically, I would recommend that leaders in technology organisations hold regular structured conversations with their teams not just about what AI tools they are using, but how they are experiencing the use of them. Are people feeling stretched in the right ways? Are they building understanding alongside delivery? Are they connecting with their colleagues, or are they increasingly alone with their machines? These conversations produce information that no dashboard provides.

Finally, leaders need to invest explicitly in the human skills that AI de-emphasises rather than letting them atrophy. Communication, system thinking, specification clarity, peer teaching, and critical evaluation of AI output are becoming more important as coding mechanics become less so. The developers who navigate the next five years well will not necessarily be the fastest coders. They will be the ones who developed judgment, expressiveness, and the ability to think clearly about what they actually want to build.

The Scrum Master role is, in my view, uniquely positioned to respond to what AI is doing to software teams, precisely because the role is not primarily about delivery. It is about the team. It is about the conditions that allow people to do their best work and grow as professionals. In an AI-assisted team, those conditions are changing in ways that require active tending.

Start with the retrospective. The retrospective is the only ritual in Scrum that is explicitly about the team's experience of the work, not just the output of the work. In most teams I observe, retrospectives have been captured by delivery concerns: what slowed us down, what went wrong, what should we do differently about the sprint. AI gives Scrum Masters the opportunity to restore the retrospective to its fuller purpose by introducing questions that surface the human experience: What felt energising this sprint? What felt depleting? Where did you feel genuinely engaged, and where did you feel like you were just managing processes? These questions produce different conversations and different information.

Second, Scrum Masters should be actively monitoring for isolation patterns. The developer who never pair-programs, who never asks a colleague a question, who reviews all their own pull requests through AI tooling and rarely appears in team conversations, is not just changing their working style. They may be developing a disconnection from the team that will show up later as disengagement or attrition. Making pairing and collaborative work visible in sprint planning, not as a mandate but as a recognised and valued activity, helps counteract the pull toward working alone.

Third, Scrum Masters can advocate for what I call AI literacy without shame: the team norm that it is acceptable, expected, and professionally responsible to say 'I accepted this AI output and I do not fully understand it' or 'I am feeling overwhelmed by the tool complexity this sprint.' The absence of this norm does not mean these experiences are not happening. It means they are being hidden, which is worse.

Sprint reviews offer another opportunity. Rather than demonstrating features, Scrum Masters can facilitate moments where team members share what they learned during the sprint, not just what they built. The developer who can articulate what they understand better after the sprint, whether about the system, about the domain, or about their own practice, is the developer who is growing. This makes learning visible and valued in a context where shipping velocity can crowd it out entirely.

The peer dimension of this challenge is, I think, underestimated. The colleagues sitting alongside each other in these teams have both the most direct visibility into what is happening and the most power to change the daily texture of the experience.

The most practical thing an experienced developer can do for a junior colleague in an AI-intensive team is to reinstate the question. Not 'let me review your PR,' but 'walk me through how you approached this.' Not 'did the tests pass?' but 'what would you do if you had to debug this in production without any AI tooling?' These questions are not hostile. They are the questions of genuine mentorship, and they are the ones that most often stop being asked when AI tools provide a faster and less uncomfortable alternative.

Senior developers can also model uncertainty. If you do not fully understand a piece of code that an AI generated, say so. If you are struggling with a workflow, say so. The culture of invulnerability that exists in many engineering teams, the culture that makes imposter syndrome so corrosive, is maintained by the people at the top of the hierarchy appearing to find everything manageable. When senior people make the difficult things visible, junior people learn that it is safe to have difficult experiences.

Pairing remains one of the most effective learning mechanisms in software development, and it requires almost no technology investment. A pair-programming session where one developer navigates and one drives, with AI tools used collaboratively and transparently, produces both better code and better understanding than either developer working alone with AI. It also produces conversation, relationship, and the kind of incidental knowledge transfer that isolated individual work cannot replicate. Teams that have kept pairing alive as a practice, even informally, even occasionally, are consistently in a better position than teams that have let it lapse.

Finally, the informal check-in is not a soft option. It is a professional responsibility. Asking a colleague 'how is it going, genuinely?' and meaning it, and listening to the answer rather than accepting 'fine' as sufficient, is one of the most consequential things a peer can do in a team that is navigating significant change. The developers I described at the beginning of this article were not hiding their experiences because they chose to. They were hiding them because nobody had created a moment in which it was safe not to.

Beyond cultural and relational practices, there are specific technical and workflow techniques that I have seen teams use effectively to preserve depth of understanding and human agency in AI-assisted development.

The first is what I call the Explain-Back Protocol. Before a developer merges any significant AI-generated code, they must be able to explain it: not to the AI, but to a colleague, or written down in a comment, or stated aloud to themselves. 'This function does X by doing Y. I chose to use the AI's implementation because Z. If this fails, the first place I would look is W.' If the developer cannot do this, the code is not ready to merge. This is not a bureaucratic gate. It is a personal professional standard that several teams I have worked with have adopted as a team norm with significant positive effect on code quality and developer confidence.

Code Ownership Hours are a practice some teams have introduced where, for a set number of hours per sprint, AI-assisted tools are set aside and developers work purely from their own knowledge. This is not a punishment or a test. It is maintenance of a capability: the ability to reason about and contribute to a codebase without a crutch. Teams that have implemented this consistently report that it also improves the quality of AI-assisted work, because developers have a clearer and more personal relationship with the systems they are asking AI to help with.

Structured AI Retrospectives, distinct from the sprint retrospective, focus specifically on the team's experience of AI tools: which tools are helping, which are adding overhead, what has been learned about using them well, and what concerns are present. The structured nature matters. A general invitation to discuss AI is often met with silence or with performance talk. Specific questions, asked with genuine curiosity by a Scrum Master or team lead who is prepared to hear the difficult answers, produce the conversations that actually improve the team's experience.

Architectural Intent Documents are short, human-written records of the reasoning behind significant design decisions, written before implementation, not generated from the implementation by AI afterward. When a developer articulates in writing what they are trying to achieve and why they have chosen a particular approach, two things happen: they clarify their own thinking, and they create a record that belongs to the team rather than to a model context window that will not be available the next time the codebase is revisited. This practice also creates natural review checkpoints where colleagues can engage with intent rather than only with code.

Deliberate pairing on difficult work, rather than on routine work, inverts the usual mentoring model. The tendency in AI-assisted teams is to pair on simple tasks while doing complex work alone with AI. The better approach is the reverse: handle the routine with AI, and bring human collaboration to bear on the genuinely hard problems. This is where the pair's joint judgment adds most value, and it is where junior developers learn most from senior colleagues.

Beyond the practices that I have seen work in the field, there are several approaches I think are worth deliberate experimentation. These are not proven playbooks. They are directions I believe are worth pursuing based on what I am observing in the leading edge of how teams are adapting.

The first is the AI Translator role: a rotating team responsibility where one developer per sprint takes explicit ownership of curating the team's AI practice. This person reviews the tools in use, flags emerging concerns about over-reliance, suggests workflow experiments, and reports findings in the sprint review. This is not a specialist AI engineer or a tool administrator. It is a regular team member, rotating through the responsibility, building collective AI literacy rather than centralising it.

The second is what I think of as a Craftsmanship Portfolio: a personal record maintained by each developer of problems they have genuinely solved by thinking, not by prompting. Architecture decisions they reasoned through. Bugs they diagnosed from first principles. Systems they understood deeply enough to refactor confidently. In a world where the AI can always be credited with the implementation, having a visible record of genuine intellectual contribution matters, both for the developer's own confidence and for the team's understanding of where individual expertise actually lies.

The third is Specification-First Sprints, where the entire sprint begins with human-authored specifications for every significant piece of work, before any AI tooling is involved. The specifications are reviewed in planning, challenged by the team, and refined until they are clear enough that a competent developer (human or AI) could implement from them without ambiguity. The discipline of writing a specification that meets this bar is itself a significant cognitive exercise that builds system thinking, domain understanding, and communication skills. It also tends to produce substantially better AI-generated code, because the quality of AI output is almost always bounded by the quality of the input.

The fourth is what I am calling a Dark Factory Audit: a team exercise where members map their current workflow against the five levels described earlier in this article, and ask themselves, honestly, whether the level they are operating at is the level they chose or the level they drifted to. This conversation, facilitated by a Scrum Master or coach, regularly produces significant surprises. Teams discover they are at Level 3 behaviours when they thought they were at Level 1. They discover that certain developers have effectively moved to Level 4 individually while the rest of the team is at Level 2. The audit does not prescribe a level to be at. It creates the awareness that allows a conscious choice.

The fifth is the practice of Failure Archaeology, deliberately revisiting production incidents or significant bugs and asking: what human understanding was missing that would have prevented this? If the answer is that a developer accepted AI-generated code they did not understand, the retrospective action is not to blame the developer. It is to ask what systemic condition allowed that to happen, and to change it. Failure Archaeology treats each incident as evidence about the current state of the team's understanding, and builds the institutional memory that AI tooling, with its context-limited and stateless nature, cannot provide.

I want to close with something that I think about a great deal when I am working in these teams.

The output of a software team is not code. The output is a sustainable capability to solve the organisation's problems over time. That capability lives in people: their knowledge, their judgment, their relationships with each other, their ability to work together under pressure, and their commitment to the craft. Code is evidence of that capability. It is not the capability itself.

AI tools, used well, can amplify that capability. They can free human attention for higher-level thinking. They can accelerate learning for developers who use them with genuine curiosity. They can enable small teams to deliver at a scale previously impossible. I have seen all of this. It is real.

But AI tools, used without deliberate attention to the human conditions underneath, will erode the capability they are meant to serve. A team of developers who do not fully understand the systems they maintain, who have stopped learning from each other, who feel overwhelmed and isolated and unable to demonstrate the depth of knowledge they worked years to build, is not a high-performing team. It is a team that is performing well today and accumulating the conditions for a significant failure tomorrow.

The leaders, Scrum Masters, and peers who are paying attention to both sides of this story, the productivity gains and the human experience underneath them, are the ones building something that will last. The ones who are watching the velocity metrics and not asking harder questions are building something more fragile than they know.

What I am asking for is not a slowdown. It is an honest look at what is happening to the people. Because the people are not a cost of the transformation. They are the asset the transformation is supposed to serve.