Rendered at 09:38:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jameskilton 11 hours ago [-]
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.
albertodenia 1 hours ago [-]
> 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.
nomel 10 hours ago [-]
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!".
beej71 10 hours ago [-]
> 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.
theshrike79 4 hours ago [-]
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.
3 hours ago [-]
albertodenia 18 hours ago [-]
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.
theshrike79 4 hours ago [-]
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.
albertodenia 1 hours ago [-]
> 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 build it properly.
teleforce 10 hours ago [-]
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.
Very cool, thanks for that. I was vaguely aware that clay metaphors were important in old 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 :)
benoq 10 hours ago [-]
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.
theshrike79 4 hours ago [-]
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).
aogaili 10 hours ago [-]
I came to the exact conclusion anology myself. So there is something to it.
vivzkestrel 6 hours ago [-]
- i still write my code by hand and ll continue to do so
- only thing I use AI for is to review it
BatchJob 8 hours ago [-]
This is just current day LLM consumer conceit packaged as information.
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.
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.
This used to be what being a dev was, if I recall. It's been a few years.
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 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.
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 build it properly.
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
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.
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).
- only thing I use AI for is to review it