In Greek mythology, Daedalus was the architect who built the Labyrinth of Crete. He designed every corridor, every false turn, every dead end. The maze was his masterwork, commissioned by King Minos to contain the Minotaur. It worked perfectly. And then Minos imprisoned Daedalus on the island, and the architect found himself trapped by the consequences of his own creation. He couldn't sail away because Minos controlled the ports. The labyrinth he'd built hadn't trapped him physically, but the power it gave Minos had trapped him politically. According to Ovid, Daedalus eventually escaped not by navigating the maze but by building wings and flying over it entirely.^[1]

That story maps onto a pattern familiar to any engineering team that has lived with a codebase for more than a few years. You build the system under pressure, making reasonable decisions with the information and constraints you have at the time. Each decision adds structure. Over months and years, the accumulated structure becomes a labyrinth that the team spends more time navigating than extending. The builders become trapped by what they built.

Ward Cunningham coined the term "technical debt" in 1992 to describe this dynamic, using a financial metaphor to explain to non-technical stakeholders why software that works today may need rework tomorrow.^[2] The metaphor has proven durable because it captures something real: shortcuts and expedient decisions accrue interest over time, and that interest compounds.

How the Labyrinth Grows

Technical debt doesn't usually arrive as a single dramatic decision. It accumulates through hundreds of small ones. A workaround for a deadline. A "temporary" solution that becomes permanent because nobody has time to replace it. A dependency added to solve one problem that introduces ten new integration points. A configuration that works in production but nobody remembers why. Each of these is a corridor added to the labyrinth.

The compounding effect is what makes the labyrinth metaphor apt. In a financial debt, interest accrues on the principal. In technical debt, each new corridor makes every other corridor harder to navigate because the interactions multiply. A workaround in service A constrains what service B can do. A pinned dependency in module C prevents upgrading module D. A naming convention established in year one conflicts with the naming convention adopted in year three, and now both coexist, each confusing engineers who encounter the other.

Fred Brooks, in his 1986 essay "No Silver Bullet" (later included in the Anniversary Edition of The Mythical Man-Month), distinguished between essential complexity (inherent in the problem being solved) and accidental complexity (introduced by the tools and approaches used to solve it).^[3] Much of what accumulates as technical debt can be understood as accidental complexity: structure that doesn't serve the problem domain but rather reflects the history of how the system was built. Not all technical debt fits this category neatly (some is deliberate and strategic), but the corridors that cause the most navigation difficulty tend to be those that serve no current purpose beyond historical inertia.

The Institutional Knowledge Problem

The labyrinth's most dangerous property isn't its size. It's that the maps exist only in human memory.

The engineer who wrote the workaround knows why it exists. The architect who chose the unusual dependency structure remembers the constraint that made it necessary. The team lead who approved the "temporary" solution recalls the deadline that justified it. These people carry the labyrinth's map in their heads. When they leave the organization, the map leaves with them. The labyrinth remains, but now nobody knows why the corridors turn where they do.

This is where technical debt becomes genuinely dangerous rather than merely inconvenient. A labyrinth you understand is navigable. A labyrinth you don't understand is a trap. Engineers encountering undocumented complexity face a choice: spend time understanding it (expensive, slow) or work around it (adding more corridors to the maze). Under deadline pressure, the second option often wins. The labyrinth grows.

The problem scales with team turnover. Organizations with high attrition rates lose institutional knowledge faster than they can document it. Each departure removes a map. Each new hire encounters corridors they can't explain. The labyrinth becomes progressively more opaque to the people who must navigate it daily.

AI as the Thread: Code Comprehension and Explanation

This is where AI-assisted tooling offers something genuinely new. Large language models can read code and produce explanations of what it does, why it might have been structured a particular way, and where the risks are. The explanations aren't always correct, and they can't fully replace the institutional knowledge of someone who was there when the decisions were made. But they can provide a starting point that didn't previously exist.

The "explain this code" use case is perhaps the most immediately valuable application of AI to technical debt. An engineer encountering an unfamiliar module can ask an AI assistant to summarize its purpose, identify its dependencies, and flag potential issues. This doesn't eliminate the need to understand the code deeply, but it compresses the time from "completely lost" to "oriented enough to ask the right questions."

A 2025 paper from Google describes using LLMs to assist with large-scale code migrations across their monorepo, reporting that in a study of 39 migrations over twelve months, approximately 74% of code changes and 69% of edits were generated by the LLM, with developers focusing on review and correction rather than writing migration code from scratch.^[4] This suggests that AI can meaningfully accelerate the work of navigating and modifying complex codebases, though the human review component remains essential.

AI-assisted refactoring tools can also identify dead code, unused dependencies, and redundant abstractions across large codebases. These are corridors in the labyrinth that serve no purpose but still add to the navigation burden. Identifying them manually in a codebase of any significant size is prohibitively time-consuming. AI can scan the full graph and surface candidates for removal, effectively identifying walls that can be torn down.

The COBOL Problem: Labyrinths Nobody Can Read

