AI distrust is GitHub’s opportunity
InfoWorld ·
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 the system (whether GitHub or something else) should insist on verification of every trivial change forever. GitHub recently introduced , in public preview, an optional capability for Copilot code review to approve pull requests and satisfy required-approval rules. It’s not automatic; administrators must enable it and can restrict it by file path. But it’s a good sign of where things are heading. It’s also quite useful. A team might reasonably automate acceptance of some routine changes while reserving sensitive work for a knowledgeable reviewer. But enabling another AI approval doesn’t, by itself, supply independent evidence. The company still has to decide which checks justify that authority and when a person must intervene. GitHub’s own documentation warns that Copilot reviews can miss problems and recommends supplementing them with human review. I like how GitHub is doing this. While some have worried about the Microsoft-ification of GitHub, arguing that the company is making GitHub Copilot subservient to the larger task of selling Microsoft’s AI services, GitHub opening up access to third-party agents is actually developer and commercial genius. For developers, they get to use whichever frontier models they wish, with convenient billing through GitHub. In this way, GitHub can retain a paying customer even when Claude or Codex wins the coding task. Ironically, this expanded choice leads to making GitHub as a platform even harder to leave. Enterprises should weigh the convenience of consistent reviews and controls against the potential for greater dependence on GitHub, but convenience usually wins for developers . Other platforms can offer similar controls, so it’s not as if GitHub can sleepwalk its way into longer-term agentic success. Even so, it has a clear opportunity to let developers change coding agents without making companies rebuild the process for getting code into production. If GitHub gets that right, it can keep the customer even when someone else writes the code. It’s a super smart way to stick to GitHub’s long-term focus on developer needs while also providing a very Microsoft-focused platform future.
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 the system (whether GitHub or something else) should insist on verification of every trivial change forever. GitHub recently introduced , in public preview, an optional capability for Copilot code review to approve pull requests and satisfy required-approval rules. It’s not automatic; administrators must enable it and can restrict it by file path. But it’s a good sign of where things are heading. It’s also quite useful. A team might reasonably automate acceptance of some routine changes while reserving sensitive work for a knowledgeable reviewer. But enabling another AI approval doesn’t, by itself, supply independent evidence. The company still has to decide which checks justify that authority and when a person must intervene. GitHub’s own documentation warns that Copilot reviews can miss problems and recommends supplementing them with human review. I like how GitHub is doing this. While some have worried about the Microsoft-ification of GitHub, arguing that the company is making GitHub Copilot subservient to the larger task of selling Microsoft’s AI services, GitHub opening up access to third-party agents is actually developer and commercial genius. For developers, they get to use whichever frontier models they wish, with convenient billing through GitHub. In this way, GitHub can retain a paying customer even when Claude or Codex wins the coding task. Ironically, this expanded choice leads to making GitHub as a platform even harder to leave. Enterprises should weigh the convenience of consistent reviews and controls against the potential for greater dependence on GitHub, but convenience usually wins for developers . Other platforms can offer similar controls, so it’s not as if GitHub can sleepwalk its way into longer-term agentic success. Even so, it has a clear opportunity to let developers change coding agents without making companies rebuild the process for getting code into production. If GitHub gets that right, it can keep the customer even when someone else writes the code. It’s a super smart way to stick to GitHub’s long-term focus on developer needs while also providing a very Microsoft-focused platform future.