Hey everyone, I’d love to get a broader industry take from vibe coders and other developers here on technical debt in the LLM era.
We’re clearly in a phase where code generation is faster than ever, iteration cycles are shorter, and teams are shipping at a pace that would have felt unrealistic a few years ago. At the same time, we still do not have a shared understanding of what code health actually means in a world where writing code is cheap but maintaining coherence over time remains difficult. I am curious how you all believe companies should think about debt when LLMs are embedded in the development loop. What really predicts long-term pain? Is it complexity, churn, architectural drift, unclear ownership, or something harder to quantify? Should code health be distilled into measurable signals, or is it fundamentally multidimensional and resistant to simple scoring? And would you ever trust LLM-based evaluation in CI, or should it remain advisory?
I have not seen many compelling solutions yet. As an experiment, I have been working on an open-source technical debt analyzer that combines static analysis, heuristic checks, and LLM-based evaluation to surface hotspots and suggest improvements. The goal is to make debt more visible and easier to prioritize, especially for growing teams or inherited codebases. If you were evaluating a tool like this, what metrics would you expect it to include? Would LLM-based signals be something you would take seriously in a production workflow?
I am genuinely curious how others are thinking about this. It feels like a large and growing industry problem, and I would love to hear what has or has not worked in practice.
I built tech-debt-visualizer to find the worst offenders in a vibe-coded codebase. In projects where people hack quickly and iterate fast, code tends to bloat. Functions balloon, docstrings disappear, and complexity sneaks in everywhere.
Most tools either count lines or require a heavy setup, which misses the real hotspots. This works by utilizing both static and LLM-based approaches to determine the cleanliness of a codebase.
I'd love if you all gave it a try, and I am looking for any and all thoughts. You can try it out without even installing in one CLI command in your codebase right now:
npx tech-debt-visualizer analyze .
(for the LLM part to work, you will also need an API key for Gemini, OpenAI, Openrouter, or OpenAI compatible)
We’re clearly in a phase where code generation is faster than ever, iteration cycles are shorter, and teams are shipping at a pace that would have felt unrealistic a few years ago. At the same time, we still do not have a shared understanding of what code health actually means in a world where writing code is cheap but maintaining coherence over time remains difficult. I am curious how you all believe companies should think about debt when LLMs are embedded in the development loop. What really predicts long-term pain? Is it complexity, churn, architectural drift, unclear ownership, or something harder to quantify? Should code health be distilled into measurable signals, or is it fundamentally multidimensional and resistant to simple scoring? And would you ever trust LLM-based evaluation in CI, or should it remain advisory?
I have not seen many compelling solutions yet. As an experiment, I have been working on an open-source technical debt analyzer that combines static analysis, heuristic checks, and LLM-based evaluation to surface hotspots and suggest improvements. The goal is to make debt more visible and easier to prioritize, especially for growing teams or inherited codebases. If you were evaluating a tool like this, what metrics would you expect it to include? Would LLM-based signals be something you would take seriously in a production workflow?
I am genuinely curious how others are thinking about this. It feels like a large and growing industry problem, and I would love to hear what has or has not worked in practice.