The zillions of LOCs generated by AI tools are just job security for experienced developers, assuming enough are still around by the time companies realize the amount of debt they've buried themselves under.
Every line of code is a liability, in the accounting sense of the word. That is, it's what makes the asset (software) exist.
The balance sheet is always equal, so you always have as much liability as asset in amount. Despite the negative connotation of the word, some liabilities are good (earnings[1] is the best, equity and long term debt with low interest rate are nice too), but some are bad.
And it's the same for code, spitting more code to do the same thing is akin to emitting too many shares, having brittle code that needs constant intervention to keep working is akin to high interest debt.
[1] yes, your company's earning belong to the right side of its balance sheet.
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.
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.
> Imagine two very similar companies. Both companies generate similar revenue and produce a similar software product. The only difference between these companies is that Company A uses 1 million lines of code and Company B uses 100 thousand lines of code. Which company is better off?
Company A uses a good framework that allows underlings to make for their middle managers reports which those middle managers use to demonstrate that their portion of the company is providing value. Upper management is well pleased, and refrains from laying off those productive portions.
Company B has no framework, and underlings cannot produce good reports for middle managers. Upper management fires at random, and great lamentations go up across the land.
More seriously: You can spend money to make money in the software world, and making a good abstraction is well worth the effort. There might just be a reason we us OSes these days instead of writing every application to sit directly on hardware. That might be the result of some actual thought.
While I agree that it's very easy to create too much code, I think one of the bigger sources of debt we face as an industry is poorly fitting our tools to the tasks at hand. Sure, a SQL database is nice if you need to query the data in undefined ways in the future, but there's a vast set use-cases that won't benefit from all the features that come with it and could bankrupt you if you decide it needs to scale.
I wonder how many servers Company A and Company B are running.
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?
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.
One of the aphorisms I repeat a lot is that in this age where everybody programs a little, including analysts, devops, QA, researchers, etc., the thing that separates all of them from actual software developers is that developers know that "code is bad. Code is where I find all my bugs.
And I do wear these other hats sometimes. I think nothing of scripting a useful utility or cranking something out in R or VBA for a presentation. But when it comes to production code, I'll spend a lot of time trying to think of ways to reduce the amount of code required.
But it's two completely different philosophies regarding code, and unfortunately in some organizations AI is starting to blur the lines.
So many people are unable to imagine a future where any misunderstandings in execution by the programmer (AI in this case) can be more pleasantly and quickly solved by a conversation between product team / designer / QA and the AI-dev. There are systems in place to prevent junior devs from nuking your systems. Or senior disgruntled / insane devs from nuking your systems. This is why we have db backups, staging, etc. Programming uses a relatively limited vocabulary to talk about a relatively limited number of things. It will be better at the build-feedback-correct loop than 99% of devs. It will remember conversations, detail, everything basically. Just wait a few years. Lines of codes will be as irrelevant as #s of 0s and 1s.
> All other things being equal, less code is better. Put another way code is a form of debt. If you use an AI to generate code, you are effectively getting a debt – a debt of code.
This does have the implication baked in that AI will generate more code than people to do the same thing. Seeing as it had language features that not everyone knows about, alongside a bunch of algorithms and programming paradigms in the training data, sometimes the opposite will be true - the human code will be longer and therefore have more debt.
Of course, others also pointed out how you'd probably want to look at how complex or simple the code is, not just how long it is, but that's besides the point I'm making.
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?
Generated AI code is produced quickly, and might work. But there's no art. Nobody on your team wrote that code. There's no ownership, and nobody to ask about it.
The lack of knowledge about your own codebase will only go deeper and deeper until the debt is insurmountable and the organization can't function at all because it has no knowledgeable engineers.
There is only computer-generated code cobbled together into some kind of business solution.
1. Just because you use AI to write code does not imply there is more code. You can write concise code with AI, you just have to set yourself (and the AI / tools) up for it.
2. The opposite of debt is not value.
I agree that less code is (usually) better.
When it comes to AI folks are far too quick to use models / tools without properly understanding how to get the outcomes they want - then make blanket statements (or complain) when things don't go the direction they want.
All tools are not created equal, some are far more inclined to create an over-engineered mess (Kiro, Cursor). Using agentic coding tools like Cline or Claude Code with the right agent tools, rules and workflows you can achieve high quality outcomes.
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.
For some reason, people never seem to think about highly relevant questions such as "What is the minimum amount of code required to fully implement feature X?" Sure, it's an impossible question to answer accurately (in most cases) but it's useful to think about because it puts you in the correct mindset; it's worthwhile to approximate.
On the other hand, a lot of people do think about all sorts of almost irrelevant stuff like formal verification.
The thing that bugs me about formal verification is the fact that it's extremely wasteful and pointless when you haven't even thought about the answer to the first question.
People wrongly assume that all code which engineers produce is good code and serves a worthwhile purpose. This is very wrong. Most coders invent unnecessary abstractions all the time which create more work.
A lot of work in software engineering adds negative value. Sometimes it adds both negative and positive value so it's hard to tell.
35 comments
[ 4.4 ms ] story [ 53.3 ms ] threadThe balance sheet is always equal, so you always have as much liability as asset in amount. Despite the negative connotation of the word, some liabilities are good (earnings[1] is the best, equity and long term debt with low interest rate are nice too), but some are bad.
And it's the same for code, spitting more code to do the same thing is akin to emitting too many shares, having brittle code that needs constant intervention to keep working is akin to high interest debt.
[1] yes, your company's earning belong to the right side of its balance sheet.
Well, there is some dimension pertaining to how well the code is understood by the employees of Companies A & B.
The theoretical advantage of a smaller codebase is of scant practical value if that codebase cannot be maintained.
And maybe this point is captured by the "very similar companies" statement.
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.
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.
Company A uses a good framework that allows underlings to make for their middle managers reports which those middle managers use to demonstrate that their portion of the company is providing value. Upper management is well pleased, and refrains from laying off those productive portions.
Company B has no framework, and underlings cannot produce good reports for middle managers. Upper management fires at random, and great lamentations go up across the land.
More seriously: You can spend money to make money in the software world, and making a good abstraction is well worth the effort. There might just be a reason we us OSes these days instead of writing every application to sit directly on hardware. That might be the result of some actual thought.
I wonder how many servers Company A and Company B are running.
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?
A burden, a liability, a drag. But not debt.
That's not solid !
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.
And I do wear these other hats sometimes. I think nothing of scripting a useful utility or cranking something out in R or VBA for a presentation. But when it comes to production code, I'll spend a lot of time trying to think of ways to reduce the amount of code required.
But it's two completely different philosophies regarding code, and unfortunately in some organizations AI is starting to blur the lines.
This does have the implication baked in that AI will generate more code than people to do the same thing. Seeing as it had language features that not everyone knows about, alongside a bunch of algorithms and programming paradigms in the training data, sometimes the opposite will be true - the human code will be longer and therefore have more debt.
Of course, others also pointed out how you'd probably want to look at how complex or simple the code is, not just how long it is, but that's besides the point I'm making.
The lack of knowledge about your own codebase will only go deeper and deeper until the debt is insurmountable and the organization can't function at all because it has no knowledgeable engineers.
There is only computer-generated code cobbled together into some kind of business solution.
Maybe it's load-bearing and you need to change it?
1. Just because you use AI to write code does not imply there is more code. You can write concise code with AI, you just have to set yourself (and the AI / tools) up for it.
2. The opposite of debt is not value.
I agree that less code is (usually) better.
When it comes to AI folks are far too quick to use models / tools without properly understanding how to get the outcomes they want - then make blanket statements (or complain) when things don't go the direction they want.
All tools are not created equal, some are far more inclined to create an over-engineered mess (Kiro, Cursor). Using agentic coding tools like Cline or Claude Code with the right agent tools, rules and workflows you can achieve high quality outcomes.
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.
On the other hand, a lot of people do think about all sorts of almost irrelevant stuff like formal verification.
The thing that bugs me about formal verification is the fact that it's extremely wasteful and pointless when you haven't even thought about the answer to the first question.
People wrongly assume that all code which engineers produce is good code and serves a worthwhile purpose. This is very wrong. Most coders invent unnecessary abstractions all the time which create more work.
A lot of work in software engineering adds negative value. Sometimes it adds both negative and positive value so it's hard to tell.