How I Ship Five Times More With AI

In the 365 days before September 2025, I made 1,685 GitHub contributions. In the 365 days since, I made 9,455.

That's 5.61× — not a better-feeling year, a measured one. Same person, same hours, same commit discipline. What changed is how I work: I stopped typing most of my code, and I built a system where three or four AI agents implement plans in parallel while my job became planning and reviewing.

This post is that system, end to end — the tools, the workflow, the guardrails that make it safe, and the receipts.

Key takeaways

My GitHub contributions went from 1,685 to 9,455 in a year — a 5.61× jump that started the month I joined Baseloop and went all-in on agent-driven development.

The keystone is compound engineering: I brainstorm with AI, have it write an implementation plan I read and correct like a spec document, then hand the validated plan to an agent and move to the next task.

Parallelism only works because every task runs in its own isolated git worktree — on ParliamentConnect each worktree gets its own full Supabase stack, so agents never trip over each other.

End-to-end tests are the contract: AI writes them well, and a green e2e run after an agent finishes is what lets me trust work I didn't type.

None of it merges without a review gauntlet — my own review, then CodeRabbit, Codex, and Claude reviews — with a hard budget, because we learned what happens without one.

The graph I can't argue with

The monthly numbers behind the chart

Month	Contributions	Month	Contributions
Sep 2024	160	Sep 2025	122
Oct 2024	157	Oct 2025	110
Nov 2024	87	Nov 2025	418
Dec 2024	171	Dec 2025	196
Jan 2025	188	Jan 2026	550
Feb 2025	301	Feb 2026	624
Mar 2025	111	Mar 2026	897
Apr 2025	123	Apr 2026	838
May 2025	98	May 2026	893
Jun 2025	60	Jun 2026	1,199
Jul 2025	111	Jul 2026	1,143
Aug 2025	112	Aug 2026	2,483

Fig. 02 — Monthly GitHub contributions, Sep 2024 – Aug 2026. Bars are calendar months; the window totals are exact 365-day counts. Source: my public contribution calendar — github.com/tao101, retrieved 2026-08-31.

Look at the shape, not just the totals. Through mid-2025 I was averaging around 100–150 contributions a month — the output of a busy CTO who writes code between meetings, reviews, and infrastructure work. Then November 2025: 418. Then a climb that doesn't stop — 550, 624, 897 — until August 2026 lands at 2,483 in a single month. That's more than the entire year before it.

November 2025 is when I joined Baseloop as a founding engineer — while staying CTO at Veedoo. By every conventional rule, my output on each job should have halved. Instead the total went up more than fivefold, the active days went from 233 to 329 out of 365, and I still shipped side projects in my off time — this portfolio site, open-source self-hosting tools, and a steady stream of experiments — because exploring is what I do to relax.

I'm not claiming contributions are a perfect measure of value. A commit is not an outcome. But the same measure, applied to the same person across the same repos with the same habits, moving 5.61× in one direction — that's not noise. Something structural changed.

What my day actually looks like now

Here is my screen on an ordinary morning:

The Superset app showing a sidebar of a dozen projects — ParliamentConnect, Runday, Lifeline Ukraine, Baseloop, this portfolio — each with named git worktrees, while an AI agent session runs in the main pane. — Fig. 03 — Superset, one ordinary session: a dozen projects in the rail, each with its own worktrees, agents running in the panes.

