The Subprime Technical Debt Crisis
39 points by happyfellow
39 points by happyfellow
In A Deepness in the Sky one of the protagonists is a "programmer archaeologist" -- someone whose job is navigating systems so layered and intertwined that no one really understands them anymore.
That feels less and less like sci-fi now.
Junior hiring is effectively frozen right now (in my circles). Even if that's temporary, it creates a gap in the pipeline of people who actually learn systems from the inside out. That seems like a real problem.
AI coding doesn't just produce "more software". It produces software faster than we can understand it. Systems that work, get shipped, and get depended on, but that fewer and fewer people can reason about end-to-end.
That’s why the subprime comparison feels apt It's not just technical debt. It's risk that gets distributed, abstracted, and hard to locate.
"Managing the software" rather than writing it becomes the core skill.
Tangentially - that book was one of the most disappointing I ever read. Not because it was bad - it was pretty good! But because everyone-and-their-dog had mentioned the "Software Archeologist" character, neglecting to mention that they're only present for a handful of pages right at the start.
Oh, I always recalled that Pham Nuwen was a programmer archaeologist? To be honest, it's been many years since I read it... and that book has a lot of plots and layers in it.
It's also possible that I'm misremembering, but I thought that it was the mother of a lead character who's the archeologist, not the lead character themself. Regardless, it's certainly true to say that "software archeology is negligibly present in the plot", even if a long-present character is(/was) an archeologist.
It's one of my favorite books, and you are misremembering. Pham's role on the ship is described that way. There's a fun little bit about him discovering that the Qeng Ho epoch is not based on when humans first landed on the moon, as they commonly believe, but in fact a few months later because they are still ultimately using unix time.
This isn't too much of a spoiler, but a minor plot element is that the Emergent use their focus technology to rewrite a whole bunch of the software to "streamline" it. And the result is a mess that no one can actually understand, so they have to scrap it all and bootstrap it back from old code. Which feels increasingly relatable these days.
Thank you for the correction!
EDIT: AH, my bad: I was remembering "A Fire Upon The Deep", I haven't read "A Deepness in the Sky". I remain hopeful!
The promise of agentic coding is that paying back technical debts is going to get easier over time as the frontier models improve. If you expect a significant capacity improvement every couple of months, why would you ever pay back the technical debt right now? It'll be cheaper to do it in a year. It's only rational to postpone it.
I see this far differently. Since writing code is “cheap” and fast, I push my team to implement the more ideal solution. I’m also trying to add more guardrails in the form of foundational components and abstractions to reduce boilerplate and deviation from desired norms.
Agree. With regard to that quoted text, I've been applying exactly the opposite approach. Agentic coding makes paying down technical debt now much cheaper than it was before - that small refactor you just spotted that would take an hour so you can't justify it yet? Now takes five minutes, so get it done.
Remote agents/environments have been a blessing and a curse in this aspect. We setup a Coder.com instance, so it’s very easy to simply assign those small fixes to the Coder agent and get back a pull request.
I take 30+ minute walks in the morning. Some days I’ll have Claude transcribe a voice memo into a Linear ticket, assign to Coder, and forget about it all until I start getting surprised by review notifications.
This is an amazing superpower, but now I and my team must greatly learn to focus and prioritize to avoid death by a thousand “just let Coder do it” fixes that clog our review queue. I’m not ready to go full AI review. I need my team to understand what we own in the event of another AI provider outage.
As someone who has always found it difficult to focus and prioritize I totally get that - what was hard before is even harder now because side quests and distractions are so much cheaper.
I get similar idea. It's really about what you do with the tool not the tool itself. For so many things I didn't care enough about before, now I can easily write "generate more pathological case tests for (situation)" and get much better coverage and ensure the failure paths are handled properly. I'm getting less tech debt from this process, not more.
When implementing the ideal solution, writing the code has always been relatively cheap. Figuring out the ideal approach that makes the code trivial and obvious is hard. A large part of my programming time is spent walking and thinking.
Since writing code is “cheap” and fast, I push my team to implement the more ideal solution.
This is an internal struggle I haven't been able to articulate until recently, too.
There's a lot of philosophical talk of whether we even need to care what the output is like if agents will be doing everything. But if agents free up so much of our time, what is there to lose by nudging them to make things understandable? Even if it's only for insurance so humans can understand a system during an incident when the AI providers are down, it's still worth it.
One of the nice properties of debt, is that you can declare bankruptcy and not pay. This works for code too. We can build multiple projects much more quickly and then discard the useless or rewrite the useful as needed.
And technical debts are also generally independent too, and don't necessarily spin into deflationary spiral of whole software economy.