Photo by Matvey Logachev on Unsplash

The Invisible Divide

Keeping AI from Splitting Engineering Teams

TL;DR

AI coding tools are not landing uniformly inside engineering teams. They are landing on a fault line, splitting teams into those who have restructured their entire workflow around AI and those who haven’t moved at all, with everyone else somewhere in between. That fault line was already there. AI just made it visible.

The risk is not the disagreement itself. A team with enthusiasts pulling forward and cautious adopters applying the brake is a team with useful tension. The risk is that the disagreement goes underground, quietly eroding the common ground that makes a group of individuals a team: the shared context, shared history, and shared assumptions about what the work actually is.

The point is not mandate and not avoidance. It is noticing that both movement and restraint are necessary, and that the balance between them depends on common ground surviving the divide. Which turns out to be less a question about AI than about how teams are structured in the first place.

Context: What Is Making the Divide Happen

There is a version of this story that says AI adoption in software teams is just another technology transition, like the move to version control, or the shift to cloud infrastructure, or the containerisation wave. Teams resisted, then adapted, then forgot there was ever a question. This version is wrong, or, at least, incomplete.

Previous technology transitions in software were largely organisational in character. Moving to Git meant the whole team moved to Git. Adopting Kubernetes meant the infrastructure changed for everyone. These shifts were visible, legible, and, critically, they often happened at the infrastructure layer, below the level of individual workflow. That does not mean every prior transition was clean or collective. The spread of IDEs, editors, and local development habits was also individual, gradual, and uneven. But infrastructure changes usually forced themselves into the open. You could see who had adopted and who had not. There was a clearer before and after. Teams were more likely to go through the transition together.

AI coding assistants arrived at a different layer entirely. They land in the editor. They change the texture of how an individual writes and thinks about code. They are adopted privately, iteratively, and silently, often a habit formed over weeks of solo experimentation before it ever becomes visible to a colleague. By the time an organisation notices that adoption is happening, some engineers have months of practice and have fundamentally restructured their workflow. Others have barely opened the tool. Nobody made a team decision. Nobody announced a transition. The divide accumulated one workflow at a time, below the waterline of any process or policy.

This is the structural reason the divide is hard to name and harder to manage. It is not a disagreement about a shared decision. It is the divergence of private habits into something that eventually shows up in code reviews, in velocity, in estimation, and in what different people think a normal day of work looks like, made less visible because no one formally decided anything.

There is a second, related dynamic worth naming: the hype cycle around AI tools has been unusually loud, which means the social pressure to adopt — or to visibly not adopt — is unusually high. Engineers who haven’t adopted are aware that they are expected to have a view. Engineers who have adopted are aware that their colleagues are watching. This adds a layer of performance to what would otherwise be a straightforward tool evaluation, and it makes honest conversation harder. The argument is no longer just “does this help me do the work?” It becomes “what does my answer say about what kind of engineer I am?”

The Problem: Why this has all the marks of an accident waiting to happen

Early Adopters and Cautious Adopters

Inside the same team, you now find people operating with fundamentally different assumptions about what the work is.

The early adopters have restructured their workflow around AI assistance. They are faster (at least on certain classes of task), more experimental, and increasingly impatient with friction they no longer experience. The cautious adopters have made a considered, or instinctive, decision that the current generation of tools does not meet their standard for correctness, craft, or dependability. Both positions contain real reasoning. The enthusiast is not simply naive about the risks. The cautious adopter is not simply afraid of change.

The danger is not the disagreement. It is the stories each side tells about the other. The enthusiast reads the sceptic as afraid, as someone protecting a status quo for self-interested reasons. The sceptic reads the enthusiast as shallow, as someone trading depth and craft for the appearance of productivity. Once those stories calcify, the conversation is over before it starts. The team fractures along a line nobody officially drew, and disagreements that should be about tools start showing up sideways: in code review tone, in estimation arguments, in quiet resentments about whose work is valued and in misreadings of what the other side actually produces.

Rogers’ research on the diffusion of innovations found that early adopters and the late majority have always coexisted inside any technology transition [1]. The dynamics he described — the gap in values, the communication breakdown between cohorts, the way innovation characteristics get distorted in transmission — are all present here. What is different is the unit of analysis. Rogers was describing market segments. But this is the same five-person team, disagreeing about what work means, every day, in quiet resentments about whose work is valued, and eventually in how each side labels the other: the early adopter unconsciously writing off the cautious colleague as resistant; the cautious adopter gradually dismissing the early adopter as someone who has outsourced too much judgment to the tool.

