Thomas Nys' Post

Thomas Nys · article · 2025-12 Reader 🖥️

Code Was Never the Bottleneck Legacy & Organizational Forgetting Measuring AI Impact Technical Debt

Organizations can't get AI initiatives to scale because a large, usually invisible share of engineering capacity (the author cites 20-40% industry estimates) is already consumed maintaining accumulated technical-debt shortcuts, so AI pilots stall not for lack of model quality or team size but because they're being layered on fragile, duct-taped foundations that were never fixed first.

practical · argumentative — A short LinkedIn thought-leadership post arguing engineering leaders should fix technical-debt-laden foundations before layering AI on top — practical (argues for a reallocation of effort), with a closing engagement-bait question typical of the format.

Structure

Part	Role
Opening claim + industry statistics (McKinsey 20-40%, Gartner 40% of infrastructure flagged)	evidence establishing scale of the problem
The 10-engineer illustration (4 maintaining legacy decisions, 6 simultaneously building new debt)	concretizing example — translates the abstract percentage into a staffing picture
Invisibility claim (no dashboard line item; shows up as slowness, missed deadlines, attrition)	explains why the problem persists unaddressed
The AI-specific payoff (pilots stall, POCs can't scale, fragile integration layers) and the counter-example of companies that fixed foundations first	conclusion — applies the general technical-debt argument specifically to AI initiatives

Key terms

capacity lost to accumulated shortcuts
The author's own phrase for technical debt's maintenance burden, framed explicitly as an invisible capacity tax with no dashboard line item, rather than as a code-quality or architecture concept.

Propositions

explicitIndustry estimates put 20-40% of a typical tech estate's value (McKinsey) and 40% of infrastructure systems (Gartner) as carrying debt concerns, meaning a large share of IT investment goes to maintenance rather than innovation.conf: medium
explicitIn a 10-engineer team, roughly 4 are effectively maintaining legacy decisions while the other 6 build new features that simultaneously create tomorrow's maintenance burden — so the debt-generating and debt-servicing populations overlap and reinforce each other rather than being cleanly separable.conf: medium
explicitTechnical debt's cost is structurally invisible to management: there is no dashboard line item for 'capacity lost to accumulated shortcuts'; it only surfaces indirectly as slowness, missed deadlines, or burnout-driven attrition.conf: high
explicitAI pilots and proof-of-concepts stall or fail to scale specifically because of what's underneath them — brittle data pipelines, integration layers only a few engineers understand, and systems fragile enough that deploying a model risks production — not because of model choice or team size.conf: high
supportsCase Study: Refactoring at Scale with Agents · p8 — Both argue technical debt becomes more, not less, urgent once AI coding is adopted, because naive AI adoption onto unhealthy codebases compounds rather than resolves the underlying problem.
supportsEveryone Is Talking About Context for AI. Here's What Most Companies Still Miss. · p1 — The post's 'pilots stall, POCs can't scale' claim is a mechanism-level account of the same enterprise-scaling gap McKinsey's adoption-vs-scaling statistic (90% using AI, only 10% scaling it) measures at the industry level.
explicitCompanies leading with AI in 2025 are distinguished less by team size or model quality than by having engineers who spend roughly 80% of their time on forward progress rather than firefighting, because they prioritized fixing the foundation before adding intelligence on top.conf: medium
implicitYou cannot layer AI on a foundation that is already consuming roughly 40% of engineering capacity just to stay standing — the implicit premise that AI adoption has a capacity cost of its own which competes directly with debt-servicing work for the same scarce engineering hours.conf: medium
supportsPresentation: AI-First Software Delivery: Balancing Innovation with Proven Practices · p5 — Near-identical thesis stated more generally: AI amplifies existing engineering practice, so weak foundations get amplified into worse outcomes rather than fixed by AI.
supportsAI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p1 — Both frame AI as an amplifier of the underlying organizational/technical system rather than an independent source of value — without that foundation, gains stay localized and get lost downstream.

Arguments

Leaders should fix the technical-debt-laden foundation before — or at minimum alongside — layering AI initiatives on top of it. strength: medium

Explicit premises:

A large, industry-wide share of engineering capacity (20-40%) is already consumed by legacy maintenance rather than new work.
This burden is structurally invisible to standard reporting, so leaders chronically underestimate how much capacity AI initiatives will actually have available.
Observed AI pilot failures trace specifically to fragile underlying systems (pipelines, integration layers), not to the AI technology itself.

Implicit premises:

AI adoption consumes engineering capacity in competition with debt-servicing work, rather than being additive or capacity-free.
The companies the author cites as 'leading with AI' are leading specifically because of foundation work, rather than for some other unexamined reason (e.g., better data, more capital, different risk tolerance).

Inferences:

If the premises hold, an organization's realistic AI roadmap should be gated by a debt-reduction plan with a visible capacity metric — a concrete recommendation the post gestures toward (the closing question) but never actually prescribes.

Questions addressed

✅ Why do AI pilots and proof-of-concepts stall or fail to scale in many organizations?
Attributed to a fragile technical foundation (data pipelines, integration layers, deployment risk) rather than to model quality or team size.
⭕ What percentage of your own engineering capacity is spent on maintenance vs. innovation?
Posed to the reader as a closing, unanswered engagement question rather than resolved by the author.

Gaps

incompleteThe post's own headline statistics (McKinsey 20-40%, Gartner 40%) are cited by source organization only, with no report named or linked, and the closing '80% on progress' claim about AI-leading companies has no citation at all — the piece's rhetorical force depends on numbers it doesn't let the reader verify.
Read next: Trace the actual McKinsey and Gartner reports behind these figures to check whether '20-40% of tech estate value' and '40% of infrastructure systems' are being accurately summarized or rounded into a more alarming framing than the source data supports.
incompleteThe post asserts debt-reduction as a precondition for AI success but gives no account of the reverse possibility raised elsewhere in this corpus — that AI-assisted refactoring and comprehension tools might be a more effective way to pay down exactly the debt the post describes, rather than a capability that has to wait until after debt is paid down.
Read next: extract-codescene-refactoring-at-scale-with-agents directly tests AI-assisted refactoring at scale against legacy technical debt and reaches a more conditional verdict than this post's strict 'foundation first' framing.