We Already Have That: When AI Features Reinvent Code You Already Own

A team I worked with shipped a "smart" date extractor last quarter. The model parsed natural-language phrases like "next Tuesday" and "two weeks from the 14th," ran in production behind a feature flag, and cost about three cents per request at the chosen tier. Six weeks later, a backend engineer wandered into a design review and mentioned, casually, that the company already had a date parser. It had been written in 2019, lived in a utility module nobody on the AI team had read, handled 99.4% of the same inputs at sub-millisecond latency, and ran for free. The AI feature did not get pulled. It got rationalized — "the model handles the long tail" — and the team moved on, having shipped a more expensive, slower, less accurate version of something the company already owned.

This is not a one-off story. It is the dominant failure mode for AI features inside companies older than the AI team. The pattern repeats: a smart classifier duplicates a regex pipeline written years ago, a retrieval system fetches a vendor list that an internal service has been maintaining as a typed table, an agent learns to extract entities a parser already extracts deterministically. The AI feature ships with a quality bar lower than the deterministic system it didn't know existed, and the team who built the deterministic system finds out at a cross-team meeting.

The failure mode is not technical. It is organizational discovery. The team building the AI feature does not know the legacy capability exists because it was written by someone who left in 2021, lives in a service nobody on the AI team has clicked into, or is documented in a wiki page nobody opens. The codebase has the answer. The org chart hides it.

The discovery gap is wider than the AI team realizes

Most AI teams are new. They were stood up in the last twenty-four months, often by hiring outside the existing engineering org, and their bias toward greenfield work is structural — they are reward-aligned to ship novel ML capabilities, not to read someone else's 2019 utilities. The codebase they treat as their substrate is the one they wrote. Everything else is a black box.

Meanwhile, the deterministic capabilities they would benefit from knowing about are exactly the ones least likely to be advertised. A regex parser written in 2019 has no marketing budget. The team that owns it does not show up at the AI architecture review. Its README, if it has one, was last updated in 2020 and refers to a version of the system that has since been refactored. The capability exists, works, and is invisible.

This invisibility compounds in the typical org topology. A monorepo with three thousand files looks like a single codebase but functions as a federation of fiefdoms — each directory has an owner, a tribal style, and a set of conventions that engineers from outside that fiefdom cannot navigate without help. Engineers can spend as much time rediscovering "the right way" to do something in a codebase as actually implementing it. The AI team does not budget for that rediscovery cost, so they never pay it. They greenfield instead.

The cost of recapitulation is not just tokens

When the AI feature duplicates a deterministic capability, the visible cost is the inference bill. That number is real but not the largest cost. Larger costs sit downstream and rarely get tallied against the AI feature's ROI.

The first hidden cost is quality regression. A regex parser written and battle-tested over five years has handled every weird input the production traffic has ever surfaced — Unicode edge cases, locale-specific date formats, the particular punctuation users from the enterprise tier insist on using. The new model, trained on a generic corpus, has not. It will get most cases right and a few cases catastrophically wrong, and the catastrophic ones will trace back through three layers of agent infrastructure before anyone realizes the problem is that the LLM hallucinated a date the deterministic parser would have rejected. LLMs do not yield deterministic information. That is not a bug of any specific model — it is the contract. When the existing deterministic system handles the case, swapping in a stochastic system is a downgrade priced in latency, money, and rare-but-loud failures.

The second hidden cost is latency. The deterministic parser returns in microseconds. The model returns in hundreds of milliseconds at best, and in the long tail multiple seconds. If the AI feature sits on a user-facing path, that latency budget is gone — and the team will spend the next quarter trying to claw back milliseconds with prompt caching, smaller models, and parallel speculative decoding, optimizing toward a latency profile the deterministic version had for free.

The third hidden cost is operational surface area. The deterministic capability had no eval suite, no token budget, no provider dependency, no fallback policy, no rate-limit handling, no staged rollout — because none of that infrastructure was needed. The AI replacement requires all of it. Every duplicated capability multiplies the surface area the platform team has to operate, and the platform team's headcount does not grow proportionally with the surface they inherit.

The political consequence is the worst part

If the only cost were money and latency, the calculus would still tilt toward auditing first. But the cost that compounds across years is political, and most AI teams do not see it coming.

When a legacy-system maintainer learns at a cross-team meeting that the AI team has shipped a feature replacing their work, they read the situation correctly: their work was discarded without consultation. The maintainer's response is rational. They stop sharing context with the AI team. They stop showing up at architecture reviews. They stop volunteering what their service does. The next time the AI team is about to build over a deterministic capability, the person who would have warned them no longer attends the meeting where the warning would have happened.

This is a self-reinforcing failure. The AI team's lack of awareness of legacy capabilities causes recapitulation. Recapitulation alienates the maintainers of those capabilities. The alienation reduces information flow, which deepens the unawareness, which produces the next recapitulation. Within a year or two, the company has effectively two engineering organizations that do not talk to each other, and the AI team is operating with a permanent discovery deficit they cannot close because the people who could close it have stopped talking.

Loading…