AI has made everyone a citizen CTO overnight! Non-technical founders are shipping AI-generated MVPs at lightning speed. But while the launch was quick, they’re completely blind to the explosive ‘hot potato’ of technical debt silently ticking down in the background – and that clock is running out. Here’s why that is and what to evaluate in diligence, to see how much time a startup has in their technical runway.
What is Technical Debt?
Perfect code doesn’t exist. Every product is a compromise in time, scope, and costs [Project Management Triangle]. There is never enough time to get everything right the first time; that’s why teams iterate!
Traditionally, technical debt is a deliberate financial loan. It’s a calculated trade-off: sacrifice code quality to get in front of customers today, buying yourself the runway needed to fix things tomorrow.
For example, suppose a startup launched an MVP with a recommendation engine that works fine for the first 100 customers; they get results in 5 to 10 seconds. When alternative solutions aren’t in real-time, customers are willing to wait. But with more and more customers onboarding, recommendations times balloon to minutes – or crash the customers’ system entirely. Suddenly, the interest on the startup’s technical debt has grown exponentially, threatening to take down the entire company if the underlying causes of sub-par performance isn’t fixed.
Why Code Written by LLMs has Exponentially Growing Technical Debt
The structural integrity of a prompt-based code base is a bit shaky.
In tech companies with Technical leadership, roadmaps require intentional coordination: Engineering, Product, and leadership sync up (annually, quarterly, or sprint-by-sprint) to debate trade-offs: Does this new feature move the business forward, or is the accumulated technical debt preventing us from moving the needle on our product?
Code written by LLMs makes those trade-offs implicitly, silently, and behind the scenes. You can prompt for this, but you aren’t guaranteed to get the right answer!
Then there’s the issue of code quality! Think about the training data.
General-Purpose Text LLMs typically use digitized and out-of-copyright books, Wikipedia, news archives, and moderated content.
Code Companion LLMs typically use public repositories of code, such as those available on GitHub. And let’s be honest about who makes their production-grade enterprise software repositories public: volunteer developers, students with passion projects, and contributors to open-source foundations (such as the Apache Software Foundation). Rarely it’s for-profit enterprises with rigorous release standards.
Put simply: LLMs are trained on the wild west of code, and then handed over to citizen CTOs who don’t know the difference.
Why Exit Strategy Should be Different for AI-native Teams
Of course anyone can preach software development best practices. But what if the AI-native startup and its LLM-generated MVP in your pipeline is just too good to pass up?
If you choose to invest, your playbook has to change; here’s how.
