Code is clay now

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.

A few more of these, and you have a blob of software that has no recognizable shape, and does "everything", with no guardrails and gates on anything, whereas meaning arises from these.

The problem is not knowing when to stop, when to avoid implementing something. The AI will not stop you.

The skill and knowledge and intuition for what make good software cannot be offloaded, no matter how many times people write articles asserting that the machines have got it all figured out.

Why exactly do you think code wasn't clay until a few years ago, and why is it now? It's a bit hard to tell from the article where exactly you draw the line between the two stages.

For example, the more experience I gain, the more annoyed I get when software or code is compared to machines, cars, or factories. These days, I exclusively use cooking as an analogy because it shares so many traits with software development. Using the same ingredients at the same time doesn't necessarily produce the exact same result. Everyone does things slightly differently, and there's a whole spectrum of outcomes, from factory-produced frozen pizzas to five-star Michelin dishes.

That's why I use this analogy whenever we discuss architecture and similar topics. I feel like it gets my point across much better.

You can't break anything you can't fix, and you can start out with something crappy that fulfills your needs at the moment and make it better later ... or not, if it continues to serve your purpose.

A stonemason has to buy new stones if they break something, a painter new paint, a woodworker new wood. If you build a crappy guitar you might have to buy new material, taking it apart and improving it might be tough.

With code, none of that has ever been a problem. You can start with something small, make mistakes, improve, all with the same material. You can even undo mistakes without a trace.

I'd say it's this pre-existing malleability of code that enabled LLM-based coding in the first place.

So I find the whole spec-driven development hype odd. I much rather vibe code an app, use that as a spec and then start anew to create the real thing. I haven't fully figured out yet what the best mode is there. So far I'm mostly hand coding it, thinking a lot about trade offs and I have an LLM read the full codebase of the vibe coded prototype and what I'm hand coding, so that I can ask very specific questions about how certain data flows or certain small things that I'm missing.

To me, this way of working is working great. You go from proving that an app provides value to your users through vibecoding through then productionizing it so you can capture all the users that this would be valuable to. It is of course important to sample your users correctly, such that they are a representative sample of your user population but since I do this within organizations usually and the apps are internal, that's usually an easy thing to do.

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.

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.

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.

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

The problem with most existing code is that you start off with the MVP, which is terrible because it needed to get out the door by the deadline. At which point tons of people start using it and you're stuck supporting the poorly conceived original interface for decades because so many things now depend on it, while also trying to support three newer versions because those versions had their own deadlines and now people are expecting them to continue working.

If we could realize the promise of these things then ideally what would happen is that the efficiency would make it cost effective to make the "MVP" a good well-tested well-considered final product. At which point it's done and has minimal if any future changes because you got it right the first time. Which is very useful to the human users who then don't have to re-learn how the thing works every 18 months.

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/

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.

Code has always been a means to build software based solutions. Code was only ever a stone if you did not know how to design and implement software.

The article alludes that LLMs have made changing code free? LLMs are not free. Tokens are not free.

Tinkering on small side projects or apps is great but not a reflection of how this works in larger production grade products.

Unlike hardware circuits, where logic is harder to change.

In what world this was ever true ? a software or a lib is pretty much never finished

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.

What we've done though is really reduce the cost of clay and its availability.

Good clay was expensive to come by, not cheap and difficult to procure, now it's wildly available.

A good developer now will have to be better to think and communicate as the code quality is becoming less important. I don't like it but it's the world we live in.

Always has been.

Now it is liquid.

But what good architecture gives us is the ability to move slowly and methodically. No we don't just knock down the edifice and start from scratch every time. We change the bits that matter with surgical precision, or write a new plugin to extend the capabilities into an unforeseen direction.

I'd actually say LLMs are less likely to treat code as clay, what with their zeal for implementing things completely from scratch and ignoring existing architecture and conventions.

- only thing I use AI for is to review it

It's literally the Disney Fantasia scene of the Sorcerer's Apprentice: https://www.youtube.com/watch?v=m-W8vUXRfxU

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

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