What happens when code moves faster than feedback?

On a recent project, I implemented stories faster than they could be peer reviewed. The work kept moving into pull requests, but getting it through review was another matter.

My teammate spent so much time reviewing my work that they weren’t getting time to implement their own stories. My next stories depended on one of theirs. I’d filled the review queue, and now I was waiting too.

I’d seen review queues and dependencies before, but hadn’t run into them this quickly. Across two recent projects, well-written stories and parallel agents had let me implement features much faster. Delivery wasn’t keeping up in the way I’d expected.

If we’re implementing faster, why aren’t we delivering faster?

One part had become faster

In How I Accidentally Became a Team Manager, I wrote about planning with agents, delegating focused work, and reviewing the result against the original acceptance criteria. My parallel agent workflow made it practical to keep several stories moving at once.

Planning with an agent helped me put what I thought the story meant into words. This experience showed me what we’d missed.

Beyond implementation, a story still had to move through code review, testing, fixes, and release. In this case, peer review was where the queue became obvious.

The awkward part was that my output was also someone else’s workload. Every story I implemented created another change for my teammate to understand and assess.

I can’t say overall delivery became slower. But reviews had delayed my teammate’s stories, and I couldn’t continue until one of them was finished.

We built on a misunderstanding

One incident made the cost clear. I’ve anonymised the domain here.

We misunderstood which level of a workflow the acceptance criteria applied to. Our interpretation placed the behaviour on a container, when the intended behaviour belonged to the individual items within it.

That interpretation carried through the stories and into several stacked PRs. The stories were clear enough for agents to execute, but they described the wrong behaviour.

Those PRs depended on changes in earlier ones, so a correction near the bottom of the stack affected the work above it.

In another review session with the client, we realised they used the same word for the container and its items. We’d understood it to mean the container. By then, most of the work was already implemented.

Once it surfaced, we had to revise the stories, change the implementations, and repeatedly rebase the dependent PRs. Correcting the behaviour was only part of the cost. Just keeping the PR stack up to date took time.

We’d built more before finding out we’d misunderstood.

Building what was already there

The agents also tended to build something new rather than reuse an existing feature that could have done the job with a small change. It felt like “not invented here syndrome”, a pattern I kept seeing in their work.

During PR review, the reviewer pointed out the duplication in a comment and asked why we’d added it. By then, later work in the PR stack already depended on the new implementation. Undoing it rippled through the stack too. What could have been a small change became another round of rework.

That gave us another assumption to question early. Before building a new feature, had we checked what the system already did? The longer that question went unasked, the more work we built on the answer we’d assumed.

Review meant recovering context, too

Delayed feedback had another cost. When PR comments arrived, I had to get back into the story and remember what had been done and why.

That happens with code you write yourself. With agent-generated code, I often needed to reopen the agent conversation to recover the reasoning. I hadn’t written the code, and the diff didn’t always explain why it had ended up that way.

To answer those comments, I had to work out what we’d decided and which later changes depended on it. With stacked PRs, that could mean tracing the decision through several changes.

The agents could help make the corrections. I still had to understand what needed correcting and check that the new implementation matched the revised intent.

Rapid waterfalls

Our workflow looked iterative. We had small stories, PRs, reviews, and plenty of short feedback cycles with agents during implementation. But the feedback that challenged our shared understanding came after most of the dependent work was complete.

That’s what makes it feel like a rapid waterfall. We were implementing small stories, but discovering the mistake all at once.

Our stories reflected what we understood at the time. More detail wouldn’t necessarily have exposed the mistake. We needed to question the assumptions behind them.

Clearing review might not be enough

My first reaction was to fix the PR queue. That’s where the work was waiting.

Peer review caught the duplication. Earlier review could have helped us question that implementation before more work depended on it. Our misunderstanding about the container and its items surfaced in a conversation with the client. A reviewer who shared that misunderstanding could have approved the implementation without catching it.

We can spend a long conversation with an agent clarifying a story, answer every question, and end up with a detailed plan. It can feel as though we’ve done the hard thinking. But agreement in that conversation doesn’t mean the team and client share our understanding.

A reviewer needs a chance to question the interpretation behind the change, as well as the code. Some questions need to go back to the client.

We still need to share implementation and review fairly. A shorter queue would have helped my teammate get back to their stories.

Where do we go from here?

For me, working in an agile way means learning with the client as we build and adapting as our understanding changes. Starting fewer stories at once would leave more room for review and those conversations. We don’t need to race through every story just because the agents can keep going.

One experiment we can try is to write down assumptions as they surface, including what we think a term means, and review them with the client at the next meeting. If an assumption affects work we’re about to build on, we should ask sooner.

Before implementation, we can also ask the agent to find existing behaviour that could meet the story with a small change, then review that together.

The Agile Manifesto values individuals and interactions over processes and tools. For me, that means making room for the conversations that change what we build next. I’d judge these experiments by whether we catch misunderstandings and duplication before more work depends on them.