Are You a Carpenter or a Surgeon? Why the Analogy Matters for Developers

John Allsopp 27th October, 2025 @johnallsopp

TL;DR: We’ve been using the wrong metaphor for AI in development. It’s not just a power tool that makes us more productive—that’s a sustaining innovation mindset. The better analogy is the surgeon: someone with deep foundational knowledge, embodied expertise from thousands of cases, and the judgment to make critical decisions. As AI handles more of the execution, what matters isn’t typing speed but knowing which data structures to use, understanding how systems connect, and maintaining mastery of constantly evolving platforms. Your expertise isn’t obsolete—it’s more essential than ever.

I’ve been thinking about AI for a very long time. I studied it back in the 1980s at university—obviously something very different from what it is today. We ran our first AI-focused conference way back in 2017, before GPT, when IBM Watson was all the rage and the conversation centered on chatbots, efficiency, and bringing personality to inanimate devices.

By 2022, I was writing multiple articles on the topic, and toward the end of that year, I even started to feel a bit apologetic about how much I was focusing on it.

In September 2022, I wrote “AI has been the next big thing for a very long time.” (For what it’s worth, in that I highly recommend people play around with the precursor to ChatGPT, OpenAI’s GPT Playground. If you’d followed my advice, you would have had a couple of months head start on most people when it came to ChatGPT.)

And this was before ChatGPT came out and completely transformed our technology landscape.

For a long time, I’ve focused on the idea of AI as a tool—like a power tool for a carpenter. A drill that makes you more productive and efficient. Makes you better at your work, but doesn’t make someone a carpenter simply because they own one.

Then recently I encountered Geoffrey Litt’s article “Code Like a Surgeon” which uses the analogy of what we do when we work with AI tools as being more like a surgeon.

Which I think is a far more enabling analogy and captures a sense of AI not simply as a sustaining innovation but a transformative one.

Why Analogies Matter

The carpenter-and-tool analogy suggests something specific: a sustaining innovation. The carpenter does certain things, makes certain things in certain ways with certain tools, and what we’re giving them is a new tool to make the same thing more efficiently. Classic sustaining innovation.

But AI is clearly much more than that. There are two distinct dimensions here:

First, what we build. When we imbue a product or feature with the capability of a large language model, we can do things that were previously impossible—or at least economically unfeasible. Take podcast transcription. Imagine you have 100,000 podcasts and want to build a player where every podcast has a transcript. In the past, you might have employed a tea of humans to create transcripts–but that’s prohibitively expensive. With AI models, it costs a few cents per podcast. You can generate the transcript the first time anyone listens and cache it for everyone else. Suddenly, something economically impossible becomes feasible, even with a very modest budget.

Second, and this is what I want to focus on in this piece: what do humans do when we have AI and language models at our disposal? What is our job when these tools can do a lot of what we do much more quickly, effectively, and efficiently, as in that example of podcast transcription?

The Limits of Vague Abstractions

Often, right now, we see people say things like, “Well, humans will do what humans can only do.” We talk about things like taste and discernment. Maybe that’s true, but it’s also nebulous and, frankly, in many contexts taste and discernment probably doesn’t matter all that much.

We’ve settled into a few familiar analogies:

The Manager Model: We’re like engineering managers with AI agents as our development team. We manage them, assign work, review their output.

The Artisan Model: We’re the craftsperson—the carpenter, the builder—who still does what we always did, just more quickly and efficiently. We lay the bricks; we just lay them faster, cleaner, more precisely because we have tools that handle the tricky, fiddly stuff.

These aren’t wrong, exactly. But they’re incomplete.

The Surgeon Analogy

Let’s think through what a surgeon does.

Yes, surgeons use scalpels to cut things. But that’s a superficial understanding. A surgeon is surrounded by a team—anesthesiologists monitoring vital signs, surgical nurses ensuring the right tools and information are available at precisely the right moment. The surgeon uses magnification not simply their own eyesight, and increasingly relies on robotic assistance where manual dexterity matters less than it once did.

But what really defines the capability of a surgeon?

Deep foundational knowledge. A surgeon has intimate understanding of human anatomy and physiology. The finger bone connects to the hand bone, yes, but more importantly: how this nerve bundle relates to that muscle group, how this drug interacts with that condition, how symptoms in the eye might indicate something happening in the cardiovascular system.

Pattern recognition built on experience. That foundational knowledge becomes intuition through thousands of cases during internship and practice. It’s not just hierarchical knowledge—it’s seeing how things connect in complex, non-obvious ways. This person has this symptom pattern, which combined with this history suggests this diagnosis.

