Why I Still Code as an Architect

There's a question I've gotten a few times over the years, usually from younger developers or project managers who seem genuinely puzzled: "Why are you still writing code? Isn't that what the dev team is for?"

The short answer is that I don't know how else to do the job.

The longer answer is that architecture without code is like navigation without ever looking at a map. You can talk about destinations all day, but eventually someone has to figure out which roads actually exist.

The Myth of the Pure Architect

Let me be clear about what I mean by "architecture" here. At the very highest level, sure, you don't need to touch code. There's a database. There's an application. There's some sort of gateway. At 30,000 feet, technology choices are almost irrelevant. You're dealing with business goals, system boundaries, integration patterns.

But as soon as you come down even one or two levels below that? Now you're choosing between Postgres and Mongo. You're deciding whether to use a message queue or REST callbacks. You're picking between a TypeScript stack and C# and Go. These are real technology decisions with real tradeoffs, and the only way to understand those tradeoffs is to have worked with the technologies.

I never understood how someone could stay in touch with the rapidly changing tech landscape if they were only doing "architecture." What does that even mean in practice? You sit in meetings and draw boxes on whiteboards, then hand off your diagrams to developers who discover that half your assumptions don't survive contact with reality?

The Prisma Incident

Here's a recent example. I've been building out a questionnaire app for our company. It's a business assessments tool, first iteration, prototype stage. I wanted to keep the tech stack simple, so I chose Next.js. All the tutorials and documentation pointed me toward Prisma as the ORM.

So I started down that path.

And it was hard. Normal development things were hard. I kept hitting friction and thinking "this shouldn't be this difficult." But I pushed through, because the docs said this was the way, and who am I to argue with the ecosystem?

It took me quite a while to finally say enough. The last straw was trying to Dockerize the Postgres database and the application. I work on a lot of projects simultaneously, and Docker containers let me move ports around easily, keep things isolated, keep my dev environment sane. This should have taken ten minutes. I spent an hour fighting it.

I stopped and did something I should have done earlier: I asked Claude to tell me what people don't like about Prisma.

Everything I'd been experiencing was a known issue. Prisma is great for new developers who don't want to think about proper frontend/backend separation, who have simple schemas, who aren't building anything too complex. I ended up calling it "ORM with training wheels," which is funny because plenty of database folks would say ORMs themselves are training wheels. But there's a difference between an abstraction that helps you work faster and an abstraction that prevents you from doing the work at all.

If I hadn't been hands-on with this, I never would have known. The documentation doesn't say "this will fall apart when you try to do real development things." I had to discover that by doing real development things.

What Good Architecture Actually Looks Like

A few months ago, I came into a project that was failing. The client, God bless him, was extremely budget-conscious. He was pushing back on every hour I spent in an advisory capacity. Two, three hours a week, and I'm getting questioned on it.

So I backed off. The developers had it. They could handle it.

Eight weeks later, they were at a standstill.

I had told the backend developer to use clean architecture. Gave him tutorials, showed him how to build it. He wasn't able to execute it. There were giant security problems, architectural problems throughout. On the frontend, my friend who was doing that work had organized things in an ad hoc way. Everything was mixed together: data fetching, state management, component logic, all tangled up. Lots of repetitive code. Difficult to know where anything was coming from.

It was a hard project to begin with. Legacy rewrite, porting from an older technology, and the client wanted to keep the look and feel. Lots of constraints. But the disorganization made it impossible to make progress.

I used Claude and Cursor to basically re-architect the whole thing. Good architecture in this case meant the right level of abstractions. Things that needed to interact generically were too concrete. Things that needed to be concrete were too generic. On the backend, cross-cutting concerns that needed to be split into separate classes. On the frontend, reusable components, a single source of truth for state, a clear layer for data fetching separate from other parts of the application.

The app went from 60% done with bad architecture to 95% done with good architecture. It took me about a week. Maybe four ten-hour days.

And then it got messy.

Everything had been moved around, and the developers were a bit uncurious about seeing what changed and how they needed to work with it. The budget-conscious client was asking why I spent all this time redoing things that were "already done." It was already working, they said. Why did you change everything?

I held my ground. Listen, this had to happen. You were stuck. We hadn't made progress in weeks because things had gotten disorganized and out of control. I made some decisions that needed to be made.

