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.

There's also another sticky, malleable substance that could work for this analogy...

But more seriously: the question, the same as before, is "what are you going to sculpt". Sculpting for the sake of sculpting achieves nothing, and if it's too cheap and too easy, it can cost you time and money than if you had to pause and think beforehand.

I implore you to look at the past several months of vibecoded games and Github projects submitted to HN. It's amazing that you can prototype something in hours. It's bleak when you realize that half of these projects weren't even working properly - we often upvote based on vibes too - and are now abandoned in a half-broken state because the author has no attachment to it whatsoever. It was just some money exchanged for internet points.

There's no doubt that we're going to have more software; I think it's very much an open question whether there's going to be more good software, or more software that can make money.

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.

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

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.

To torture the analogy a bit: You didn't sculpt bridges out of clay - critical infrastructure was built from stone. Even if you wanted to use clay, you made bricks, and architected the structure from those units. You couldn't just throw a lump of clay across a stream and vibe-build a bridge...

If we want to use LLMs responsibly, to build substantial pieces of infrastructure, we should be using it to create discreet "bricks" of code, that can be tested, relied upon, and used to implement human-driven architectural decisions.

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.

Opinions are mud now

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 is clay now, agents have surpassed most human coders, arguably arriving at AGI. Yet the team at Hacker News STILL can't figure out how to make their forum software bump a post without these embarrassing fake time stamps.

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

It's actually Pokemon, but you can crossbreed and genetically modify them.

I remember explaining software to someone, and I explained that it was like a sandpit, every day - it is cleared, you make shapes, lines, add rocks, toys - surely, at the end of the day, it gets cleared, and starts again new the next day.

What remains are the lessons we learnt, the sand is a medium through which we express ourselves.

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?

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've always thought of it as a sand mandala.

- i still write my code by hand and ll continue to do so

- only thing I use AI for is to review it

Code is more like a garden. You spend a lot of time just watching stuff grow, you don't know what you're going to get, sometimes you have to pull weeds, and you have to be mindful of the weather and soil conditions to ensure stuff grows optimally.

And it is still better to be a coder in a garden, than a gardener in CODE.

code has been clay for 4+ decades now, kiddos, I can confirm firsthand

[dead]

This is just current day LLM consumer conceit packaged as information.