The Best Architects Never Stop Coding

You can't feel what your own design costs unless you build something in it. And nobody is going to tell you.

“Architects don’t code.”

I’ve heard this sentence too many times.

And every time, I worry.

Because the moment someone thinks coding is beneath them, they are already moving away from the thing they’re supposed to understand.

The code.

The good ones

The best architects I’ve worked with never stopped writing code.

They reviewed pull requests.

They paired with developers when something got stuck.

They built the first few features of what they designed.

They understood the pain developers faced because they experienced it themselves.

"Coding is below me"

In many companies, an “architect” is what you get when there is nowhere else to go except management.

The architect stops coding. Not because the job doesn’t need it, but because the title says they’ve outgrown it.

Then the calendar fills up. Meetings, roadmaps, steering committees.

A year later they are deciding how the system should be built, without knowing how it is built.

“But nobody writes code by hand anymore”

This is where someone brings up AI.

If developers are generating most of the code, why should an architect write any?

Because typing the code was never the point. Knowing how the system is actually built was.

You can know that without writing every line yourself. You can’t know it without reading any of it.

Someone still has to notice that logging is now done three different ways in three different places. Or validation. Or error handling. Nobody told the model how this codebase does any of it, so it picked something reasonable each time.

What you want is consistency in the design itself: the same kind of problem solved with the same structure everywhere, so that a developer who has read one part of the codebase can predict what the next part looks like. No diagram gives you that. It comes from someone reading the code and saying, we already have a way of doing this, use that one.

That work is closer to the code than a diagram ever gets you. An architect who only reviews the design, and never looks at what came out the other end, is exactly as far away as before. The tooling is just newer.

If anything, AI makes it worse. More code arrives, faster, and less of it has been thought about by anyone. Judging whether it fits the system is more work than it used to be, not less.

Don’t become an ivory tower architect

The dangerous architect is the one who designs a system they would never have to maintain.

There is no way to find out what a design costs except to build something in it. Add a feature. Change one that already exists. Fix a bug in it six months later. That’s when you find out which parts of your own design fight you — the layer you have to touch every time, the abstraction nobody can extend without asking you first, the test that takes ten lines of setup before it can assert anything.

And don’t expect anyone to report it back to you.

Developers mostly won’t tell you the design is painful. You’re the architect, you decided it, and to them it’s a given — something to work around, not something to question. The more junior they are, the less likely you are to hear about it at all. What comes back is “it took a bit longer than we thought.”

If you haven’t opened the codebase in months, you’re not designing the system anymore.

You’re describing one.

---

Join the live training session:

Clean Architecture for Backend Developers

🗓 Aug 26
⏰ 5:00–6:30 PM (CEST)