Much (but not all) of software engineering is more like bricklaying than architecture. And that’s part of why AI coding assistant hype is unevenly distributed.

If you were to sum up all the hours spent on software engineering by all software engineers, you’d find that most of itExcluding meetings, which most engineers have far too many of… is spent on implementation: adding features, fixing bugs, cleaning up code, refactoring, changing interfaces. I think of this work as “bricklaying.”

Software engineers do also spend a lot of time figuring out the details of how to execute tasks — novice engineers often spend the most, and as you get more experienced, you spend less and less. Wrestling with syntax, planning logic flows, looking up libraries and documentation, and so on. But this work is not architecture — it’s planning how to lay the bricks before you start.

Think about actual bricklaying. You get a diagram with a plan of where a wall needs to go. You then need to spend time sorting out how to execute on that diagram (“how do I make it curve like this?” “how do I make the decorative feature look like that?”). But you’re not doing the architecture — you’re planning for, and then executing on, the actual bricklaying. And the less skilled and experienced you are, the more time you’ll need to spend on the planning.

Architecture, on the other hand, is the creation of the blueprint and the overall approach to the project. And, it turns out, in aggregate we need way less architecture than bricklaying. There are about 125,000 architects in the US, and about 7,000,000 construction workers. I’d guess that the ratio of true software architects to software engineers is similar — at least in the same order of magnitude.

Before going further: I’m not casting judgement here on physical architecture versus bricklaying, or software architecture versus engineering. Both are beautiful, important, and hard. Great architecture work is hard (just like bricklaying), and great bricklaying requires craftsmanship (just like architecture).

But this post is about software engineering — bricklaying — not architecture.

Here’s my highly-precise-and-specific mental model for engineering productivityIf you’re missing any of the references: Lockheed Skunk Works, Healthcare.gov, Jeff Dean.:

Basically: 10x (or 100x, or 1000x) engineers do exist. It’s a power law dynamic. There are exceptionally skilled people who are productive — creating bricklaying output — at levels far beyond typical performance.

Recently, the technology world was given a “transformative” new tool for bricklaying: AI coding assistants. I’m talking about products like Cursor, Replit, and Windsurf, or even just interacting with LLMs like OpenAI’s or Anthropic’s.

But I’ve found wildly divergent perspectives on just how “transformative” these tools are.

Non-technical people seem underwhelmed (“it’s cool, but I’m still not really sure how to use it”).

Extremely talented engineers seem nonplussed or skeptical (“it’s cool, kinda helpful, but it makes mistakes and I don’t get the hype” — see any Hacker News thread on the topic).

But mid-range technical people like junior-mid engineers, technical product managers, and out-of-practice founders? They are over the moon. Suddenly, they can build things way faster and way better, and create products they would never have been able to build before.

Here’s what I think has happened:

Basically:

  • these tools still require strong engineering knowledge to be able to prompt them effectively and fix their mistakes — which means they can’t really be used by non-technical people
  • they speed up bricklaying and let you skip a lot of “planning” (not architecture!) — but for the truly exceptional engineers, that often doesn’t help so much (and sometimes introduces more problems than it solves, especially at the difficulty of problem they are working on)
  • but they are a game changer for everyone in the middle. Suddenly there is no more fighting with syntax, a huge speed boost for any repetitive tasks (which exceptional engineers often have their own tooling/techniques for), an ability to bypass the learning curve of new libraries and frameworks, and much more

The hype curve is unevenly distributed, and for good reason.

Of course, this is just what I’m seeing today, in December 2024. At the pace these tools are improving, I think that “booster curve” will change shape dramatically over the coming months and year — probably becoming much more even. (And over time, getting even more useful for architecture as well.)

Looking for more to read?

Want to hear about new essays? Subscribe to my roughly-monthly newsletter recapping my recent writing and things I'm enjoying:

And I'd love to hear from you directly: andy@andybromberg.com