The Shift of Complexity: From Coding to Specifying and Reviewing

AI does not eliminate complexity from software development. It relocates it.

The bottleneck is no longer writing code. It is knowing precisely what to ask for and knowing whether what came back is correct, coherent with the broader system, and appropriate to the actual problem rather than a plausible-sounding approximation of it. Specification and review have always mattered. They now matter more than implementation, in a way that most job descriptions, career ladders, and team processes have not caught up with.

This relocation is not neutral across the team. The engineer with fifteen years of domain experience and strong system intuition is exceptionally well-positioned for it. They know what good looks like. They can spot the plausible-but-wrong output, the code that solves the stated problem but misses the real one, the architectural choice that will be painful in six months. Their expertise, previously bottlenecked by typing speed and implementation time, is now a direct multiplier on output.

The engineer two years into their career is in a harder position. They were still building the pattern-matching intuition that comes from writing a lot of code, making a lot of mistakes, and wrestling with problems long enough for the lessons to stick. The reps they need may be getting abstracted away before they have had a chance to accumulate them.

This concern has to sit alongside the early task-completion evidence, not pretend it does not exist. Peng et al.’s controlled experiment with GitHub Copilot found that developers using Copilot completed a bounded JavaScript task 55.8% faster than the control group, and that less-experienced developers appeared to benefit especially strongly [6]. That matters. But completing a task faster is not the same thing as being more productive inside a living software system. Team productivity includes specification, review, integration, maintenance, and the cost of discovering later that a plausible solution was only locally correct.

That is where the role of the experienced engineer becomes more important, not less. In a study of AI-assisted programming in open-source projects, Xu et al. found that productivity gains were driven largely by less-experienced or peripheral contributors, while the added review and rework burden fell disproportionately on more experienced core developers [7]. The senior engineer’s value shifts from being the person who writes the most code to the person who prevents, absorbs, or pays down the cost of code that arrived too easily.

The inversion is worth sitting with: AI tooling may make junior engineers faster at producing first drafts while making them more dependent on senior judgment for framing, validation, and integration. If that is true, the implications for hiring, mentoring, and career development are significant and largely unexplored.

A Hole the Size of Implicit Knowledge

This is the most underweighted risk in most discussions about AI adoption, and it operates at two distinct levels that are easy to conflate.

At the individual level, software expertise is not primarily stored as explicit knowledge — as things you could write down and hand to someone else. It is stored as pattern recognition, intuition, and embodied judgment built through years of accumulated struggle. Polanyi called this tacit knowledge, and his observation — that we know more than we can tell [2] — was not a philosophical nicety. It was a precise description of how expert performance actually works.

The cognitive science behind this is fairly well-established: expertise is built through effortful engagement with problems at the edge of current ability, through making errors and receiving feedback, through the slow accumulation of pattern-matching that eventually becomes intuition [3]. What learning researchers call “desirable difficulties” or productive failure — the friction, the struggle, the time spent stuck — can be generative rather than wasteful [8]. The difficulty is not always a bug in the learning process. Sometimes it is the learning process.

AI tooling, adopted without deliberate attention to this, bypasses the mechanism. The engineer who would have spent two days wrestling with a hard problem and emerged with embodied understanding of why a particular approach fails, what the failure modes feel like, and how to recognise them early, instead generates a working solution in twenty minutes and moves on. The output is indistinguishable. The understanding is not. The knowledge that would have been built in those two days is simply not built.

This is not an argument against using AI tooling. It is an argument for being deliberate about when the struggle is the point. A senior engineer who already has the pattern-matching can use AI to go faster without losing anything essential. A junior engineer who is still building it may be trading future capability for present velocity while oblivious that they are doing it, and worse, often being praised for it.

At the group level, the dynamics are different and in some ways more alarming.

Software teams do not store knowledge in individuals. They store it in a web of knowing who knows what, built up over time through repeated collaboration. Wegner called this a transactive memory system: the team as a cognitive unit, where the value is not just what any individual knows, but the shared map of expertise that lets the team route questions to the right person and combine knowledge effectively [4]. This is why long-tenured teams outperform collections of individually talented people who don’t know each other. And it is why losing a key team member is far more damaging than losing their formal documentation.

