4,154 Commits in Six Months With AI Agents

TL;DR: In six months of 2026, I’ve committed 4,154 times to a single repo. My previous average was 500–1,500 commits per year, across everything. The project — EnergyConnect, a bulk liquid and chemical marketplace — went from zero to production in sixty days. I’ve written almost none of the code by hand. I guided every line of it, reviewed every line of it, and broke things I didn’t catch at a pace I’ve never broken things before. Lines of code is a terrible metric. Commit count is a terrible metric. But zero to production in sixty days with a team this small is not a metric — it’s a receipt.

The screenshot that made me write this

I pulled up my GitHub contribution graph a few days ago and genuinely didn’t believe it.

4,154 contributions in 2026. We’re barely past the halfway mark. My entire 2024 was maybe 1,200. My 2023 was somewhere around 800. And those were years I’d have called productive — I was shipping features, closing tickets, doing the work.

This year I’ve shipped more code than the previous four years combined, and I have written almost none of it by hand.

The commits are real. They compile, they pass tests, they run in production, and customers are using the software behind them. But what they represent is fundamentally different from what a commit meant to me two years ago, and I think it’s worth being honest about what changed, what got better, what got worse, and what it means if you’re watching your own commit graph spike and wondering whether any of it is real.

What 4,154 commits actually are

Let me kill the first objection before it forms: no, this is not commit noise.

There’s a reasonable person’s version of that argument — that agents commit more often, in smaller chunks, and inflate the count relative to how a human would batch work into larger, less frequent commits. That’s true. But I’d argue that’s a feature, not an artifact.

When I was writing code by hand, a typical commit was a bundle. “Implement carrier onboarding flow” — a commit message covering 400 lines across eight files. If something broke in that bundle three weeks later, good luck bisecting it. The commit message told you nothing about which of those eight files was the problem.

The agent commits differently. It commits after each logical change — a function, a migration, a test, a style fix — with a message that describes exactly what changed and why. We’ve instructed it to do this deliberately, and we’ve instructed it to attach Linear ticket IDs to every commit. The result is that our git history is, for the first time in my career, actually searchable. It’s documentation. It’s the changelog we always said we’d write and never did.

So yes, the commit count is higher. It’s higher because each commit is more precise, more traceable, and more useful than the bloated bundle commits I used to write by hand. The 4,154 isn’t noise. It’s granularity we never had before.

Zero to production in sixty days

The project those commits live in is EnergyConnect — a SaaS marketplace for bulk liquids and chemicals. It sits as middleware between carriers, brokers, suppliers, and end customers. The kind of platform that has a dozen user roles, complex multi-path forms, regulatory requirements, and integration points with external systems.

We went from an empty repo to production in sixty days.

We’re now at roughly 120 days, and the project is more mature than some codebases I’ve worked on for years at previous companies. We’re close to shipping a mobile app — the first mobile app I’ve ever built. I would not have had the confidence to say “yes, I can do that” twelve months ago. Not because I couldn’t learn it, but because the calendar math didn’t work. Learning a new platform, a new set of conventions, a new build system, and actually shipping something production-grade — that’s a quarter of focused work for an experienced mobile developer. I am not an experienced mobile developer. But I can describe what I want, review what comes back, and iterate until it’s right. That loop is fast enough now that the calendar math works.

The codebase has 1.5 million lines across it. I need to be clear about what that means: it’s not 1.5 million lines of hand-crafted, artisan code. It includes generated code, vendor code, scaffolding, configuration, and all the other things a real project accumulates. Lines of code is a terrible metric for measuring value — always has been. But it is a useful metric for measuring surface area, and surface area is where the real story gets complicated.

More code, more blast radius

Here is the thing nobody talks about when they celebrate AI-assisted shipping speed: every line of code you ship is a line of code you have to maintain, debug, and answer for when it breaks at 2am. I’ve written about this at the org level — velocity creates surface area. This is what it looks like from inside one codebase.

EnergyConnect has a carrier onboarding flow with six completion paths — different carrier types, different document requirements, different approval chains. An agent will nail the path you described in your prompt and silently break two others. We had a week where every fix to the hazmat carrier flow introduced a regression in the general freight flow. The agent had no persistent memory of the other paths unless we explicitly described them or it read the whole file. Memory helps — once you correct a mistake, a well-configured agent won’t make the same one twice. But you have to catch it the first time, and catching it the first time in a codebase growing this fast is genuinely hard.

