After five months behind main, classifying 312 conflict hunks helped turn a two-week rebase estimate into 11 hours
The leverage in this rebase sits in routing rather than prompting, and the three regexes that decide which hunks skip the model entirely are tuned to one repository's five months of noise. Copying the method means re-deriving them.
The Engineer · Build desk

What happened
- The branch was a storage-layer rewrite begun in February and kept alive on "we'll land it next sprint", and by July it sat five months and 1,900 commits behind main.
- Rebasing it onto main produced 312 conflict hunks across 137 files, including content conflicts in the storage adapter and index and an add/add conflict on an LRU cache file.
- A first attempt that simply opened the repo in Claude Code and asked it to resolve the merge conflicts got through about 40 hunks before it went sideways.
- A triage script then classified every hunk and split the 312 into 117 mechanical, 171 semantic and 24 human-only, each class routed to a different resolver.
- Semantic hunks went to the model ten at a time behind a build-and-test gate, and the whole rebase landed in 11 hours against a two-week budget.
Why it matters
- What it limits constraint The gate can only fail a batch that breaks the build or an existing test, so the plausible-but-wrong resolution the author names as the real danger rides straight through it, leaving the human queue and the decision log as the only defence.
- What it costs cost Adoption is priced in gate runs rather than tokens: at least 18 build-and-test cycles plus every retry, so a team with a 30-minute pipeline pays in wall clock what this author paid in review attention.
- Who has to decide decision Anyone lifting this harness has to re-derive the mechanical patterns against their own repo's churn first, or they will hand hunks with real semantics to a three-line regex list.
- What it sets up precedent If a five-month rebase can be done for roughly a seventh of the hand-rolled budget, the cost argument for killing long-lived branches early gets weaker, and more of them get kept alive on the same promise.
The economics of this pipeline are set by one guard inside the classifier. `classify()` calls a hunk mechanical only when every line on both sides is blank or matches one of three regexes [15]. Everything else falls through to the model or to the human queue. That default is the right way round: each hunk has to earn its place on the cheap path before it gets there.
The three patterns tell you what repository this was. One matches lines beginning with `import` or `from`, one matches a quoted key followed by a quoted version string, one matches Markdown-style bullets [16]. Between them they cover import block collisions, lockfile churn, formatter disagreements and two branches appending to the same list [14]. That is 37.5 percent of the hunks routed around the model [21]. For that share to transfer, your drift has to be made of the same noise. A repo whose five months of churn is generated clients, resource YAML or renamed fixtures will see the mechanical bucket shrink and the model's share grow, and the second-order cost of that lands on review attention rather than tokens.
Now the gate. A passing batch is committed and recorded in `resolutions.md`; a failing batch is reverted and re-run with the failure output attached [13]. Worth being precise about what that buys, because the author's own statement of the danger is a resolution that compiles and passes the tests that happen to exist while shipping a bug that looks like it was always there [10]. A green build and a green suite cannot detect that, by construction. What actually stands against picking a side to make the markers go away [6] is the human-only queue and the written record. `resolutions.md` is doing the job the chat session failed at: conflict #12 in `adapter.ts` settled the new retry signature, conflict #88 in a caller reintroduced the old one, and nothing in the session tied the two together [7].
Batch size sets the clock. 171 semantic hunks at ten per batch is 18 batches at minimum [22], so the build-and-test cycle runs at least 18 times before any revert-and-retry loop [13]. Against 11 hours of wall clock that averages about 37 minutes per batch for context assembly, model time, gate, review and commit [23]. If your gate takes 25 minutes, the arithmetic stops working and the method does not fit.
The piece I would want before copying this is the context bundle. The published excerpt breaks off inside the classifier and never says what goes into one [19], and that is exactly where intent is supplied, which the author identifies as the thing the agent was never shown [9]. Everything around it is scheduling, and scheduling is the easy half. Two weeks was the hand estimate [4]; on a branch kept alive by "we'll land it next sprint" [3], estimates had a track record.
What to watch
- A released triage script, which would let teams measure their own mechanical share instead of inheriting three regexes tuned to one repo.
- Whether resolutions.md holds up as decisions accumulate, or whether cross-file rulings need to be machine-enforced rather than merely recorded.
- Whether the human-only bucket stays near 8 percent of hunks on a branch that is not a storage-layer rewrite.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence45
- Adoption12
- Hype gap+20
- Incentives55
- Confidence52
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The rebase took 11 hours instead of the two weeks the author had budgeted.
- [2]
Running `git rebase main` on the branch produced 312 conflict hunks across 137 files, including content conflicts in src/storage/adapter.ts and src/storage/index.ts and an add/add conflict in src/storage/cache/lru.ts; `git diff --name-only --diff-filter=U | wc -l` returned 137.
- [3]
The branch was a storage-layer rewrite started in February and kept alive by "we'll land it next sprint"; by July it was five months and 1,900 commits behind main.
- [4]
The author estimated three days of solid work at best and two weeks realistically to resolve the conflicts by hand, plus a meaningful chance of silently breaking something.
- [5]
The first attempt was to open the repo in Claude Code and say "resolve the merge conflicts"; the agent resolved about 40 hunks before things went sideways.
- [6]
Failure mode one: on genuinely ambiguous hunks the agent took HEAD or theirs to make the markers go away, which was syntactically clean and semantically a silent revert of somebody's bug fix.
- [7]
Failure mode two: the agent lost track of decisions across files. Conflict #12 in adapter.ts established that the new retry signature was kept; conflict #88 in a caller reintroduced the old one, and nothing in the session tied those together.
- [8]
Failure mode three: context ran out and quality degraded. By hunk 40 the useful details from hunk 5 were gone and resolutions became noticeably more generic.
- [9]
The author's framing: a merge conflict is not a text-merging problem but a question about intent, and the intent lives in history the agent was never shown.
- [10]
The author states that a merge conflict resolved plausibly but wrongly does not blow up: it compiles, it passes the tests that happen to exist, and it ships a bug that looks like it was always there.
- [11]
The triage script bucketed the 312 hunks into 117 mechanical, 171 semantic and 24 human-only.
- [12]
Mechanical hunks were auto-resolved by deterministic rules; semantic hunks got a per-conflict context bundle and went to Claude Code in batches of 10; human-only hunks were queued for the author.
- [13]
Every batch was gated on a build and test run: on pass the batch was committed and recorded in resolutions.md, on fail the batch was reverted and re-run with the failure output.
- [14]
A large share of the conflicts were noise with deterministic answers: import block collisions, lockfile churn, formatter disagreements and two branches appending to the same list; the author considered spending agent tokens and review attention on them waste.
- [15]
In triage.py, classify() returns "mechanical" only if every line across both sides of the hunk is blank or matches one of the MECHANICAL patterns.
- [16]
The MECHANICAL pattern list contains three regexes: one matching lines starting with import or from (labelled "imports"), one matching a quoted key followed by a quoted version string (labelled "dep-version"), and one matching lines starting with a dash or asterisk bullet (labelled "list-append").
- [17]
A comment in the classifier states that a hunk touching control flow or signatures is where silent bugs hide, and the code searches hunk bodies for keywords including if, for, while and return.
- [18]
The hunks() helper parses each conflicted file by splitting on the <<<<<<<, ======= and >>>>>>> markers and yields the ours and theirs line lists for each conflict block.
- [19]
The published excerpt ends part-way through the classify() function and does not describe the contents of the per-conflict context bundle beyond the flowchart label "Build context bundle per conflict".
- [20]
Reading the two-week budget as ten eight-hour days, 11 hours is about one seventh of it.
- [21]
The mechanical bucket is 37.5 percent of all hunks, the semantic bucket 54.8 percent, and the human-only bucket 7.7 percent.
- [22]
171 semantic hunks at ten per batch requires at least 18 gated batches.
- [23]
Across 18 batches, 11 hours of wall clock averages roughly 37 minutes per batch.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toHow I Let Claude Code Resolve 312 Merge Conflicts in One Rebase: 5 Lessons
1 article · August 30, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Developer productivity claimsFollow
- Context EngineeringFollow
- Verification gates for generated codeFollow
- Merge conflict resolutionFollow
- Agentic coding workflowsFollow