The most extreme version of the institutional knowledge problem exists in legacy COBOL systems. An estimated 800 billion lines of COBOL remain in active use globally, according to frequently cited industry estimates, running critical infrastructure in banking, insurance, and government.^[5] Many of the engineers who wrote these systems have retired or left the field. The systems work, but modifying them safely requires understanding code that may be decades old, poorly documented, and written in a style that few active developers can read fluently.

AI-assisted COBOL comprehension and translation is an active area of development. Microsoft, for example, has published work on using AI agents for COBOL migration and mainframe modernization, describing the challenge as one of the most complex forms of legacy modernization.^[6] The approach typically involves AI reading COBOL code, generating explanations of its business logic, and producing equivalent code in a modern language, with human review at each stage.

The results are promising but imperfect. AI can often translate syntax correctly, but business logic embedded in decades-old code frequently depends on undocumented assumptions, implicit conventions, and edge cases that the original developers handled through experience rather than explicit specification.^[8] The labyrinth's corridors may be translatable, but the reasons they turn where they do may not be recoverable from the code alone.

The Strangler Fig: Simplifying Rather Than Navigating

Martin Fowler coined the "strangler fig" pattern in 2004 to describe an approach to legacy system migration that avoids the risks of a complete rewrite.^[7] Named after the strangler fig tree, which germinates in the canopy of a host tree and gradually grows downward until it replaces the host entirely, the pattern involves building new functionality around the edges of the old system, gradually routing traffic to the new components until the legacy code can be retired.

The strangler fig is a labyrinth simplification strategy. Instead of navigating the old corridors better, you build new, simpler corridors alongside them and gradually redirect traffic until the old ones can be demolished. AI can assist this process by mapping the old system's behavior (what does this code actually do?), identifying the boundaries where new components can intercept traffic, and verifying that the new implementation preserves the old system's behavior.

This is the higher use of AI in the context of technical debt: not helping you navigate the labyrinth faster, but helping you identify which corridors can be eliminated. Every wall torn down, every dead-end removed, every redundant path consolidated is a permanent reduction in the system's complexity. Navigation aids are temporary. Simplification is permanent.

The Danger: Better Thread, Bigger Labyrinth

There's a risk worth naming explicitly. If AI makes complex codebases more navigable, organizations may tolerate more complexity rather than less. If the thread makes the labyrinth survivable, the incentive to simplify diminishes. Why tear down walls when the AI can guide you through them?

This is the Daedalus trap in modern form. The architect who builds a labyrinth and then builds wings to escape it hasn't solved the labyrinth problem. He's just found a personal workaround. The labyrinth still exists. The next person who enters it still faces the same complexity.

AI that helps individual engineers navigate technical debt without reducing it is a wing, not a solution. It helps the person with access to the tool, but it doesn't help the system. The labyrinth remains for everyone else, and it continues to grow.

The discipline required is to use AI not just as a navigation aid but as a simplification tool. Not "help me understand this complex code" but "help me identify what can be removed." Not "explain this workaround" but "is this workaround still necessary?" Not "navigate the labyrinth" but "make the labyrinth smaller."

Daedalus didn't improve the labyrinth. He escaped it. The goal isn't a better thread. It's fewer corridors.

References

[1] Ovid, Metamorphoses, Book VIII, lines 183–235. Translation by A.S. Kline, 2000. https://ovid.lib.virginia.edu/trans/Metamorph8.htm

[2] Ward Cunningham, "The WyCash Portfolio Management System," OOPSLA '92 Experience Report, 1992. For discussion of the original metaphor, see also Ward Cunningham, "Ward Explains Debt Metaphor," wiki.c2.com. http://wiki.c2.com/?WardExplainsDebtMetaphor

[3] Frederick P. Brooks Jr., "No Silver Bullet—Essence and Accident in Software Engineering," Proceedings of the IFIP Tenth World Computing Conference, 1986. Later included as Chapter 16 in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 1995.

[4] "Migrating Code At Scale With LLMs At Google," arXiv, April 2025. https://arxiv.org/html/2504.09691v1 The study reports that across 39 migrations, 74.45% of code changes and 69.46% of edits were LLM-generated.

[5] The "800 billion lines" figure is widely cited in industry reporting but difficult to verify independently. For context, see Reuters, "Banks scramble to fix old systems as IT 'cowboys' ride into sunset," April 2017, which discusses the scale of COBOL in financial services. The precise global figure should be treated as an estimate.

[6] Microsoft DevBlogs, "How We Use AI Agents for COBOL Migration and Mainframe Modernization," 2025. https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/

[7] Martin Fowler, "StranglerFigApplication," martinfowler.com, June 2004. https://martinfowler.com/bliki/StranglerFigApplication.html

[8] For discussion of the limitations of AI-assisted COBOL translation, see Rob Mee, "What the COBOL Translation Backlash Gets Right — and Wrong," CIO, March 2026. https://www.cio.com/article/4141171/what-the-cobol-translation-backlash-gets-right-and-wrong.html