Back to blog
AI SystemsDeveloper ToolsEngineering Leadership

The Code Was Done. The Stack Wasn't.

An operator field note on agentic development, stacked pull requests, review churn, CI evidence, and why faster code production needs stronger integration discipline.

Renzo Saravia · Aug 10, 2026 · 13 min read

The code was done before the work was done.

That was the uncomfortable lesson.

AI-assisted development made implementation faster. The agent could inspect the codebase, draft a plan, make changes, respond to review notes, update tests, and keep moving. From the outside, that sounds like the dream: more throughput, less waiting, faster product work.

But once the implementation accelerated, the bottleneck moved.

It moved into the pull-request stack. Branches had to be restacked. Checks ran again. Reviews went stale. People had to rediscover whether a change was behind, conflicting, missing approval, stack-inconsistent, or genuinely unsafe.

The important lesson is not that Git is obsolete. It is not that GitHub is bad. It is not that stacked pull requests are wrong.

The lesson is sharper:

When AI makes code production faster than the surrounding delivery system can absorb, the constraint moves from writing code to integrating, reviewing, validating, and merging change.

The Field Note

This is an anonymized field note from a recent product epic.

The work involved a sequence of dependent changes. The team used a mixed workflow: GitHub pull requests, protected branch rules, a stack-management layer, multiple worktrees, coding agents, automated review tools, CI, and human engineering review.

Stacking was a rational choice.

The changes were related, but each slice was easier to inspect than one epic-sized branch. Stacking also let later implementation continue while earlier work waited for review.

That is the appeal of stacked pull requests:

  1. Smaller conceptual diffs.
  2. Earlier review opportunities.
  3. Continued progress while parent work waits.
  4. A visible dependency order.

But the same structure creates a mutable dependency chain.

When a parent branch changes, merges, or gets rewritten, the branches above it may need restacking, resubmission, CI, and review-state reconciliation.

At human-speed implementation, that cost can stay hidden.

At agent-speed implementation, it shows up fast.

The Pattern Is Bigger Than One Epic

After seeing this pattern once, I started hearing versions of it elsewhere.

An engineer at another product company described the same pain in plain language: constant rebase bottlenecks, PR approvals getting reset, stack tools helping with organization but not fully keeping up with the speed of change.

I would not name that company without permission, and I would not turn one conversation into market research.

But the signal matches what the industry is already moving toward.

GitHub has started productizing stacked pull requests. Graphite, GitHub, merge queues, automated review tools, and CI optimization products all point at the same pressure: modern software teams are trying to break work into smaller reviewable units while preserving enough confidence to merge quickly.

AI raises the stakes because it removes one of the accidental limits in the old system.

Humans could only create dependent pull requests so quickly. That human writing speed acted as a rough work-in-progress limit.

Agents weaken that limit.

That is good, but it means the delivery system needs a more explicit operating model.

What I Would Not Claim

I would not write this as "today's tools were not designed for this speed."

That claim is too broad.

On July 30, 2026, GitHub moved stacked pull requests into public preview. GitHub's documentation describes stacks as a way to break large changes into smaller dependent pull requests, review and merge them independently, and automatically rebase or retarget upper branches when lower layers land.

That matters.

The mechanical branch-management layer is improving. Platforms are starting to absorb some of the work that used to live in local scripts, terminal discipline, and painful restacks.

So the better claim is narrower:

Our collaboration workflows assumed the number of changes in flight would be bounded by how fast humans could produce them. AI agents weaken that accidental backpressure. The missing layer is not simply better branch mechanics. It is a protocol between production rate, review capacity, CI evidence, and approval state.

Stack tools organize the queue.

They do not decide how much change the system can safely absorb.

The Operating Model

The simple model is this:

integration pressure rises with active stack depth, mutation rate, and review latency

A team can run high velocity with low coordination cost when changes are independent, merge quickly, and land behind safe interfaces or flags.

A deep mutable stack is different.

Every lower-stack mutation can affect the work above it. A parent branch changes. Descendant branches are restacked. Commit identities change. Diffs or merge bases change. CI executes again. Prior approvals may become stale. Reviewers and agents repeat work to restore confidence.

This is not primarily a Git performance problem. Git operations are fast.

It is a coordination problem.

The phrase I would use is integration invalidation: the system invalidates machine and human evidence because the representation changed, even when some of the underlying intent may not have changed.

That distinction matters.

If behavior changed, review should be refreshed.

If dependency context changed, the affected surface should be made visible.

