Code was malleable only to a developer with great code comprehension. In my experience, this was actually very rare. I think part of the reason is, you don't get any recognition for modifying a few lines of someone else's code compared to "I created this new library/app to solve this problem for our org!".

I think you may be misunderstanding.

The point is that previously, changing code in a major way might take months of refactoring. Large changes were simply not contemplated unless they were justified by similarly large additional profit. Once you designed your architecture, you were pretty much stuck with it.

Now, the kinds of changes that were simply unrealistic before are now entirely realistic. A refactor/migration that would have taken 6 months before, you can now get a working version done in a day, and another few days of QA. That's what this post means -- code is no longer stone, it's clay. You can change it quickly in ways that were previous unimaginable.

This has nothing to do with the concept of code being liability or asset -- that's a totally separate conversation.

> Code always was, it's supposed to be malleable

Yes, well-designed code is malleable to an extent when coding by hand, but even then it's an order of magnitude more rigid than when working with agents (and real-world code often ossifies, as you pointed out). Malleability comes not only from the possibility of change but also from the speed.

> It's the data you generate with that code that's your asset. You can always rewrite the code.

I like that perspective, but "you can always rewrite the code" almost never happens in real life for complex projects, and when it does, it's a huge undertaking that takes many months or even years. Malleable code makes that much more feasible, I'd argue.

> Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by the exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.... https://home.adelphi.edu/sbloch/class/adages/joy.html

Dependency is a cause of ossification.

> AI does not solve this problem

AI absolutely solves that problem. Just about every prompt "fixes" the dried out pieces of the code. And it's only getting better at that every month.

Sometimes I feel like people are experiencing AI so differently that it makes talking about it nearly impossible.

Truly spoken as someone who has never worked with legacy code. You know, the kind that's still running Java 1.something when Java was already doing full numbered releases.

The kind that works, but everyone who knows why has left the company. The whole codebase is written in a way that makes automated testing either impossible or so time-consuming that the client will never pay for the required refactoring.

There is way too much code in the world we never were able to rewrite due to real-world concerns. There were people who had the skill, but a part of that skill came with knowing the risks of doing major refactoring to a money-generating system that is ancient, but still works.

Anecdote: I had to work with a system where the original coder (long gone) had rewritten Linked Lists with their custom solution that worked normally except the first X items were the sum, average and mean of the data. Fun times.

> I fully expect to see situations where AI generated code becomes so hard to work with that even LLMs prefer to throw it away and start fresh again.

You know, I've never thought about that. It's really interesting to consider, especially since refactoring code is now cheaper than ever.

It's literally called _soft_ware (vs. hardware).

> It's the data you generate with that code that's your asset.

Not sure what kind of data this refers to?

> code is a liability, not an asset

This is not the case as far as accounting and the law is concerned.

[dead]