AI distrust is GitHub’s opportunity

Developers have never been more inclined to use AI, yet never less inclined to trust its output. In Stack Overflow’s surveys, the proportion of respondents using AI tools in development keeps climbing (44% in 2023, 62% in 2024, and 83% in 2026), but trust hasn’t kept pace. In the 2025 accuracy question, only about 33% trusted AI’s output, while 46% distrusted it. In 2026 Stack Overflow changed the question but still found only 7% of developers trust AI with important work decisions, rising to 48% if they can easily check the output.

Adoption, then, is running well ahead of confidence. This could well be someone’s chance to step in and repair the trust gap.

GitHub has an opportunity here, even when developers prefer someone else’s coding agent. Teams already use it to inspect, test, and review code. Helping them do the same with work from Claude or Codex gives developers more choice while making its own platform even stickier. It’s a remarkably clever jujitsu move, but will it work?

Back in 2023, I worried GitHub’s enthusiasm for Copilot could distract it from Git, particularly the visibility and collaboration that made the platform useful. There’s a better possibility now: AI could make those capabilities more valuable. As the number of tools proposing changes grows, companies need continuity in how they inspect, test, and accept them. AI, in short, could make GitHub more relevant than ever.

Use isn’t a vote of confidence

Just because we’re using AI to build faster doesn’t mean we necessarily trust it. The 2026 survey makes that distinction explicit. Its revised trust question asks about the conditions under which people rely on AI. And? Well, roughly 48% say they trust it but only when they can easily verify the output. Just 7% implicitly trust it for important work decisions. Those figures can’t be compared directly with the earlier accuracy question, as noted, but they do describe a practical bargain: People want the help, but increasingly, they also want evidence they can check because they worry about AI being “almost, but not quite, right.”

That’s a sensible way to use AI. An assistant can save time by finding an unfamiliar API or proposing a small change without us also having to give it full authority to determine whether a customer’s payment was handled correctly. Our confidence in LLMs should be tied to particular tasks and their consequences.

The company’s standards shouldn’t change just because an agent wrote the code. Reviewers still need to know what the change is supposed to accomplish, which checks it passed, and who accepted it. That’s how a team earns the confidence to delegate more work over time.

Different agents, same rules

GitHub has started building around this opportunity as it seeks to become the governance layer across a broader universe of AI tools. As such, its third-party coding agents (currently in public preview) include Claude and Codex, not merely Copilot. An issue or prompt can become a proposed change, a pull request, or an issue for further review. GitHub says these agents running on its platform receive the same security protections and limitations as Copilot cloud agents. Note that the policies don’t automatically extend to local agents in VS Code, which is an important boundary.

The useful part is the continuity. A company can try a different generator while keeping consistency in the place where the work is assessed. Requirements, existing tests, review responsibilities, and acceptance rules shouldn’t need to be reinvented whenever the preferred assistant changes. As I’ve noted, it’s important to architect for change in AI, given how fast things are moving.

Consider an agent asked to fix an authorization bug. The company needs to preserve a simple requirement: One customer must never be able to read another customer’s records. Switching from Copilot to Claude shouldn’t change that requirement or the regression checks that enforce it, or who has authority to accept the patch. The new agent is another supplier working within an established process, if architected correctly.

Enterprises can spend considerable effort fitting a tool into their existing responsibilities and processes. If switching agents forces them to reconstruct that arrangement, model choice becomes expensive in ways a subscription price won’t capture. A platform that preserves it can make experimentation practical. There’s reason to believe GitHub can be that platform, as it has been for a number of years for human-driven development.

A good platform’s gravitational pull

GitHub won’t become trustworthy simply by collecting agent activity, nor does its history of enterprise trust guarantee its future. But GitHub is in a good position to help development teams connect evidence to the decision they’re about to make, with enough context to challenge code that looks good but might not be.

I’m not suggesting, by the way, that we need to ensure

Read the original article: