If your team needs to review your AI-generated code, you need to optimize that code for review throughput.
AI can produce code significantly faster than your teammates can review it. You prompt a substantial feature into existence, verify that it works, and then have a nightmare getting thousands of lines reviewed. Starting another feature adds more work to the same queue.
Your individual speed only translates into team velocity if the team can absorb that output.
Separate implementation from review preparation
The unit of implementation and the unit of review can be different. You can have AI create a substantial feature, verify the behavior, and then have it reconstruct the implementation into a sequence your teammates can review.
That’s the workflow I’d adopt: create, verify, organize for review, then automate the upkeep.
Build a coherent stack of PRs
The first tool is stacked PRs. These are simply a sequence of dependent PRs, with each building on the one below it. They let the reviewer build their understanding progressively.
But there’s a premise here: you’ve set up the stack well.
You want small, cohesive changes in context. Something like 300 relevant changed lines is a useful rule of thumb, but the boundaries need to make sense.
A database migration on its own can be difficult to review. Why are these fields here? How will the application use them? Unless there’s a document explaining the design, the reviewer has to go looking for those answers.
I’d rather give them a contextual vertical slice. Include enough of the behavior and its supporting code that they can understand why the pieces belong together.
Your first PR might be a preparatory refactor. Your next might implement the first complete flow. Subsequent PRs add the remaining behavior. Each change has a coherent purpose, and the stack takes the reviewer through the feature.
Give them a short map of the overall change, too. They should know where the sequence is going when they open the first PR.
Have AI construct the review sequence
Give it this monstrosity and ask it to identify the core changes, their dependencies, and a sensible review order. Have it create the slices, write useful descriptions, and verify the resulting stack. Splitting working code can introduce mistakes, so verification needs to happen after the reconstruction.
I’d turn this into a skill. Give it explicit expectations for cohesive changes, context, dependencies, and verification. Preparing work for review should be a normal part of what the agent delivers.
Automate the upkeep
Someone requests a change near the bottom of the stack. Now you have to propagate it through everything above it. There are conflicts. CI fails. More feedback comes in. You can spend a ridiculous amount of time babysitting this.
Your next tool is automating that ceremony and toil.
Have AI monitor CI, address straightforward feedback, propagate changes, resolve routine conflicts, and keep the PRs current. If an upstream change affects behavior someone has already reviewed, have the agent call that out and bring it back for review.
Small, cohesive PRs have been good advice for a long time. AI gives us a way to construct and maintain them even when the initial implementation is large.
If peer review is required, producing a working implementation leaves another job to do: make it efficient for your teammates to understand and evaluate. Have AI do that work as part of finishing the change.