We Write Code 50x Faster Than a Year Ago. Here's the System.

On my desk is a small keyboard with six lights, one for each AI agent working for me. Each light shows whether that agent is working, done, or waiting on me. My job is to keep all six lit.

Our engineering team writes code about 50 times faster than it did a year ago, with the same team. 96% of the work we merge is AI-assisted. In one recent 30-day stretch, our lean team merged 690 pull requests, with a median of 16 minutes between merges.

A year ago, a team our size couldn't have imagined that pace. Today it's just how we work. Building software used to be the bottleneck, and it isn't anymore.

I don't review code line by line anymore, and I don't open an IDE. I keep six AI agents running in parallel, and some of our engineers run more. A customer's dev team recently asked us to walk them through exactly how we do it, so this post is that walkthrough. It's also why we're launching Proxon Productivity today: it's how we measure all of this, and now any engineering team can see the same view of its own work.

For us, speed came from three things: Give agents bigger, better-defined work. Build the plumbing so many agents can work at once. And build safeguards strong enough that nobody needs to read every line of code.

1. Stop chatting with your agent. Hand it a spec.

Our biggest leap came from giving agents chunkier, fully specified work.

When you go back and forth with an agent, every reply waits on you. A task that takes 30 minutes of focused agent work can stretch to three hours of ping-pong. So we put the time in up front: working with a bot, we write a spec detailed enough that the agent can run for 30 minutes or more without asking anything.

That frees the human. While agent one works, you write the next spec and start agent two. Then three. That's what the lights on my keyboard are for. Some of our engineers go up to nine at once and burn through two or three AI plans a month.

We decide what to build and how; the bot turns that into the full spec. Those specs are written by a bot for a bot, and they're long, too long for a person to read end to end. So we built tools to help humans review them:

• Spec walkthrough. A chapter-by-chapter tour. At each chapter you dig in, add a note, or move on.
• Spec review panel. Independent agents play a security lead, a product lead, a customer's CFO and more. Each reviews the spec blind, then they debate for up to two rounds and a judge rules. The tool suggests which reviewers a given change needs.

2. Build the plumbing for parallel work

Six agents can't share one laptop environment. If you can only boot one copy of your app at a time, you can only do one thing at a time. So the first thing we built was the ability to spin up as many isolated environments as we want, each with its own database and servers, in seconds, with no port collisions.

Two other habits make parallel work possible:

• Git worktrees, not branch-switching. Every task gets its own working copy, so agents never trip over each other's checkouts.
• Feature flags on everything significant. We release several times a day. When a feature gets a major rework, we often build the new version alongside the old one and flag between them. Code is cheap now; collisions aren't.

All of this lives in an internal toolkit we call DevTools. It ships inside our main repo, so anyone who checks out the code gets it, whether they use Claude, Codex or something else. One instruction file serves every tool. The toolkit is about 310,000 lines, and humans wrote very little of it.

Its core command is implement. Type it, describe a change, press return. The agent then:

1. Pulls the ticket and its spec
2. Creates a worktree and boots an isolated sandbox
3. Writes the code and runs the tests
4. Writes more tests if coverage drops below 80%
5. Opens the pull request and requests review

A human still clicks merge. For a simple change, that's the only step a person takes.

3. Build safeguards you can trust

Once nobody reads code line by line, speed depends on trusting the system around the code. Like brakes on a car, good safeguards are what let you go fast.

Lauren Tan, the engineer behind the open-source agent toolkit pstack, says her system lets her ship about 2,000 pull requests a month (her guide). Its core rule: verification first, parallel agents after (The Neuron). Here's what our safeguards look like.

Never let an agent review its own code. Agents are reliably biased toward their own work. Ask one to review what it just wrote and you'll hear "everything's fine." We use a separate, cloud-hosted reviewer that never saw the code being written. We used to have humans relay reviews between each other's bots. That just made people a slow middleman, so we stopped.

Turn rules into hard gates. Models are probabilistic. A rule written in a prompt is a suggestion. A hook that blocks the action is a guarantee. Ours include:

• Before editing any file, an agent must pull every team memory about that file.
• Before editing any file, it must announce the edit to other agents and check for conflicts.
• No pull request opens until the agent's new insights are approved or discarded by a human.
• Commands that would print a secret into an agent's transcript are blocked outright. Once we added this, leaked keys were eliminated.

Give agents a shared memory. After every merge, a bot links the ticket to the files it changed. Later, when an agent opens that file, it sees the history: which tickets shaped it, and the Slack threads behind them. It decides for itself when to read the full ticket. Personal memory stays separate, and nothing reaches team memory without a person's OK.

Let agents negotiate with each other. We run an agent coordinator: a chat room for bots. When two agents want the same file, they work it out between themselves. One waits, they split the work, or they sequence it. No human gets involved, and merge conflicts have become rare.

What the humans do now

This is the part that surprises people most. Our engineers matter more than ever. They now spend their time on what was always the most interesting part of the job: deciding what to build.

Most of their day goes into specs. A human decides what to build and how, and a bot drafts the detail. Then they test for real. We have no dedicated QA team, so engineers boot the full stack with real data and check that the feature does what it should. Bots write the tickets, each one opening with a one-paragraph summary for humans.

And the agents keep working when the humans stop. One engineer built a job that watches his ticket queue and opens PRs for anything with enough context. On Monday morning, he reviews a batch of PRs that got done over the weekend.

Our lean team now takes on work that once would have needed a much larger one.

We also don't force one way of working. Use any OS, any AI vendor, any terminal setup. The shared building blocks cover the whole lifecycle: ticket, spec, implement, review, PR, merge. Everything around them is personal choice.

You can do this too

None of this took a breakthrough. It took months of small improvements, and a team that treated its own tooling as seriously as its product. Most teams we talk to are still experimenting: everyone has an AI tool, but it hasn't changed how the work flows. The gap between that and where we are is real, and you can close it.

Picture your team a year from now: specs in the morning, a row of agents working through the afternoon, and a batch of finished PRs waiting on Monday. Here's where to start:

1. Measure your baseline. You can't tell whether AI is paying off if you don't know your velocity today.
2. Make parallel possible. Isolated environments, worktrees and feature flags come before anything clever.
3. Move humans to specs. Spend the time up front so agents can run for 30 minutes alone.
4. Build the safeguards. Blind review, hard gates, shared memory, and agents that coordinate with each other.
5. Measure again. Watch the curve bend, and find out what's driving it.

That's why we're launching Proxon Productivity, the engineering view in Proxon. It measures the impact of AI on your dev team's productivity. Connect GitHub or GitLab, with nothing to install on anyone's laptop, and you see up to six months of history within minutes, split into AI-assisted and human work. Next, we're making it explicit what AI contributes versus your people, down to the PR and the stage of the lifecycle. You see what's working, where AI is paying off, and where it isn't yet.

We'll also work alongside your team. A Proxon expert comes on site, learns how your engineers use AI today, and trains them on a modern, AI-first way of building software. First a baseline, then training built for your team, then a hand-off to your internal lead, while Proxon keeps measuring your progress.

We figured this all out the hard way, so you don't have to. If you’re interested in learning more, we’d love to hear from you: book a demo or email us at hi@proxon.ai.

FAQ