The AI-Native Developer - ACM Queue
-->
End Google Tag Manager (noscript) -->
Current Issue Past Issues Topics
We are redesigning the Queue website.
Take a look and let us know what you think.
May 4, 2026<br>Volume 24, issue 2
AI Literacy
The AI-Native Developer
Redefining work, identity, and the future of craft
Rudrajit Choudhuri, Eirini Kalliamvakou, Brian Houck, and Thomas Zimmermann
AI is changing software development in a way that forces a more uncomfortable question: Which parts of the job are still worth doing? Developers are making deliberate choices about what to keep, what to delegate, and what they no longer recognize as their work. Many report that their work feels less meaningful than before, suggesting a deeper shift in the role itself.
Drawing on large-scale mixed-methods surveys of developers and in-depth interviews with AI-fluent practitioners, we investigate what it actually means to be a software developer today, how the role evolves as AI fluency deepens, and where this all might lead. We explore what futures become possible as AI augments software creation and what choices might help us design for the futures worth wanting.
Picture a developer's day. There's the stereotype of a man in a hoodie in a dark room, writing code at lightning speed, delivering innovation in uninterrupted isolation. In practice, though, a developer's day is fragmented, interrupt heavy, and often far removed from the work developers value most.2,7,9
What it means to be a software developer has never been fully settled. Is the role defined by writing code? Designing systems? Solving problems? The answer has always shifted with tools, abstractions, processes, and organizational structures. AI is the latest shift, but unlike previous ones, it doesn't just change how developers work. It challenges what they do.
The discourse is polarized. Some predict AI will write nearly all production code within months; others see developers becoming orchestrators of autonomous agents, constrained by systems too complex and context laden to delegate to agents fully. Each narrative captures part of the change, but none fully resolves the harder question: What does it mean to be a builder when building can increasingly be outsourced?
We take a different approach. Rather than predicting a single outcome, we examine the now, the evolution, and the future across three acts: (1) What does it actually mean to be a software developer today? (2) How does the role evolve as developers deepen their AI fluency? (3) Looking forward, where does all of this lead? What futures become possible as these patterns accelerate? What choices will help us design for the future we want?
Throughout, we draw on mixed-methods research to anchor these discussions empirically, including large-scale surveys of 484 and 860 developers and in-depth interviews with 22 AI-fluent developers.
Act I: The Present: What It Means to Be a Developer Today
Today, developers spend roughly 14 percent of their week writing code The rest is scattered across meetings (≈13 percent), security and compliance (≈11 percent), debugging (≈11 percent), system design (≈9 percent), customer support (≈7 percent), code reviews (≈6 percent), and a long tail of documentation, testing, mentoring, and administrative tasks (figure 1).7
Figure 1. Average percentage of time spent on the key activities in the actual versus ideal workweek
That alone wouldn't be a problem if it matched how developers "ideally" wanted to spend their time. It doesn't. Developers consistently report wanting to spend far more time on problem solving, learning, and making visible progress and far less on interruptions and reactive work. As this time gap widens, productivity and job satisfaction plummet.
AI was touted to close this gap. Over the past few years, increasingly sophisticated tools have promised to reduce toil and accelerate delivery. AI adoption has surged. Yet, the gap has not closed. In fact, developers now report using AI more while simultaneously spending less time on work they find meaningful.1,10 It's as if a magnificent shovel meant to dig them out of a hole was used to dig faster in the opposite direction.
Why? Most AI integration strategies assume productivity improves when toil is automated. The tasks developers find tedious, however, aren't necessarily the ones they trust AI to handle, and the tasks they trust AI to handle aren't necessarily the ones creating the time gap.
So, we stopped asking, "What tasks could be automated?" and started asking, "What makes tasks meaningful to developers in the first place?" We found that developers cognitively appraise their work along four key dimensions: value (Does this matter to outcomes?), identity (Does this reflect my interests and expertise?), accountability (Am I responsible if this fails?), and demands (How much cognitive effort does this require?).2
These appraisal dimensions reveal three distinct clusters of developers'...