The implicit knowledge that lives at this group level is qualitatively different from what any individual holds. It is the understanding of why this service is structured the way it is. Why that architectural decision was made three years ago, and what the alternatives were, and why they were rejected. What the domain edge cases are and which ones have bitten the team before. Which old failures still shape current decisions. This knowledge is not written down, and not because people are lazy or secretive, but because most of it was never explicit in the first place. It emerged through experience and lives in the collective memory of people who were there.

AI cannot reliably access this knowledge, for a simple reason: by definition, it was never codified. If the knowledge lives only in people’s heads, in shared memory, in scars from past incidents, in the tone of a conversation after a failed migration, then there is nothing for the tool to index. The things that ended up in commit messages, documentation, ADRs, and Stack Overflow answers are the things that were made explicit. The things that were too contextual, too political, too obvious-to-someone-who-was-there never made it into any corpus. The model has no way to know that this particular service has a quirk in how it handles timezones because of a migration decision made under pressure in 2019, or that the data team and the platform team have a long-standing tension about ownership of the pipeline that makes certain conversations politically loaded, unless the team has first done the human work of surfacing that context.

When an engineer generates a solution with AI and doesn’t understand it deeply, they are not just skipping their own learning. They are also failing to connect the output to the group’s implicit knowledge, failing to ask whether this approach conflicts with a prior decision, whether it has been tried and abandoned, whether the person who would know is still on the team. The output is produced. The contextualisation is skipped. And the implicit knowledge, already fragile, already barely present, degrades a little more each time.

The power structure dimension is the part nobody talks about directly, which is usually a sign it is worth talking about.

Implicit knowledge is not just epistemically important. It is politically important. The engineer who understands the system’s old failures, who sees constraints nobody else sees, who is the first person the team turns to when something breaks — that engineer has informal power that is disproportionate to their title. They are often the person a team actually cannot function without, regardless of what the org chart says.

AI adoption threatens this arrangement, or at least appears to. If a tool can generate plausible answers to questions that previously required years of accumulated expertise, the informal power of the expert as the team’s default reference point diminishes. This is a real loss for the people who hold that position, not just financially or statuswise, but in terms of identity and meaning. Sennett’s work on craft and recognition helps explain why this matters: expertise is not only a capability but also a source of dignity, status, and belonging [5]. In software teams, that dynamic is rarely discussed directly, but it is there whenever someone’s authority rests less on title than on being the person who understands the system.

What makes it complicated is that the threat is partly real and partly illusory. AI can generate code that looks like it reflects deep system knowledge. It cannot actually replace the judgment of someone who has that knowledge, because the knowledge the model needs was never in the training data. That informal power may feel threatened before it is actually threatened. And that feeling, unspoken and unacknowledged, shows up in how the cautious adopter engages with the enthusiast’s AI-generated output in code review.

Is the Divide a Problem?

Not necessarily. The answer depends on what the divide does to the team — and that depends on whether it stays visible.

Yes: when the divide erodes what makes a team a team

A group of individuals becomes a team through shared assumptions about what the work is, what good looks like, and what the system they are building actually does: the common ground built through repeated collaboration and shared experience, not through process or org charts.

The divide becomes a problem when it erodes that common ground quietly enough that nobody notices until something breaks. Two engineers reviewing the same pull request are no longer operating from the same frame of reference. While one is evaluating craft and depth, the other is evaluating whether the specification was adequate. They are not disagreeing about the code. They are disagreeing about what the work is.

That is a different and more corrosive problem. The loss of common ground introduces friction in the day to day and the long term of the team. It may even foster conflict (or uncover latent conflicts) that becomes harder to solve because of that lack of a shared baseline of understanding.

No: when the divide keeps the team honest

There is an equally strong case that diversity of adoption is not just tolerable but actively useful.

The enthusiast pulls the team forward, surfaces what is possible, raises the ceiling on velocity and ambition. The cautious adopter applies the brake, scrutinises the output, asks whether what was generated is actually correct and actually understood. Neither role is dispensable. A team of pure enthusiasm moves fast and breaks things in ways nobody catches. A team of pure caution struggles to move at all. The tension between them, held openly, produces better outcomes than either faction winning.

