This is a shortsighted way of seeing things. The first issue, though surface-level, is using LOC as a measurement. If Company A’s million lines of code are cleaner, clearer, and better-documented than Company B’s 100k lines, then in that case Company A would be better off. What I’m getting at is that the author means to talk about complexity, and is using lines of code as rough measurement for complexity. Code itself is not debt, the complexity engendered by code is.
Code is an asset. It is the product of software companies. Having more assets certainly increases complexity, but this is almost definitionally true. Imagine saying “the US interstate highway system is debt, because it’s complex and difficult to maintain.” The premise is true, but the conclusion is such a one-dimensional way of seeing things.
The AI stuff aside, in light of the above, what is the author’s thesis here? “For the same code, all else being equal, it’s better to have less complexity than more complexity”? Sure, true, but that’s a pretty easy and obvious point.
It seems this entire article could have been profitably boiled down to “make sure your AI coding tools aren’t adding unnecessary complexity to your finished code.”
Hmm, I actually think complexity is a red herring here.
Postulate that you have a viable software business, and work backwards from there. Everything else: every purchase and every pay period you pay someone to work for you is a cost, from this point of view, and undesirable unless necessary for the welfare of the business. But every cost is a step away from the platonic ideal of a business, one with arbitrarily high profits and arbitrarily low costs.
I agree that complexity is worse than simplicity, to the extent that complexity really is more expensive. But cost: whether long term or short term, capital or operational, is what really matters.
The question is whether LLM-generated code increases or reduces cost. Size, complexity, and a million other details not considered in the OP or in your comment all matter a lot.
I tend to look at cyclomatic complexity[0], in my functions. I use SwiftLint[1] to measure it, and flag functions that are too complex. Sometimes, I sort of kludge, and break the function into parts, but I usually find some way to do things more simply.
My files tend to be fairly long, but I also have a 50/50 comment-to-code ratio.
I'll bet that you could prompt an LLM to both reduce CC, and add lots of comments.
Code is an asset/liability the same way that unstable volatile chemicals are.
If you use them promptly, in the right way, you'll make money. If you let it sit and degrade, or spill it, then it's a liability.
While source code--unlike certain chemicals--doesn't spontaneously change on its own, its fitness-for-purpose does, as the organization constantly shifts goals and process.
I'd say the software is an asset more than the code itself, much like an interstate is an asset rather than the concrete that it consists of. The quality of the concrete impacts the depreciation (reduction of value) of the asset and how much operational expenditure is required to upkeep the asset which would again impact the asset value. There's probably also a risk management angle which should be considered.
Interesting talk about complexity: Complexity is when your systems interact. A complex system can become unreasonable. A complex system cab be generative and surprising!
100k LoC vs 1M LoC to do the same thing is a big deal. Most likely the 1M code has a lot of redundancy and indirecting.
It's just one measure but quantity is often bad.
Also the latest economic buzz to declare dept as something positive and not at all just a often blind defense for aching economic systems facing some pressures and problems, it would still not align too well with this anology.
And before someone tries to refute the "debt is mostly bad for the debt holder"-statement by some coked up economist in his first semester, I know how money is created today. I also know about the opportunity new debt can open. Doesn't make debt something positive, the field really lacks structured thought... I forgive you if you are the lawyer of Greece, but ffs... Some concepts are simple and fundamental.
I guess the author tried to connect debt and technical debt and there are certain similarities. In both cases work has to be done without direct compensation aside from working of the debt. Perhaps that is why it is called debt.
Most of my early career was about writing a lot of code. Now 20 years later I pride myself in removing more code than I add to most repos. As a security engineer code is not just debt, it is risk. Especially dependencies.
Recently a colleague and I wrote a tiny linux init system that is used in production for several orgs. Under 600 lines of rust standard library, no dependencies. Boots in under 1 second. Turns out you do not need all the risk and disk i/o of systemd and a million lines of c to run an appliance like linux server.
Seriously, if you write it yourself you end up with a lot less code and systems you can understand top to bottom.
Nothing for the use cases I have in production other than more platform support, but those can be compile time features for when using those specific environments. I want 0 lines of dead code in production for easy auditing.
The worst case with AI-generated code is worse than this. Instead of a company, I'll talk about smaller personal projects.
You can make a very real decision right now - spend a lot of time making 10,000 lines of good code that you know well, or spend VERY LITTLE time (maybe 1-2% as long) making 20,000 lines of bad code that does the same thing and that you don't know well at all.
Personally I'm continuing to find the middle ground, because if you want to continue to build past that, I think you've actually lost that time in the first case.
Personally, I have only used AI to write actual code when it is for Bash and Python scripts that are self contained. In my case self contained means they are interfaced to via command line so their boundaries are very well defined.
I have never returned to look at any of the code.
I would never use it to generate domain code for my codebase because then I'd have to code review it anyways. I mean, if I have an agentic AI solving an issue and generating a PR, great, I can review that and give it feedback on how to change the code before its accepted.
Unless I can either throw the code away or review it for maintainability rather than correctness then I have no need for a tool that write my code for me.
Oh, unless the AI can be the product owner and understand the financial ramifications of not doing its job correctly but I would be worried that the solution is to not have a product by reducing the users to ash.
Every time I overreached with trusting AI to correctly implement large parts of code I've paid the price in lost productivity later. I imagine with fully vibecoded apps the skill you need most is "you know what maybe I didn't need that feature after all" because I can't imagine how frustrating it would be debugging spaghetti code where you have no idea what the hell it does.
Terse, poorly named variables, and clever code is worse than verbose, well documented, thoroughly named variables with readable dsl.
Debt is proportional to the time it takes to understand, change, and extend the codebase.
Lines of code are an imperfect mapping to tech debt. And if all things truly were equal then this metric has been minimized at the expense of readability - which almost certainty impacts debt worse.
So I think the better argument here is that, "lack of theory is debt" - so ironically, perhaps the better argument is the shorter codebase is debt in the analogy to LLMs. LLM usage minimizes theory building. But this is assuming that AI doesn't continue to progress and its ability to build theory about the project (and communicate it correctly to the engineer) remains constrained.
I love programming as theory building. One key thing: if the program is built for a business then the theory must revolve around the business. For example, it should include things as "easiness to hire devs for this code base”, "stability of current business model” and “how important each feature is for the business”.
You can, but with Claude, be sure to watch what files it reads—I’ve seen close to entirely incorrect analysis due to shallow/lazy reading.
If you think it’s phoning it in, tell them to study upstream and downstream consumers, consider edge and corner cases, and what assertions any tests are making of the code in question, and to redo their analysis.
But it can only amplify information already present in the code or apply "common sense" from other code bases, in other ways the things a programmer already does.
In addition LLMs recognize "meaning" mostly like prose, i.e. they take the code behaviour mostly from the names of the variables and functions less from the actual behaviour. When you name everything randomly, then a LLM is way worse to recognize what the code is doing.
This means that when the code is already confusing, wit naming doesn't match behaviour than the LLM is more likely to tell you the story from the naming not the story of actual behaviour.
No. Your understanding is only as good as what you saw for yourself, no superficial explanation will serve you. Of course, the LLM will not even give you a suitable answer anyway for anything beyond trivial code snippets.
I've been at companies where the company itself has no code assets but depends on a bunch of 3rd party enterprise services to run the core business. Brings up the question of how to measure how much code you have: if you depend on a legacy saas provider, do their lines of code count as your liability?
I think the top liability If you depend on a bunch of 3rd parties is if they close or are acquired and change the terms. Many times, we are using services from startups that were only well-funded and have not reached break-even and/or a sustainability business.
A lot depends on the details of what the service provides, but yea, the worst is when your critical data is not accessible or recoverable because someone else holds it for you and something happens that cuts you off. The doesn’t mean that you shouldn’t use any service, but you do need to think through some worst case scenarios and think about your recovery strategy.
At a previous place we used a dreadful email marketing SaaS tool and it caused us no end of fire-fighting, even though we probably only had 500 lines of integration code. We ended up rewriting the functionality we needed and bringing it in-house and saved a ton of pain and money, and added ~3k lines.
Code is definitely an asset, but it deprecates just like hardware does, for a variety of reasons like faults but also just the software and hardware moving on in the industry. The more code you have the more depreciation you are paying annually, which if you don't pay the system will eventually stop working and will in various parts fall into disrepair before that point.
The bit that is a challenge with the deprecation view of things is that if the code isn't sufficiently maintained (size outstrips developers) then the cost of fixing the problem increases with time disproportionately, its like you pay interest on the outstanding depreciation debt. So I understand why people use debt but its not quite right.
Long ago, a proud moment for me was writing -20K lines of code in a month.
A few years ago, I tried that again with a remote team of 20 coders. I failed; I couldn't keep up with the barrage of pull requests.
Today, pair programming with Claude Code and GPT feels more like the later.
I think there is an opportunity here for smart refactoring. But, needs a larger context. I tried this on some legacy code with Cursor and Claude opus 4.1, but a million tokens is not enough. I dunno; maybe translate between a private and shared LLM. Has anyone tried this?
Readit News
Code is an asset. It is the product of software companies. Having more assets certainly increases complexity, but this is almost definitionally true. Imagine saying “the US interstate highway system is debt, because it’s complex and difficult to maintain.” The premise is true, but the conclusion is such a one-dimensional way of seeing things.
The AI stuff aside, in light of the above, what is the author’s thesis here? “For the same code, all else being equal, it’s better to have less complexity than more complexity”? Sure, true, but that’s a pretty easy and obvious point.
It seems this entire article could have been profitably boiled down to “make sure your AI coding tools aren’t adding unnecessary complexity to your finished code.”
Postulate that you have a viable software business, and work backwards from there. Everything else: every purchase and every pay period you pay someone to work for you is a cost, from this point of view, and undesirable unless necessary for the welfare of the business. But every cost is a step away from the platonic ideal of a business, one with arbitrarily high profits and arbitrarily low costs.
I agree that complexity is worse than simplicity, to the extent that complexity really is more expensive. But cost: whether long term or short term, capital or operational, is what really matters.
The question is whether LLM-generated code increases or reduces cost. Size, complexity, and a million other details not considered in the OP or in your comment all matter a lot.
My files tend to be fairly long, but I also have a 50/50 comment-to-code ratio.
I'll bet that you could prompt an LLM to both reduce CC, and add lots of comments.
[0] https://en.wikipedia.org/wiki/Cyclomatic_complexity
[1] https://littlegreenviper.com/swiftlint/
If you use them promptly, in the right way, you'll make money. If you let it sit and degrade, or spill it, then it's a liability.
While source code--unlike certain chemicals--doesn't spontaneously change on its own, its fitness-for-purpose does, as the organization constantly shifts goals and process.
Interesting talk about complexity: Complexity is when your systems interact. A complex system can become unreasonable. A complex system cab be generative and surprising!
https://www.youtube.com/watch?v=czzAVuVz7u4&t=257s
Funnily enough, this doesn't contradict "code is debt" because Asset = Equity + Liability.
And before someone tries to refute the "debt is mostly bad for the debt holder"-statement by some coked up economist in his first semester, I know how money is created today. I also know about the opportunity new debt can open. Doesn't make debt something positive, the field really lacks structured thought... I forgive you if you are the lawyer of Greece, but ffs... Some concepts are simple and fundamental.
I guess the author tried to connect debt and technical debt and there are certain similarities. In both cases work has to be done without direct compensation aside from working of the debt. Perhaps that is why it is called debt.
Dead Comment
Recently a colleague and I wrote a tiny linux init system that is used in production for several orgs. Under 600 lines of rust standard library, no dependencies. Boots in under 1 second. Turns out you do not need all the risk and disk i/o of systemd and a million lines of c to run an appliance like linux server.
Seriously, if you write it yourself you end up with a lot less code and systems you can understand top to bottom.
https://git.distrust.co/public/nit
You can make a very real decision right now - spend a lot of time making 10,000 lines of good code that you know well, or spend VERY LITTLE time (maybe 1-2% as long) making 20,000 lines of bad code that does the same thing and that you don't know well at all.
Personally I'm continuing to find the middle ground, because if you want to continue to build past that, I think you've actually lost that time in the first case.
Personally, I have only used AI to write actual code when it is for Bash and Python scripts that are self contained. In my case self contained means they are interfaced to via command line so their boundaries are very well defined.
I have never returned to look at any of the code.
I would never use it to generate domain code for my codebase because then I'd have to code review it anyways. I mean, if I have an agentic AI solving an issue and generating a PR, great, I can review that and give it feedback on how to change the code before its accepted.
Unless I can either throw the code away or review it for maintainability rather than correctness then I have no need for a tool that write my code for me.
Oh, unless the AI can be the product owner and understand the financial ramifications of not doing its job correctly but I would be worried that the solution is to not have a product by reducing the users to ash.
Debt is proportional to the time it takes to understand, change, and extend the codebase.
Lines of code are an imperfect mapping to tech debt. And if all things truly were equal then this metric has been minimized at the expense of readability - which almost certainty impacts debt worse.
So I think the better argument here is that, "lack of theory is debt" - so ironically, perhaps the better argument is the shorter codebase is debt in the analogy to LLMs. LLM usage minimizes theory building. But this is assuming that AI doesn't continue to progress and its ability to build theory about the project (and communicate it correctly to the engineer) remains constrained.
Dead Comment
If you think it’s phoning it in, tell them to study upstream and downstream consumers, consider edge and corner cases, and what assertions any tests are making of the code in question, and to redo their analysis.
In addition LLMs recognize "meaning" mostly like prose, i.e. they take the code behaviour mostly from the names of the variables and functions less from the actual behaviour. When you name everything randomly, then a LLM is way worse to recognize what the code is doing.
This means that when the code is already confusing, wit naming doesn't match behaviour than the LLM is more likely to tell you the story from the naming not the story of actual behaviour.
At a previous place we used a dreadful email marketing SaaS tool and it caused us no end of fire-fighting, even though we probably only had 500 lines of integration code. We ended up rewriting the functionality we needed and bringing it in-house and saved a ton of pain and money, and added ~3k lines.
Deleted Comment
The bit that is a challenge with the deprecation view of things is that if the code isn't sufficiently maintained (size outstrips developers) then the cost of fixing the problem increases with time disproportionately, its like you pay interest on the outstanding depreciation debt. So I understand why people use debt but its not quite right.
A few years ago, I tried that again with a remote team of 20 coders. I failed; I couldn't keep up with the barrage of pull requests.
Today, pair programming with Claude Code and GPT feels more like the later.
I think there is an opportunity here for smart refactoring. But, needs a larger context. I tried this on some legacy code with Cursor and Claude opus 4.1, but a million tokens is not enough. I dunno; maybe translate between a private and shared LLM. Has anyone tried this?