TL;DR: Instacart's CTO didn't declare tech debt dead. He described a payoff earned by years of disciplined refactoring and AI-assisted rebuilds. That payoff works for the 97% of code that can be thrown away and rewritten. The remaining 3% sits in legacy, compliance, and latency-sensitive systems. That is exactly the layer your next audit will grade on.

Key Takeaways: - The 97% statistic is real. The 3% it leaves behind is where your audit risk lives. - AI tech debt is probabilistic, not deterministic. The dashboards you trust today won't catch it. - Five metrics now sit between your AI system and a clean audit. Most teams track none of them.

Instacart's CTO Atul Kundu told a packed room that his company "doesn't care about tech debt anymore." Within hours, the quote was on every engineering leader's slide deck. Half the industry read it as proof that AI had eliminated a category of work.

The other half read it as a quarterly audit finding waiting to happen. Only one of those readings is correct. The difference matters more than anything else you read about AI this quarter.

The quote was never a declaration of victory. It was a description of a payoff. Kundu's team spent years on a refactor project called Atoms. They broke monoliths into modular pieces. They rebuilt them in cleaner form. They also built an agentic SRE system. It was trained on years of Instacart's own incident and root-cause data, not generic failure patterns.

The "we don't care" line came after all that work. It applied to code that was inactive, duplicated, or low-value. That is the kind of code where throwing it away and letting AI rebuild it is genuinely cheaper than maintaining it.

That's the 97% number. Instacart estimates about 3% of their codebase remains in legacy, compliance, and latency-sensitive systems. In those areas, AI cannot safely refactor. Boards and engineering leaders are screenshotting the headline. They are ignoring the second sentence. The reading is wrong. Tech debt didn't disappear at Instacart. It got concentrated into a specific subset of systems. That subset is precisely the layer auditors focus on.

If you want to understand the framework auditors are now applying, start with our AI code compliance frameworks breakdown. The signals auditors look for have changed. Most teams have not caught up.

There's a number in that same interview that nobody screenshotted. It's the part that should worry you.

That 3% is the part nobody talks about in conference talks or LinkedIn posts. It includes regulated workflows with hard audit trails. It also includes systems with real-time latency constraints. In those systems, variance crosses SLA thresholds. And it includes what Kundu called a "boatload of code." That code is dead, half-active, or undocumented.

These are the systems where AI-assisted refactors can break compliance. They can change behavior across model versions. They can silently corrupt the data layer underneath. Engineers can't just "let AI rebuild it." The rebuild is the risk.

This is also where a new category of debt accumulates fastest. This debt arises not from deliberate shortcuts. It arises from uncertainty about the behavior or fit of AI-generated code. Engineers inherit it without knowing they took it on.

AI tools produce code faster than engineers can fully validate. Each piece carries unstated assumptions. These assumptions are invisible to code review and standard testing.

Conventional tech debt produces known failure modes. Tests fail. Shortcuts get documented. The next engineer can see the seam. AI tech debt produces probabilistic degradation. Outputs look correct but aren't. Behavior shifts silently across model updates.

Failures spread across prompt, context, model, and tool layers at the same time. No single component is "broken." That is the hardest part of an engineering metrics audit methodology to defend. The failure mode is the absence of a failure mode.

Auditors aren't auditing the 97%. They already know AI can rebuild that. They're auditing the layer beneath it. It's the one that doesn't show up in your CI pipeline.

Industry security frameworks note that AI shifts risk to the data and decision layer. Most security tools still focus on networks and the endpoint layer. In other words, the controls your team invested in are watching the wrong layer. Auditors are looking where traditional monitoring is blind. They are finding things.

The pattern emerging from developer surveys is consistent. AI generates code that looks correct. It introduces hidden defects and false security confidence. It produces unnecessary or duplicative code. That code passes code review because it compiles, runs, and looks like a reasonable refactor.

The dangerous part is that none of this triggers a static analysis alert or a test failure. It just sits in the system until an audit surfaces it.

The audit-visible signals are specific: - Hard-coded prompts with no versioning, no diff history, and no rollback path - Missing evaluations or evals that have not been re-run against current model versions - Undocumented data lineage, where the transformation between source and output is not provable - Agent systems operating with broad permissions inherited from the engineer who first wired them up

Security researchers have identified this last pattern as the top agentic risk. Autonomous systems are running with the credentials of whoever first connected them. This often happens long after that person has rotated off the project. The signal does not trigger a security alert.

It triggers a finding six months later. An auditor asks for the permission scope log and nothing exists. We have seen this exact pattern in our work on the blind spot in your AI stack that audits always find first.

Which means the metrics your team tracks this quarter probably don't map to what auditors will score next quarter. Here are the five that do.

What matters at audit time is not your sprint velocity. It's not your code coverage or MTTR either. It is whether the AI systems you ship can answer five questions in writing, with evidence. - Prompt version coverage. What percentage of production prompts are under version control with diff history? Auditors treat unversioned prompts the way they treat unversioned database schemas. Untracked is unmanaged. Unmanaged is an audit finding. - Eval coverage and freshness. What percentage of AI outputs are covered by automated evaluation? How recently were those evals run against the current model version? Old evals against retired models are not evidence. They are theater. - Data lineage completeness. Can you trace any production output back to the training or retrieval data that produced it? Undocumented transformations between data source and model output are now audit findings. Not edge cases. Findings. - Permission scope audit. Are agent systems operating on least-privilege? Or are they inheriting broad access from whoever first deployed them? This is the one that catches teams flat-footed. The inheritance is invisible until an auditor asks for the scope log. - Model dependency documentation. Which models, which versions, which fallbacks, in what order? Auditors want a dependency graph, not a Slack thread. If your fallback path is tribal knowledge, it is also an audit liability.