Eventually things got accepted. They're making progress again. But it was not ideal. We'll leave it at that.

The AI Makes This Non-Negotiable

Here's the thing about AI tools. Before generative models, you could maybe argue that staying hands-on was too time-consuming for a senior architect. Learning a new framework takes weeks. Building a prototype takes months. You've got strategic work to do.

That argument is dead now.

You can make toy applications and prototypes incredibly quickly. You can build out the prototype architecture you're trying to create, completely, then hand it off to the dev team. There's really no reason whatsoever why you wouldn't code.

Except that you're out of practice. Or you think you're better than coding, whatever that means.

The failing project I mentioned? I saved it with AI tools. I was able to re-architect a messy codebase in days instead of weeks. That's the kind of leverage that makes hands-on architecture not just possible but expected.

The Principal Engineer Who Couldn't Ship

I worked with a guy whose official title was something like Principal Engineer. He thought he was signing on to be an architect, an engineering manager type. In the end, he was just not capable of getting anything done. He was getting in the way of everything, throwing out ideas that were completely unmoored from the reality of the problem.

He wasn't willing to dig in and figure things out.

I see this pattern a lot. No condemnation on any of them. But you get to be an older developer, you think you know what's what, and you try to move into this advisory role where you're telling people how to dig without holding a shovel yourself.

My suspicion is that as we get older, we're just not as sharp as we used to be. That's just reality. The day-to-day details get harder to hold. And so there's this temptation to retreat upward, to operate purely at the strategic level where your wisdom and experience can add value without requiring you to understand what's actually happening on the ground.

The problem is that tech is moving too fast for that to work. You have to go really, really high up for general wisdom to be helpful by itself. At 30,000 feet, a sense of how the world works is valuable. At 10,000 feet, some value. At 1,000 feet, it's getting iffy. On the ground? There's no room for the guy holding up the shovel telling people how to dig. Everyone on the ground has to be digging.

Especially now that we all have the equivalent of steam shovels and bulldozers available to us.

The Process of Getting Dirty

When I'm evaluating a technology decision, I spin something up. I run tests.

There was a project early on where we were trying to figure out a messaging technology that would run on Linux on an ARM processor. We got a board similar to what the app would run on, wrote some tests, tried various messaging transport technologies. Eventually landed on ZeroMQ, which worked well for us.

That's what you have to do. The reality of technology is that you're very rarely aware of every detail going in. You have to walk down the path a little bit to start getting the shape of the problems you're solving. You have to push down into the problem depth-first to see the details, even if you're not solving every detail at every step.

This ties directly into holding plans loosely. You can't etch your architecture in stone at the beginning of a project. You have it drawn out on sand, and as new details come in, you make adjustments. That's the only way technology can work. It's moving too fast. The problem domains are too huge for anything else.

Lord Help Me

I wrote earlier about that principal engineer who couldn't ship. I said "Lord help me that I don't go this way."

I mean it.

I can already see that I'm not as sharp as when I first started. The main thing I notice is that it's harder to hold all the nuance in my brain at one time. My working memory is getting smaller. Maybe that's getting older. Maybe it's working on four or five or six projects simultaneously instead of one or two. But it used to be that I'd think about something for a little bit and all the nuance would come back. Now it's harder to get everything into working memory.

And honestly, the brain rot doesn't help. Too much doom scrolling. I'm not immune. I've fallen into that trap many times.

So what do I do about it? I work at every level.

Some projects I'm a solo developer, doing the architecture and writing all the code. Some projects I'm not even the architect, just helping manage the vision at a strategic level. Contributing at the highest and lowest levels is what keeps me grounded in reality. It gives me perspective because I can see things from both views and be the bridge between them.

It's not a complete defense against losing your edge. But it's something.

The Real Reason

Here's what I've come to understand: staying hands-on isn't about proving anything or maintaining status. It's about keeping your work connected to reality.

Architecture that isn't grounded in how technology actually works is just drawings. Pretty boxes that don't survive contact with compilers, databases, network latency, and all the other unglamorous realities of building software.

I still code because I don't know how to do good architecture any other way. The moment I stop, I become the guy in meetings throwing out ideas that don't connect to anything real.

And there are already plenty of those guys.