Hacker News Reader

Comment by frevib | Hacker News Reader

Code is a liability. Saying no is because the engineer wants to reduce complexity, not because she/ he is so subjectively “obsessed” with code quality. The term “quality” is nowadays misunderstood by management. It means the right amount of effort to build the product as fast and for as low as cost possible, taking into account a team of engineers that can easily add and modify code.

This description is the better one: https://www.nair.sh/guides-and-opinions/communicating-your-e...

View on HN

"quality" isn't succinctly definable. Zen and the art of system maintenance quality code is written by an old and wise programmer and any attempt to rigidly codify what it is they did and why is doomed to fail.

And in the agentic world, that liability is both minimized and amplified. Teams that successfully mitigate AI risks will be able to churn out massive amounts of sustainable code.

[flagged]

Thank you. I was about to reply the same comment but I couldn't say it as concisely.

The funny part is some top comments are saying this article is straw man and the rest of them are just proving the archetype is very real.

Nah man. You got to say "no" a lot. Even in the age of AI. Often times features downright make no sense, the time to implement can span weeks and it would actively damage the product in the long term. I work in a ecom startup and I got to say no so many times due to added complexity for little reward.

I think saying no is more important now with AI, as features can be built so quickly now. But there are a lot more costs after the feature has been built. Mostly with AI the code isn’t understood that well, wich incurs a cognitive debt. Then there are extra maintentance and documentation costs. And the costs of carrying around features that add no value.

I can imagine that if you’re a startup and want to try new features quickly, it makes sense to say yes more. But the senior mentioned in the article will also be able to understand that.

You got all that from four words?

Also what's wrong with "code is a liability"? That's just 100 % true. The idea isn't exactly novel or revealing, but it's also really fundamental. Every line of code is a liability from day one.

The comment you replied to used that as a reminder and as an opening to an actual argument, it wasn't just a knee-jerk reaction.

Code is an asset.

Code that enables a company to generate revenue is an asset.

Code is an asset.

Code that can be sold for more than it cost to generate is an asset.

That's an oversimplification. Asset vs liability isn't a binary state but a superposition. An asset can carry liabilities.

Your asset might generate $10k a month in revenue, but at the same time may have a high chance of needing a $100k investment in upgrades and repairs to remain productive.

A building is an immovable asset. It’s also made of things that wear and tear. Its value is derived from its capability to house and the capability to house something extends beyond four walls and a roof.

The asset has inherent liabilities. A codebase can be reasoned about extremely similarly

Note how the longer sentences are significantly stricter than the shorter ones. You could maybe add another condition, in the sense that the code has to generate more revenue than it costs to maintain. Then I'd start to agree.

Also note that even when a line of code is generating revenue, it never stops being a liability in almost every sense of the word. Testing it still costs money and time, understanding it costs cognitive power, having it in the context of your LLM coding agent costs tokens, and that's assuming it's a good line of code. If it's bad code (badly named, badly placed, a logic chain that works but has hidden flaws), the costs increase and reverberate throughout the codebase (and your AI coding sessions).

Yep, that was pretty much the point of my comment.

Code is a liability - yes with an and / no with a but.

I’m sure volumes have been written amount, and there’s roughly an infinite amount of nuance to be talked about over a few drinks and a smoke.

Production code is an asset, its maintenance and obligations are an expense, its risks might become liabilities, and companies shouldn't run more code than they need for the same reason they shouldn't own a larger vehicle fleet or more spare warehouse capacity than they need.

I don't think most engineers really disagree with this. Saying code is a liability is technically incorrect but pithy shorthand to communicate that it comes with the associated baggage of maintenance, obligation, and risk; these things suck up money the same way a liability does. Tech debt is also not real debt. It's a figure of speech.

Please don't cross into personal attack on HN. You can make your substantive points without that.

https://news.ycombinator.com/newsguidelines.html

p.s. We've had to ask you this before: https://news.ycombinator.com/item?id=47103856. If you'd please review the guidelines and take the intended spirit of the site to heart, we'd be grateful.

Are you nitpicking that with the right achitecture and safeguards, unaccountable lines of code are perfectly harmless?

Because I think in most regular situations, code-without-adjectives, uncertain commits, or any number of things might be rightfully justified as a literal legal liability for business cases.

I get that you don't like how flat it is, but on a business website, in a world forecasted to be full of black box code, the statement is correct.

Code in a vacuum may not be a personal liability, but it is a professional one in 2026 where there's a gulf between slop and secure code

Reply on news.ycombinator.com