AI Writes 29% of New Code: What That Means for API Docs

A new study puts a real number on something that's been more vibe than fact until now: how much code running in production today was never typed by a person. The answer, as of early 2025, is close to three in ten new Python functions on GitHub. That number matters here for a specific reason, not a general one: docs written for a person reading a browser tab are a worse and worse fit for how code actually gets written now, and it's part of why AIOZ Stream maintains a parallel, machine-readable version of its API docs at all.

TL;DR:

• A 2026 study in Science found AI wrote an estimated 29% of new Python functions from US contributors by early 2025, up from 5% in 2022.
• Less experienced programmers use AI in 37% of their code, more than the 27% figure for experienced programmers, but the productivity gains go almost entirely to the experienced group.
• The study measured Python on GitHub specifically, not "most software" broadly, worth keeping in mind before treating this as a universal claim.
• As more code gets written with an AI assistant in the loop, docs formatted for a person scrolling a page are read less, and docs formatted for a model to load directly matter more.
• This is the same reason behind AIOZ Stream's llms.txt files, machine-readable documentation is becoming a real second audience, not a nice-to-have.

What the study actually measured

Researchers Simone Daniotti, Johannes Wachs, Xiangnan Feng, and Frank Neffke trained a classifier to spot AI-generated Python functions across more than 30 million GitHub commits from roughly 170,000 developers, then published the results in Science in early 2026. That's a fairly narrow scope on purpose: Python, GitHub, functions specifically, not every language or every code host. It's a solid, large dataset, but it's not a census of all software written anywhere, and the study doesn't claim to be.

The number that matters

By early 2025, an estimated 29% of new Python functions from US contributors were AI-generated, up from 5% in 2022. Three years, roughly a sixfold increase, and this is presumably still climbing given how much has shipped in coding assistants since the study's data window closed. Other countries showed lower but still rapidly rising shares over the same period, consistent with US developers having earlier and broader access to the coding assistants driving the shift. Whatever the exact number is today, the direction isn't ambiguous, and given how much has shipped in coding tools since the study's early-2025 data window closed, treating 29% as a ceiling rather than a snapshot would be the wrong read.

The experience gap nobody quite expected

Here's the part that's actually interesting, not just the topline number. Less experienced programmers use AI in 37% of their code. Experienced programmers use it in only 27%. So less experienced developers lean on AI more, which sounds like it should close the skill gap. It doesn't. The study found the productivity and exploration gains, working faster, trying unfamiliar libraries, taking on less routine tasks, are driven almost entirely by the experienced group. Beginners barely benefit despite using the tools more.

That's a genuinely uncomfortable finding if you were hoping AI assistants would flatten the playing field. The likely explanation isn't that beginners are bad at using the tools, it's that getting real value out of an AI-generated suggestion requires enough existing judgment to tell when it's right, when it's subtly wrong, and when it's a plausible-looking answer to a question you didn't actually ask. That's exactly the skill a beginner hasn't built yet. Put concretely: an experienced developer looking at a generated function that calls an API in an unfamiliar order can often tell something's off just from the shape of the code, even before running it. A beginner has no such instinct to draw on, so a plausible-looking but wrong suggestion is just as convincing to them as a correct one, which is a much worse position to generate code from than not having an AI assistant at all in some cases.

What this has to do with API documentation

Set the equity question aside for a second and look at the mechanical fact underneath it: a rising share of the code that touches any given API was drafted by something reading documentation, not a developer reading it themselves. That changes what "good documentation" means. Docs written for a person, a nice-looking page with a sidebar, syntax-highlighted examples, a search box, are optimized for a reading experience a model never has. It doesn't scroll, it doesn't click through, and it doesn't benefit from visual hierarchy the way a person does. What it needs is the actual operational detail: the exact auth pattern, the exact base URL, the order operations have to happen in, in a format that doesn't cost it a lot of context to parse.

Why HTML docs are a worse fit for this than they used to be

None of this makes rendered HTML docs useless, people still read them, and they're still the canonical reference. But a browser-first doc site carries a lot of structural overhead that only makes sense for a human: navigation chrome, marketing copy, expandable sections, screenshots. An AI assistant loading that page as context pays a real cost for all of it before it gets to the part that actually matters, the request shape, the field names, the sequencing. A flatter, plain-text format skips that cost entirely, which is the whole reasoning behind the llms.txt convention.

What AIOZ Stream already does about this

This is exactly why AIOZ Stream publishes a parallel llms.txt-standard set of docs alongside the normal ones, not instead of them. The index file and per-section files exist specifically so a tool like Cursor or Claude Code can load the operational detail it needs, without loading a full HTML page's worth of overhead for every request. A recent example: writing a working video upload endpoint by pointing an assistant at one section file instead of the whole API surface. That's a small, concrete case of exactly the shift this study is describing at scale.

What this doesn't mean

It's worth being precise about the limits here, since it's easy to round "29% of new Python functions on GitHub" up to "AI writes most software now," and that's not what the study says. It's one language, one code host, and a measure of function-level generation, not a claim about entire applications, entire codebases, or languages outside Python. It also doesn't mean generated code is reliable by default. The same discipline applies here as everywhere else in this series: check the order of operations, check that a status gets polled rather than assumed, and verify against the real API before shipping anything an assistant wrote. It's also worth being honest that a study measuring what got committed to GitHub says nothing about how much of that code was later rewritten, reviewed heavily, or reverted, commit-level detection catches the moment code entered a repository, not how much human correction happened around it before or after.

Frequently Asked Questions

Where does the 29% figure actually come from?
A 2026 study in Science by Daniotti, Wachs, Feng, and Neffke, based on a classifier trained to detect AI-generated code across more than 30 million GitHub commits from about 170,000 developers.

Does this mean most software today is AI-written?
No. The study measured new Python functions on GitHub specifically, not software in general, and even within that scope the figure is under a third.

Why do less experienced programmers use AI more but benefit less?
The study found productivity and exploration gains are concentrated among experienced programmers, likely because judging whether an AI-generated suggestion is actually correct takes experience beginners haven't built yet.

How does this connect to AIOZ Stream's llms.txt files?
As more code gets written with an AI assistant in the loop, documentation formatted for that assistant to load directly, rather than for a person to read in a browser, becomes more useful. That's the reasoning behind maintaining llms.txt alongside the standard docs.

Should I stop reading the regular API docs and rely on an AI assistant instead?
No. The regular docs remain the canonical reference. An AI assistant speeds up a first draft; checking it against the real docs and real API behavior is still on you.

Related Reading

• What Is llms.txt?: the machine-readable docs this shift in coding habits makes more relevant
• Building a Video Upload Endpoint with Cursor or Claude Code: a concrete, worked example of the pattern this article describes at scale
• AIOZ Stream Developer Guide: the full API and SDK surface behind both sets of docs

References

• Who Is Using AI to Code? Global Diffusion and Impact of Generative AI: the preprint of the Science study cited throughout this article, including the exact percentage figures
• AI Is Already Writing Almost One-Third of New Software Code: the Complexity Science Hub's summary of the same study, including the experience-level breakdown