Tech debt is weird
Jesse wrote this interesting article on technical debt, which resonated with me spiritually but not directionally -- which is a very weird way to say that I agree with some parts and disagree with others (so you should read this not as a critique of the post but an exploration from my point of view). The title of this essay is "negative-interest tech debt", which gives you a sense of where Jesse is going, but read the post in its entirety for two reasons:
- it is short,
- it is nuanced; he is clearly neither arguing that technical debt is a thing of the past and we should treat it as such, nor that it's the exact same as it's always been.
With that in mind, I have four commingled takes. Thank you to Sonny who reminded me that I cannot count.
Technical debt is materialized as drag against the ability to deliver customer value.
This sounds like a pedantic recharacterization of Jesse's words, but I want to be very deliberate about this because I think the distinction is meaningful. In particular, it is important to remember that there are times where the technical debt brings pain even though we're not trying to make a code change or deliver value through a code change. If there's an incident that takes 2x as long as it should because nobody knows how the relevant subsystem operates, that is still technical debt.
If you would like to argue that that gets materialized purely as bad documentation or some other failure, okay, fine, whatever. But then the question becomes: how do we more adequately build LLM-generated codebases which humans can operate and internalize the mechanics of just as well as their own? I don't think we have arrived at that answer,
LLMs are default net-producers of technical debt
I am a person who abhors technical debt, often to the detriment of my ability to build more directly useful things for customers. I feel fairly proud of my ability to leverage LLMs to drive down technical debt. There is no question that Buttondown's codebase is filled with less technical debt than it used to be, even though it is more generated by LLM than it used to be. However, that's not happening a priori. If I were to ask the Council of Frontier Models what specific things I could do to lower technical debt, their answers would be incorrect and would probably end up increasing technical debt. (This harkens back to one of my favorite aphorisms, which is that technical debt is the delta between a codebase and the reality which it attempts to map.)
I have seen enough codebases from organizations and individuals who do not care about technical debt to know that, absent very strenuous guardrails and intervention, the situation gets dire very, very quickly. This is a problem exacerbated by the fact that observability tooling for LLMs is still at a very nascent period, such that we feel the pain of technical debt without being able to quantify it. When you are spending all day struggling with some bad abstraction or kludge, you notice and internalize that much more than when an LLM is.
LLMs are not free
In a world where technical debt is completely solvable by LLMs, all that means is that the technical debt now assumes the form of traditional financial debt. LLMs are not free. I know it's really boring to say that, and I don't mean it in any sort of doomerish way. The thing that frustrates me about the school of thought that with enough tokens you can solve any problem is that, like, yeah, man — the tokens cost a lot of money. I think this is important to remember because suddenly we will want to reason about this work financially and not just from a productivity perspective. Certainly, I have been evaluating my own tool usage with the end goal of driving down cost, driving down token spend — which is technical debt in its purest form, if you can approximate token spend as a rough proxy for knowledge-work-based labor.
LLMs devalue features at the same rate they pay down debt
Jesse ended the post with a supposition:
[If you think LLM improvements continue to compound relative to consumer price], you should probably spend less time worrying about tech debt, and spend more time shipping new features.
I think this is true if and only if you are in a position where there's genuine first mover advantage and you happen to be that first mover. Otherwise (again, given this supposition) you must assume that your competitors are reasonable people who will be using these tools too, and therefore also pay down all of their tech debt and ship all of the features. The Red Queen problem comes for us all!
Personally speaking, though, I have learned to grow suspicious of prognostication that lets me lean into the kind of work that is easy and fun.
As I wrote in Snacks are cheaper and tastier than ever, I think you have to spend some time thinking really hard about what is the most important, highest-leverage use of your time — whoever you are — and changing your habits and approach to engineering accordingly. Regardless of the future of LLM capability or cost, I think the relative margin in having a given feature goes down for the simple reason that marginal cost of implementing that feature has gone down.
So this essay ends the same way all of mine lately: you need to find durable and meaningful ways to create value for your users. Same as it's ever been, but more so.