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.

Related:

Malleable Systems Collective

https://news.ycombinator.com/item?id=50188437

This analogy is apt for working with LLMs. Were you aware, tho, that it has repeatedly been used to describe Lisp?

I think Lisp is an ideal language to use with an LLM, because it is essentially a notation for a logical assembly code, and I expect there to be compound benefits in using it with AI.

Lisp [...] made me aware that software could be close to executable mathematics.

— ACM Fellow Profile of L. Peter Deutsch.

APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way — even by adding another diamond — you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it [...] and it still looks like a ball of mud!

— R1RS (1978) page 29, paraphrasing remarks attributed to Joel Moses.

Part of the beauty of the ball-of-mud quote is that there really does seem to be a causal connection between Lisp's use of generic, unencapsulated, largely un-type-checked data structures and its extensibility. The converse implication is that we should expect specialization, encapsulation, and aggressive type-checking of data structures — all strategies extensively pursued in various combinations in modern language paradigms — each to retard language extension.

Each of these three characteristics of Lisp serves to remove some kind of automated restriction on program form, leaving the programmer more responsible for judging what is appropriate — and thereby shifting things away from close conversation with the machine, enabling (though perhaps not actively encouraging) more human engagement. The downside of this is likely obvious to programming veterans: it leaves things more open to human fallibility. Lisp has a reputation as a language for good programmers. (As a remark attributed to Dino Dai Zovi puts it, "We all know that Lisp is the best language around, but in the hands of most it becomes like that scene in Fantasia when Mickey Mouse gets the wand.")

Lisp, Mud, and Wikis

https://fexpr.blogspot.com/2018/10/lisp-mud-and-wikis.html#s...

{LISP Is a Ball of Mud}

LISP is extensible in two ways. First, there is the simple ability to define new functions; these are used in a way that is both syntactically and semantically identical to built-in primitive functions like CAR. This is in contrast to “algebraic” programming languages, which either make an arbitrary syntactic distinction between addition, say, and a user function, or wander into the quagmire of extensible parsers. Second, there is a uniform macro facility for transforming one syntactic form into another; this facility is based on internal data structures rather than external character-string syntax.

The Revised Report on Scheme

https://research.scheme.org/lambda-papers/lambda-papers-revi...

https://wiki.c2.com/?HackerLanguage

Also:

Lisp is Clay: The Power of Composable DSLs (video)

https://archive.fosdem.org/2026/schedule/event/HDE7JZ-lisp-i...