> Code is not an asset it's a liability, and code that no one has reviewed is even more of a liability.

Code that solves problems and makes you money is by definition an asset. Whether or not the code in question does those things remains to be seen, but code is not strictly a liability or else no one would write it.

"Code is a liability. What the code does for you is an asset." as quoted from https://wiki.c2.com/?SoftwareAsLiability with Last edit December 17, 2013.

This discussion and distinction used to be well known, but I'm happy to help some people become "one of today's lucky 10,000" as quoted from https://xkcd.com/1053/ because it is indeed much more interesting than the alternative approach.

It’s well known and also wrong.

Delta’s airplanes also require a great deal of maintenance, and I’m sure they strive to have no more than are necessary for their objectives. But if you talk to one of Delta’s accountants, they will be happy to disabuse you of the notion that the planes are entered in the books as a liability.

You're hinting at the underlying problem with the quote. "Asset" in the quote reads, at least to me, in the financial or accounting meaning of the term. "Liability" reads, again to me, in the sense of potential risk rather than the financial meaning. Its apples and oranges.

Liability is also an economic term. As in, "The bank's assets (debt) are my liability, and my assets (house) are the bank's liability."

I don't think it's a wrong quote. Code's behavior is the asset, and code's source is the liability. You want to achieve maximum functionality for minimal source code investment.

Sorry, my point wasn't that liability doesn't have a meaning in finance. My read of the quote is that it uses liability in the sense of risk not debt on a balance sheet.

I could always be wrong though, that was just my interpretation of it. I don't get how code could be a liability in the financial sense, but I do get how every line of code risks bugs and other issues.

Sure, but all code is a potential future debt.

You wrote a music player that only allows one artist from list of all artists? Tech debt.

You wrote optimized assembly for x86_64? It's the year 2060, and we only support NGPU_ARM_N_LEG.

The moment your expectations change (which is all the time), your code needs to be changed, and effort isn't free.

Tech debt is not part of a financial account or disclosure though. Yes those are forms of debt, no they aren't financial debts or financial liabilities.

Sure it isn't. It is still a financial liability. You need to sacrifice time clearing it to get to work that actually pays the bills.

It's possible for something to be both an asset and a potential liability, it isn't strictly one or the other.

Delta leases a big portion of its fleet, which makes your example pretty bad.

Not a terrible example. The planes delta owns are delta’s assets; the planes the leasing company owns are the leasing company’s assets. The point is, the code and the planes are assets despite the maintenance required to keep them in revenue-generating state.

If Delta was going bankrupt it would likely be able to sell individual planes for the depreciated book value or close to it.

If a software company is going bankrupt, it’s very unlikely they will be able to sell code for individual apps and services they may have written for much at all, even if they might be able to sell the whole company for something.

The other half of the quote about liability is that the capabilities of the code are an asset. I don’t know if your bankrupt company would be able to sell their code, but they sure as hell couldn’t sell their capabilities without the code.

Whoa whoa whoa let's not bring the accountants in!

Code isn't a liability b/c it costs money (though it does). Code is a liability like an unsafe / unproven bridge is a liability. It works fine until it doesn't - and at that point you're in trouble. Just b/c you can build lots of bridges now, doesn't mean each new bridge isn't also a risk. But if you gotta get somewhere now, conjuring bridges might be the way to go. Doesn't make each bridge not a liability (risky thing to rely on) or an asset (thing you can sell, use to build value)

Even proven code is a liability. The point of it being a liability is that it costs time and effort to maintain and update.

The same with the bridge. Even the best built and most useful bridge requires maintenance. Assuming changing traffic patterns, it might equally require upgrades and changes.

The problem with this whole “code is a liability” thing is that it’s vacuous. Your house is a liability. The bridge that gets you to work as a liability. Everything that requires any sort of maintenance or effort or upkeep or other future cost is ina sense a liability. This isn’t some deep insight though. This is like saying your bones could break so they are liability. OK, but their value drastically outweighs any liability they impose.

If we're bringing in other industries, you'd be wise to consider banking. Savings accounts are something most people would consider an asset, because it's money the bank has on hand and can use for loan purposes.

But it's the opposite, deposits are liabilities because they need interest paid out and can be withdrawn at any time.

Just because the company has a thing that could be assigned value doesn't make it automatically an asset.

Code requires maintenance, which grows with codebase size, minus some decay over time. (LLMs do not change this, and might actually be more sensitive to this), So increasing code size, esp with new code, implies future costs, which meets the definition of a liability on a LOC kinda-sorta-basis.

It's not right but it's not wrong either. It at least was a useful way to think about code, and we'll see if that applies in LLM era.

Not a very valuable one. Never had been. That's the funny part. So many people want software but then don't know what to do once they have it.

Developers that can’t see the change are blind.

Just this week, sun-tue. I added a fully functional subscription model to an existing platform, build out a bulk async elasticjs indexing for a huge database and migrated a very large Wordpress website to NextJS. 2.5 days, would have cost me at least a month 2 years ago.

To me, this sounds like:

AI is helping me solve all the issues that using AI has caused.

Wordpress has a pretty good export and Markdown is widely supported. If you estimate 1 month of work to get that into NextJS, then maybe the latter is not a suitable choice.

To me, this sounds like:

If AI was good at a certain task then it was a bad task in the first place.

Which is just run of the mill dogmatic thinking.

it's wild that somehow with regards to AI conversations lately someone can say "I saved 3 months doing X" and someone can willfully and thoughtfully reply "No you didn't , you're wrong." without hesitation.

I feel bad for AI opponents mostly because it seems like the drive to be against the thing is stronger than the drive towards fact or even kindness.

