This analogy is fundamentally flawed, both literally and metaphorically:

  A surgeon isn’t a manager, they do the actual work! But 
  their skills and time are highly leveraged with a support 
  team that handles prep, secondary tasks, admin. The surgeon 
  focuses on the important stuff they are uniquely good at.

Surgeons are managers of the operations they perform and heavily rely on the surgical team with which they work. If the author had any clue about surgeries, they would understand that the most important person in a major surgery is the anaesthesiologist, not the surgeon(s).

Second, the metaphorical.

The author goes to great lengths to identify "grunt work" as being "not the most intellectually fulfilling or creative part of the work." What they do not do is understand that there is no such thing as "grunt work" if, for any definition of work, it is valued without judgement.

But if a person identifies with being "the surgeon", with everyone else being "a support team that handles prep, secondary tasks, admin", then the post makes sense from an egocentric perspective.

I’ve long advocated that software engineers should read The Mythical Man-Month[0], but I believe it’s more important now than ever.

The last ~25 years or so have seen a drastic shift in how we build software, best trivialized by the shift from waterfall to agile.

With LLM-aided dev (Codex and Claude Code), I find myself going back to patterns that are closer to how we built software in the 70s/80s, than anything in my professional career (last ~15 years).

Some people are calling it “spec-driven development” but I find that title misleading.

Thinking about it as surgery is also misleading, though Fred Brooks’ analogy is still good.

For me, it feels like I’m finally able to spend time architecting the bridge/skyscraper/cathedral, without getting bogged down in terms of what bolts we’re using, where the steel come from, or which door hinges to use.

Those details matter, yes, but they’re the type of detail that I can delegate now; something that was far too expensive (and/or brittle) before.

[0]https://en.wikipedia.org/wiki/The_Mythical_Man-Month

It's a nice analogy, and I think I'll use it in future.

If you want another one, think of painting. An "Old Master" painter like Rembrandt or Rubens or Botticelli would have had a large workshop with a team of assistants, who would not only do a lot of the work like stretching canvases or mixing the paints, but would also - under the master's direction - actually do a lot of the painting too. You might have the master sketch out the composition, and then paint the key faces (and, most of all, the eyes) and then the assistants would fill in areas like drapery, landscape, etc.

This changed in the Romantic period towards the end of the 1700s, with the idea of the individual artist, working alone in a moment of creative inspiration and producing a single work of genius from start to finish. Caspar David Friedrich or JMW Turner come to mind here.

Some programmers want to be Turner and control the whole work and feel their creativity is threatened if a machine can now do parts of it as well as they could. I'd rather be Rembrandt and sketch out the outline, paint the eyes, and leave the rest to junior engineers... or an AI Agent. It's a matter of preference.

This reminded me of a slide from a Dan North talk - perhaps this one https://dannorth.net/talks/#software-faster? One of those anyway.

The key quote was something like "You want your software to be like surgery - as little of it as possible to fix your problem".

Anyway, it doesn't seem like this blog post is following that vibe.

I like this approach. After some months of gamely trying to involve Claude in my coding process, I find it's much more enjoyable and efficient for me to just write the code myself, rather than babysitting it and going over and over something it wrote finding errors and logical flaws. I was about to cancel my subscription.

This month, however, I had to start upgrading a very large db from MySQL 8 to 9, on a codebase that involves a few hundred long and complex queries. I wrote this code, so I know what they do and I understand the schema, but I'm also aware that some of them may violate ONLY_FULL_GROUP_BY, and a few (but can't remember which) had historical oddities unless DERIVED_MERGE was turned off. I was girding myself to run tests on dozens of suspects, but as a lark I handed Claude the whole codebase and the schema and asked it to identify any queries that might break if those two default options were enabled. Astonishingly, it did. It identified 15 queries and explained what they violated. It was wrong about 7 of them... those seven were actually fine, and it acknowledged that it had farmed this out in some way and that whatever it used for evaluation had been overly conservative and had returned false positives. But the other 8 queries were fixable. It was also a bit off about how to rewrite them - it created a lot of slow and inefficient workarounds. It neglected the idea of lateral joins, it didn't write SQL optimized for the indexes, etc. But it saved me hours and hours of locating these queries myself.

To me, this idea of letting the LLM render down a lot of code into potential pain points seems like a much more valuable use of it than asking it to write code itself. I kept my subscription for that reason.

   Like a surgeon
   Coding for the very first time
   Like a suuuuurgeon
   Let your script run
   Close to mine

So the Chief Programmer Team structure [0] is back in fashion is it.

But this time with agents.

Fred Brooks has never been more relevant.

[0]: https://en.wikipedia.org/wiki/Chief_programmer_team

> Yes, junior members will often have more grunt work, but they should also be given many interesting tasks to help them grow.

This and all the talk of status is a bit worrying

Junior devs are challenged by and have room to grow from tasks that would be routine and boring for a much more senior dev. The junior member might be completely out of their depth taking on a task that the senior dev would be challenged and grow from. This may influence who should do what tasks, although collaborating on a task is often an option

Interestingly, I used the exact same metaphor the other day. Suggesting that tools like GitHub Speckit should have /wrap-up command:

> And then maybe "/wrap-up" to tie all the untied knots once you're sufficiently happy. Kinda like surgeon stepping aside after the core part of the operation.

The role of the engineer in large enterprises with deep legacy systems is indeed quite like a surgeon, but not for the reason suggested. Rather, it involves delicate operations on a complex and confusing object that you didn’t design or build, that maybe nobody really understands in full, where simply locating the problem is more than half the job, where parts depend on other parts in unexpected ways, where one tiny mistake can have catastrophic consequences, and where a litany of credentials and clearances are required before they’ll even let you near the operating table.

