Code requires maintenance, so it's not an asset?

That makes little sense.

A lot of assets require regular maintenance to keep working well, but that doesn't make them a liability.

I think the main point (written again and again) is that more code = more liability, and since AI generates a lot of code, it generates a lot of liability. It might have been better to lean on the AI thing in the title.

But it's kind of a weird thing to say that code is not an asset unless you're leaning heavily into pulling that AI rant into the mix.

This isn't a particularly new idea. The main thing being that you should consider the amount of code written to achieve something to be part of the cost of having that capability, and minimizing that cost is valuable. The mark of an effective system to me is how much capability it gives its users for how much burden it places on those maintaining it, and burden correlates well with the amount of code in the system.

(This is mainly something that's useful to consider in organizations which a lot of programming resource, as a way to counter the tendancy for them to consider the amount of code they are producing as a measure of their productivity, when often they could be better served by reducing the amount of code they write and focusing on producing better code or even removing existing code. AI tends to make this problem worse, but it's not the original cause of it)

But that's literally not how assets or liabilities work, so it's a weird statement to make and an even weirder title for a post on essentially AI coding.

Sure, counting your productivity by lines of code is stupid, but that doesn't mean all code is liability. Good code and products are always assets and, like most assets, require maintenance to keep running.

You wouldn't call your car a liability just because you need to ensure it stays maintained. Why is it any different with code? Or machinery at a plant? Or jets owned by an airline?

I get the point they're trying to make, but it's very poorly made and uses broad metaphors that do not align with reality.

> You wouldn't call your car a liability just because you need to ensure it stays maintained. Why is it any different with code?

Wouldn't I? If I have to keep my car maintained, insured etc, but I don't get enough value out of it to offset that, then it's a liability.

The conceptual difference you can make with code is that code contains all the liability and none of the value. It is only in the capabilities of the system the code manifests that value is achieved. In the same way the perfect car simply teleports you to your destination without need to maintain all that metal and rubber, the most desirable software delivers behaviors without the need to maintain any code.

> Wouldn't I? If I have to keep my car maintained, insured etc, but I don't get enough value out of it to offset that, then it's a liability.

No you wouldn't and cannot legally or business-wise speaking.

> The conceptual difference you can make with code is that code contains all the liability and none of the value. It is only in the capabilities of the system the code manifests that value is achieved. In the same way the perfect car simply teleports you to your destination without need to maintain all that metal and rubber, the most desirable software delivers behaviors without the need to maintain any code.

Then make the point clearly. It is a conceptual decision to see the "capabilities of the system the code manifests" as different from the code that was written to do the same. I do not agree with the decision, since you're ignoring all the value the code provides and seeing it only as a liability.

The perfect car doesn't exist and neither does the perfect code. But that doesn't make them liabilities in any business/accounting/conceptual sense.

So, no, you cannot call a car you own a liability in the common sense of the word, but you may if you make a decision to do so within your own conceptual framework. But that is disconnected from reality.

There are two things being blurred together here that we need to separate:

1. Maintenance tasks needed to ensure continued original behavior and capability.

2. Renovations and alterations needed to maintain enough utility as environments and needs change.

A big truck that carries thousands of pounds of cargo is an asset, even if you have to replace the oil... But what happens when the water rises and you have to choose between junking it entirely versus welding on pontoons to make it float? Now all those strong welds of heavy steel start to seem like a liability.

Trucks mainly have problem #1, while software mainly has problem #2.

But in your example, the big truck is still an asset in all real sense of the word. If you have to junk it, you will write down that asset, but it doesn't magically become a liability just because you said so. Simillarly the new truck you get that can operate in that environment is also an asset, not a liability.

Counter example: you can modify the truck to operate in that environment by adding extra stuff to it instead of junking it completely. The cost of doing that is an expense and the truck's asset value goes up based on that cost. The truck always remains an asset.

If we want to just throw words around then yeah everything can be a liability and everything can be an asset based on how you think but then nothing means anything and your metaphor doesn't work.

Some of the analogies are a bit strained, but I'm in agreement.

Every line of code is technical debt - all of it. The engineering responsibility is to minimize the rate you pay on the debt, and to make its eventual renegotiation cheaper.

It's a liability management exercise that goes on as long as you want to use your system as a working asset.

Bang on. We'll start seeing the AI story become increasingly about addressing this particular issue in the coming year. I expect the mainstream talking point will be around codebases that can be rewritten instantly when the world changes under them, thus making code ephemeral and not a liability.