Ask HN: What are the metrics for "AI-generated technical debt"? Here’s one place where I think proponents and skeptics of agentic coding tools (Claude Code, Codex, etc.) tend to talk past each other: Proponents say things like: - “I shipped feature X in days instead of weeks.” - “I could build this despite not knowing Rust / the framework / the codebase.” - “This unblocked work that would never have been prioritized.” Skeptics say things like: - “This might work for solo projects, but it won’t scale to large codebases with many developers.” - “You’re trading short-term velocity for long-term maintainability, security, and operability.” - “You’re creating tons of technical debt that will surface later.” I’m sympathetic to both sides. But the asymmetry is interesting: The pro side has quantifiable metrics (time-to-ship, features delivered, scope unlocked). The con side often relies on qualitative warnings (maintainability, architectural erosion, future cost). In most organizations, leadership is structurally biased toward what can be measured: velocity, throughput, roadmap progress. “This codebase is a mess” or “This will be a problem in two years” is a much harder sell than “we shipped this in a week.” My question: Are there concrete, quantitative ways to measure the quality and long-term cost side of agentic coding?. In other words: if agentic coding optimizes for speed, what are the best metrics that can represent the other side of the tradeoff, so this isn’t just a qualitative craftsmanship argument versus a quantitative velocity argument? |