Friday, July 31, 2026
HomeSoftware DevelopmentWhy Your Codebase Is Forcing Your AI to Underperform

Why Your Codebase Is Forcing Your AI to Underperform

-


You rolled out Copilot, Cursor, or Claude Code throughout tons of of engineers. Six months in, the productiveness raise is actual however smaller than the slide deck promised — and uneven, with some improvement groups flying and others barely shifting. 

The AI isn’t underperforming. Your codebase is forcing it to.

The brand new value of carrying unused code

Each codebase carries weight that not earns its hold — strategies no person calls, libraries no person masses, options that shipped years in the past and quietly stopped mattering. Engineering leaders have at all times recognized the price of sustaining and securing lifeless or unused code is dear. What’s modified is who pays the invoice. 

Till not too long ago, the tax was paid in human consideration: slower onboarding, longer code critiques, the hesitation earlier than touching an unfamiliar department. Painful, however bounded — a senior engineer learns to navigate across the lifeless zones, and the group absorbs the friction. AI coding assistants don’t get that luxurious. 

To make a change in any non-trivial space, the assistant has to learn the encompassing code, and its context window is finite. Each library, each unused class, each orphaned helper, each dependency the agent pulls in to “perceive the world earlier than altering it” consumes pricey tokens that would have gone to the precise job. 

Unused code seems equivalent to stay code on disk. The AI can’t understand it’s irrelevant till it’s already learn it. By then the fee is paid: longer prompts, weaker reasoning, extra hallucinated calls to strategies that not matter, extra rework. 

The AI’s efficient intelligence in your codebase is inversely proportional to your lifeless weight. And that interprets into the consumption of AI token spend that pulls from budgets that needs to be allotted to leveraging AI to innovate new options and purposes  

That is technical debt, and it now compounds quicker

It’s value naming this for what it’s: technical debt, within the authentic Ward Cunningham sense — work that was rational to defer on the time, accruing curiosity till any individual pays it down. Each acquisition you take in, each modernization you sequence, each function you ship with out retiring the one it changed provides to the principal. 

Engineering groups really feel it: in Azul’s 2026 State of Java Survey & Report, 63% of respondents stated lifeless and unused code is hurting their group’s productiveness, and solely 6% reported no affect in any respect. Two issues have modified within the final 24 months. 

First, the rate of interest went up: AI assistants now sit in the midst of almost each code change, and so they pay the carrying value with token utilization on each immediate. Second, the principal grew quicker than your group did — in the identical survey, each respondent reported utilizing AI code-generation instruments, and 30% stated greater than half their new code is now written by AI. Extra code, written quicker, with much less of it being deleted on the way in which in.

If you happen to’re an engineering chief making AI funding choices immediately, the implication is uncomfortable. The identical productiveness software that guarantees to clear your backlog can be increasing the floor space it has to purpose over. With out an intentional countermeasure, you’re funding each side of the commerce. 

Why the apparent reply — “simply run static evaluation” — solely will get you partway 

Most engineering organizations have already got static evaluation wired into CI, flagging unreachable branches, unused imports, and lifeless variables. It’s the fitting baseline: if no code path reaches a way, deleting it’s secure. 

However static evaluation is conservative by design. The instruments would fairly miss actual lifeless code than flag one thing that seems to be stay — a improper deletion is catastrophic, a missed one is merely wasteful. They usually can solely purpose what they will see within the supply: something referred to as by reflection, dependency injection, configuration-driven dispatch, function flags, or runtime service lookup seems reachable on paper, even when that path hasn’t fired in manufacturing for 3 years. 

The analyzer leaves it alone, accurately, as a result of it has no technique to know. So the simple 10–20% of unused code — the stuff with no caller in any respect — will get cleaned up by these static evaluation and IDE instruments you already personal. The opposite 80% — code that compiles, has callers, passes the linter, and by no means truly runs — sits within the repository, within the context window, and in your AI invoice.

Runtime proof: ask what ran, not what may run 

The class that closes the hole is runtime proof — observing purposes as they execute in manufacturing and cataloging which lessons, strategies, and libraries truly run. Azul Intelligence Cloud’s Code Stock is probably the most direct expression of this strategy for Java estates. It really works on any JVM — Azul, Oracle, Eclipse Temurin, Microsoft, Pink Hat, IBM — so a single dataset covers the entire footprint. 

The place static evaluation asks may this code be referred to as, Code Stock is aware of whether or not it was or not. Over a standard enterprise cycle — lengthy sufficient to seize quarter-end jobs, the annual reporting module, the seasonal promotion path — the image of what your code truly does in manufacturing resolves with excessive confidence. 

Code that has callers on paper however by no means executes reveals up as precisely what it’s: lifeless weight that static instruments can not see. One Azul buyer described it concisely after an acquisition: hundreds of thousands of traces of unfamiliar code, months of studying forward of them, and as a substitute they used Code Stock to establish massive parts of unused code and archive it. That’s the form of the win — not a marginal refactor, however a defensible choice to take away code, backed by proof fairly than guesswork. 

Pair Code Stock with an automatic refactoring platform like Moderne and OpenRewrite, and the removing step scales throughout tens of hundreds of thousands of traces as a substitute of turning into its personal multi-quarter challenge. 

Cleanup is the multiplier in your AI spend 

Right here is the half that issues for the finances dialog. Eradicating unused code just isn’t a competing line merchandise towards AI tooling. It’s the multiplier that determines what your AI tooling is definitely value. Each line that comes out of the repository pays compounding dividends. 

AI brokers learn much less to know any given change, so extra of the context window is out there for the precise drawback. This implies higher strategies and fewer fabricated calls to strategies that not exist. Human reviewers cease second-guessing whether or not the lifeless department issues. 

Vulnerability triage shrinks: fewer dependencies, fewer CVEs to analyze, fewer hours spent on the false-positive treadmill that 30% of groups now report consumes greater than half their vulnerability-triage time, a lot of it spent on code paths that by no means run in manufacturing. Exams for retired options might be deleted together with the options themselves. 

None of those advantages present up on the AI vendor’s pricing web page, however each certainly one of them reveals up within the ratio of AI spend to delivered output. The inverse can be true, and it’s the case value making to your CFO. 

If you happen to scale AI instruments throughout a codebase carrying years of unused code, you’re paying full value for AI classes that spend a big fraction of their context finances studying materials that ought to have been deleted. That value is invisible on the bill and really actual within the output. 

Sequence the work 

You don’t have to decide on between cleanup and velocity, and the framing of “pause AI rollout to do refactoring” is the improper one. The work runs in parallel, on this order: 1. Instrument manufacturing with runtime proof and let it construct the image of what’s truly used. That is passive — engineering groups hold transport whereas the information accrues. 2. Take away what the proof says is secure to take away. Use static evaluation for the structurally unreachable circumstances and runtime proof for the a lot bigger class it may well’t see. The place the quantity justifies it, automate the removing with rules-based refactoring fairly than treating it as bespoke developer work. 3. Scale your AI tooling towards a codebase the place each line earns its place within the context window. 

The most cost effective line of code to take care of has at all times been the one which isn’t there. Within the AI period, it’s additionally the most cost effective line on your assistants to learn, the most cost effective to maintain safe, and the most cost effective to depart out of each immediate your engineers will run for the remainder of the product’s life. That’s the road merchandise value funding first. 

 

Erik CostlowErik Costlow

Related articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Stay Connected

0FansLike
0FollowersFollow
0FollowersFollow
0SubscribersSubscribe

Latest posts