Engineered for the AI Era: We Ship Faster and Break Less

When we brought AI into how we build software, we weren’t chasing raw output. We changed the shape of the work: smaller, more frequent, fully reviewable changes — each one easy to read, easy to undo, hard to get wrong. Then we checked whether it paid off, pulling the numbers from source control and our ticket tracker, before and after. Work now ships in roughly a third of the time, carried by changes a fraction of their old size. Here’s what we found.

Commits per week · before vs after AI

Before AI

After AI

Each block is one unit of weekly commit volume, normalized across both three-month windows. More blocks, landing more often.

+77%

Commits per week

~440

Avg lines / commit
(was ~3,800)

We didn’t adopt AI software development to write more code. We adopted it to change how work moves through the pipeline — smaller pieces, reviewed faster, shipped with less risk.

As we’ve written before, the model matters less than the discipline built around it — see our piece on agent harness engineering for how we build that discipline. This is what it produced.

The loop got shorter

Commits per week climbed 77% across two equal three-month windows — a fair comparison, not a trick of the calendar.

In a microservices codebase, committing more often means each piece of work reaches review and integration while it’s still small and fresh, instead of aging in a branch for a week. Shorter loops, and far fewer surprises when it’s finally time to merge.

Smaller changes break less

The number we watched most closely wasn’t volume — it was the size of each change. The average commit shrank from about 3,800 lines to roughly 440, close to a ninth of what it was.

That shift is the whole reliability story. A 3,800-line change is nearly impossible to review properly and frightening to roll back; a 440-line one can be read, understood, and reverted in minutes.

Smaller changes mean less hidden in any single merge, less surface area for something to go wrong — and a fast, clean exit on the rare occasion something does. AI made it cheap to keep changes this small and this frequent, turning the discipline good teams chase with or without it into the path of least resistance.

A force multiplier for the team

Zoom out from any single engineer and the team-level pattern is the clearest part of the story: more changes, landing faster, in smaller and safer pieces. AI takes the friction out of the unglamorous work — boilerplate, test scaffolding, getting oriented in a service nobody has opened in months — so engineers can spend their attention on the parts that actually need judgment.

Architecture, trade-offs, and the call on what’s worth building stay with our engineers. AI coding tools clear the drag; they don’t make the decisions. That’s not a policy we bolted on afterward — it’s the reason the numbers above hold up, because a change that’s fast to ship still has to be one a human was willing to sign off on.

The payoff: faster, and fewer dead ends

Code volume was never the number we cared about. What matters is whether reliable work reaches production faster — that’s the real measure of software development productivity, and where AI software development either earns its keep or doesn’t.

All of that describes how we work. The question that matters is whether it changed what we deliver — so we pulled the same before/after windows from our ticket tracker and measured how long work took to finish, and how much of it got there at all.

It moved sharply. The time to deliver a piece of work — from the moment it’s logged to the moment it’s done — dropped about 63%. The distribution shifted with it, not just the midpoint: the share delivered within two weeks went from 16% to 41%, and within a month from 28% to 51%.

And it wasn’t because there was less to do — new requests coming in rose 21%, while the team completed about 9% more of them per week. Fewer fell away along the route, too: the cancellation rate dropped from about 10% to under 7%, work that used to stall now reaching the finish instead.

A force multiplier for the team

Zoom out from any single engineer and the team-level pattern is the clearest part of the story: more changes, landing faster, in smaller and safer pieces. AI takes the friction out of the unglamorous work — boilerplate, test scaffolding, getting oriented in a service nobody has opened in months — so engineers can spend their attention on the parts that actually need judgment.

Architecture, trade-offs, and the call on what’s worth building stay with our engineers. AI coding tools clear the drag; they don’t make the decisions. That’s not a policy we bolted on afterward — it’s the reason the numbers above hold up, because a change that’s fast to ship still has to be one a human was willing to sign off on.

The payoff: faster, and fewer dead ends

Code volume was never the number we cared about. What matters is whether reliable work reaches production faster — that’s the real measure of software development productivity, and where AI software development either earns its keep or doesn’t.

All of that describes how we work. The question that matters is whether it changed what we deliver — so we pulled the same before/after windows from our ticket tracker and measured how long work took to finish, and how much of it got there at all.

It moved sharply. The time to deliver a piece of work — from the moment it’s logged to the moment it’s done — dropped about 63%. The distribution shifted with it, not just the midpoint: the share delivered within two weeks went from 16% to 41%, and within a month from 28% to 51%.

And it wasn’t because there was less to do — new requests coming in rose 21%, while the team completed about 9% more of them per week. Fewer fell away along the route, too: the cancellation rate dropped from about 10% to under 7%, work that used to stall now reaching the finish instead.