Automated verification is the path auditors are now expecting. Teams not running it are falling behind on the metric that matters. Our own work on why AI coding assistants are quietly breaking your engineering metrics tracks this shift. It shows what gets measured, and what gets penalized.

Knowing what auditors measure is the easy half. The harder question is how to get there in a quarter. You need to do this without halting the AI features your business is depending on.

The build playbook that works has four moves. None of them require halting feature work.

First, classify debt at intake. Chosen debt, where a human made a known trade-off, gets a ticket and a remediation plan. Inherited debt, the kind engineers pick up without realizing it, gets a flag in the same dashboard.

Both flow into a single view your auditors will eventually see. The cost of merging these two views is small. The cost of keeping them separate shows up as duplicated findings six months later.

Second, embed tracking into daily workflows, not quarterly audits. The Atoms project at Instacart is the model here. Break monoliths into modular pieces. Rebuild them in cleaner form. Ship them incrementally.

The instrumentation lives in the PR template. It lives in the CI check. It lives in the deploy pipeline. Not in a quarterly spreadsheet. We have a detailed walkthrough of tech debt tracking implementation that covers the day-one setup.

Third, instrument the five metrics as CI checks. Prompt diffs in pull requests. Eval runs triggered on every model upgrade. Lineage graphs generated from existing pipeline metadata, not hand-drawn. Permission scope logs pulled from your identity provider.

Model dependency graphs built from your registry. None of this is a documentation project. It is plumbing that runs every time code ships.

Fourth, recognize the value of prior experience. A focused tech debt tracking implementation that instruments the five core audit metrics benefits from prior experience. This experience covers instrumentation patterns, identity provider integrations, and CI plumbing.

Teams attempting the work from scratch rebuild patterns that experienced teams already understand. This is the operating standard auditors in regulated industries are now benchmarking against.

The teams that pull ahead over the next five years won't be the ones shipping the most AI features. They'll be the ones whose AI systems still work in five years. They'll be the ones that still pass an audit.

The systems that survive five years in production share one trait. Their instrumentation survived every model upgrade, every compliance review, and every audit cycle. Not because they were over-engineered. Because the debt was visible at write-time, not discovered at audit-time.

The pattern across enterprise deployments in regulated industries is consistent. Teams that track the five metrics ship faster. That's because the constraints are visible at PR time. They audit cleaner. The evidence is already in the pipeline. They retain clients longer.

Their systems keep working through regulatory changes that knock out competitors. The competitors treated audit-readiness as a remediation project.

The real outcome is not slower AI adoption. It is AI adoption that compounds. Every PR leaves a trail. Every model upgrade leaves evidence. Every audit becomes a checkpoint that passes on the first review.

That is what five years of production AI actually looks like. It is available to any team willing to treat the 3% as seriously as the 97%.

What is AI technical debt and how is it different from traditional technical debt?

AI technical debt is the accumulated cost of shortcuts, missing governance, and architectural compromises in AI-dependent systems. It includes debt from AI-generated code that was accepted without full validation. It also covers debt from the architecture and operations of AI systems themselves. Those systems include prompts, retrieval, orchestration, and permissions.

Unlike conventional tech debt, AI tech debt produces probabilistic degradation. Conventional debt produces known failure modes like test failures and documented shortcuts. AI debt produces outputs that look correct but aren't. Behavior shifts silently across model updates. Failures spread across multiple layers at once.

How do auditors measure AI technical debt?

Auditors now grade AI systems on five primary axes. Those axes are prompt version coverage, eval coverage and freshness, data lineage completeness, agent permission scope, and model dependency documentation.

They are looking for the signals traditional security tools miss. These include hard-coded prompts, undocumented transformations, and overly broad agent access. Conventional audits focused on static code issues instead.

What is inherited AI debt?

Inherited AI debt is technical debt that arises not from deliberate shortcuts. It comes from uncertainty about the behavior or fit of AI-generated code.

Engineers inherit it without knowing they took it on. AI tools produce code faster than engineers can fully validate. Each piece carries assumptions invisible to code review and standard testing.

Why did Instacart say they don't care about tech debt anymore?

Instacart's CTO Atul Kundu said the company "doesn't care about tech debt anymore." The reason is that AI now lets them rebuild inactive or low-value code rather than maintaining it. He compared this to how assembly code was eventually replaced by higher-level languages.

The statement applies to roughly 97% of their codebase. The remaining 3% sits in legacy, compliance, and latency-sensitive systems. Those still require careful human attention. That is exactly what auditors focus on.

How long does it take to make an AI system audit-ready?

A focused deployment that instruments the five core audit metrics benefits from prior experience. This experience covers instrumentation patterns, identity provider integrations, and CI plumbing. Teams attempting the work from scratch rebuild patterns that experienced teams already understand.

The difference is the difference between treating audit-readiness as a build constraint versus a remediation project. Teams that build instrumentation into the pipeline from day one ship faster. They also audit cleaner than teams that bolt it on after the first finding.

Research and references cited in this article:

• KEY!
• KEY Definition & Meaning
• KeyBank
• KEY | definition in the Cambridge English Dictionary
• KeyBank Reviews | Read Customer Service ...
• AI Technical Debt: What It Is. Why It Compounds. How to Control It.
• AI technical debt: What it is — and why it matters | RL Blog
• The Role of AI in Managing Technical Debt at Scale · Seerene Insights
• Reducing technical debt in 2026 - IBM
• How to Manage Tech Debt in the AI Era _(academic)_
• The Complete Guide to Technical Debt Tracking for Engineering Leaders
• Measure Tech Debt in 2026: 7 Metrics That Actually Work