← Async Digital
Working notes ·

Thirty days of agentic development

Async Digital Ltd Cardiff, UK

Abstract

I spent thirty days building with an AI coworker in the loop and then counted what came out. From 24 March to 23 April 2026, across 22 repositories: 426 commits, 153 merged pull requests, 55,900 insertions against 19,700 deletions. Two thirds of the insertions came from one macOS app in the run-up to an App Store release, and the rest went to compliance documentation, a marketing site, support packages and tooling. I am publishing the count because I could not find an honest one to compare against when I started. It measures motion rather than value, and it describes one month rather than a rate.

I had no idea what normal looked like. Every figure I could find about working with coding agents came from somebody selling something, or from somebody’s best week. So I counted my own month. I took the numbers out of the git history rather than out of how it felt, because how it felt was “fast”, and that is not a measurement.

§1·Numbers

The headline figures

Thirty days, 24 March to 23 April 2026. Work touched 22 repositories. Inside them, 426 commits landed across 153 merged pull requests. The git history shows 55,900 insertions and 19,700 deletions, so roughly 36,000 net lines.

There is a second count, and it does not agree. The assistant’s own session log records 81,000 insertions and 7,700 deletions across 2,120 files. The gap is not an error in either number. The session count includes everything I asked for and then threw away: drafts, experiments, attempts rolled back before they reached a commit. About a third of the insertions never survived into git. The committed figure is what shipped. The session figure is what it cost to get there, and the cost is the more interesting number.

Session edits versus committed lines Four horizontal bars comparing edit volume during agent sessions versus committed git history across the 30-day window. Session insertions are 81,000; session deletions 7,700; committed insertions 55,900; committed deletions 19,700. Session insertions Session deletions Committed insertions Committed deletions 81,000 7,700 55,900 19,700 0 20k 40k 60k 80k 100k
Fig. 1 Session edits against committed lines, 24 March to 23 April 2026. Session counts include drafts, throwaway and rollbacks. Committed counts are what shipped.

On my side of the keyboard: 4,740 messages across the window, an average of 153 a day. The Bash tool ran 11,086 times. The session clock recorded 186 hours, which averages a little over six hours a day for thirty days.

Counted across the studio’s GitHub organisation for 24 March to 23 April 2026 inclusive. One repository is deliberately left out. The app was called Recall until 15 April, when it became Audient in a new repository seeded with the old one’s history, so every Recall commit in this window also sits inside Audient. Counting both would double every line of the app’s work. Count them both anyway and the totals come to 649 commits across 275 merged pull requests, which is the same month counted twice.

§2·Shipped

What landed

Most of the shipped value sat in one place. Within the 153 merged pull requests, Audient, my macOS app, took the bulk: features added, features removed, sandbox hardening, and a run of fixes against linker and dependency problems that only surfaced as the app moved towards release. The marketing site got its launch copy and its SEO foundation. The compliance corpus got its first full draft.

A pull request is one shipped decision with a record attached. A hundred and fifty of them in thirty days says something about the rate at which decisions could be drafted, reviewed and committed. The count says nothing about how hard the problems were. Some of those PRs were a typo fix that landed in minutes. Others sat under review for hours, across several rounds.

§3·Surface

Where the output landed

The output was lumpy. Around 69 per cent of the insertion volume went into Audient, which was in the late run-up to its App Store release. The remaining third spread across the other surfaces I was keeping alive at the same time: a marketing site, a compliance corpus drafted in English and Welsh, support packages and tooling for the app, and a follow-on workflow project.

Insertions by work surface Horizontal bar chart of insertion volume across the 30-day window, grouped by category. Audient is 38,446 lines (69 per cent). Documentation and marketing is 7,778 (14 per cent). App support packages is 6,000 (11 per cent). Workflow projects is 1,148 (2 per cent). Other is 2,552 (4 per cent). Audient (app) Documentation and marketing App support packages Workflow projects Other 38,446 · 69% 7,778 · 14% 6,000 · 11% 1,148 · 2% 2,552 · 4% 0 20% 40% 60% 80% 100%
Fig. 2 Insertions by work surface across the window. Audient accounted for around 69 per cent of insertion volume. The remainder spread across documentation, marketing, support packages, tooling and a workflow project.

By file type it was Markdown and Swift, and Markdown won by a distance. That surprised me until I looked at what the month had actually contained: compliance documentation in English and Welsh, brand and marketing copy, knowledge-vault maintenance, project planning. The Swift concentrated in Audient and its supporting packages. If you had asked me at the time what I had spent the month doing, I would have said building an app. The file counts say I spent it writing.

§4·Caveats

What the numbers do not capture

Lines of code measure motion, not value. A refactor that deletes a thousand lines makes the count smaller and the software better. A careless commit that adds a thousand does the opposite. Every figure above measures how much text moved through the working tree, not whether the moves were good ones.

One window is not a steady state, and this one was not typical. Audient was in a launch sprint. The compliance corpus was written from nothing inside this period, and the following thirty days would go on maintaining it rather than expanding it. A month’s throughput records what happened in that month.

This is also one studio, one person and one set of surfaces. Whether any of it holds for a different team, a different codebase or a different month is not something these numbers can tell you. I published them because I wanted a reference point and could not find one, not because I think they are a benchmark.