Cathedral Builders Probably Shouldn't Use Coding Agents

Musings on different kinds of programmers and who benefits from AI

Source

In the past two months I’ve spoken to maybe three dozen different engineers who use coding agents. Single person companies just getting their footing. Series B growth stage everything is on fire. Massive companies like Apple. Companies in disparate industries from chemicals to manufacturing to SaaS. For the most part I am a huge believer in coding agents, and as I’ve written in the past they have massively sped up my process.

But no matter where I went, on every team I spoke to there was always at least one guy who was adamant that these things suck ass and they will never be any good. A good founder tries to pull out patterns from the people they talk to. So who were these guys?

• Generally, these were extremely well respected engineers on the team, people who were responsible for the direction of not just the tech stack but often the entire product.

• They were rarely managers themselves. They almost never had direct reports. That’s not to say they didn’t have mentorship responsibilities; rather, they didn’t really do people management.

• These engineers were very opinionated. They had thoughts about coding process, of course. But they also cared a lot about the structure of the codebase itself. Often, that was because they were responsible for the codebase. These folks were often the person who had all or most of the codebase living in their head.

Eventually it clicked: these were cathedral builders. Every engineer I knew who hated coding agents built cathedrals.

For folks who aren’t aware of the metaphor, the term ‘cathedral builder’ comes from an essay titled The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary by Eric Raymond back in 1999. At the time, Raymond was speaking about different ways software got built. You had the cathedrals where software was released to the public bit by bit and development was confined to a small number of developers. And you had the bazaar, where software was developed in public entirely, and where anyone could contribute.

I think over time, the metaphor has evolved. Where once it referred to kinds of process, it now refers to kinds of programmers. There are cathedral builders, and there are bazaar shop owners.

The cathedral builders are perfectionists. They take rigor to an art form. They care deeply about every character in their code. The code is a temple, a place of worship (at my last startup, our resident cathedral builder literally named our terraform repo ‘chapel’). I’ve had the pleasure of working with some incredible cathedral builders, and I’ve learned more from cathedral builders than I have from anyone else. They are often tech leads, and just about every 1000x engineer I’ve ever met is a cathedral builder.

The bazaar shopkeep is the opposite. They care about getting things done. Plugins, interfaces, hide the dirty code and make things extensible so everyone can play along. For this kind of programmer, the code is a means to an end, and its sometimes unclear whether this archetype even likes programming all that much! Often bazaar shopkeepers make for great managers and strategists. I personally fall into this category. I like programming, but I’m an engineer. The code is a means to an end.

No one is 100% a cathedral builder or 100% a bazaar shopkeep, it’s a spectrum. But I’ve found that the more someone falls towards the cathedral side of the spectrum, the more likely they were to dislike coding agents. Not everyone; I know cathedral builders who love coding agents. But everyone who hated coding agents was, to a t, a cathedral builder.

I think this makes a lot of sense.

The average cathedral builder is thinking extremely deeply about one task at a time — often the most impactful task for the technical team, things that only they can build. At SOOT, there was a week where our cathedral builder just disappeared, and when he came back he had built a library that ended up being the backbone for all of our multiplayer functionality. That thing was magic, and it was just absolutely the most important thing he could have done with his time.

I’m reasonably confident that that process would not have benefited from coding agents, like at all.

In some sense, the point of a coding agent is to distance the engineer from the code they are writing. In some cases this is quite extreme — when I use a nori-powered agent, the coding agent is often chugging away autonomously for ten, twenty, thirty minutes before I check in on it. That’s great for me, because I’m not working on one extremely nasty extremely difficult problem at a time. I’m working on like 5 mostly straightforward problems. But if you’re the kind of person who’s primary workflow involves thinking super deeply about one thing, then even the simplest coding agent is designed to pull you out of that flow. A simple ‘hello world’ request from Claude Code takes ~5 seconds. Asking it to write ‘hello world’ to a python file takes ~20 seconds. In that time, you’re just sitting there twiddling your thumbs!

Never getting those 5 seconds of my life back

The coding agent is built to disconnect you from whatever you’re thinking about, which makes it uniquely bad for cathedral builders who need to think deeply about problems for long periods of time before they can make progress. So I think if you’re a cathedral builder you probably shouldn’t use coding agents at all.

The one caveat: research. I think coding agents are still great for research, and even the most committed cathedral builder can still benefit from having a coding agent do a bunch of research on things in parallel and come back with some suggestions. I might add a ‘cathedral mode’ to nori for this exact use case…