Decision-making and planning. Surgeons draw on this deep knowledge to make a plan to treat a patient based on symptoms they’ve observed. Often routine, sometimes rare and abstract. Then they execute on that plan using tools.

It’s not just abstract theoretical knowledge. It’s embodied capability from doing the thing over and over again.

What This Means for Developers

Let’s think about using a code generation tool to build a component like a button. Suppose I’m not a software engineer, but–I’ve used lots of web pages. I’ve seen lots of buttons. I have taste. I have a lookbook. I know what I want to build. I can tell an AI model: “Build me a button that says Buy Now in our website’s color scheme.”

The model will build something that meets our request.

But what exactly will it build. Will it be an HTML button element? A div styled to look like a button? How accessible will it be? How will it connect to our broader website architecture and backend systems?

Now, give the same requirement to an experienced software engineer. First, they’ll ask questions about that button. But more importantly, they’ll be thinking: How do we ensure accessibility? What happens when the user clicks? What happens in edge cases? What happens on mobile devices with touch targets? How does this integrate with our existing component library?

There’s foundational knowledge here—of the web platform, HTML semantics, CSS layout, JavaScript event handling. Knowledge that’s tacit, absorbed over a long period of time. The ankle bone connects to the foot bone.

What Developers Bring That Models Can’t (Yet)

If I’m an expert in my field–a front-end developer, a Go developer, a Python developer. What are the implications of this AI transformation for me?

What do we bring that these models can’t do? Right now, these models are, as people observe, the statistical average of everything they’ve seen. That’s why they tend to produce things that may not be best practice. That may be out of date.

As an example from my experience, for a long time, unless I expressly specified otherwise, AI would build web page layouts using floats—a much older layout model—rather than CSS Grid or Flexbox. That’s improved, but two or three years ago this happened constantly.

Often a model will default to React because the statistical average of what it’s seen suggests that’s best practice. That’s not something I want it to do for all kinds of reasons, but this is where my knowledge matters. My knowledge sets expectations before the model starts working, and my knowledge guides refinement throughout the process.

The Real Skills That Matter

Coming back to the core question: What are the implications for you as a developer? This applies to other areas of expertise, but software is what I know well.

What matters is less how quickly you can type code, and more:

What data structure do you want?
How do you want to iterate over this returned result–do you want a map? forEach?
Which architectural pattern fits this problem?
What will be the the implications of this technical decision three months from now?

This is knowledge and capability you as an expert developer bring.

But here’s where the surgeon analogy breaks down in an important way: human anatomy and physiology don’t change much over long periods of time. The web platform changes constantly.

A big part of what I do in my life is keeping up with those changes. I run conferences that help developers keep up with the evolution of the Web platform. I post 20-30 pieces a week amplifying new features, refined techniques, and emerging patterns for developing for the Web (and then I bring them all together weekly in a newsletter). It’s a lot of work, and these models will always lag behind. The foundational layer the model learns from is always going to be behind the current state of the art.

Just one example, View Transitions went from a very experimental feature behind flags a couple of years ago in Chrome to being broadly supported across all browsers. Given the evergreen nature of browsers these days, something can go from experimental to widely usable in a couple of years.

So a big part of your job—focusing on the area of expertise I know well—is keeping up with how the platform is evolving. These are the primitives, like the anatomy and physiology a surgeon needs to know. But your anatomy and physiology changes all the time, changes constantly.

What This Means for Your Career

AI won’t make your expertise obsolete, It will make it increasingly essential.

But your value isn’t in your ability to type out boilerplate code faster than your colleague (or an LLM). It’s in:

Your deep knowledge of how systems fit together
Your pattern recognition from having solved similar problems before
Your judgment about which approach fits this particular context
Your understanding of trade-offs and implications
Your ability to ask the right questions before writing any code
Your commitment to staying current as platforms evolve

The AI handles the scalpel work. You’re still the surgeon making the critical decisions.

Staying Sharp

This is where I’ll make a pitch: developers need to invest in maintaining and deepening their expertise. And I’ll argue that a really efficient, effective way of doing that is to come to conferences.

Keeping up isn’t optional anymore. Indeed, it never was. It’s always been the core of what makes you valuable.

The models will handle more and more of the execution. What they can’t handle—what humans must bring—is the deep foundational knowledge, the pattern recognition from experience, and the judgment to make the right decisions in context.

We’re not power tool operators. We’re surgeons. And like surgeons, our expertise requires constant study, practice, and engagement with an evolving body of knowledge.

The pane of glass we’ve stared at for forty years is changing. But our role isn’t disappearing—it’s evolving into something that requires more depth, more judgment, and more expertise than ever before.

Web Directions Year round learning for product, design and engineering professionals