The Architect, The Potter, and the Carpenter

Software architecture has historical roots in building architecture.

In physical construction, buildings are extremely expensive to change, once constructed.

If you get even the tiniest thing wrong in the planning, it can be ferociously expensive to fix later.

The solution in construction is to have a dedicated role -- the architect -- who plans every last aspect of the building in painstaking detail, before construction begins.

By the late 1960s an analogous architect role evolved into a key position on large projects.

There is a ton of research showing that the earlier a bug or requirements change is fixed, the less expensive the change overall. This is obviously true in physical construction, but hard-won experience has shown it also true in software, for example, the many studies cited in influential works like Steve McConnell's Software Project Survival Guide from Microsoft Press.

So for decades, the dominant model has was:
Plan carefully, thoroughly, and lock down key decisions as early as possible in the process.

But this is beginning to change.

AI and LLM tools — what’s now called “vibe coding” have seemingly changed things.

True, you can sit down with almost zero pre-planning, talk to the computer, tell it what you want to build, and presto bingo -- you've got code.

This is the opposite of the architect model.

It’s more like a potter model:

• You start with a lump of clay.

• You slap it on the table.

• You gradually form it into the thing you want.

This approach relies on continuous and extensive refactoring.

In fact, refactoring becomes the main operation after the short initial burst of creation.

This model brings its own problems — especially around maintenance, which we will discuss in future articles.

There is an intermediate model we can call the carpenter model.

A carpenter:

• Pre-plans to a reasonable degree, possibly with some shorthand (like 'use a dovetail joint here')

• Produces a cut list.

• Knows exactly what wood is needed.

• Has clamps, glue, and tools on-hand and ready.

• Uses purpose-built tools like table saws, miter saws, and routers.

Then they execute the plan. But during execution:

• Small mistakes inevitably happen.

• Adjustments need to be taken in stride.

• If an assistant is available, they can take on much of the grunt work.

A really good carpenter might not rely heavily on measurement -- they fit pieces directly against each other so things line up perfectly. This avoids transferring small measurement errors from ruler to saw.

This carpenter model is a hybrid approach to software development.

You still need to:

• Think before writing code.

• Own the architecture.

• Make the hard decisions.

But you allow generative AI to handle the grunt work -- cranking out the many lines of code that implement or re-implementing your ideas. Refactoring is not free, but an order of magnitude cheaper. You still need a viable starting design for structural integrity, and a constant eye on things to make sure you don't get wedged into a complexity trap.

This hybrid approach -- not pure waterfall architecture, not pure vibe-coding -- seems to be the most promising model going forward.

What do you think?

Join the discussion in Architect+ Discuss (free).