If only history moved, the system should help prove that conservatively.

Today, those cases often blur together.

What The Metrics Showed

In the scoped epic sequence, the GitHub Actions data showed repeated validation work across a short delivery window.

The observed values were:

  1. Workflow executions including attempts: 26.
  2. Repeat workflow executions after the branch's first execution: 19.
  3. Jobs executed across all attempts: 52.
  4. Aggregate job execution time: 188.28 minutes.
  5. Aggregate workflow wall time: 131.58 minutes.
  6. Repeat-execution job time: 148.08 minutes.
  7. Repeat-execution workflow wall time: 99.90 minutes.
  8. Literal manual rerun attempts: 1.

These are timestamp-derived execution minutes, not billed minutes. Job time sums concurrent jobs. Workflow wall time counts each attempt from first job start to last job completion.

The important distinction is attribution.

Not every repeat run is waste. Some repeated CI validates real semantic updates, bug fixes, or review changes. In this dataset, five workflow records could be directly matched to four force-push or restack events by head SHA and timestamp.

Those directly restack-correlated records consumed:

  1. Restack-correlated workflow records: 5.
  2. Restack-correlated job time: 22.05 minutes.
  3. Restack-correlated workflow wall time: 17.67 minutes.

That is the hard floor for identified restack-related CI cost.

The broader repeat-execution pattern shows the operating shape: once a stack becomes active and mutable, validation work starts to repeat. Some of that repetition is necessary. Some of it is avoidable. The delivery system needs to know the difference.

The review data showed the same pattern from the human side.

In the scoped PR set, the timeline showed two approval invalidations on an upper-stack pull request after force-pushes.

  1. First invalidation: approval dismissed, then restored after 25 minutes 1 second.
  2. Second invalidation: approval dismissed, not restored at snapshot after more than 15 hours 38 minutes.
  3. Combined unapproved elapsed time at snapshot: 16 hours 3 minutes 48 seconds of wall-clock time without the required approval.

That is not reviewer labor.

It is queue time.

But queue time matters because a pull request can be technically close and still operationally blocked. If the system requires a fresh approval, the work is not done until confidence has been restored.

The Recovery Merge

The most important artifact was not the CI table.

It was the recovery merge.

After the stack became tangled, the team needed a larger pull request to put previously developed work back onto the intended trunk path. The diff was much larger than the individual stacked slices, and it moved quickly.

A skeptical reader would be right to pause there.

If a large recovery pull request merges quickly, is that evidence of integration burden, or evidence that the team routed around review?

The honest answer is: it can be both.

The large diff did not mean every line was brand-new work written in one burst. Much of it represented previously developed work being recovered onto the correct base after stack ancestry diverged.

But that does not make the artifact harmless.

The recovery merge is the point of the story.

In a healthy delivery system, review protects quality by making meaningful change visible.

In a strained delivery system, repeated invalidation can create the opposite pressure. People still want to ship. If the smaller reviewed path becomes tangled in restacks, stale approvals, and repeated validation, a bigger recovery merge can feel like the way out.

That is the failure mode worth studying.

Not "review is waste."

Not "stacking failed."

Not "the tool was wrong."

The failure mode is review churn taxing the safe path until the system nudges the team toward a less-reviewable path.

Each Tool Was Locally Correct

This is why blaming one tool is not very useful.

Git represented the changes.

GitHub protected the branch and tracked whether the reviewed diff still matched the current merge context. GitHub's protected-branch documentation says stale approvals can be dismissed when the diff changes, including when the merge base changes after review.

CI did what CI does. Status checks exist to show whether commits meet repository conditions and whether a pull request is ready to merge. If a branch is rewritten, many systems treat the new commit as a new validation subject.

The stack-management layer reduced manual branch coordination. Stack tooling can make dependent pull requests easier to create, restack, submit, and merge. The documentation for stack-oriented workflows also acknowledges that stacking can create more CI runs because it creates more PRs and may rebase branches behind the scenes.

Reviewers were also behaving rationally. If the branch history changed, they needed to recover confidence.

The problem emerged from the interaction.

Each tool enforced a reasonable local invariant. The workflow lacked a shared model for saying:

  1. This semantic change is the same.
  2. This dependency context changed.
  3. This approval still applies.
  4. This CI evidence can be reused.
  5. This part needs human attention again.

That is the missing operating layer.

What Agentic Speed Changes

AI-assisted development does not remove software delivery constraints.

It moves them.

