Google DeepMind’s audit separates code volume from research speed
Google DeepMind’s reported internal audit says AI writes a large share of code but has not yet produced a measurable acceleration in AI research, which is a useful warning for builders tracking output instead of actual cycle-time gains.
TL;DR: AI-written code can raise output without making research or product teams meaningfully faster, so measure the whole workflow, not just generated lines.
Is AI already accelerating AI research?
Not measurably, according to Google DeepMind’s first internal audit of AI-driven research, as reported by Decrypt in “Google Says AI Isn’t Building Itself Yet—Even Though It Writes 75% of the Code.”
That is the useful part. Not the headline number by itself.
Decrypt reported that Google says AI is writing 75% of its code. Taken alone, that sounds like the recursive self-improvement story has arrived. Models write code. Better code improves models. Better models write better code. Repeat until the curve goes vertical.
Google DeepMind’s reported audit points the other way: even with a huge share of AI-written code, it found no measurable speedup in AI progress.
That does not mean coding assistants are fake. It means “AI wrote the code” is not the same as “the organization learned faster.” Research is not just typing. It is choosing the experiment, setting up the data, debugging weird failures, noticing a false positive, waiting on compute, interpreting results, and deciding what to try next.
A model can help with several of those steps. But if the bottleneck is experimental design, GPU queue time, eval quality, or human review, then code generation moves the visible part of the work while the calendar barely changes.
Why does 75% code generation not translate into faster progress?
Because code is a poor proxy for progress.
A team can generate more scripts, more training harnesses, more eval wrappers, and more internal tools without improving the rate at which good ideas survive contact with reality. In fact, more generated code can create its own drag if the review burden rises, test coverage lags, or engineers spend time untangling plausible-looking output.
This is the common trap in applied AI too. A marketing team measures drafts created. A support team measures replies suggested. A dev team measures pull requests opened. Those numbers look great on a dashboard. The better question is whether the approval loop shrank, error rates stayed flat or improved, and the same team shipped more finished work.
For AI labs, the bar is higher. “AI accelerates AI research” should mean faster validated model improvements, not just more code in the repo. Google DeepMind’s reported audit matters because it appears to separate activity from acceleration.
There is also a measurement problem. If a coding assistant saves a researcher 20 minutes on boilerplate but the experiment still takes two days to run, the gain is real but hard to see at the program level. If AI helps junior engineers contribute sooner, that may show up as team resilience before it shows up as frontier model velocity. No measurable speedup is not the same as no value.
Still, it punctures the cleanest version of the hype.
What should builders measure instead?
Measure cycle time from intent to verified outcome.
For software teams, that means time from ticket to merged, tested production change. For research teams, time from hypothesis to trustworthy result. For content and ops teams, time from request to approved asset or resolved case. The unit should be finished work, not generated artifacts.
I would also track review load. If AI doubles output but senior people spend twice as long checking it, the gain is cosmetic. Watch rollback rates, bug rates, hallucinated assumptions, duplicated work, and the number of abandoned branches or drafts. Those are where “productivity” quietly leaks out.
The Google DeepMind audit, as reported by Decrypt, is a useful reminder that the AI self-improvement story needs receipts. Code share is interesting. Measured acceleration is the claim that matters.
Practitioner’s Take: If you run a team using coding agents or research assistants, run a two-week baseline before adding the tool widely. Track one real workflow end to end, then compare after adoption: elapsed time, reviewer time, defect rate, and shipped outcomes. The catch most people miss is that AI often speeds up the easiest stage first. Your job is to find the actual bottleneck, or the extra generated work just piles up in front of it.