AI automated what developers love most: coding. Yet collaboration and communication, the parts that consume most of a senior developer’s day, remain largely under supported.

A few months ago, Caleb Mellas posted a question on LinkedIn that stuck with me: “Why did we build AI to do coding, when most of our time as Senior+ engineers is actually spent talking in meetings?”

Our own pre-AI research confirmed this repeatedly: how developers actually spend their time differs from what they wish they could spend it on: What makes a good workday is more coding time and more agency, while meetings, interruptions, and coordination consistently appear as the key sources of friction. So the question Caleb was really asking is not just about time allocation. It is about what developers value in their work.

And yet those are the parts AI has left largely untouched. Developers now report using AI more while simultaneously spending less time on work they find meaningful. A recent article from Brian Houck picked up on this observation: of all the key dimensions of developer experience (and SPACE), collaboration and communication is the one least impacted by AI (and also the least studied one). That made me wonder more broadly: how has AI actually changed the way developers spend their days?

Developers love coding. Why did we automate this away?

As one interview participant recently described it, the non-coding parts of the job feel like “death by a thousand cuts”: context switching, unexpected interruptions, helping others, compliance tasks, meetings that could have been an email. Research confirmed this: developers consistently report wanting more time on coding and problem-solving, and less on everything else.

So when AI tools arrived with the promise of reducing toil, the question worth asking was: which toil, exactly?

Today, writing new code accounts for only around 14% of a developer’s week. The remaining time is spread across meetings (~13%), security and compliance (~11%), debugging (~11%), system design (~9%), customer support (~7%), code reviews (~6%), and a long tail of documentation, testing, mentoring, and administrative overhead.

AI tooling has, overwhelmingly, targeted those 14% (i.e., coding).

In many companies, Claude Code, Cursor & Github Copilot have positively impacted coding, and have started supporting documentation, code review and security & compliance too. But the collaboration and communication parts of the job, which consume a growing share of developers’ time, remain almost entirely untouched.

The identity-craft split

To understand why this matters beyond productivity metrics, consider how developers actually appraise their work.

Choudhuri and colleagues surveyed 860 developers to map their daily tasks by how much they matter to outcomes, how strongly they align with professional identity, and how much cognitive effort they demand. This reveals three distinct clusters:

  1. Core Work: coding, debugging, testing, system design score high on all four. It is what developers consider their actual job, the source of craft and professional identity; and what makes workdays good.
  2. Ops & Coordination: DevOps, documentation, environment setup, stakeholder communication score high on value and demands, but weakly on identity. Developers know it has to happen; they do not feel it defines them.
  3. People & AI Building: mentoring, onboarding, AI feature integration score moderately across the board, but with relatively strong identity alignment. Developers protect this work deliberately.

Ironically, it is Core Work which AI has impacted most — yet developers wanted it there as a collaborator, not a replacement for their judgment. The tasks they most wanted automated, environment provisioning, monitoring, documentation, compliance, sit in the Ops & Coordination cluster, where current tools remain weakest. Developers get AI support for the work that gives them flow, and are left largely alone with the work that drains them.

Developers’ worklives have changed a lot, except collaboration

AI has shifted what developers spend their time on. Less writing, more verifying. Less implementing, more specifying. The most AI-fluent developers, what Choudhuri et al. call “Strategists”, have renegotiated their role around orchestration rather than implementation. One participant captured it well: “Maybe we become less code producers and more code enablers. My next title might be creative director of code.” But Strategists remain a small group. Most developers are adapting to a tool landscape not built around their preferences.

What has not changed is collaboration. A recent study by Afroz et al. found it to be the dimension least affected by AI: fewer than half of AI users reported any improvement in their ability to work with teammates.

Current tools can summarize a meeting transcript. They cannot tell a team why they are having the same architectural debate for the third time, reduce meeting load, surface diverging mental models, or help carry context across conversations and time. The hard parts of collaboration remain entirely unsupported and they consume a large and growing share of a developer’s week.

This is both a research and a tooling gap, and they reinforce each other: collaboration is hard to instrument, so it attracts less research, so tool builders have less to build from. The real opportunity is not AI that summarizes meetings, but AI that helps teams make sense of accumulated context — what was decided, why, and where understanding has drifted. That is a different class of problem from code completion, and arguably a more important one.

For both tool builders and researchers, that might mean starting from a different question: not “what can an LLM generate?” but “what makes a good day for a developer?”

This article first appeared in my blog: flowlabs.substack.com – Subscribe to be notified of new articles there!