My coding agents got faster. I became the bottleneck.

For a while, getting better at coding with AI agents meant getting more done. Better context, better instructions, better tools. I could take on larger features and move through them faster.

Then something changed. The agents were ready to move, and I was the one holding things up.

I was reading their output, reviewing changes, answering questions and deciding what should happen next. More of my day went into managing the work. Adding another agent could just give me another queue to clear.

That was an uncomfortable discovery. I’ve written software and managed technical teams. I thought I knew how to delegate. Delegating implementation to agents, at this volume, felt quite different.

There is a point where you cannot read everything

At around 10,000 lines of code a day, I could still imagine keeping up with detailed review. My estimate for September so far is roughly 60,000 a day. At that volume, reviewing everything stopped being a realistic plan.

Those numbers describe the volume I was dealing with, not the amount of useful software delivered. More code can also mean more work to maintain. But the volume forced a decision: I could either become a permanent brake on development or change how I decided that a feature was ready.

My instinct was to read more carefully. Understand every choice. Check every implementation detail before letting the agents continue.

Honestly, letting go of that is hard. When you’ve spent years building confidence by understanding the code yourself, accepting code you haven’t personally read feels like removing the thing that made you responsible for it.

I still own the result. I just cannot make reading every line the condition for producing it.

Confidence needs somewhere else to come from

Three things became essential in my workflow: the harness around the agents, unit and integration tests, and automated review. They work together, and they need a measurement strategy behind them.

By harness, I mean the working environment that helps an agent do the job: project knowledge, tools, checks, clear completion criteria and a way to recover when something fails. A good instruction matters. So does making the relevant information and verification available when the agent needs them.

Tests give that work something concrete to meet. Unit tests help check individual decisions. Integration tests check whether the pieces still behave correctly together. A feature can look convincing in isolation and fail at the point where it meets permissions, storage or another part of the application.

Automated review adds another opportunity to question the implementation. I want the reviewer to look for missed consumers, unsupported assumptions and requirements that were quietly left behind. A reassuring summary from the agent that wrote the code isn’t enough.

The measurement part is what stops this becoming a ceremony. “Tests passed” needs to mean something specific. Which behavior did they exercise? Did the relevant integration actually run? What did the review find, and was the correction checked?

For me, the useful unit of progress is a feature with evidence behind it. Code volume tells me how much is moving. It doesn’t tell me whether the work is finished.

This works most of the time. It also leaves mistakes. The point is to make those mistakes discoverable and feed what they teach us back into the next round of work.

The enormous specification did not save me

I tried the other obvious route: specify more before starting.

I wrote specifications running to thousands of lines. The hope was straightforward. If I made everything explicit, the agents would have less to guess, and I could trust them to carry the whole thing through.

In practice, they got lost. Keeping all those requirements connected to the implementation, right through to completion, did not work the way I expected.

I still need clear specifications. But making a document longer doesn’t automatically make the work easier to execute or verify.

What works better for me is a bounded piece of work with an observable result, followed by another pass that strengthens it. Build a coherent feature, exercise it, review it, then use what you learned to decide the next improvement.

Strengthening the feature is part of building it

This is where I’ve had to accept the iterative side of the work much more fully.

A first implementation teaches you things the specification didn’t. An integration exposes an assumption. A review finds another path through the same behavior. Using the feature reveals that the technically correct result is awkward for the person trying to use it.

Those discoveries need their own short rounds of work. Enrich the behavior. Strengthen the checks. Revisit the parts that looked settled before they met the rest of the application.

That doesn’t mean calling something finished when a known requirement is missing. It means giving each iteration a clear scope and checking that scope properly, while accepting that the feature will develop through several iterations.

The speed of the agents makes that loop much more practical. I’ve had to change my own expectations to take advantage of it.

Moving the work into issues made a huge difference

One surprisingly effective change: I stopped using planning files scattered through the repository as the place to manage ongoing work.

I moved that work into GitHub Issues. In my experience, that change alone roughly doubled my productivity. That’s my assessment of the workflow, not a controlled benchmark.

An issue gives a piece of work an address and a visible state. The objective, findings, remaining work and evidence can stay together. I can return to it, or hand it to another agent, without rebuilding the task from a conversation and several planning documents.

I like the Kanban-style flow of GitHub Issues. If your team works around Scrum and sprints, Linear may suit your habits better. The important change is having one place where the work is tracked and kept current.

Specifications and technical documentation still belong beside the code where they help explain the system. A temporary implementation plan can still help an agent think. But the backlog and the state of delivery need a home I can actually manage.

I’m learning to delegate a different kind of detail

I still need to decide what the feature is for, which constraints matter and what evidence would make me accept it. I still need to pay attention when a change carries consequences that deserve my judgment.

I’m learning to leave more of the implementation to the agents, including choices I would once have insisted on examining myself.

Some days that feels like progress. Some days it feels like losing control. Usually it’s both.

The biggest change in my ability to build with AI has been learning how to keep the work moving without making my attention a prerequisite for every step. Better agents helped me get here. Learning to work differently is what lets me keep going.