My .02c: I am saving months of efforts using AI tools to fix old (PRE-AI, PREHISTORIC!) codebases that have literally zero AI technical debt associated to them.

I'm not going to bother with the charts & stats, you'll just have to trust me and my opinion like humans must do in lots of cases. I have lots of sharp knives in my kitchen, too -- but I don't want to have to go slice my hands on every one to prove to strangers that they are indeed sharp -- you'll just have to take my word.

Slice THEIR hands. They might say yours are rigged.

I'm a non dev and the things I'm building blow me away. I think many of these people criticizing are perhaps more on the execution side and have a legitimate craft they are protecting.

If you're more on the managerial side, and I'd say a trusting manager not a show me your work kind, then you're more likely to be open and results oriented.

From a developer POV, or at least my developer POV, less code is always better. The best code is no code at all.

I think getting results can be very easy, at first. But I force myself to not just spit out code, because I've been burned so, so, so many times by that.

As software grows, the complexity explodes. It's not linear like the growth of the software itself, it feels exponential. Adding one feature takes 100x the time it should because everything is just squished together and barely working. Poorly designed systems eventually bring velocity to a halt, and you can eventually reach a point where even the most trivial of changes are close to impossible.

That being said, there is value in throwaway code. After all, what is an Excel workbook if not throwaway code? But never let the throwaway become a product, or grow too big. Otherwise, you become a prisoner. That cheeky little Excel workbook can turn into a full-blown backend application sitting on a share drive, and it WILL take you a decade to migrate off of it.

You can use AI to simplify software stacks too, only your imagination limits you. How do you see things working with many less abstraction layers?

I remember coding BASIC with POKE/PEEK assembly inside it, same with Turbo Pascal with assembly (C/C++ has similar extern abilities). Perhaps you want no more web or UI (TUI?). Once you imagine what you are looking for, you can label it and go from there.

yeah AI is perfect at refactor and cleaning things up, you just have to instruct it. I've improved my code significanlty by asking it to clean up, refactor function to pure that I can use & test over a messy application. Without creating new bugs.

Holy hell, AI is not at all perfect at refactoring. Absolutely terrified on your behalf if you believe this to be the case.

I am a (very) senior dev with decades of experience. And I, too, am blown away by the massive productivity gains I get from the use of coding AIs.

Part of the craft of being a good developer is keeping up with current technology. I can't help thinking that those who oppose AI are not protecting legitimate craft, but are covering up their own laziness when it comes to keeping up. It seems utterly inconceivable to me that anyone who has kept up would oppose this technology.

There is a huge difference between vibe coding and responsible professional use of AI coding assistants (the principle one, of course, being that AI-generated code DOES get reviewed by a human).

But that, being said, I am enormously supportive of vibe coding by amateur developers. Vibe coding is empowering technology that puts programming power into the hands of amateur developers, allowing them to solve the problems that they face in their day-to-day work. Something that we've been working toward for decades! Will it be professional-quality code? No. Of course not. Will it do what it needs to do? Invariably, yes.

I think the issue is that most vibe coders believe it is professional quality code, or is sufficient moving forward.

It produces code (in the hands of an amateur) that is good enough for a demo or at best an MVP, but it’s not at all a stable foundation.

Just look at the METR study. All predictions were massive time savings but all observations were massive time losses. That's why we don't believe you when you say you saved time.

You should know better than to form a opinion from one study. I could show you endless examples of a study concluding untrue things, endless…

I’ve been full time (almost solo) building an ERP system for years and my development velocity has gone roughly 2x. The new features are of equal quality, everything is code reviewed, everything is done in my style, adhering to my architectural patterns. Not to mention I’ve managed to build a mobile app alongside my normal full time work, something I wouldn’t have even had the time to attempt to learn about without the use of agents.

So do you think I’m lying or do you just think my eyes are deceiving me somehow?

I think any measurement of development velocity is shaky, especially when measured between two different workflows, and especially when measured by the person doing the development.

Such an estimate is far less reliable than your eyes are.

So if people want to do more and better studies, that sounds great. But I have a good supply of salt for self-estimates. I'm listening to your input, but it's much easier for your self-assessment to have issues than you're implying.

Not saying you're wrong, but solo developers building (relatively) greenfield projects are the best bet for increased AI productivity.

Solo dev projects are usually reasonably sized (< million LOC), style is more uniform, there's fewer silos etc. etc.

Good studies look at a broader picture.

It’s a very good point. I have full control and everything is incredibly uniform, and more recently designed with agents in mind. This must make things significantly easier for the LLM.

It is wild. I must admit I have a bit of Gell Mann amnesia when it comes to HN comments. I often check them to see what people think about an article, but then every time the article touches on something I know deeply, I realize it’s all just know-it-all puffery. Then I forget and check it when it’s on the many things I do not know much about.

My cofounder is extremely technically competent, but all these people are like good luck with your spaghetti vibe code. It’s humorous.

You are assuming a lot of things.

The work was moving the many landing pages & content elements to NextJS, so we can test, iterate and develop faster. While having a more stable system. This was a 10 year old website, with a very large custom WordPress codebase and many plugins.

The content is still in WordPress backend & will be migrated in the second phase.

There is much going on in that exchange.

I don't even know what a Wordpress site is anymore.

> then maybe the latter is not a suitable choice.

But now it only takes days which makes it suitable?

There also is the paradoxical question if it is worth the time from someone who knows what they are doing? how would you even tell?

>Code is not an asset it's a liability

This would imply companies could delete all their code and do better, which doesn't seem true?

A more accurate description of code is that it’s a depreciating asset, perhaps, or an asset that requires maintenance cost. Neither of which is a liability