I think AI is swapping code debt for tooling debt
I talked with an engineer recently who told me he was single-handedly (or rather, Claude-handedly) paying down tech debt in his company's codebase. And, at the same time, implementing a bunch of tools in their CI to catch all the kinds of quality slop problems that vibe coding everything could bring with it.
I am thinking that this is representative of switching to a new mode of thinking about tech debt.
The classic tech debt is code. Code debt starts at 0, when you have 0 code. When you add more code, like a feature, you add a bit of tech debt. You can reduce the amount of debt you go into by improving the design of the feature. And after some debt has accumulated, and small principals have combined and yielded big interest payments, you do a spurt of concentrated activity to pay it down. The amount of time you can afford to delay paying that debt is linked to your tolerance in every change in the code taking more time to complete and being more fragile each time.
But I think people are now implicitly shifting into tooling debt. And with tooling debt, it's the opposite: you don't accumulate it with time, instead you start in the red already. The moment you point an AI at your codebase and say "go," you're already carrying a deficit roughly equal to the gap between what the model can reason about and what an experienced engineer would catch. Any possible linter or automated review that you could ever implement to close that gap, and that you haven't implemented yet, is debt that you acquire from the get go.
Is this good, or is it bad? idk 🤷♂️. To me, someone who's very invested in setting up the best tooling for whatever I work in, it's very appealing. But I recognize that it sounds like every of these checks are just another serving of AI slop reaching the codebase, just in the shape of ancillary tooling instead of runtime code.
Is that code debt too? People working on this mode don't seem to think so. Same way that as a web coder, I don't worry about the assembly output of the JavaScript interpreter. And I guess that's the flip waiting to be switched, using code as mass of output, just at a higher level than 0s and 1s.