What happened. Simon Willison published the “Code frequency” graph from GitHub for the Datasette project, showing a visible increase in commit activity in recent weeks. Willison explicitly links this to the arrival of the Opus 4.8, GPT-5.5, Fable 5, and GPT-5.6 Sol models: the graph’s final spike corresponds to when he started using these models as coding agents.

Why it matters to you. It’s a continuation of the sqlite-utils story: as we reported on July 5th, Willison shipped a release candidate written almost entirely by Claude Fable, documenting costs and prompt count. Now he documents the long-term impact with verifiable data: commit frequency on GitHub, which anyone can check. It’s not an impression, it’s a public metric showing how much code changes over time. For those augmenting with AI, it’s an example of how to measure adoption impact: not just “I seem to be going faster”, but “here’s the graph of changes before and after”.

If you want to try. The “Code frequency” graph is available for every public repository on GitHub: go to github.com/<user>/<repo>/graphs/code-frequency and you’ll see additions and removals per week. On your project, does the spike align with agent adoption?

In depth

The context: from sqlite-utils to Datasette. In early July, Willison had told how he rewrote much of sqlite-utils 4.0rc2 with Claude Fable, spending $149 and documenting every step. That story ended with a working release candidate and a first dot-release confirming: the agent-written code holds up in production. Now the narrative shifts to Datasette, another Willison open source project, and the measurement tool changes: no longer the cost of a single release, but the trend of development activity over time.

What the graph shows. GitHub’s “Code frequency” graph displays two curves: lines added (green) and lines removed (red) for each week. Willison flags an activity spike at the end, which aligns temporally with the adoption of Opus 4.8, GPT-5.5, Fable 5, and GPT-5.6 Sol. It’s a rough indicator — it counts modified lines of code, not quality or impact — but it’s public and verifiable: anyone can open the link and see the same graph. It’s not a synthetic benchmark: it’s real work on a project that’s existed since 2017 with a steady commit history.

How much to trust it. Willison himself writes “out of curiosity” and presents the graph as an illustration, not a rigorous proof. The spike could reflect other factors: a project phase, a large refactor, features touching many files. We don’t know what percentage of code in that spike was directly written by the agent versus modified by Willison after the first draft. The graph says nothing about quality: more modified lines can mean more delivered value, or more steps to reach the same result. But as a trend signal — “development activity increased during the period I adopted these models” — it’s honest and verifiable data.

What NOT to conclude. This isn’t a controlled test: there’s no control group, no baseline normalized for feature complexity. You can’t take the graph and say “agents double productivity”, because you’re not measuring productivity: you’re measuring volume of changes. But it’s an example of how a professional documents impact on their work with already-available metrics, instead of relying solely on impressions. For those adopting coding agents, the practical lesson is: watch your commit graphs, your issue closure times, the number of pull requests opened. If impact exists, it should show up there, not just in the narrative.