Subtractive Synthesis
A few years ago, I got really into synthesisers. There are broadly two main ways to produce a sound with a synthesizer: additive synthesis, and subtractive synthesis. You might be more familiar with the difference between additive and subtractive manufacturing if you're closer to hardware, and you're almost certainly aware of the difference between additive and subtractive color.
In any event, the point is this: we can divide methods of creation into two broad areas. Additive techniques are those that build incrementally, and start from a blank slate; subtractive techniques are those that begin with some raw material and refine it until it fits some desired criteria. Importantly, I'm not claiming these methods are dual or equivalent. To build something by subtraction is to accept the fundamental flaws of your raw materials, while someone starting from an empty canvas shoulders completely the responsibility for the quality of their work. I'm also not claiming these methods are mutually exclusive, and I suspect there are vanishingly few domains that are purely additive or purely subtractive.
I am not an artist, at least in the narrow sense; I am a programmer. For my entire life, the work of programming has been largely additive. It has been a line-by-line process that begins with an empty repository, and which involves a surprising amount of grunt work to complete. And I've always found some pride in that. Pride in my skill with the tools that accelerate my work; pride in my familiarity with my own code; pride in the aesthetic quality of what I choose to publish. I love the process of starting from a blank page, and losing myself in my work for hours at a time. I've been doing this for nearly a decade now, and I cannot remember a time in my life that I wasn't writing some kind of code.
Which is all to say that I find working with LLMs strange and entirely unlike the skill I've devoted so much of my time towards. Not bad, I feel I should say, but just strange.
Working with Claude Code is fundamentally subtractive: I receive code at a rate faster than any human could hope to match, and I filter and refine it until I'm happy with results. I'd liken it to sculpting, where Claude chisels off large chunks of granite under my supervision, and in turn I give feedback on the overall design and make fine alterations where necessary. If we end up in a bad place, there's no real problem; the cost of generating raw material is so low that I feel no remorse about throwing away bad work and starting over again.
I find myself spending much more time considering overall architecture and design, and far less on basic programming tasks. Let's pick an example: say I want to define a type called Hour in Rust that represents an ISO 8601 hour (ranging from 00 to 23). It's pretty trivial to sketch out the basic design as follows:
pub enum Hour {
H00,
H01,
H02,
H03,
// the rest of this enum is boring and obvious
}
impl Hour {
pub const fn new(value: u8) -> Option<Self> {
// boring and obvious (to implement safely)
}
}
// other boring and quite obvious trait impls, e.g.
// - Display
// - FromStr
// - Add
// - Sub
In a real project, this is the exact point at which I would get bored and go do more high-level design work instead of actually bothering to implement all of this properly. It's dull, you know what it does, I know what it does, and we now live in a world where a decent programming agent knows what it does. My projects tend to be full of types like these, and the fact that I can just get Claude to implement them for me is frankly miraculous; it saves me hours of tedium that I can spend on design work, and documentation, and testing, but also on things like going to the gym and spending time away from my desk relaxing.
As I write this, I'm watching Claude fix some bugs in a project for which I wrote at most 5% of the code. It's producing essentially the same code that I would have written, in a fraction of the time it would have taken me, and the evidence of the time it's saving me is this very blog post. I cannot help but be amazed by this, even as a small part of my brain mutters quietly about falling for big tech propaganda.
And yet, I cannot shake a vague malaise. In the recent Oxide and Friends episode about engineering rigour with LLMs, there's some discussion about "LLM depression" that feels quite poignant in this context. I don't fear the sudden end of the software industry, or an inevitable fall into the permanent underclass; I have no concern that I'll be replaced by a polecat or a deacon. But the mechanical process of programming has been an essential part of my life for so long that I find it hard to imagine what I'll do with my time, and my hands. I still love beautiful code, and language design, and despite the grunt work I still find programming by hand to be deeply fulfilling.
If a random person on the street asked me who I was, I would tell them my name, and then I would say that I'm a programmer. Not because it's my job, or because it's my hobby, but because it's an essential part of my life. To work alongside an LLM is not to program, at least not as I have understood it for most of my life.
To touch on something I've talked about before, we are not independent of our technologies. Clothing and mass manufacturing are as human as skin and bone, and so technological shifts cannot help but affect the identities of those who must handle them. The question ringing in my head—and the question I cannot answer, for you or for myself—is how this technology changes us.