When code is expensive to write, teams naturally limit work in progress. Review and integration still matter, but production speed itself acts as a throttle.

Agents weaken that throttle.

They can inspect a codebase, draft plans, implement changes, write tests, and respond to feedback quickly. That is useful. It also means more work can accumulate above an unmerged parent.

Once that happens, the stack becomes WIP inventory with dependencies.

That is different from a normal queue.

A normal queue has independent items waiting in line. A mutable stack has items that can be affected by the items beneath them. The longer the stack stays open, and the more often lower layers move, the more expensive the queue becomes.

This is where engineering leadership matters.

The answer is not to tell people to stop using agents.

The answer is to make integration capacity visible.

What I Would Do Differently

The immediate improvements are operational, not exotic.

  1. Limit active ready-for-review stack depth to two or three pull requests.
  2. Keep upstack work in draft until the lowest unmerged dependency stabilizes.
  3. Request final approval only after the final planned restack.
  4. Assign one canonical owner for restacking and submitting a shared stack.
  5. Avoid having multiple tools or worktrees mutate the same branch history.
  6. Merge from the bottom and restack once, instead of repeatedly restacking the whole chain.
  7. Prefer interface-first sequencing and feature flags when they can break a dependency chain.
  8. Track force-pushes, approval invalidations, repeated CI executions, and time to restored approval.
  9. Configure CI for stacked workflows where the security tradeoff is acceptable.
  10. Treat any recovery pull request as a special review object, not a normal merge.

That last point matters.

If a recovery pull request is necessary, it should say exactly what it is recovering, what prior review evidence exists, what changed after recovery, what tests ran, and what parts still need fresh human inspection.

It should not look like an ordinary feature PR.

What Teams Should Measure

If a team wants to adopt agentic development seriously, it should measure more than lines shipped or PR count.

The useful metrics are integration metrics:

  1. Active stack depth, because it shows how much dependent WIP is open.
  2. Stack age, because it shows how long dependent work has been waiting to land.
  3. Force-push or restack count, because it shows how often history movement invalidates evidence.
  4. Repeat CI executions, because they show validation work caused by mutable branches.
  5. Approval invalidations, because they show review-state churn.
  6. Time to restored approval, because it shows queue cost after evidence is invalidated.
  7. Recovery pull requests, because they show when the safe path became too tangled.

These metrics do not exist to shame teams.

They exist to make the delivery system visible.

AI makes implementation more elastic. Review capacity, CI capacity, and merge capacity are less elastic. If teams do not measure that mismatch, they will feel it only after the stack is already tangled.

The Missing Abstraction

Longer term, agentic development needs a better change-management model.

A branch name and a commit SHA are not enough.

A useful system would track a durable change identity that survives rebases, restacks, splitting, and non-semantic history movement.

It would connect three pieces of evidence that currently live apart:

  1. Change identity: what intended semantic change is this?
  2. CI attestation: what exactly was validated, against which inputs?
  3. Review state: what did a human approve, and under which dependency context?

Then it would classify what changed after a restack:

  1. History-only movement.
  2. Dependency-context change.
  3. Local semantic change.
  4. Conflict resolution.
  5. Formatting or generated-file churn.

Review should become an attestation over a semantic change, relevant dependencies, files or symbols reviewed, security-sensitive areas, and test evidence available at the time.

After a restack, the system should calculate which attestations remain valid and which require human reapproval.

CI should work the same way. Reuse evidence only when the system can conservatively show that the relevant inputs did not change. Fail closed when uncertain.

This should not become a casual AI assertion.

Semantic classification can help focus attention. It should not silently remove accountability.

The goal is not weaker review.

The goal is more precise invalidation.

The Operator Takeaway

The code being done is no longer the same as the work being done.

That was always true, but AI makes the gap harder to ignore.

If agents increase implementation throughput, the delivery system needs matching capacity for integration, review, validation, and merge coordination. Otherwise the bottleneck moves downstream and creates pressure in the worst possible place: the moment where the team decides whether to preserve the safe path or route around it.

The right response is not to slow agents down by default.

The right response is to run engineering delivery with more explicit controls:

  1. How much agent-generated work can be active at once?
  2. Who owns the stack?
  3. When is approval requested?
  4. What CI evidence survives a restack?
  5. What makes a recovery merge acceptable?

These are operating questions.

That is why this is not just a developer-tools problem. It is an engineering leadership problem.

When agents outrun the pull request, the answer is not a bigger pull request.

It is a better operating system for change.

References