Code Is Debt(tornikeo.com)
tornikeo.com
Code Is Debt
https://tornikeo.com/code-is-debt/
74 comments
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.
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.
[0] https://en.wikipedia.org/wiki/Cyclomatic_complexity
[1] https://littlegreenviper.com/swiftlint/
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/
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.
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.
Why Can't We Make Simple Software?
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
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
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.
> Code is an asset.
Funnily enough, this doesn't contradict "code is debt" because Asset = Equity + Liability.
Funnily enough, this doesn't contradict "code is debt" because Asset = Equity + Liability.
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.
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.
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.
Lovely. Now, what's missing?
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.
https://git.distrust.co/public/nit
https://git.distrust.co/public/nit
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.
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.
This, there is always middle ground.
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.
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.
> I think you've actually lost that time in the first case.
And in the second case, as opposed to the middle ground.
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.
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”.
That gave me an idea. Is it possible to ask an AI what a variable/function does in a piece of code? I've only ever used them for generation.
Absolutely, it’s a great use of the tools. I use it to explain unfamiliar idioms or large functions on a regular basis.
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.
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.
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.
I do this literally every day when I'm debugging, understanding a new system, or planning my work.
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.
Absolutely, came here to say this.
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.
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]
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.
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.
Of course, the one and only perfect repo: https://github.com/kelseyhightower/nocode
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?
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?
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.
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.
Conversations are debt. They become ideas and eventually more work
Not when they lead to ways of refactoring code to make it easier to maintain, or reasons for not adding a particular feature.
Even then! I've gone to regret even the most productive conversations; junky wants another fix. Now they know you're selling.
Nice to be needed, yes. Peace is also nice
Nice to be needed, yes. Peace is also nice
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.
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.
> 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.
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.
> Clearly, the company with fewer lines of code is better off.
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.
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.
> 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.
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.
Two things:
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.
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.
I don't understand, are you saying:
1) you dont need AI to generate code because you dont need any code at all? If you dont need any code then this discussion is useless.
2) AI generates more and worse code. Well, if you start with this assumption of course the conclusion is dont use AI. But then this is a big assumption to make, you dont back it up with anything and you dont even mention this at all.
Lets consider other things:
1) AI will generate less and better code that you would. Shouldnt you use it?
2) AI will generate code the same quality as you would but in 50% less time. Shouldnt you use it too?
1) you dont need AI to generate code because you dont need any code at all? If you dont need any code then this discussion is useless.
2) AI generates more and worse code. Well, if you start with this assumption of course the conclusion is dont use AI. But then this is a big assumption to make, you dont back it up with anything and you dont even mention this at all.
Lets consider other things:
1) AI will generate less and better code that you would. Shouldnt you use it?
2) AI will generate code the same quality as you would but in 50% less time. Shouldnt you use it too?
> Clearly, the company with fewer lines of code is better off.
Fewer lines of code are better if functionality is constant. But that doesn’t make code debt. By that logic, factories, employees, equipment, processes, and policies would also be debt — since fewer of them would likewise be better if revenue stayed constant.
Code is fundamentally an asset: it generates revenue, scales with near-zero marginal cost, and embodies intellectual property. Like any asset, it carries liabilities. Well-designed and reliable code behaves like a productive factory; buggy or hard-to-maintain code behaves like debt, draining resources instead of producing returns.
Fewer lines of code are better if functionality is constant. But that doesn’t make code debt. By that logic, factories, employees, equipment, processes, and policies would also be debt — since fewer of them would likewise be better if revenue stayed constant.
Code is fundamentally an asset: it generates revenue, scales with near-zero marginal cost, and embodies intellectual property. Like any asset, it carries liabilities. Well-designed and reliable code behaves like a productive factory; buggy or hard-to-maintain code behaves like debt, draining resources instead of producing returns.
Exactly, this blog post is grossly oversimplifying, and maybe we are meant to “get the idea” but I think that even if it’s intentionally oversimplified it needs to address the elephants in the room.
Is longer code more “debt” if it’s more readable and more verbose? I could save lines of code by messing ternary operators, shortening variable names, using obscure language-specific features, or stuffing complicated expressions into one-liners.
Is longer code more “debt” if it’s more extensible and flexible for future growth and change?
Is longer code more “debt” if it has more test coverage? This is especially relevant to the article because AI is generally great at assisting with writing tests especially when the alternative is engineers not doing it.
We can’t just say “all else being equal” because that’s not how life works.
Is longer code more “debt” if it’s more readable and more verbose? I could save lines of code by messing ternary operators, shortening variable names, using obscure language-specific features, or stuffing complicated expressions into one-liners.
Is longer code more “debt” if it’s more extensible and flexible for future growth and change?
Is longer code more “debt” if it has more test coverage? This is especially relevant to the article because AI is generally great at assisting with writing tests especially when the alternative is engineers not doing it.
We can’t just say “all else being equal” because that’s not how life works.
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.
I wonder how many servers Company A and Company B are running.
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.
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.
Reminds me of every time I run npm install.
Before that, reminds me of when people talked about monkey patching RoR.
Seems like the general trend in programming since the beginning, when asked "Cheap, Fast, Good", the winners are always cheap and fast. Regular people have a hard time conceptualizing something they can not see.
Before that, reminds me of when people talked about monkey patching RoR.
Seems like the general trend in programming since the beginning, when asked "Cheap, Fast, Good", the winners are always cheap and fast. Regular people have a hard time conceptualizing something they can not see.
Yes, time spent writing code is often a worthwhile investment of time into understanding that code, which you need to do anyway.
But only for the person writing it. And only for some amount of time.
Other than that, clean code that is easy to read and understand is way more important.
Other than that, clean code that is easy to read and understand is way more important.
In a lot of cases, code is debt because modern platforms don't give a crap about backwards compatibility. There is no reason some simple apps cannot just be "finished". The only reason they need constant maintenance is that the platforms they run on keep changing things and breaking them.
The idea here is right, but the word "debt" is not the right word at all.
A burden, a liability, a drag. But not debt.
A burden, a liability, a drag. But not debt.
I think its better to argue in terms of lines-of-code "spent" not produced. Ultimately its about solving the business problem. Its not perfect but it should balance out the urge to write as much code as possible.
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.
How long are those conversations between team designer and QA? How many seemingly trivial details have to be discussed over and over because addressing one of them creates an inconsistency in the others? I think this is the debt that can usually be estimated by lines of code.
It is a lot easier for one unified ML model to remember all the conversations as opposed to a team of engineers who may not communicate with each other anywhere nearing perfect accuracy.
Code that you can throw out at any time seems unlike debt? If you're in a hole, it must somehow arise from your attachment to it.
Maybe it's load-bearing and you need to change it?
Maybe it's load-bearing and you need to change it?
Having the debt doesn’t imply it has value. Debt is risk. Removing that old code also has risk. While it may not actually do anything anymore, can anyone say that with 100% certainty? At some point, you do all the checks you can, then delete it and hope nothing unexpected breaks.
The easy case is when you can statically determine that a function has no callers and can therefore safely delete it. So it seems like risk comes from usage, or uncertainty about usage.
Just last week I was cleaning things up an Ansible repo and found a role to manage a dead product which wasn't called anywhere. However, the role contained a vars file that set a half dozen variables. Someone included that single file from the role somewhere else to set one or two variables they needed for something else that was largely unrelated.
In theory, we should have been able to delete that role without much thought, but without any extra layer of validation and some code updates, it still would have broken things.
The uncertainty is where most of the risk lies, especially when some people do odd things like this.
In theory, we should have been able to delete that role without much thought, but without any extra layer of validation and some code updates, it still would have broken things.
The uncertainty is where most of the risk lies, especially when some people do odd things like this.
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.
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.
I feel like this post might be a bit clickbaity. It presents a strong statement without much context, analysis or evidence.
> They have fewer lines of code and so they can understand and modify their code more quickly.
That's not solid !
That's not solid !
Code is an asset of different levels of quality and importance.
Code is debt when humans manage it. It may not be debt when AI's do it.
It’s a 100% liability when AI manages it.
>Code is debt when humans manage it. It may not be debt when AI's do it.
It may be more so as AI has a specific context window and each token counts.
It may be more so as AI has a specific context window and each token counts.
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.
I suspect that this depends on what the code does and where it lives. E.g. some unmaintainable web frontends can be simply discarded and get redesigned and rewritten rather than fixed.
No thanks.
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.”