Code is clay now
albertodenia.com
albertodenia.com
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.
This used to be what being a dev was, if I recall. It's been a few years.
A great coder loves legacy old projects because theyre challenging, unpredictable, undocumented, and if you figure out, you are like a God.
Starting the perfect greenfield project and writing amazing code the first week is a skill every freshmen student at a CS college has. That's not a problem area, its a solved thing.
But do it for 10 years straight after 5 acquisitions, different infrastructure, different industry, language, culture? You are a RARE BREED.
Or even simpler put, never measure yourself with easy things, only with the hard ones since then the easy things are a joke.
Been there done that, the problem is you will not get rewarded by your superiors. Keeping old shit alive is useful to keep your skills sharp, but it's bad in a culture utterly dominated by "resume driven development".
Regarding the average developer as an imbecile was a cottage industry from Djikstra to FizzBuzz.
And non-slop parts were maybe some prominent open source projects.
Most bigtech company had an internal joke of "we couldn't ever open source X, not because it can't be done, but it would be too embarrassing"
Unless you worked at the shittiest company in the world, lets try to not bring others down just because they weren't as amazing as we are. They might have other skills weve lacked.
E.g. like a journalist complaining that they colleagues didn't publish books... who cares? Thats not their job, they need to write clear good concluded articles. If they write their articles like books, nobody reads that shit.
I'm not sure your experience is the norm.
LiveCoding in CommonLisp.
We tend to forget in tech-oriented forums that most of us are bound to those who pay our salaries, and for many developers that payment is to be focused on revenue-generating, or client-focused work.
Developing advanced comprehension and being able to use it for long-term system stability are unfortunately not always paired in the daily work.
Also comprehension is one side, its "Consuming" code, but it doesnt say anything about theyre talent of producing great code.
Now instead of aiming for robust, malleable code, people are throwing up their hands and saying, "It was always a mess, let's just keep throwing more tokens at it."
If a dev just followed public trends, then I guess I can see how they came to the conclusion that this is the best way out, because their baseline level of comprehension is so far in the floor. It's like circling around the entrance of a maze for days until finally an AI merchant shows up near the door, and they say "well clearly, the only way to get out of this maze is to pay the merchant for his fancy roomba to carry me out" instead of carefully mapping your way through.
From a selfish perspective, that's fine by me. I've built up skills that I don't think will be replaced in the near-term, and in that same period most people will end up de-skilling. The only downside is that I've had to shrink my circle that I collaborate with even further.
This is a one possible approach/explanation:
https://pragprog.com/titles/swdddf/domain-modeling-made-func...
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'm not using any LLMs directly (my workplace still bans them in-house) and my experience on the receiving end of contractors using them is quite poor. That includes one major, "we'll replace your ancient software with shiny new stuff"... with significantly reduced capability that in turn makes everything far more difficult than it was or ought to be. The UI appears much more user friendly, but really is just broken in multiple ways where the much-patched 1980s software it replaced was user-unfriendly but largely worked.
This all could be the result of poor coding, regardless of LLM use, of course.
The cost of experimenting is just mind mindbogglingly cheap now, it's really insane. Don't like the abstractions it comes up with, or think it generated a bunch of slop? Go again, who cares? With a little more steering, they'll often produce exactly what you want.
As for contracting firms, many of them were slop shops before AI, I imagine those kinds of firms are even worse slop shops now.
This is a great use case, as you have ground truth to compare to. LLMs are phenomenal at this stuff. Where you don't have this is where they are less successful (in my experience).
As others have said... it's a tool. A powerful tool in the hands of a wise and skilled wielder who makes planned, focused changes, or a slop-cannon in the hands of someone who is happy to churn out features with minimal understanding of context or system design.
LLMs don't magic away the need for careful and extensive testing. Good code still takes a lot of time. But it's also a lot less time than before.
I suspect a lot of problems come from people trying to one-shot entire apps, or from those who do not have the relevant experience or knowledge to understand that close-with-a-nice-modern-GUI is not nearly good enough.
That is my hope anyway, apart from that, I do think there is an inherent laziness in business to not mess with the machine that makes money.
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.
You know, I've never thought about that. It's really interesting to consider, especially since refactoring code is now cheaper than ever.
This is not the case as far as accounting and the law is concerned.
Dependency is a cause of ossification.
The point is that previously, changing code in a major way might take months of refactoring. Large changes were simply not contemplated unless they were justified by similarly large additional profit. Once you designed your architecture, you were pretty much stuck with it.
Now, the kinds of changes that were simply unrealistic before are now entirely realistic. A refactor/migration that would have taken 6 months before, you can now get a working version done in a day, and another few days of QA. That's what this post means -- code is no longer stone, it's clay. You can change it quickly in ways that were previous unimaginable.
This has nothing to do with the concept of code being liability or asset -- that's a totally separate conversation.
Good Architecture will try to isolate the two. You got the internal logic which is either the business domain abstracted away. And you got the highly volatile part (request from frontend, new integration, new drivers, deps update,....).
If you've done that, migration/refactoring, unless it entails some unlikely core changes, will not take that long. It's just a matter of dropping that part and replacing it (like changing a car's brake pads or steering wheel). But the actual core mechanism will hardly change over the years.
To go with the thread flow: It's a stone core wrapped by clay.
[0]: https://www.youtube.com/watch?v=P5eO7BNyJao
ADDENDUM
In regards to separation, one of the best example in mind is the OpenBSD kernel code. The OS concepts are in /kern, while each architecture lives in /arch. There's an horizontal separation between machine independent code (core idea of Unix) and machine dependent code (The hardware platform). It can also be found in the various subsystem like audio (the concept of a sound card) and implementation like uaudio (usb interface) and azalia (Intel's HD Audio).
> Now, the kinds of changes that were simply unrealistic before are now entirely realistic. A refactor/migration that would have taken 6 months before, you can now get a working version done in a day, and another few days of QA.
Significantly changing a system implementation is a function of understanding, not time.
Given a starting solution state being A and a desired functionality state of A', the tooling used to codify the A -> A` delta is largely irrelevant. Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.
Code is neither stone nor clay.
When making software, remember that it is a snapshot of
your understanding of the problem. It states to all,
including your future-self, your approach, clarity, and
appropriateness of the solution for the problem at hand.
Choose your statements wisely.> Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.
And this is exactly what agentic coding brings to the table in spades.
In order for agentic coding to be a net positive, the instructions given to the AI offering must be from people who understand what a system currently does as well as what functionality a product needs to provide in its future desired state.
Agentic coding does not solve these fundamental concerns.
But whether or not this is actually needed or not now, I'm not so sure. LLMs are very good at parsing a codebase, discovering what needs to be changed to provide different functionality, suggesting any architecture changes that would be needed to do so, and ultimately implementing those changes within the bounds of an existing test suite.
I sadly suspect that if it's a choice between throwing a person or an LLM on an existing large and complex codebase cold, it's now safer and faster to use an LLM in many instances. Much better still to have someone with knowledge and understanding of the codebase work with an LLM, of course. But we're getting to the point that you can do a lot with little to no human knowledge at all.
(LLMs are also very good at bringing you up to speed with a large and complex codebase. A model can absolutely help create understanding in the person overseeing these changes, provided that person deigns to ask for it.)
You're missing the point. Understanding has nothing to do with code.
"Code" is short for "encode", which is an industry term for "encoding a solution". This implies a solution has been formulated before it is expressed in a programming language.
There is no "codebase" without a person or people who understand what solution to reify in the first place.
> A model can absolutely help create understanding in the person overseeing these changes, provided that person deigns to ask for it.
A model can assist a person to gain understanding, sure, but like you said yourself:
... provided that person deigns to ask for it.
By this statement alone, you have proven my point of:
In order for agentic coding to be a net positive, the
instructions given to the AI offering must be from people
who understand what a system currently does as well as what
functionality a product needs to provide in its future
desired state.The reason code takes time to change is not because changing it takes time.
You have to redo all the testing and relearn all the hard fought and underspecified lessons of the previous attempt. That's what takes the time.
Letting an llm rewrite your internal todo tool, in another language, better design and up-to-date software stack. Yeah, this is absolutely not a fantasy anymore. We got rid of most SAAS tools in a month. Complete with Keycloak, behind wireguard, pocketbase backend, in our cooperate design with exactly the features we want. It works flawless since day one.
If you did, please do an urgent meeting with your team and dont tell anybody, just fix it. When shit hits the fan, it really hits hard.
And frankly...have you tried configuring Keycloak? It is a gigantic "do everything app". The idea that it's going to have a narrower attack surface is basically fantasy.
I also wrote about internal tools. Not public facing applications. That would be a bit much for my taste.
This has stabilised the system, fleshed out unfinished ideas, expanded testing capability, introduced new developer-experience oriented tools, and refactored sensitive systems to be more flexible for future use. Not to mention addressing the kinds of uber-niche tech debt that would take years to bite and months to fix.
It's far from fantasy.
I think this is what TFA was getting at -- what was once hard or impossible, and an absolutely massive headache to conceptualise, is now surprisingly simple and straightforward.
Did they even sit and thought deeply before they wrote this comment or have people really just started putting out slop everywhere due too much usage of AI?
The code that was produced in 6 months before cant be even read in 1 day today so dont get me started on properly functionally producing it.
Yes, they really have been. It’s exhausting at work.
That's what truly convinced me programming was over: it writes better tests, more thoroughly, then any developer.
Can you help me understand what domain and language(s) you are using here?
This really does not match my experience so I'd love to understand what the differences may be.
Was there an existing good test suite? Is this an application built before LLMs?
I'd love to get more info so I can figure out how to get Opus to do this for myself, as I really haven't had this experience.
AI absolutely solves that problem. Just about every prompt "fixes" the dried out pieces of the code. And it's only getting better at that every month.
Sometimes I feel like people are experiencing AI so differently that it makes talking about it nearly impossible.
It's hard to say because no one actually describes what and how they are doing to get AI to successfully refactor or operate in large code bases.
My experience is, slop on slop. Frontier models still can't handle even modest sized refactors without explicit hand holding. I still don't trust models with production scale refactors.
Apparently, everyone has the magic sauce and I'm blind. Or our definition of quality and production grade is very different.
Please enlighten me.
That probably means a test suite that is at least twice the size of your code base. If you started there, great, but increase it to integration and benchies if you’re mostly holding units. It actually helps a bit if you can use a different language for this too but it depends on project, ymmv.
After that you have to either let go of certain style/idiom things or enforce ruthlessly with deterministic hooks everywhere.. no middle ground there and prompts will never work.
You also need to deliberately channel chain of thought with workflows rather than hoping for the best.. most of the generated product here shouldn’t be committed or preserved at all.. non-public doc flows and ticketing systems help.
Like people, an ai can easily create code that it cant actually maintain. It’s a matter of discipline now, same as before. Always using the smartest model is wrong, but double wrong on “wide” changes like a big refactor.. it leaves you no good options if you get into trouble.
If you've got a test suite that's twice the size of the code base then those tests are almost certainly tied to implementation details and will make the code a lot less like clay.
Not sure what kind of data this refers to?
This. Since forever was I told that the term "software" was coined because, contrary to hardware, it was easy to change, adapt, and mold into your needs.
I'm very surprised to hear people in this day and age claim it wasn't.
This isn’t capturing the spirit or the essence of the metaphor. chipping away at marble or whittling has this locality to it that’s keen but myopic. Molding with clay isn’t so detail oriented, you can literally close your eyes and focus on shape, same with turning on a lathe although I wouldn’t suggest closing your eyes.
there is such a thing as being precise without being detailed or local. Before LLMs you did this with test suites techniques maybe, and a few automated refactoring tools, CSTs and AST work, sometimes macros and other metaprogramming. Yeah it happened but fair to say it was rare and difficult. Everyone is/can be a sculptor now
Akshually, you can never rewrite your code.
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 properly build the product.
> 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 =)
Unless you use code, that mold is at best a formless bag.
The reason people use software is because there's a need to manipulate some data/information, transfer it, and interact with it (input or output). All those actions needs to be done correctly, and if not possible the error should be reported. To get to that level of correctness, we need to be formal with how we express the process, which means essentially going from a non-zero amount of ambiguity (natural language) to zero (programming language).
Using AI to translate specs/prompt to code is just asking it to randomly resolve any ambiguity found in the specs. And as any experienced dev knows, some of those are just tradeoffs where there no right or wrong answers, just contextual ones that evolves over time and space.
> 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
I wonder if there's actually been conversation with the client before? Where you use some prototyping tools like RAD or Sketch to resolve UI issues, get in touch with the actual domain experts,... or was it just a telephone game full of politics?
A human defines the checks (the mold) that give the agent the limits. They can be TLA+ definitions, linters, cyclomatic complexity checkers, unit tests, integration tests, end to end tests etc. And usually some written docs - made in a way that's specifically targeted at agents. Those define the limits the agent has to stay inside of.
There will always be work for human QA too, an AI can't determine if something feels off in an app's flow, it has no taste or concept of usability beyond the purely mechanical rules.
[0] Not talking about health, aerospace or nuclear stuff here naturally.
That’s even more work than just writing the code, at least the latter is immediately useful. The reason we create complicated machinery is mostly because of industrial scale. Molds and factories help create thousand of pieces and the total value of the latter is way more than the cost of the former.
The reason we don’t write specs and other kind of docs extensively is usually that the time taken is way more than just writing the code. Yes, code do require formal thinking, and a training in syntax. But a lot of jobs require understanding some concepts and training in the jargon and techniques.
> No program will ever be perfect[0], but you need to get it good enough for the problem at hand.
The nicest thing about software is that some subproblems are nearly eternal. That’s why we reuse code and utilities. Also while some problems do evolve, it’s usually done slowly and in a way, predictably (as in how, not when). Taking care to solve it once well, usually is better, rather than solving it again and again.
It’s more important to worry about the solution to a specific problem (in terms of concept), than to worry about code. Coding was not, and will never be the primary problem. Any experienced developer knows this, which is why most will says they spend very little time thinking about code and writing it.
We're not trying to perfectly define the problem, but rather adding barriers to so that the AI can't veer off course and drive itself down a cliff.
Especially if you're in a product house developing and improving a single product over years, creating the "mold" is even more important. You know where you've been and where you want to go so it's easier to define the technologies and systems the AI should use.
For greenfield stuff there are some parts that can be re-used between clients, but there's definitely less of it.
But I do agree that code is not the problem, defining and describing the problem is the problem =)
What are they paying you for if you’re just having your clients vibe code their own apps?
These are for highly specific stuff like a tool to help a copywriter work on game dialogue for example.
It's a fuckton faster for the actual expert in the field to do it than me first learning enough of their craft to know the terms and how they work to get there eventually.
The actual code that does anything meaningful is made by Actual Programmers. As well as everything beyond that, where it's run the CI pipelines, tests, infrastructure to run it etc.
It's like an architect asking a client to draw and describe their dream home and using it as a basis for the final product.
Otherwise, create a "mold" in AST in Lisp.
But it's just writing the hard limits on the outside, in code. Define that when A goes in B must come out. Enforce hard linting rules and other code-level checks on the output etc.
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...
Hacker Language
https://wiki.c2.com/?HackerLanguage
A language that allows one to easily customize syntax, flow control structures, etc. for the convenience of the author without regard to future readers. It allows one to create their own language or sub-language in their mind's own image without worrying about other readers' preferences or grokkability of the style. Contrast with a CorporateLanguage that assumes or targets masses of mediocre PlugCompatibleInterchangeableEngineers (programmers) where there may be many readers with varying skills. Such a language tends to hard-wire ways of things to reduce variation. One can say that a CorporateLanguage is for the herd of sheep while a HackerLanguage is for the lone wolf. ("Hacker" could be "hobbyist" or "tinkerer" also in this context. It's not meant to only include the devious version of "hacker".)
One can often achieve high personal productivity with a HackerLanguage, but readability may fit a very narrow audience or be questionable. Sometimes derogatorily called a WriteOnlyLanguage.
Malleable Systems Collective
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.
Not really in the way the comparison means it. Code was malleable with big force (mandays of manual coding to change something). Now it's malleable with "change this to do that" on an LLM.
In the analogy, the former is more like a stone is also "malleable" (you can take a chisel to it after all), but much less than clay, and is a much more manual process.
Also, then, the comparison greatly underestimates clay. Sure, everyone can put a dent in a slab of clay but modifying things controlled takes time, skill and patience, a precise application of force that can easily go wrong so you might need to start over.
So, yeah, I guess my stance towards both code and clay is just very different ... the comparison doesn't make sense to me at all ...
With that being said, I think it was Fred Brooks that observed (and please correct me if I'm wrong) that software systems are the most complex systems human beings create, and this was all the way back in the 1970s, so there is something to the point of view that making changes to software systems can be difficult.
Nonetheless, I think LLMs and agents have taken software systems from being quite malleable to being really very malleable indeed, and in that sense I absolutely agree with you.
The product, on the other hand, was not, and that changed with LLMs quite a bit. But the code is not the product.
EDIT: You could even argue, the code itself becomes less malleable, in the clay sense, with LLMs because now you really NEED a tool to make changes, and changing the code by hand becomes much harder. So LLMs shift the malleability from code to product.
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.
Calling people who write programs in yesterday's programming language that really only differ from today's programming language by having fewer built-in keywords 'artisans' is, per your definition, a stretch. We've been adding more and more built-ins to programming languages ever since the first one was created.
At some point, it was clear to everyone that punchcards were no longer the most efficient way to program. People who chose to keep using them could for whatever reason could be considered artisans.
I also thing we should avoid automatically attaching to "artisan" value. I know some artisan bakers whose bread is amazing and sells out virtually every day they bake (alas, they still don't make much money which is why most people don't eat artisan bread). So artisan products can be better than their modern counterparts, but it's a mistake to assert it automatically is higher value.
Computing saw as similar medium shift from, as it pertains to programming, mechanical switching to digital switching. And I posit that is the threshold.
But we've yet to leave the digital switching realm. We still write our programs the same way we did 50 years ago. The compilers have gotten way, way, way more featureful and smarter, but it is still the same old story: You write a program in a language the computer can interpret, feed it to a compiler (or layers of compilers), and out comes something the machine can execute.
There has been no apparent change in the medium. Developers are still writing out their code in a programming language, inputting that code into a compiler, and see another representation of that program come out on the other side. Just like we've been doing since the early days of using digital switching. Whether or not a compiler is built using an LLM is just an implementation detail.
It does appear that the REPL has grown in popularity where in the past was used sparingly, but I don't really think a small difference in input method is a change in medium. I don't consider the introduction of punchcards to have been a change in medium over when switches were switched by hand either. It is still actuating the same mechanical switches.
Today's programming languages are way better than the ones we had even a few years ago. Like night and day difference. I suspect that is where your threshold idea is coming from. But, like, today's mechanical saws are way better than the early mechanical saws but I don't think we would normally consider a woodworker to be an artisan just because he's using a primitive deathtrap instead of a modern sawstop. Perhaps I'm out of touch with the kids today, but I expect an artisan woodworker is normally considered one that uses hand tools — that being a different medium from mechanized tools which do the work in a completely different way, not just an earlier version of the same thing.
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).
Very true.
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.
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:
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/
https://scicloj.github.io/clay/
> Clay is a data visualization and literate programming tool that creates documents (HTML pages, PDFs, books, blog posts, reports, slideshows) from Clojure source code and comments.
I guess it's more of a computational notebook or interactive environment.
So not only the code but the running program and the editing environment itself is clay.
It's a wonderful "Gonzo" style report by Steven K Roberts (SKR!), with photos, of a groundbreaking AI conference and soon after, the first Lisp conference (20+ years after it's creation) -- both at Stanford.
I remember Hofstadter referencing this conference at the AI symposium he hosted and I attended at Stanford in 2000 (another 20 years later). Nice to see this.
Will Spiritual Robots Replace Humanity by 2100?
I just have to say, BYTE Magazine was the best. A shame they didn't publish this story.
lol - “DWIM, not DWTWHMY (Do What I Mean, not Do What This Would Have Meant Yesterday).”
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.
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.
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.
Depends, I guess. Engineers don’t typically know 100% the business rules (think fintech, payroll, etc.). You typically need to align with domain experts (and no, these people don’t write down their knowledge in confluence pages).
So, unless we are talking about simple software (things that can be broken without too much accountability) then sure
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.
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.
In what world this was ever true ? a software or a lib is pretty much never finished
Sometimes it is reusable, much like you can use a butter container as Tupperware.
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.
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.
Unlike hardware circuits, where logic is harder to change.
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.
Code is not a material out of which you make objects. It is a precise description of a process. You do not get better plans by globbing them onto each other! This is not and never has been an "artisans vs factories" fight. It is an "I know what I'm doing vs I don't care" fight.
And it is still better to be a coder in a garden, than a gardener in CODE.
- 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
Now it is liquid.
Always has been.
What remains are the lessons we learnt, the sand is a medium through which we express ourselves.