When someone introduces GitHub Copilot into the workflow for the first time, a development team experiences a certain kind of silence. Not silence exactly — more like that moment before a meeting when everyone has already read the email but nobody has said anything yet. Without really acknowledging it, people begin to question what the tool truly means to them.
Ignoring that question has become more difficult. A recent Harvard Business School study tracked more than 187,000 open-source developers who were given access to GitHub Copilot, and the results were more nuanced than either the optimists or the skeptics had predicted. The amount of time spent coding increased by 12.4%. Project management activity — things like triaging issues, reviewing pull requests, handling backlogs — dropped by nearly 25%. That seems like a productivity win at first glance. However, it also describes a job that is subtly evolving.
What’s interesting is where the time went. Instead of simply writing more code, developers were performing less of the human coordination work that has always been a part of software development. There is a discernible decline in the informal cooperation that usually keeps teams running smoothly, including fewer peer reviews and conversations with coworkers. One of the study’s co-authors noted the risk of a cultural shift — a slow retreat from teamwork as developers lean on AI instead of each other. That’s not a productivity story. That’s a loyalty story.
When discussing developer tooling, the term “loyalty” rarely appears, but it most likely ought to. There is no model that captures the unwritten rules of a codebase, the trust between individuals who have debugged each other’s code at midnight, or the institutional knowledge that a team develops together. Despite its true value, GitHub Copilot has no idea why a certain function was written the way it was or what disagreement occurred six months prior that resulted in that architectural choice. That context is carried by humans. Additionally, that context is valuable.
To be clear, the tool is truly amazing. Developers report completing tasks 55% faster in some studies, and for repetitive work — boilerplate, standard API calls, scaffolding — Copilot can feel almost magical. Newer developers especially seem to benefit, finding suggestions that would have taken real digging to produce on their own. Today, prototyping can be completed in a day instead of a week. Those are real gains, and dismissing them would be dishonest.
However, there is a tension that is difficult to ease. Sonar’s 2026 developer survey found that 96% of developers struggle to fully trust AI-generated code, and nearly 40% say reviewing it takes more effort than reviewing a colleague’s work. One of the main causes of daily annoyance is now subtly correcting AI output. That’s an important detail to keep in mind because it implies that the efficiency gains aren’t coming at no cost, and that cost is being absorbed somewhere, typically by the developers the tool was meant to assist.
The employment situation is still genuinely ambiguous. Engineers aren’t being completely replaced by businesses, at least not yet. However, when a tool can produce useful code in a matter of seconds, they are posing more challenging queries regarding headcount and what a mid-level developer truly contributes. There’s a feeling that the standard for what constitutes valuable human input is gradually but subtly rising.
There has always been more to software development than just writing code. It’s about judgment, context, accountability, and the kind of creative problem-solving that doesn’t have a pattern to match. A loop can be written by GitHub Copilot. It can’t tell you whether the loop should exist at all. People still hold that distinction for the time being, and it’s likely what the discussion about AI and developer employment should be about.
