Stop worrying about technical debt

I never thought I would say that title. For most of my career, technical debt was something you tried to prevent from the start.

You hired good engineers, invested in code reviews, argued over architecture, and resisted shortcuts that would haunt you six months later.

Technical debt makes code harder to read, more brittle, and more expensive to extend. And I rarely find developers (or myself) eager to go back and fix it when shiny new features are next on the list.

Plus, once a product is working and customers are paying, there is always something more urgent. A new feature. A customer issue. A sales deadline. The refactor and cleanup stay on the roadmap forever.

AI-generated code, even a year ago, made this argument even stronger. It had the things engineers hate: duplicated logic, long functions, weird abstractions, and code that worked for the exact prompt but clearly did not belong in a codebase anyone wanted to own. AI made you faster, but you were trading that speed for a big mess tomorrow.

While I believed that strongly a year ago, my opinion has changed. It’s really weird for me to say this (and I kind of cringe saying it) but technical debt does not really matter as much anymore. (Yikes! - still does not feel good).

Over the last three to six months, AI has gotten much better at writing code. It has also gotten much better at cleaning it up.

AI makes test-driven development much easier. It can write tests alongside the code and run them every time it changes something. A year ago, those tests were often performative like checking for words on a page (AI once wrote me a test asserting that 1 == 1 ). New models increasingly test real behavior, including using browser agents and LLM-based evaluations. As we build, we also build larger test suites. Even when the code is imperfect, those tests catch regressions as it changes.

Point an agent at a messy area of a codebase and it can find and fix duplication, simplify functions, add tests, and refactor the code while checking whether it broke anything.

Humans hate refactoring because it is tedious and risky. It is also not as glamorous as shipping a new feature. Developers can get credit for deleting 2,000 lines of code, but they get much more credit for shipping the feature that users can see.

But Opus, Fable, and Sol will gladly do the dirty work - cleaning up the messy code their earlier iterations created in the background, 24 hours a day, 7 days a week.

Technical debt hurt because paying it down was expensive, politically difficult, and almost always lost to something more urgent. Leaving it in place put future stability and efficiency at risk. As AI models progress, that matters less: automated reviews can catch much of the debt and code smell before code is committed, while background tasks can clean up the rest.

And the models are just getting better. The technical debt today’s models miss can be found by future ones. When a new frontier model comes out, the first thing I do is have it go through our company’s codebase to find and fix security, performance, and code-smell problems older models overlooked.

Instead of technical debt lasting forever, it just lasts until the next model comes out - which is often a matter of a few months.

In six months to a year, AI will probably be able to take much of the code you have today and rebuild it from scratch in a much cleaner architecture.

That is more than better refactoring. You can build fast now, learn what matters, and later rebuild the product around what actually worked. It’s like tearing down a rotting house to the studs and rebuilding it just the way you want.

You are no longer making a permanent choice between moving fast and having clean code. You are making a bet that the learning you get now is worth more than the cleanup you will do later.

I am not recommending you let AI spray bad code all over your product without any review. If you let a codebase become complete spaghetti, eventually neither you nor the agent can reason about it. You still need enough structure that an agent can understand what it is changing and prove it did not break the product. But a series of AI-code reviews with today’s models can do a pretty job of keeping this in check.

Architecture still matters (at least as of July 2026). Early choices can have major consequences for scalability, security, and new functionality. Architecture can be changed later, but it is much more of a hassle. It’s worth spending the time thinking about this upfront to come up with something flexible, not over-engineered, and easy to change as requirements evolve.

But most technical debt is not architecture. It is imperfect implementation around an unproven idea. The slightly wrong abstraction. The feature built before anyone knew if users wanted it. The elegant system designed for a scale that never arrived.
I have intentionally accepted technical debt many times before.

At Shop It To Me and Hawku, I built the first version of each application. They were good enough to get real people using the products, but they were not perfect. Later, developer teams rebuilt major parts of both products around the workflows that had proven themselves. They kept the learnings and removed the unused code.

That was not a failure of the first version. It was the point: build quickly enough to learn, then rebuild around what actually matters.

AI makes this cycle much cheaper. In the old world, building a feature quickly created a real cost. You would either spend months making it perfect before learning whether it mattered, or ship it quickly and hope someone found time to clean it up later.

You now have another option: let AI take its best shot. Ship it. Learn from real users. Have AI clean up, simplify, or replace the messy parts behind the scenes while you work on the next feature.

Founders should worry less about technical debt and more about learning debt.

Did you spend an extra week trying to make the code perfect before getting it out there and seeing if people would use it? Did you optimize a workflow nobody needs? Did you slow down because you were protecting a future codebase for a future product that may never exist?

That is the debt that compounds.

Build fast enough to learn. Keep the code understandable enough to change. Then let the machines do more of the cleanup.

(originally posted at https://iamcharliegraham.substack.com/p/stop-worrying-about-technical-debt)