alt Hacker NewsCode is clay now
Comments
Someone who writes code without LLMs is now an artisan software developer.
An artisan is (by definition) someone who creates manually, using traditional methods. Before there are automated or higher tech means of creating the same output, artisans don't exist, they are just craftspeople or tradespeople.
A factory worker, or factory owner, can care deeply about the quality of the product, and can be "in the loop" as you write about, but they are in the loop with the factory equipment vs. in the loop in manually crafting the product.
I don't think I'm refuting or in any real disagreement with you, in fact I may be here pushing artisan pedantry because I didn't see the literal use of the term coming through strongly enough.
The way code actually becomes clay, without needing a clay-wielding robot to do things for you, is to work in a material from the Lisp family.
Lisps have been compared to clay historically; search for it.
Recently, FOSDEM 2026 talk title: https://archive.fosdem.org/2026/schedule/event/HDE7JZ-lisp-i...
Not so recently, 1978 Revised Report on SCHEME: https://research.scheme.org/lambda-papers/lambda-papers-revi... ("LISP is a ball of mud" note)
Rephrased as "clay" in 1980 "Lisp Comes of Age" article for Byte Magazine: https://microship.com/lisp-comes-of-age/
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:
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.
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.
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.
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.
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.
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.
> 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 still write my code by hand and ll continue to do so
- only thing I use AI for is to review it
I came to the exact conclusion anology myself. So there is something to it.
Opinions are mud now
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’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.
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.
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.