[davidvartanian]

I've been thinking about this exact tension for the past few years while building tools for operational efficiency. The real predictor of long‑term pain isn't complexity per se; it's interdependence. LLMs make writing code cheap, but they don't instinctively architect for modularity. They'll happily generate a tightly‑coupled monolith that "works" today but becomes a coordination nightmare tomorrow (same as with human-implemented poor architectures). What I've observed (Prof. Christensen's modularity framework applies here) is that teams that treat LLMs as "fast writers" but enforce "good enough" modular interfaces (clear boundaries, well‑defined jobs‑to‑be‑done for each component) can scale without the usual debt explosion. Teams that let the LLM dictate the architecture end up with a "house of cards"; every change risks cascading failures. So the measurable signal I'd look for isn't lines of code or even cyclomatic complexity; it's change‑propagation distance. How many other files/modules need updating when you modify one? That's a proxy for interdependence, and it's something static analysis can actually track. On LLM‑based evaluation in CI: I'd trust it for spotting obvious anti‑patterns (e.g., "this function is 500 lines") but not for judging architectural coherence. That still requires human context about the business's actual jobs‑to‑be‑done. Have others found useful heuristics for measuring interdependence in real codebases?