Code is clay now

# Code is clay now Source: [https://www.albertodenia.com/writing/code-is-clay-now](https://www.albertodenia.com/writing/code-is-clay-now) Alberto Denia ∙Sep 25, 2026  In the Middle Ages of coding \(that is, before November 2025\), we coder\-stonemasons spent our days meticulously carving code\-stone into finished pieces\. Stone is unforgiving, and modifying it remained difficult even as better tools improved things over time\. Small corrections were okay\-ish \(some chiseling here, some patching there\), but larger ones meant demolition, scaffolding and a careful plan pinned to the wall\. Agentic coding has turned that around: code has become*malleable*\. Even though it’s still made of the same underlying substance as medieval code, the cost of making a change has collapsed\. That makes it behave like a different material entirely\. Code is clay now\. ## Working with clay Once code is clay, you can start*modeling*it\. Slap some big blobs of code\-clay into the rough shape you want and see how it feels\. Don’t like it? It’s easy to reshape a part or even squash the whole thing and start over\. When the overall structure feels right, you refine the way a sculptor does: from the general mass, to the mid\-sized features, to the details\. Modeling can be applied fractally, at any layer of the thing you’re building\. A solo developer exploring a new product could sketch the entire core in a day to see what works before getting into the details, while a team in charge of a struggling product feature could spend a couple of days taking it in a completely new direction to find out whether the pivot is worth it\. No amount of planning or mockups beats watching the actual thing in action\. Your product and engineering judgment still matters, though\. Making a change might be nearly free now, but knowing whether it’s the*right*change isn’t\. If you want to build things that feel right and hold together, you can’t just keep piling blobs up\. You need to be refining the pieces and thinking about how they fit, or the whole thing will collapse into a sloppity\-slop puddle faster than you can prompt your way out of it\. Taste, context, guardrails, architecture… those are your armature and your kiln\. When to apply this judgment, and how much of it, is something we are still figuring out\. Several workflows are emerging across a spectrum of human involvement\. At the extremes of that spectrum sit two approaches worth looking into: artisans and factories\. ## The way of the artisan The artisan wants to be*in*the loop\. The fast feedback loop is the best thing about malleable code, and the reason many of us are addicted to it\. In the time it takes to get a coffee, you can think of a feature, plan the approach with the agent on your phone and have it ready for review when you come back to your desk\. Add some polishing iterations and you have compressed a full product/engineering/QA cycle into one person and thirty minutes\. When you are your own user, the loop gets absurdly satisfying\. For example, I’m working on a Markdown editor that I’m using more and more every day\. A few days ago I was looking at a file with a list of expenses and I thought: “It’d be cool if I could automatically sum all of them… wait a minute, let me throw some code at it\!” Half a soda later, I had the first version of calc blocks \(a block that evaluates simple operations and shows the result in its margin\) working in the app and already useful\. Software development in real time\. Isn’t this just vibe coding? Not necessarily\. The way of the artisan is about staying in the loop and applying your judgment to every iteration\. When you only judge the user\-facing surface, that’s vibe coding\. When you also judge the code \(its shape at least, if not every line\), that’s engineering\. The loop is just faster now\. ## The way of the factory At the other extreme, you want to remove yourself*from*the loop\. That’s the way of the factory\. The factory is all about building systems that shape code\-clay into bricks that fit neatly into a larger structure\. Think a pipeline made of specs, generators and verifiers \(tests, evals, guardrails, reviewing agents\) in loops that only escalate to a human as a last resort\. It works best in well\-structured codebases with repeatable patterns acting as*molds*, and clear criteria it can verify its work against\. The factory is amazing for things like adding that eleventh CRUD endpoint or grinding through a hundred minor bugs\. Judgment still exists in the factory; it has just moved upstream or been embedded in the pipeline\. The jury is still out on how much of it can be embedded and automated, but I suspect setting up the factory so it produces reliable outcomes is a lot of what engineering is about to become\. ## Artisan or factory? In both cases, human judgment is still steering the work\. The difference lies in when it is applied\. The artisan applies it at every iteration, which is great for exploring ideas and refining features that need to*feel*right\. The factory applies it upfront, when building the pipeline, and as little as possible during the loop\. Neither can afford to skip it\. You’d think that, given the industrial connotations, factories only belong in large corporate codebases, whereas artisans are indie hackers tinkering with their apps from a beach in Thailand\. But the two can be complementary, and many real\-life workflows will look like a mix of both\. Large, established products need artisanship to solve novel problems or add features that have to feel right\. And even solo developers will want to run factories to take care of the boring, repeatable parts, and to achieve a scale that was unthinkable for a single person before\. The point is to pick the right approach for the problem you are trying to solve\. Which, as it turns out, is what software engineering has always been about\. So we have this new material in our hands\. Code is clay now\. What will we build with it?