Besides, if the divide is to be resolved by decree, there is the question of where to settle. Closer to the early adopters or the cautious adopters’ position? Either way, everyone will be at least a little unhappy.

Now What?

Engineering teams have always contained people with different relationships to change. The engineer who reads every RFC before touching a new library and the one who has already shipped something with it before the RFC is published. The one who wants to understand the system completely before changing it and the one who learns by changing it. These tensions are not new, and the teams that function well have never resolved them. They have learned to live with them.

The AI divide is the same tension, louder and faster. The question is not which policy to impose or which side should win. It is whether the tension can stay visible enough to remain productive rather than corrosive. And that depends, as with most things in software teams, on a condition more than on a process.

The condition is common ground. Not agreement, not uniformity, not a shared opinion about whether Copilot is good actually. Common ground in the older sense: enough shared context, shared history, and shared trust that the disagreement stays above the surface where it can do useful work, rather than going underground where it quietly corrodes everything it touches.

This is precisely what the AI divide is eroding, and precisely what most modern team structures make harder to maintain. A distributed team with no stable physical space, high turnover, and low-ceremony remote rituals has almost no mechanism for producing common ground organically. The enthusiast and the cautious adopter develop their positions in separate windows, on separate days, and bring them into contact only in pull request comments and sprint reviews. The common ground that would let them hold the tension productively was never built.

This is where the Brigade Model sits in the background of the argument. Its relevance here is not as a checklist or a universal prescription. It is as a way of thinking about the conditions under which balance becomes possible. Small teams, stable membership, and one day a week in the same room are not primarily about productivity or velocity. They change the kind of disagreement a team can hold. The conversation that happens after a whiteboard session. The offhand remark about a production incident that becomes a shared reference point. The moment someone says “I tried that six months ago and here is what happened” — and the person across from them actually knows what six months ago looked like, because they were there.

That is the space where the middle ground lives. The enthusiast and the cautious adopter, in that room, are not just colleagues with different tool preferences. They are people who know each other, who have shared history, who have enough mutual trust to say the uncomfortable thing and enough shared context to hear it charitably. The divide does not disappear. It becomes something the team can work with.

The point is not that one side should win. The enthusiast without caution loses depth. The cautious adopter without experimentation loses movement. The difficult, valuable thing is the held tension: enough ambition to explore what the tools make possible, enough judgment to notice when the shortcut has skipped the work that mattered, and enough common ground that neither side has to become a caricature of the other.

A Note on Evidence

Several arguments in this article rest more on practitioner observation than on established research. That is partly a function of the recency of the phenomenon: the evidence base is still forming, and much of what is described here is happening now, not in retrospect. Where specific claims are speculative or lightly evidenced, the text tries to signal that uncertainty in the prose rather than pretending the evidence is stronger than it is.

The author writes from direct exposure to both sides of the divide described, and holds these conclusions with appropriate uncertainty. The goal is not to settle the question but to name something that seems to be happening and offer a frame for thinking about it. The conclusions here may turn out to be wrong. The author would rather be honestly uncertain than falsely confident.

References

[1] Rogers, E.M. (2003). Diffusion of Innovations (5th ed.). Free Press.

[2] Polanyi, M. (1966). The Tacit Dimension. Doubleday.

[3] Ericsson, K.A., Krampe, R.T. & Tesch-Römer, C. (1993). The role of deliberate practice in the acquisition of expert performance. Psychological Review, 100(3), 363–406.

[4] Wegner, D.M. (1987). Transactive memory: A contemporary analysis of the group mind. In B. Mullen & G.R. Goethals (Eds.), Theories of Group Behavior. Springer.

[5] Sennett, R. (2008). The Craftsman. Yale University Press.

[6] Peng, S., Kalliamvakou, E., Cihon, P. & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv:2302.06590.

[7] Xu, F., Medappa, P.K., Tunc, M.M., Vroegindeweij, M. & Fransoo, J.C. (2025). AI-assisted programming decreases the productivity of experienced developers by increasing the technical debt and maintenance burden. arXiv:2510.10165.

[8] Kapur, M. (2016). Examining productive failure, productive success, unproductive failure, and unproductive success in learning. Educational Psychologist, 51(2), 289–299.