Using AI to Reconcile a Fragmented Legacy Codebase

Adapted from Ravi Singh’s The merge that should have been impossible, published December 19, 2025.

Long-lived branches carry more than conflicting lines. They contain customer commitments, abandoned experiments, undocumented workarounds, and different answers to the same product problem. Bringing them together requires decisions about behavior. A clean Git merge proves only that the text can coexist; it cannot establish that the combined product is correct.

In the original essay, Ravi describes a team using AI during the reconciliation of a product with thirteen divergent branches. His account emphasizes historical investigation, written plans, principal engineers, and several forms of testing. This is a reported anecdote, without independent validation or a transferable delivery estimate. The useful question is which parts of that working method another team can evaluate safely.

Establish what each branch represents

Begin with an inventory before generating changes. For each branch, record its base revision, deployment status, owner, distinct capabilities, and known consumers. Preserve references to the starting commits. Mark uncertainty explicitly: a branch with no obvious owner may still power a contractual customer workflow. Ask the relevant team to resolve that uncertainty before scheduling removal.

AI can assist with history summaries and candidate differences. Require those summaries to point to commits, files, and existing tests. Cross-check them against release notes and support records. A model may infer intent from code, but an inference is a question for an engineer or product owner to resolve. It should not silently become the migration requirement.

Turn differences into a behavior matrix

List capabilities across branches and identify where implementations differ. For an export feature, one customer might require a particular column order while another depends on a different rounding rule. Those differences need separate acceptance examples, even when both paths have similar names. Decide which behavior is shared, which remains configurable, and which can be retired with explicit agreement.

This matrix becomes a practical instruction set for AI-assisted work. Ask for one bounded reconciliation, list the files it may touch, and describe the observations that would demonstrate correctness. Keep modernization work separate when it adds uncertainty without helping the integration. Changing a framework and reconciling financial behavior in the same patch makes failures harder to isolate.

Choose an integration sequence with recovery points

Select a baseline because it has a defensible deployment and testing history. Then order the work by dependencies and risk. Reconcile shared contracts before their callers, and preserve representative fixtures for customer-specific cases. Use short changes with named reviewers so the team can understand the effect of each step and return to a known revision if necessary.

For example, consolidate an export interface first while keeping both implementations behind explicit configuration. Compare outputs using the agreed fixtures. Only retire an implementation after the owner accepts the replacement behavior. Configuration itself needs validation: a missing setting must not quietly select the wrong customer workflow. A rollback plan should cover data changes as well as code.

Make verification part of the work package

Define the checks before asking AI to implement the slice. Include focused regression tests, contract checks between components, and a build of the combined branch. Add performance or manual verification where automated coverage cannot answer the actual acceptance question. Record which checks ran against which revision, along with unresolved gaps and the person responsible for accepting them.

The completion decision belongs to the engineers maintaining the product. Passing tests can support that decision, but their scope matters. A suite that never exercised an old customer variant cannot prove that variant survived. Review the behavior matrix alongside the test results, then validate a staged release before treating consolidation as operationally complete.

Use the repository to frame the decision

Binomial can help frame this work through scoped repository evidence and human interpretation: where fragmentation appears, which areas deserve investigation, and what follow-up would support a modernization plan. Repository patterns alone do not establish AI usage or explain every delivery outcome. Start with an AI Engineering Readiness Assessment to define the evidence boundary and prioritize the next technical decisions.