How much does AI really speed up development? I measured it

Developers, managers from other companies, colleagues — the question I get asked most often this year is the same: how much does AI actually speed you up? I always had an answer, but it was a feeling. As a developer I clearly got faster. I wanted to check that feeling against numbers.

I had a convenient setup for it. Over the last year I have been the only iOS developer on GrowDiaries, a social network for growers written in pure SwiftUI and The Composable Architecture. The project splits neatly into two halves: in the first I worked the way I always had, and in the second I gradually built an AI workflow around my development. Because the whole history lives in one git repository and every commit to main is a shippable build, the two halves can be compared directly.

The result

Two identical six-month windows: June–November 2025, before the workflow, versus February–July 2026, with it. Same product, same architecture, same level of code review.

My gut said "about one and a half times". The numbers came out even higher: delivery cadence grew by 48%, feature throughput by 38%, and raw code output by 81%. I honestly did not expect it to be that big.

One caveat before the details. These numbers measure the part of the job that is writing code. Developers also spend a lot of time discussing features, planning and coordinating, and how much of your week that takes depends entirely on the company. On this project I could dedicate myself almost fully to development, so what you see here is mostly the speed-up of building features, not of everything a developer does.

What the workflow looks like

Like most developers, I started by chatting with ChatGPT, and as agentic coding appeared I brought it into my work step by step. Over time I learned what my harness is good at and where it fails — and most of my effort went into one thing: closing the feedback loop. Not the prompt, not the generation, but the last part: testing the code the agent produces.

The feedback loop

The best decision I made early on was choosing TCA as the architecture. It is built around testability, and that turned out to matter far more with an agent than with a human on the keyboard.

I started where it was cheapest — generating unit tests. That covers the business logic, but only the business logic. So I moved further and made the agent run full autotests: after finishing a feature it verifies the feature itself. I wrote guidelines for deriving test cases from my original specification, so every ticket comes with its own checklist. And the final step of every ticket is the agent running the feature in the simulator and walking through those cases.

Getting this loop right took real work and taught me a lot about how to structure testing for an agent. But it is exactly what raised the quality of the generated code — and higher quality of the first draft is what turned into faster delivery. It also changed how I think about architecture: I now value tests and an agent-friendly structure even more, because they are the fastest way to catch mistakes and hallucinations before they cost anything.

Getting the data in

The input side was surprisingly simple to set up with MCP. Documentation is pulled in from where it lives, and the Figma MCP gives the agent the full design specification of a screen, down to spacing and colors.

One piece of advice here: break your design down into a design system and maintain it from day one. It pays off twice. The agent does not keep re-creating the same UI components with small differences, and quality goes up, because those small differences are exactly where the bugs would have lived.

The numbers, and how they were measured

• Code output is lines of Swift added per month, *.swift files only, generated localizations and assets excluded. It went from about 6,000 to about 11,000 lines a month.
• Delivery cadence is shippable builds per month. The project is trunk-based: every non-merge commit to main is a working build carrying a feature or a fix, so the commit count is the delivery count. It rose from roughly 17 to roughly 25 builds a month.
• Feature throughput is features shipped per month, mined from ticket titles in the commit history. Tickets that are pure bug fixes are excluded. It rose from under 5 to almost 7 features a month.

July 2026 was the record month: 29,125 lines added, with the brand pages, ads and dark mode landing in the same month. The full month-by-month picture, including the per-feature breakdown, is on the stats page.

What did not change

• Review quality. I read every diff. The agent writes more of the first draft; I still own the decision.
• The architecture. Pure SwiftUI and TCA before, pure SwiftUI and TCA after. Agents work best in a codebase with strong, explicit conventions, and TCA turned out to be a very good fit for that.
• Stability. The app is in the App Store and crashes are, at the moment, simply absent.

A note on the metric

I know lines of code are a proxy metric, and I know they do not fully capture productivity. That is why builds and features are shown alongside them, and why the comparison uses identical windows on the same project. But these are the numbers that can actually be measured — and all of them point the same way: with the workflow in place, development speed and delivery speed went up, by more than I expected.