Developers want AI as a collaborator, not a replacement
GitHub Next recently interviewed 25 developers to build a qualitative understanding of how they view working alongside AI. The goal: identify where AI assistance creates real value in complex workflows, and where developers want to keep control. The interviews surfaced consistent signals about which tasks developers want help with, which ones they want to keep, and the boundaries they expect from AI tools.
Two kinds of mental load
Developers in the interviews described two distinct categories of cognitive burden in their work. The first is tedious, repetitive work — boilerplate and uninteresting tasks developers consider not worth their time and ripe for automation. The second is demanding but engaging work: problem solving, learning, and figuring out difficult systems. Developers see this second category as the core of programming and as essential to their growth as engineers.
Tooling like GitHub Copilot already addresses the first category, acting as a second pair of hands to move through uninteresting tasks quickly. Developers report higher satisfaction when more of their energy goes to work they find interesting. The remaining opportunity is reducing the mental load of the tasks that are both complex and interesting — the ones where an overwhelming level of difficulty can discourage developers from even attempting the task. One interviewee described the state as "having mental blockers and distractions that prevent you from solving problems."
The shift in paradigm is from a second pair of hands to a second brain: AI that augments thinking and lowers the mental tax of advanced tasks, helping developers take on complexity rather than avoid it.
Where developers draw the line
The interviews made clear that developers feel a strong attachment to complex and advanced programming tasks. They see themselves as ultimately responsible for solving these problems, and it is through working on them that they learn, develop an understanding of large systems, and provide value. That attachment shapes how open developers are to AI involvement — and in what form.
There is good news for AI tool designers: developers are not expecting perfection. They see themselves as supervising AI output, guiding it toward results that fit their context. That process can still be frustrating, but developers view it as paying dividends over time as both sides adapt to each other.
A framework for the four parts of a task
This framework, adapted from earlier research on automation allocation logic, resonated with all the interviewees. It provides a useful mechanism for examining where developers face challenges and how open they are to AI help at each stage.
Openness to AI in understanding and planning
Developers want to get to context quickly, but they first need to find and absorb a lot of information, and often are uncertain where to begin. They see AI agents as far more efficient at this initial gathering phase. In this stage, AI can parse large amounts of information, synthesize it, and surface the highlights to focus the developer's attention.
Yet developers want oversight over that process. They want to see which sources the AI is using and be able to feed in additional sources that are situationally relevant or unknown to the tool. As one interviewee put it: "There's context in what humans know that without it AI tools wouldn't suggest something valuable."
Developers also find it overwhelming to determine what specific steps to take to solve a problem. This inherently open-ended activity creates cognitive load as they evaluate courses of action, tradeoffs, and the relative importance of a quick fix versus a more durable solution. Developers want AI to get them past the intimidation of the blank canvas — proposing one or more plans and arguing the pros and cons of each. They want strawman options to evaluate or use as prompts for further brainstorming, and they still want the ability to edit or cherry-pick steps in any proposed plan.
Resistance to autonomous decisions and implementation
Where developers are cautious is equally instructive. They want to retain control of all decision making during complex tasks and large changes. Given that identity is tied to these tasks — and that developers see themselves as ultimately accountable — AI may simplify context and offer alternatives, but developers expect to hold executive oversight.
Autonomous implementation drew two specific concerns. One is reliability: today's AI is perceived as not accurate enough to handle implementation without supervision. That perception could shift as models improve. The other concern is about identity and value: developers worry that autonomous implementation would remove the value they contribute, compromise their understanding of the code, and eliminate learning opportunities. The design implication: AI tools should help developers acquire and refresh mental models quickly and enable them to pivot in and out of implementation details, even as those tools handle changes on the developer's behalf.
What this means for the developer's role
The first wave of AI tools gave developers a second pair of hands. The next frontier is saving mental energy — an equally finite and critical resource. The correlation in the interviews is clear: lower cognitive burden tracks with developer satisfaction.
As partnerships with AI mature, developers will naturally shift up a level of abstraction. They will increasingly act as systems thinkers, specifying what behavior they want from applications, steering and supervising what AI produces, and intervening when necessary. Systems thinking has always been a quality of experienced developers, but as mechanical work moves to AI tooling, this skill becomes available earlier in a developer's career — accelerating growth. That path enables more developers to handle increasing complexity while establishing clear boundaries between their value and the role of AI tools in the workflow.
What the Interviews Taught Us About Developer-AI Collaboration
The interview findings point toward a division of labor that leverages each partner’s strengths. AI excels at parsing, summarizing, and synthesizing large volumes of information quickly, and AI agents can propose and critique plans for complex tasks. Together, those capabilities can lower the mental tax developers pay at the start of a task and help manage the inherent complexity of large codebase changes. Developers, for their part, remain the best judges of whether a recommended course of action is sound, thanks to their situational awareness and the context they bring to each implementation decision.
Two qualities emerged as essential for meaningful AI integration: steerability and transparency. Developers want tools that help them think, not think for them. They’re open to AI participating in sense-making and plan formulation, but they don’t want it to act without oversight, consent, review, or approval. Maintaining that transparency and steerability is what keeps developers in control even as tools grow more autonomous.
Trust in AI output remains largely unearned. Developers aren’t yet convinced AI can reliably handle significant autonomy, and that confidence will only build over time as tools demonstrate consistent, dependable behavior. One interviewee captured the sentiment: “The AI shouldn’t have full autonomy to do whatever it sees best. Once the AI has a better understanding, you can give more control to the AI agent.” Until that trust develops, enabling developers to easily validate AI-suggested changes is critical. As the same interviewee put it, “The AI agent needs to sell you on the approach. It would be nice if you could have a virtual run through of the execution of the plan.”
Putting the Principles Into Practice
These design principles directly inform how we’re building Copilot Workspace at GitHub Next. Our vision is a partnership that runs from a task description all the way to a pull request. The workflow derives context from everything in the task description, supporting developers’ sense-making. The AI agent proposes a plan of action, which developers can edit before implementation. Once they approve, they can inspect and modify every Copilot-suggested change, then validate the work by building and testing. The flow ends the way it normally would: with the developer opening a pull request for team review.
That’s only the starting point. The next wave of value will come from evolving AI into a true second brain through natural language interfaces, AI agents, visual programming, and related advances. As those new capabilities arrive, we intend to be careful not to overstep. Software creation is going to change faster than many expect, and our aim is to reinforce developers’ ownership, understanding, and learning of their code and systems in new ways. Even as we make consequential technical leaps, we’ll keep the focus on the people we’re building for.
Who We Interviewed
This round included 25 US-based participants working full-time as software engineers. Eighteen (72%) were favorable toward AI tools, while seven (28%) identified as AI skeptics. The developers came from organizations of varying sizes, with 64% in large or extra-large enterprises, 32% in small or medium businesses, and 4% in a startup. They also spanned a range of experience levels: 32% had 0–5 years, 44% had 6–10 years, 16% had 11–15 years, and 8% had more than 16 years.
