OpinionAI & Development

The Waymo Effect: AI Is Eroding Developer Collaboration

Split-screen showing AI-assisted solo developer on left versus two developers collaborating at a whiteboard on right, representing the Waymo Effect on team collaboration

Before autonomous vehicles, a taxi ride came with an awkward side effect: conversation. Small talk about nothing in particular. Sometimes a tip about a local shortcut. Occasionally, a useful perspective from someone whose job required talking to strangers all day. The friction was real. So was the signal hidden inside it. Daniel Hook, CEO of Digital Science, calls what happens when you remove that signal the “Waymo Effect”: technology strips human friction from an interaction, we experience the removal as pure gain, and we don’t notice what’s missing until it’s gone. He’s describing AI tools and academic research. He’s also describing your team’s engineering culture — whether you’ve named it yet or not.

The Friction Is Not the Bug

There’s a widely shared assumption baked into how we talk about AI productivity: friction is waste. Remove it. Code review slows you down. Architecture debates stall the sprint. The senior developer who pushes back on your approach costs an afternoon. AI tools eliminate all of this and deliver a suggestion in milliseconds. The productivity gains are real and well-documented. But Hook’s central argument is worth sitting with: “The collaborator’s inconvenience is not a bug in the collaboration; it largely is the collaboration.”

A landmark Nature study examined 65 million papers, patents, and software products spanning six decades. The finding: small teams consistently produce disruptive breakthroughs while large teams excel at developing existing ideas. Why? Because small teams operate with tight collaboration, limited resources, and genuine friction — disagreement, constraint, intellectual challenge. Remove that friction and you remove the mechanism for disruption. AI pair programming delivers output without any of this. It does not ask why you’re building what you’re building. It doesn’t connect your current bug to an architectural decision from six months ago that it knows nothing about. It doesn’t serendipitously mention a pattern it noticed in a different service.

The Numbers Are Already Here

This isn’t a hypothetical risk. The shift is measurable. A 2026 IEEE study from researchers at UBC and the University of Zurich followed 30 developers in their actual work for up to twelve days, then surveyed 131 more. The result: 51% of developers now ask AI for technical help they would previously have asked a teammate. More than 60% said it was easier to ask the AI — specifically because there’s no fear of looking stupid in front of a colleague.

That last part is doing a lot of work. The social friction of admitting ignorance to a peer is uncomfortable. It is also one of the primary mechanisms by which knowledge transfers in a team. When that discomfort disappears, so does the transfer. Hook cites early data showing individual productivity rising while the diversity of ideas narrows. Those two things are not in conflict. They are happening simultaneously, and the productivity gain is making the idea narrowing invisible.

The Confidence Gap

There is a second-order effect worth naming. When non-experts gain confidence from AI validation, they stop deferring to domain experts. When domain experts repeatedly face AI-backed challenges they can’t efficiently refute, they withdraw from collaboration. The result is a team where the people who know most have the least incentive to engage. The Hacker News discussion of Hook’s article — 231 comments as of this writing — surfaced this pattern repeatedly: people using AI output as a shield to challenge expert recommendations they cannot actually evaluate. Experts stop correcting. The gap widens.

The Incentive Structure Is the Problem

It would be easy to frame this as a personal failing — developers choosing convenience over rigor. That misses the structural issue. Velocity metrics, sprint throughput, ticket closure rates: these are the numbers that get measured. AI-enabled solo output moves all of them in the right direction. Pair programming, architecture review, knowledge transfer between senior and junior developers — these are slower, harder to quantify, and largely invisible to the dashboards that drive decisions. The Waymo Effect is not a choice. It’s what happens when rational actors respond to rational incentives.

The Counterpoint Is Real Too

Not all friction is useful. Some pair programming sessions are two developers confusing each other. Some architecture debates are cargo-culted arguments about patterns neither person fully understands. Some of what AI removes was genuinely waste. The actual risk is more specific: losing the valuable friction while celebrating the removal of useless friction, and not having a way to tell the difference until the collaborative infrastructure has already degraded.

Hook’s proposed fix for academic research — “fund the friction” — translates reasonably well to engineering teams. Schedule the architecture debate. Make code review about genuine challenge, not rubber-stamping. Create space where asking a colleague is the default before reaching for the model. The 51% who’ve already shifted their default didn’t make a deliberate choice — they followed the path of least resistance. The question for the other 49% is whether they’re deciding, or just haven’t hit the convenient threshold yet.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *

    More in:Opinion