I really like Geoffrey Litt's new analogy for working with AI coding tools:

> Personally, I'm trying to code like a surgeon.

> A surgeon isn't a manager, they do the actual work! But their skills and time are highly leveraged with a support team that handles prep, secondary tasks, admin. The surgeon focuses on the important stuff they are uniquely good at.

It's also a neat callback to the Mythical Man Month, the most influential early textbook on large scale software engineering.

The surgical metaphor really resonates with my experience building real-time interview analysis systems. One key parallel I've found is that both surgery and complex software require careful state management and graceful error recovery.

When we first implemented real-time code analysis during interviews, we struggled with the "do no harm" principle - how to provide feedback without disrupting the candidate's flow. Our initial approach of running full AST analysis on every keystroke caused noticeable UI lag (150-200ms). We solved this by moving to a chunked analysis pattern with a 500ms debounce and incremental parsing. This reduced CPU usage by 70% while keeping perceived latency under 50ms.

The trickiest part was handling partial/invalid syntax states without crashing the analyzer. We ended up implementing a recovery mechanism similar to how modern IDEs handle incomplete code - maintaining a stack of valid states and rolling back on error rather than failing completely. Curious if others have found better approaches to real-time code analysis with incomplete input?

If you code like a surgeon, feature/bug has to be completed during code surgery, the story points completed immediately (during surgery). In one sprint 3 years worth of features/bugs will be fixed. What will they do the remaining 3 years?

> The surgeon focuses on the important stuff

Yikes. Don’t code the way this author thinks surgeons operate. All those “support” tasks are critically important and you likely couldn’t do them as well. Be humble and appreciate that all the stuff being done around you is also the important stuff. Support them just as much!

I'm somewhat of a prompt surgeon myself. I find prompts online and then hash them together to fit my needs.

> My current goal with AI coding tools is to spend 100% of my time doing stuff that matters. (As a UI prototyper, that mostly means tinkering with design concepts.)

this struck me as weird. both in terms of “tinkering” being the most important thing to be doing, and then also describing “working like a surgeon” to be tinkering.

This is what I am doing these days.

Spent most of my time in thinking and asking Claude the right questions at the right moment instead of typing code. Review the code agent generated, let it run tests, deploy to PR branch for live debugging. Review console log and network traffic, paste the information to Cursor and ask Claude for the root cause, code paths and data flow. Solve issues one at a time.

It does feel like a surgeon working with a team of assistants. A lot of information, a lot of decisions, a lot of patience and focus.

It looks like the future is already here.

I'd like to officially coin the term "Trad Engineering" and/or "Trad Coding".

I'm always finding sponges and gloves that were left inside our patient after previous operations.

Modern surgeons evolved from barbers and butchers.

Code surgeons, where are they now on the evolution path? Barbers? Butchers?

Yes, code like someone might die if you make a mistake!

Can you imagine a surgeon using Claude Scalpel as an agent to just go ahead and fix that one artery?

This post is no longer relevant with Codex and Claude 4.5. You don’t need to be the savior that does the highly specialized important work. You just need to come up with the design and specs you need, then you need to ensure it implements them. So, you act as architect and manager, not a surgeon.

The analogy I have used is “AI as sous chef.”

Another way of saying this is:

If your development team consists of autistic junior programmers with eidetic memory, then you damn well better make sure that your documentation is exceedingly thorough, absolutely unambiguous, and as restrictive as you can make it.

it's the second time this week I see this link being posted and it's the second time this week I read it as a 'sturgeon'

“First, do no harm”.

“Surgically” is how one enters a foreign codebase, especially legacy ones.

Beautifully designed site. Looks sumptuous on mobile..

As a coder and a neurosurgeon, lol.

Oh- oh god! Blood everywhere!

I wonder if OP reads all the code the AI gives him.

I doubt it, quite dangerous.

The Mythical Man-Month focuses on a simple idea.

It can be summarized as "adding more workers to a project does not speed things up, that's a myth".

It's in the title of the book. It's a good book.

The entire IT field is about to test that idea in a massive scale. Can lots of new automated workers speed things up? We'll see.

I sometimes use AI summaries to get the answers I need out of badly written documentation. That's about as far as I find any value or productivity boost.

Consider that this "surgeon" analogy has always been applicable when docs or books are better written and full of useful examples. Also consider that a lot of the annoying "plumbing code" you probably want AI for is fairly closed-ended as there are only so many combinations of API use possible.

I'm really not understanding the continued hype in 2025.

A surgeon has 4 years of undergraduate education, 4 years of medical school, and a 5 year residency, learning to operate (pun intended) with other equally highly trained specialists, many of whom are peers, like anesthesiologists, not merely support. The comparison was already dubious when Brooks made it for operating systems programming. Setting up a comparison with the average "I don't use anything I learned in my CS degree, lol" coder wrangling a chorus of hallucinating stochastic parrots is a bonkers level of hubris from techbros.

> Code like a surgeon ... As a UI prototyper

XD yes sure. I'd most definitely put those on the same level. Maybe even favor an UI prototyper if it comes down to the real deal. Who needs an open heart surgery when you can have a magnificent css-hover animation that really seals the deal on some 90%-AI-generated slob that only caters to delusional top-management completely out-of-touch with reality.

Irony off: Let's try it with a bit of humbleness next time, ey?

My god, don't code like a surgeon!

Code like a programmer.

This article further emphasizes the obvious point that as programmers are well on the way to destroying their own profession and their work is poised to wreck the entire world, that it's time raise awareness that programmers work with much less discipline and responsibility than other professional, accredited, licensed trades, like say... doctors.

But for now, sure, why not just compare yourself to surgeons, as you already anoint yourselves as "engineers".

Not to be confused with coding like a sturgeon which is blub blub blub blub