The tool is superset.sh — a workspace manager built around git worktrees, with AI agents attached to each one. In the left rail you can see the Veedoo projects (ParliamentConnect's new-mpai-frontend with worktrees like with-tiktok-integration, with-mcp, with-mobile-app), Baseloop, and my personal projects, this site included. Right now, across all my repos, there are around sixty worktrees on this machine. Seven of them belong to ParliamentConnect's frontend alone; eight to Baseloop.

My loop looks like this:

Open a worktree. Every task starts with a fresh worktree — its own branch, its own isolated environment, before a single word of planning.
Brainstorm and plan inside it. I work the task into an implementation plan with AI — more on this below, it's the part that makes everything else possible.
Launch and leave. I hand the plan to an agent in that worktree, and the moment it starts executing, I'm done with that task for now.
Move to the next one. That's either opening a new worktree to plan the next task, or reviewing one where the agent just finished. I keep three or four tasks in flight at once.
Review, test, gate. When an agent finishes, my job flips to reviewing: I check the functionality, read the code, fix anything I don't like, have the AI add end-to-end tests, then send it through the automated review gauntlet before the PR merges.

The thing people miss when they hear "I don't type the code anymore" is that I'm not less involved with the code — I'm involved at a different altitude. Because I write and correct the plan, and because I review every diff, I stay familiar with every change in the codebase. What I gave up is the typing, and the serial waiting. What I kept is the judgment.

It's also — and I didn't expect this — much less stressful. One task blocked on a long build used to mean dead time and frustration. Now it means I look at a different worktree.

Compound engineering is the keystone

None of this multitasking works with a chat window and vibes. It works because of compound engineering — a workflow, developed by Kieran Klaassen at Every and packaged as an open-source plugin, built around a loop: brainstorm, plan, work, review, then capture what you learned so the next loop starts smarter. Their rule of thumb is that 80% of the effort goes into planning and review, 20% into execution. That inversion is exactly what makes parallel agents possible.

Concretely: I run /ce-brainstorm to think a feature through with the AI asking me questions, then /ce-plan turns that brainstorm into a markdown plan file committed to the repo. And these plans are not to-do lists — they read like spec documents, because that's what they are.

The plan for ParliamentConnect's auth-protected e2e tests runs 1,488 lines. Its header notes it was "deepened" in two research rounds — seven agents in round one, four in round two — before a human ever executed it. It contains the test-user strategy, the seed-data strategy, page-object models, implementation phases with checkboxes, and acceptance criteria that are actually falsifiable: "CI pipeline completes in under 20 minutes with 4 workers," "no flaky tests — run 3× to verify stability."

The newer Baseloop plans go further: each one carries a verification contract — a table of check, command, what it proves — and a definition of done written so a grep can confirm it. Across Baseloop's docs/plans/ there are 35 of these documents totaling almost 14,000 lines.

A stubby cartoon man presses a hand on one line of a long spec scroll cascading off a drafting table, leaving a small clay correction mark, while a boxy terminal-machine waits with an open tray to receive the plan. — Fig. 04 — The work is the scroll: correct the plan, then hand it over

My part is reading that document the way I used to read code. I fix the places where the AI misunderstood the system, cut scope it invented, and correct decisions I disagree with. When the plan is right, I launch /ce-work and the agent implements it. The plan is the interface between my judgment and the agent's labor — and editing it is why I never lose the mental model of my own codebase.

Every task gets its own sealed world

Running four agents in one checkout would be chaos — they'd fight over the dev server, the database, the test state. So every task gets a worktree, and every worktree gets an isolated environment.

A hand-drawn fan-out diagram: an inbox chute of plan sheets reaches a switch point where the mascot routes each plan onto one of four parallel tracks, each ending at its own small sealed database vat with a raised flag. — Fig. 05 — One plan per track, one database per track

On ParliamentConnect this is a 609-line setup-worktree.sh. It hashes the worktree's absolute path into a deterministic port offset, writes a .env, and brings up a complete private Supabase stack for that worktree — Postgres, Kong, auth, REST, realtime, storage, a mail catcher — about twenty containers per checkout, with Docker Compose project names derived from the directory so nothing ever collides. The setup script has its own unit tests, because infrastructure that agents depend on is production infrastructure.

Yes, this burns RAM. Four parallel Supabase stacks is not a lightweight habit. It's still one of the best trades I make, because each agent can run its own migrations, seed its own data, and run its own test suite at full speed without being limited by what any other agent is doing. No shared state, no confusion, no "who broke the dev database."

This is also where self-hosting everything stops being a cost story and becomes an AI story. Because the whole stack is mine, I can give agents real tooling instead of guesses:

CI that fails what should fail. ParliamentConnect's pipeline runs on our own Hetzner runners: unit tests, type checks, build, eleven SQL test suites against a real database, then the full Playwright e2e suite — and it posts the report on the PR. An agent's work isn't done when it says it's done; it's done when that pipeline is green.
A read-only database user for the AI. Our staging and production databases have a read-only role, and I hand it to agents when they need reality instead of source code. When we audited Baseloop's slow queries, the whole investigation ran through that role — the agent queried actual table shapes, row counts, and statistics to find the queries worth fixing. Reading the schema from code tells you what the database should look like; a read-only role shows what it is.
An MCP endpoint per worktree. ParliamentConnect publishes its own MCP server, and each worktree's agent gets the one on its own port — so an agent can search real clips in its own isolated stack while it works.

E2E tests are the contract

The question everyone asks: how do you trust code you didn't type?

The answer is boring and it works: end-to-end tests, everywhere, written mostly by the AI itself. Test generation is one of the things current models genuinely do well — hand one a plan and a running app, and it produces thorough Playwright specs faster than I ever did. ParliamentConnect's frontend now has 39 e2e spec files covering about 200 scenarios, next to 198 unit test files and 38 SQL database tests. Baseloop runs 26 Playwright specs with per-worker seeded organizations, so four workers never share state.

That suite is the contract between me and the agents. When an agent finishes a task, I don't have to wonder whether it quietly broke checkout or auth or clip search — I run the e2e suite in that worktree's private stack and I know. Every new feature is required to arrive with its own e2e coverage, which means the contract gets stronger with every merge. The safety net compounds too.

Review is a budget, not a vibe

Everything that survives my own review and a green suite still has to pass the gauntlet: a CodeRabbit review, a Codex review, and a Claude review before the PR merges. Three different models, three different blind spots.

A paper sheet rides a short track through three hanging stamp machines, each leaving its mark, while the mascot presses the final hand-stamp at the end of the line; two rejected sheets lie in a bin below. — Fig. 06 — Three machine stamps, then mine

We enforce this as a budget, because we learned the hard way what happens without one. At Baseloop, one early PR accumulated 29 Codex reviews; another collected 115 AI review submissions. Our docs literally call that state "AI code review hell." The fix was mechanical: reviews are requested through a script, capped at two Codex rounds plus one CodeRabbit round per PR, and PRs have a size ceiling — because our own history left no room for debate:

PR size	AI review rounds it took
Over 2,500 lines	5 to 29
Under 800 lines	0 to 2

That's the pattern with every piece of this system: the AI provides the volume, and the discipline — budgets, gates, contracts — comes from us.

What it costs

Honesty section. This workflow is not free.

Claude's usage settings showing a Max 20x plan with the weekly limit at 100% used across all models. — Fig. 07 — A Claude Max 20× plan, fully spent before the week resets

Two jobs plus personal projects plus the exploring I do for fun currently takes three Claude Max subscriptions and a Codex Max subscription — and I still routinely hit the weekly ceiling on one of them, like the screenshot above. Add the review bots on top. The parallel Supabase stacks eat RAM by the gigabyte. And the workflow has a discipline tax that tooling can't pay for me: actually reading the plans, actually reviewing the diffs. The day I start rubber-stamping is the day this whole system starts producing five times more garbage instead.

But stack that against what it buys: a CTO role and a founding-engineer role carried at the same time, an ML pipeline built solo, infrastructure migrations shipped with zero downtime, and evenings that still have room for the side projects that keep this fun. The subscription costs are the cheapest engineers I have ever hired.

The system, in one paragraph

Give every task a sealed worktree with its own database so agents never collide. Inside it, plan with AI until the plan reads like a spec you'd stake your name on. Let the agents type while you review at the altitude of plans and diffs. Make e2e tests the definition of done, and make the review gauntlet a budgeted, mechanical gate. Self-host enough of your stack that you can hand the AI real tools — a CI that fails honestly, a read-only window into real data. Then measure yourself, because the graph will tell you the truth either way.

Mine said 5.61×. I'm not going back.

If you want this kind of system building your product — I build MVPs in 30 days, or read more about how I got here.