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!".
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.
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.
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.
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.
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!)
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 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).
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.?
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.
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.
> 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.
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.
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
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!)
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 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).
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.
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
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.?
I came to the exact conclusion anology myself. So there is something to it.
- 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.