AI Coding’s First Trust Crisis

The rush to AI coding is meeting its first real backlash

For much of the past two years, software’s AI boom has been sold as a story of acceleration: faster prototyping, fewer blank screens, more code shipped by more people. But in recent days, a different phase has come into view — one less about novelty than about trust.

A cluster of disputes across the software world has exposed a deeper tension in AI-assisted programming. Microsoft faced criticism after a recent version of Visual Studio Code began adding a “Co-Authored-by Copilot” line to some Git commits by default, including in cases where developers said they had turned off AI features or were not consciously using Copilot at all. The Zig programming language, meanwhile, has doubled down on one of the strictest anti-LLM policies in open source, arguing that code review is not merely a mechanism for accepting patches but for cultivating dependable human contributors. And among technologists experimenting with what has come to be called “vibe coding,” there is now a more mundane but revealing concern: if AI makes it trivially easy to generate small personal apps, how are all of those apps supposed to be discovered, distributed and understood?

Taken together, the episodes suggest that the software industry is moving beyond the question of whether AI can help write code. It is now confronting the harder questions of how such help should be recorded, when it should be allowed, and who gets to decide.

A line in Git history becomes a flashpoint

The uproar around Microsoft centered on a setting in VS Code 1.118 called `git.addAICoAuthor`, which shipped enabled by default. The feature was described in release notes as a way to add Copilot as a co-author for chat and agent workflows when Copilot had made file changes. But users soon complained that the attribution appeared in commits “for no reason,” including scenarios in which they believed AI features were disabled or unrelated tools had been used.

That seemingly small change touched a nerve because a Git commit message is not just decoration. It is part of a project’s permanent record — an audit trail that can shape internal compliance reviews, open-source governance, and future judgments about who wrote what. For employers, maintainers, and researchers trying to understand how software was produced, a co-author trailer can carry meaning well beyond the moment it was inserted.

Microsoft moved quickly after the backlash. On May 3, the company merged a rollback restoring the feature to an opt-in default and disabling the tracking path when AI features are hidden. But the damage, for some developers, was not simply the bug or the awkward rollout. It was the impression that one of the industry’s most influential software companies had treated AI attribution as something that could be added silently and sorted out later.

That response reflects a broader unease in programming circles. Many developers are open to AI assistance but wary of ambiguous authorship signals. If a model suggested a function, rewrote a test or generated boilerplate that a human then substantially modified, what exactly deserves disclosure? And should that disclosure live in the commit itself, in repository metadata, in a policy document — or nowhere standardized at all?

Those questions remain unresolved. What the VS Code episode made clear is that developers do not regard authorship metadata as a product-growth experiment.

Zig’s answer: the code is not the only point

If Microsoft’s dispute is about consent and attribution, Zig’s is about governance.

The language project has long enforced a blanket prohibition on LLM use in issues, pull requests and bug-tracker comments, one of the most restrictive stances among major open-source communities. That position was publicly defended again in late April by Loris Cro, a vice president of community at the Zig Software Foundation, who argued that successful open-source projects eventually face more incoming contributions than maintainers can realistically process. The answer, in Zig’s view, is not simply to optimize for polished patches.

Instead, Cro argued, maintainers should optimize for people.

In his formulation, reviewing a newcomer’s imperfect contribution is an investment in a future collaborator. The point is to help that person learn the codebase, absorb project norms and become a trusted participant over time. A pull request generated largely through an LLM may look efficient on the surface, but, in Zig’s telling, it breaks that social exchange. The maintainer spends time reviewing code without necessarily building a relationship with a contributor who can reason independently about the project later.

Cro described the philosophy as “bet on the contributor, not on the contents of their first PR.”

The stance has drawn attention partly because it carries real trade-offs. Bun, the JavaScript runtime written in Zig and now under Anthropic ownership, recently pointed to major performance gains in its own Zig fork but said it did not expect to upstream the work because of Zig’s strict ban on LLM-authored contributions. A Zig core contributor later noted that there were technical reasons unrelated to AI that would also have complicated acceptance of that specific patch. Still, the episode illustrated how the divide is becoming practical, not theoretical: some projects are beginning to treat AI-mediated code as a governance problem even when it appears technically useful.

That position may remain unusual. But as maintainers across open source struggle with review backlogs, spam and the rising volume of machine-assisted submissions, Zig’s logic could become more influential than it now appears.

The flood of tiny apps

At the opposite end of software culture — not the carefully governed repository but the quick personal tool — AI coding is creating a different kind of problem: abundance.

Matt Webb recently argued that the explosion of “vibe-coded” apps should prompt something like RSS for software: a feed-based way to publish, subscribe to and discover the growing stream of tiny utilities being spun up with AI assistance. Simon Willison, the programmer and writer, echoed the idea and added an Atom feed to his own tools page with the help of Claude.

The analogy is telling. Webb’s premise is that when AI dramatically lowers the cost of making software, a micro-app starts to resemble a blog post: personal, contextual, frequent, often useful to a narrow audience and not necessarily intended as a full-fledged product. In that world, app creation becomes less scarce — but discovery and maintenance become harder.

Where do such apps live? How are they installed? How long are they supported? How does a user know whether a tiny AI-built tool is trustworthy, secure or abandoned? If these tools proliferate as quickly as enthusiasts expect, the old product categories of “website,” “app” and “open-source project” may no longer be enough to organize them.

The feed idea does not solve those problems, but it points to the shape of the next one. Once creation becomes cheap, infrastructure for sorting, filtering and understanding what has been created becomes newly valuable.

The question beneath all three disputes

The fights over commit trailers, contribution bans and micro-app feeds may seem unrelated. In fact, they are all arguments over provenance.

Who made this code? Under what conditions? Can that record be trusted? Who is accountable when something breaks? And in a world where software can be drafted conversationally, edited by models and published in minutes, what exactly counts as authorship?

For years, the software industry’s debates about AI coding focused on capability — whether the tools were good enough to matter. Increasingly, the answer appears to be yes. But that has only shifted attention to the institutional questions that come afterward.

A co-author line in Git history sounds trivial until it enters legal and professional records. A ban on LLM-generated pull requests sounds purist until maintainers explain that their scarce resource is not code but reviewer attention and contributor trust. A flood of delightful little AI-built apps sounds liberating until users need ways to discover which ones are safe, current and worth their time.

These are the tensions of a technology becoming ordinary. AI-assisted coding is spreading fast. What is surfacing now is not simply resistance to the tools themselves, but a demand for rules — about consent, credit, responsibility and care — that the technology’s speed has so far outrun.

Sources

Further reading and reporting used to add context:

AI News