This is the part of the AI productivity story that the conference talks skip. Yes, you can ship faster. But “faster” includes faster bugs, faster regressions, and faster accumulation of code that nobody has deeply read. The velocity is real. The risk scales with it.

The snake eating its own tail

Our review workflow is the part that sounds absurd until you realize there’s no alternative.

We use adversarial review agents — agents specifically configured to be skeptical, to look for the exact failure patterns we’ve learned to expect, to challenge assumptions and check edge cases. Then we do a manual pass — actually load it up, click through it, look at it with human eyes. Then a final review before production.

There is no version of this where a single human reviews 4,154 commits by hand. The math doesn’t work. At five minutes per commit — and that’s fast for a real review — you’re looking at 345 hours of review. That’s two months of full-time work just reading diffs, doing nothing else.

So the AI reviews the AI’s work. And I review the AI’s review. And yes, this is the snake eating its own tail. I’m aware. The question is whether the alternative — shipping less, or shipping without review — is better. It isn’t. The adversarial review catches real bugs. Not all of them, but enough that the process has earned its place. The specific patterns worth naming — the confident wrong answer, the silent regression, the context-window cliff — repeat predictably enough that you can build review agents around them. The bugs that get through are the ones where both the writing agent and the reviewing agent share the same blind spot — usually an implicit assumption about business logic that neither one has enough context to question.

That’s where the human still earns their keep. Not in reading every line, but in knowing which lines to look at — the ones where the business context is subtle enough that an agent’s confident “looks good” means nothing.

What I gained

I can ship things I’ve never built before. That’s the headline gain, and it’s not small.

A mobile app. A complex multi-tenant marketplace. Integration patterns I’d have spent a week researching and another week implementing — done in an afternoon with an agent that’s read the docs I haven’t.

I write JavaScript as confidently as I write Elixir as confidently as I write Go. Not because I learned three more languages, but because syntax stopped being the bottleneck. I can pick up where someone left off in a codebase I’ve never seen, in a language I’ve barely used, because the skill that matters now is problem decomposition and review — not remembering whether the function signature takes the error first or last.

The agents are better at certain kinds of work than I am. Boilerplate, scaffolding, the tedious mechanical work that used to eat the first two hours of any feature — they do it instantly and correctly and I never have to think about it again. That’s real time back. That’s afternoons I spent on architecture instead of plumbing.

And the ticket hygiene — I almost can’t believe I’m saying this — is genuinely better. The agents attach ticket IDs to commits, update statuses, close tickets with references to the commits that resolved them. The project management layer that every team says they’ll maintain and nobody does? It’s maintained. Because the thing doing the work doesn’t get tired of process.

What I lost

There was a simplicity in writing code by hand that I miss more than I expected to.

Not the syntax — I don’t miss semicolons or arguing about bracket placement. I miss the solving. The specific feeling of staring at a problem, tracing through the logic in your head, and arriving at a solution that you built from nothing. The agent gives you the solution in four seconds, and it’s usually right, and you saved an hour, and you lost something you can’t quite name.

Syntax used to be interesting to me. It isn’t anymore, because we don’t need to care about it. That’s probably good — it’s probably the same as how accountants stopped caring about long division when spreadsheets arrived. But it was a thing I enjoyed, and it’s gone, and I notice its absence.

The role shift is real. I am not a software engineer in the same way I was eighteen months ago. I am a director and reviewer of software engineering, performed at high speed by something that is very good at the mechanical parts and genuinely bad at the judgment parts. The judgment is what I provide. The judgment is, I think, all I provide now. And the uncomfortable question underneath all of it is whether judgment alone — without the reps of actually writing code — degrades over time. I don’t have an answer yet. Ask me in a year.

The math changed

At the end of the day, business is dollars and cents. Money in, money out. A solo developer — or a very small team — shipping a production marketplace in sixty days is a different economic equation than the same project taking six developers nine months. The math has changed.

But the math has changed in both directions. You can ship more, faster, cheaper. You also have to review more, catch more, maintain more. The blast radius of your output has grown, and if you don’t invest in the review layer — adversarial agents, manual verification, real QA — you’re not shipping faster, you’re failing faster. The commit count goes up either way. What determines whether those commits are an asset or a liability is whether you respected the blast radius.

4,154 commits. More than the previous four years combined. People are using the software. The bugs are real, the features are real, and the pace is real.

I just didn’t write most of it.

If you’re building with agents too: I wrote about what agents get wrong most often, why AI won’t shrink your team the way you think, and what my daily agentic workflow actually looks like — the boring, repeatable version of what this post describes.