Researchers say the standard ways of measuring software complexity miss most of what makes LLM-integrated apps hard to maintain.
A team studying AI application development built HECATE, a tool that measures complexity at both the code layer and the prompt layer. Starting from 25 complexity dimensions drawn from published taxonomies, they generated 52 candidate metrics and tested each against 118 components pulled from 18 open-source repositories. They used version history and maintenance activity as a proxy for real-world complexity, then discarded any metric that stopped being significant once code size was factored out. Ten metrics survived. Seven were newly introduced by the researchers, and those seven focus on what they call structural breadth - counting distinct elements like LLM call sites, memory attributes, and prompt templates rather than raw volume. Of the three surviving conventional metrics, only RFC shares that breadth orientation; the other two, Halstead N and V, held on mainly as a side effect of code size.
The finding that matters: prompt-layer metrics stayed significant even when the strongest code-level metric was added as a control variable, which means prompt complexity is not just a shadow of code complexity - it is its own measurable dimension. That has direct implications for software engineers building on top of foundation models, since most existing static analysis and code quality tooling will give them a clean bill of health on apps whose real maintenance burden is buried in prompt logic.
This is the kind of unglamorous infrastructure work the AI tooling ecosystem badly needs. The industry has spent years debating which model is smarter; less attention has gone to whether the software wrapping those models can actually be understood, tested, or handed off to another engineer without incident.