Code always was, it's supposed to be malleable. It's why it's long been said that code is a liability, not an asset. It's the data you generate with that code that's your asset. You can always rewrite the code.
We, in general, are just very bad at letting code ossify, or for this metaphor, dry out and crumble. AI does not solve this problem and 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.
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!".
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.
I was watching the most recent Rich Hickey talk[0] and at the start, he talks about correctness and the difference between the internal machinery of your software (which can be finely specified) and handling the external world (which will always be messy).
Good Architecture will try to isolate the two. You got the internal logic which is either the business domain abstracted away. And you got the highly volatile part (request from frontend, new integration, new drivers, deps update,....).
If you've done that, migration/refactoring, unless it entails some unlikely core changes, will not take that long. It's just a matter of dropping that part and replacing it (like changing a car's brake pads or steering wheel). But the actual core mechanism will hardly change over the years.
To go with the thread flow: It's a stone core wrapped by clay.
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
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.
Maybe, but I think one of the points is that the marginal cost of both understanding that legacy code base and safely refactoring it are increasingly trending down thanks to agentic coding tools. It changed the value and risk tradeoff for legacy apps, if deployed properly. There's still a lot of work (too much) to get the harness in place to make high confidence changes to legacy, critical apps. If someone makes that more automated, we'll be in a very different place for legacy refactoring and it will look a lot more like the clay molding the article discusses.
As with anything LLM-related, I feel compelled to ask, is that actually what's happening, or are they just successfully convincing their users that's what's happening? I truly cannot tell.
I'm not using any LLMs directly (my workplace still bans them in-house) and my experience on the receiving end of contractors using them is quite poor. That includes one major, "we'll replace your ancient software with shiny new stuff"... with significantly reduced capability that in turn makes everything far more difficult than it was or ought to be. The UI appears much more user friendly, but really is just broken in multiple ways where the much-patched 1980s software it replaced was user-unfriendly but largely worked.
This all could be the result of poor coding, regardless of LLM use, of course.
Fun facts, Abrahamic religions that are based on the Bible and Quran both claiming human are made from clay [1],[2].
In Hebrew name Adam, the very first human, comes from the word adamah, which means "ground," "soil," or "red clay".
In Arabic Adam, comes from the word adeem, means the surface of the earth or dust, reflecting the Islamic and Abrahamic tradition that Adam was created from the clay or dust of the ground.
By extension in Hebrew and Arabic the word Adam also means mankind and humanity.
In Chinese mythology, human beings were also created from clay. The goddess Nüwa first came to an empty river bank and spent much time carefully crafting a set of figures, then got tired, and rushed together a bunch of clay piles using a length of corded rope. The first group of clay figures were the nobility, while the latter were the commoners.
Very cool, thanks for that. I was vaguely aware that clay metaphors were important in several religions, and I thought about looking into it and maybe finding a nice quote for the article, but didn't have the time (I accept suggestions, though!)
Author here. No analogy is perfect, but this is how working with code has felt for me for a while, so I wanted to write down my thoughts about it.
I wrote this a couple of months ago, and everything moves so fast nowadays that the concept of factories is already being blurred as harnesses get better and require less tooling around them. I still think that the distinction between wanting to be in the loop vs automated out from it holds up, though.
There are other interesting aspects of malleable code that I don't explore in the article, for example:
- Ownership. People feel less attached to their code, which has both good and bad consequences (e.g. fewer ego battles but less accountability).
- Malleable software that adapt to users. Huge topic, many interesting questions to explore.
- Assets in code. Things like (some) 3D graphics and animations can now be done entirely in code. Before they were very tedious to code and tweak.
- Collaboration dynamics. Instead of high-frequency alignment (discussions, meetings) to make sure every detail is clear before the implementation, it might be more efficient to go ahead with educated guesses and align later over a working build.
What it boils down to is that the future of coding is more about creating the mold where the code is poured in and knowing how exact of a mold is "good enough" for the problem at hand.
When the mold is done, you let the agent pour in the code in any format you like. It can create a Swift version, Rust version and a web assembly version in "half a soda" as you put it =)
The people for whom the only enjoyment in programming was molding the perfect item from scratch will still be needed, but less and less as we get better and faster in defining the molds for the agent to pour the code in.
Before I had to dig specs of an application out of a client's mind and try to form them into software with a full-ass team. Now we can pretty much "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP but in more cases is just an interactive UI spec we can use as a reference to build the actual tool.
> When the mold is done, you let the agent pour in the code in any format you like.
Exactly. And the mold could be a spec, an MVP or even one of the implementations (e.g. the Swift one) acting as the source of truth for the other versions.
> "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP but in more cases is just an interactive UI spec
That's a great example of what malleable code unlocks. You let the client to create the mold themselves, refine it and then use it to properly build the product.
This analogy is apt for working with LLMs. Were you aware, tho, that it has repeatedly been used to describe Lisp?
I think Lisp is an ideal language to use with an LLM, because it is essentially a notation for a logical assembly code, and I expect there to be compound benefits in using it with AI.
Lisp [...] made me aware that software could be close to executable mathematics.
— ACM Fellow Profile of L. Peter Deutsch.
APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way — even by adding another diamond — you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it [...] and it still looks like a ball of mud!
— R1RS (1978) page 29, paraphrasing remarks attributed to Joel Moses.
Part of the beauty of the ball-of-mud quote is that there really does seem to be a causal connection between Lisp's use of generic, unencapsulated, largely un-type-checked data structures and its extensibility. The converse implication is that we should expect specialization, encapsulation, and aggressive type-checking of data structures — all strategies extensively pursued in various combinations in modern language paradigms — each to retard language extension.
Each of these three characteristics of Lisp serves to remove some kind of automated restriction on program form, leaving the programmer more responsible for judging what is appropriate — and thereby shifting things away from close conversation with the machine, enabling (though perhaps not actively encouraging) more human engagement. The downside of this is likely obvious to programming veterans: it leaves things more open to human fallibility. Lisp has a reputation as a language for good programmers. (As a remark attributed to Dino Dai Zovi puts it, "We all know that Lisp is the best language around, but in the hands of most it becomes like that scene in Fantasia when Mickey Mouse gets the wand.")
LISP is extensible in two ways. First, there is the simple ability to define new functions; these are used in a way that is both syntactically and semantically identical to built-in primitive functions like CAR. This is in contrast to “algebraic” programming languages, which either make an arbitrary syntactic distinction between addition, say, and a user function, or wander into the quagmire of extensible parsers. Second, there is a uniform macro facility for transforming one syntactic form into another; this facility is based on internal data structures rather than external character-string syntax.
I look forward to the day when the broader industry realizes code was never a bottleneck, and you still have to answer to the market to make money.
This piece, while valid, puts way too much emphasis on code. I don’t want to dismiss the author, but they’ve yet to see how little of a shit the business gives about code. This has been perennial.
Some development houses have always done sketches, proof of concepts or prototypes. Not because code was expensive or inmalleable, but because they didn’t know what would be a success. Even if it did not take forever to build the thing. If I told you what the perfect product was and how to make a boatload of money, you’d be ready with an army of programmers. But life and business rarely work out that way.
So you've NEVER had a sketch, proof of concept or prototype end up being a part of the final product? Now you're stuck with a piece of crap that was implemented expecting to be thrown away, but then because of time and money constraints it's now a load-bearing (heh) part of the application.
It also takes more time for humans to build prototypes and PoCs than doing the same with an agent. Iteration speed and time-to-market matters more and more (case in point: mobile games).
Everyone is saying this about "the factory." I have seen some successful fix and migrate campaigns for well-defined, local transformations such as retroactive fixes for new lint rules, flaky tests, or library migrations. But so far the attempts to do nontrivial new functionality in this manner have made big messes that take more effort to review and correct than simply hand-feeding 1-3 vanilla Claude Code sessions with my full attention.
Agreed, clay/modeling it is a good analogy. I keep trying to describe the level I work at now (if only to myself) and all I could conjure was shaping the product at a higher level with less control overall (unless you want to drop down and do some "detail work") but the ability to make sweeping changes much easier.
I prefer the 'code is legos' metaphor. Well defined interfaces that hurt like hell if you step on them. You get a practically indestructible chunk that is simple by itself but can be composed to extreme complexity. Parts can be used in many different contexts and new parts are constructed when required. I think AI actually increases the need for this kind of construction.
That's a fascinating topic. I'm curious about how do you approach it... like can the user-facing AI change any part of the code? Or is it constrained to a set of predefined components/plugin layer/etc.?
So I have the app deployed to railway with a Postgres database. I give the customer an agent that has the railway skill and basically access to that customers project on railway and they can talk to the agent and it can communicate with app, change the code deploy it again, do migrations.
Code always was, it's supposed to be malleable. It's why it's long been said that code is a liability, not an asset. It's the data you generate with that code that's your asset. You can always rewrite the code.
We, in general, are just very bad at letting code ossify, or for this metaphor, dry out and crumble. AI does not solve this problem and 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.
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!".
> Code was malleable only to a developer with great code comprehension
This used to be what being a dev was, if I recall. It's been a few years.
Sure, but it was certainly a difference between those projects you authored and those you inherited, at least in time-to-productiveness.
The ability to understand and maintain inherited projects is more valuable than the ability to create new greenfield projects.
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.
I was watching the most recent Rich Hickey talk[0] and at the start, he talks about correctness and the difference between the internal machinery of your software (which can be finely specified) and handling the external world (which will always be messy).
Good Architecture will try to isolate the two. You got the internal logic which is either the business domain abstracted away. And you got the highly volatile part (request from frontend, new integration, new drivers, deps update,....).
If you've done that, migration/refactoring, unless it entails some unlikely core changes, will not take that long. It's just a matter of dropping that part and replacing it (like changing a car's brake pads or steering wheel). But the actual core mechanism will hardly change over the years.
To go with the thread flow: It's a stone core wrapped by clay.
[0]: https://www.youtube.com/watch?v=P5eO7BNyJao
> 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.
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.
Maybe, but I think one of the points is that the marginal cost of both understanding that legacy code base and safely refactoring it are increasingly trending down thanks to agentic coding tools. It changed the value and risk tradeoff for legacy apps, if deployed properly. There's still a lot of work (too much) to get the harness in place to make high confidence changes to legacy, critical apps. If someone makes that more automated, we'll be in a very different place for legacy refactoring and it will look a lot more like the clay molding the article discusses.
As with anything LLM-related, I feel compelled to ask, is that actually what's happening, or are they just successfully convincing their users that's what's happening? I truly cannot tell.
I'm not using any LLMs directly (my workplace still bans them in-house) and my experience on the receiving end of contractors using them is quite poor. That includes one major, "we'll replace your ancient software with shiny new stuff"... with significantly reduced capability that in turn makes everything far more difficult than it was or ought to be. The UI appears much more user friendly, but really is just broken in multiple ways where the much-patched 1980s software it replaced was user-unfriendly but largely worked.
This all could be the result of poor coding, regardless of LLM use, of course.
> 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.
> code is a liability, not an asset
This is not the case as far as accounting and the law is concerned.
Very apt comparison and analogy.
Fun facts, Abrahamic religions that are based on the Bible and Quran both claiming human are made from clay [1],[2].
In Hebrew name Adam, the very first human, comes from the word adamah, which means "ground," "soil," or "red clay".
In Arabic Adam, comes from the word adeem, means the surface of the earth or dust, reflecting the Islamic and Abrahamic tradition that Adam was created from the clay or dust of the ground.
By extension in Hebrew and Arabic the word Adam also means mankind and humanity.
[1] Genesis 2:7:
https://www.biblegateway.com/passage/?search=Genesis%202%3A7...
[2] Quran 7:12:
https://quran.com/al-araf/12
In Chinese mythology, human beings were also created from clay. The goddess Nüwa first came to an empty river bank and spent much time carefully crafting a set of figures, then got tired, and rushed together a bunch of clay piles using a length of corded rope. The first group of clay figures were the nobility, while the latter were the commoners.
interesting, wonder which class promulgated that myth
Very broad in fact. The greeks and more had myths of creation from clay.
https://en.wikipedia.org/wiki/Creation_of_life_from_clay
Very cool, thanks for that. I was vaguely aware that clay metaphors were important in several religions, and I thought about looking into it and maybe finding a nice quote for the article, but didn't have the time (I accept suggestions, though!)
Author here. No analogy is perfect, but this is how working with code has felt for me for a while, so I wanted to write down my thoughts about it.
I wrote this a couple of months ago, and everything moves so fast nowadays that the concept of factories is already being blurred as harnesses get better and require less tooling around them. I still think that the distinction between wanting to be in the loop vs automated out from it holds up, though.
There are other interesting aspects of malleable code that I don't explore in the article, for example:
- Ownership. People feel less attached to their code, which has both good and bad consequences (e.g. fewer ego battles but less accountability).
- Malleable software that adapt to users. Huge topic, many interesting questions to explore.
- Assets in code. Things like (some) 3D graphics and animations can now be done entirely in code. Before they were very tedious to code and tweak.
- Collaboration dynamics. Instead of high-frequency alignment (discussions, meetings) to make sure every detail is clear before the implementation, it might be more efficient to go ahead with educated guesses and align later over a working build.
I've came up with the same basic analogy as you.
What it boils down to is that the future of coding is more about creating the mold where the code is poured in and knowing how exact of a mold is "good enough" for the problem at hand.
When the mold is done, you let the agent pour in the code in any format you like. It can create a Swift version, Rust version and a web assembly version in "half a soda" as you put it =)
The people for whom the only enjoyment in programming was molding the perfect item from scratch will still be needed, but less and less as we get better and faster in defining the molds for the agent to pour the code in.
Before I had to dig specs of an application out of a client's mind and try to form them into software with a full-ass team. Now we can pretty much "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP but in more cases is just an interactive UI spec we can use as a reference to build the actual tool.
> When the mold is done, you let the agent pour in the code in any format you like.
Exactly. And the mold could be a spec, an MVP or even one of the implementations (e.g. the Swift one) acting as the source of truth for the other versions.
> "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP but in more cases is just an interactive UI spec
That's a great example of what malleable code unlocks. You let the client to create the mold themselves, refine it and then use it to properly build the product.
Related:
Malleable Systems Collective
https://news.ycombinator.com/item?id=50188437
This analogy is apt for working with LLMs. Were you aware, tho, that it has repeatedly been used to describe Lisp?
I think Lisp is an ideal language to use with an LLM, because it is essentially a notation for a logical assembly code, and I expect there to be compound benefits in using it with AI.
Lisp [...] made me aware that software could be close to executable mathematics.
— ACM Fellow Profile of L. Peter Deutsch.
APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way — even by adding another diamond — you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it [...] and it still looks like a ball of mud!
— R1RS (1978) page 29, paraphrasing remarks attributed to Joel Moses.
Part of the beauty of the ball-of-mud quote is that there really does seem to be a causal connection between Lisp's use of generic, unencapsulated, largely un-type-checked data structures and its extensibility. The converse implication is that we should expect specialization, encapsulation, and aggressive type-checking of data structures — all strategies extensively pursued in various combinations in modern language paradigms — each to retard language extension.
Each of these three characteristics of Lisp serves to remove some kind of automated restriction on program form, leaving the programmer more responsible for judging what is appropriate — and thereby shifting things away from close conversation with the machine, enabling (though perhaps not actively encouraging) more human engagement. The downside of this is likely obvious to programming veterans: it leaves things more open to human fallibility. Lisp has a reputation as a language for good programmers. (As a remark attributed to Dino Dai Zovi puts it, "We all know that Lisp is the best language around, but in the hands of most it becomes like that scene in Fantasia when Mickey Mouse gets the wand.")
Lisp, Mud, and Wikis
https://fexpr.blogspot.com/2018/10/lisp-mud-and-wikis.html#s...
{LISP Is a Ball of Mud}
LISP is extensible in two ways. First, there is the simple ability to define new functions; these are used in a way that is both syntactically and semantically identical to built-in primitive functions like CAR. This is in contrast to “algebraic” programming languages, which either make an arbitrary syntactic distinction between addition, say, and a user function, or wander into the quagmire of extensible parsers. Second, there is a uniform macro facility for transforming one syntactic form into another; this facility is based on internal data structures rather than external character-string syntax.
The Revised Report on Scheme
https://research.scheme.org/lambda-papers/lambda-papers-revi...
https://wiki.c2.com/?HackerLanguage
Also:
Lisp is Clay: The Power of Composable DSLs (video)
https://archive.fosdem.org/2026/schedule/event/HDE7JZ-lisp-i...
I look forward to the day when the broader industry realizes code was never a bottleneck, and you still have to answer to the market to make money.
This piece, while valid, puts way too much emphasis on code. I don’t want to dismiss the author, but they’ve yet to see how little of a shit the business gives about code. This has been perennial.
Some development houses have always done sketches, proof of concepts or prototypes. Not because code was expensive or inmalleable, but because they didn’t know what would be a success. Even if it did not take forever to build the thing. If I told you what the perfect product was and how to make a boatload of money, you’d be ready with an army of programmers. But life and business rarely work out that way.
So you've NEVER had a sketch, proof of concept or prototype end up being a part of the final product? Now you're stuck with a piece of crap that was implemented expecting to be thrown away, but then because of time and money constraints it's now a load-bearing (heh) part of the application.
It also takes more time for humans to build prototypes and PoCs than doing the same with an agent. Iteration speed and time-to-market matters more and more (case in point: mobile games).
Everyone is saying this about "the factory." I have seen some successful fix and migrate campaigns for well-defined, local transformations such as retroactive fixes for new lint rules, flaky tests, or library migrations. But so far the attempts to do nontrivial new functionality in this manner have made big messes that take more effort to review and correct than simply hand-feeding 1-3 vanilla Claude Code sessions with my full attention.
Agreed, clay/modeling it is a good analogy. I keep trying to describe the level I work at now (if only to myself) and all I could conjure was shaping the product at a higher level with less control overall (unless you want to drop down and do some "detail work") but the ability to make sweeping changes much easier.
> we coder-stonemasons spent our days meticulously carving code-stone into finished pieces
In what world this was ever true ? a software or a lib is pretty much never finished
I prefer the 'code is legos' metaphor. Well defined interfaces that hurt like hell if you step on them. You get a practically indestructible chunk that is simple by itself but can be composed to extreme complexity. Parts can be used in many different contexts and new parts are constructed when required. I think AI actually increases the need for this kind of construction.
I came to the exact conclusion anology myself. So there is something to it.
I’m working on many open-source SaaS and am working on making them malleable from the built in AI. Anyone else working on this?
That's a fascinating topic. I'm curious about how do you approach it... like can the user-facing AI change any part of the code? Or is it constrained to a set of predefined components/plugin layer/etc.?
So I have the app deployed to railway with a Postgres database. I give the customer an agent that has the railway skill and basically access to that customers project on railway and they can talk to the agent and it can communicate with app, change the code deploy it again, do migrations.
I've always thought of it as a sand mandala.
Code might be clay, but we're not at the potter's wheel any more, the clankers are.
It's literally the Disney Fantasia scene of the Sorcerer's Apprentice: https://www.youtube.com/watch?v=m-W8vUXRfxU
Is it no longer gauche to refer to oneself as an artisan?
- i still write my code by hand and ll continue to do so
- only thing I use AI for is to review it
This is just current day LLM consumer conceit packaged as information.