21 March 2026
The Architect Who Learned to Build
Boris Cherny said a coder is now more like an architect than a construction worker. I read that from the other side of the transition — an enterprise architect who discovered he could actually build.
A recent piece in the New York Times included a quote from Boris Cherny, the head of Claude Code at Anthropic, that I haven’t been able to stop thinking about:
“A coder is now more like an architect than a construction worker.”
The article explored what’s happening to software developers as AI takes over the act of writing code itself. The consensus among the developers interviewed was clear: the job has shifted. Less construction, more design. Less creating, more judging. The work is now about the overall shape of the software — how its parts fit together, whether the structure holds.
It’s a fascinating piece about a profession in transition. But I read it from the other side of that transition.
The reverse journey
I’m not a developer who learned to think like an architect. I’m an enterprise architect who, in the last few months, discovered he could actually build.
For most of my career, ideas stayed ideas longer than they should have. Not because they weren’t worth pursuing, but because bringing them to life required things I didn’t have: deep coding skills, a development team, time, budget, and the ability to explain a vision clearly enough that someone else could execute it without losing what made it interesting in the first place.
That friction was real. And it meant a lot of ideas either died quietly or emerged from the other end of a collaboration as something slightly different from what I’d imagined.
What actually changed
What I didn’t expect when I started building with AI was how creative it would feel.
The framing in most articles about AI-assisted development is that it’s a productivity story — you get things done faster, you ship more, you clear the backlog. That’s true. But it misses something more fundamental.
When the barrier between idea and working product collapses, creativity doesn’t diminish. It accelerates. I’m not judging instead of creating — I’m doing both, faster and more freely than before, because the cost of trying something has dropped to almost nothing.
Ideas that once required effort, dependency, and compromise to bring to life now run straight from my thinking to a working prototype. The path is mine. That’s not a productivity shift. It’s an agency shift. And it changes not just what you can build, but what you’re willing to attempt.
The concern worth taking seriously
The article raises a question that I think deserves honest engagement: if the job is now less about writing than assessing, how will the next generation of developers learn to assess?
It’s a real concern. Some junior developers interviewed in the piece described feeling their skills weaken after just months of heavy AI use. If you’re not building the instincts for what good code looks like, how do you develop the judgement to catch what the AI gets wrong?
But here’s what the article doesn’t fully explore: assessment isn’t primarily a coding skill. It’s an architecture skill.
Evaluating tradeoffs. Questioning assumptions. Recognising when something is structurally unsound even if it technically works. Knowing which constraints matter now and which ones will matter later. These are the instincts I’ve spent years developing — across industries, across contexts, across problems that had nothing to do with writing code.
That’s my floor. And it turns out, it’s exactly the floor that AI-assisted development needs.
The developers who are thriving with AI tools aren’t just the fastest coders — they’re the ones with the deepest sense of what the system should look like before a line is written. That’s not a new skill. It’s architecture. It’s just being asked for in a new place.
Where the two journeys meet
The developers are becoming architects. The architects are becoming builders. These two journeys are converging, and I’m not sure either group fully realises it yet.
What I do know is that the skills that felt most specialised — systems thinking, domain clarity, structured decision-making — are turning out to be the most transferable. And the barrier that kept people like me from building is lower than it has ever been.
The question I keep coming back to, for anyone in a technical leadership or architecture role watching this from the sidelines: what would you build, if the barrier wasn’t there?
This series started as an experiment. It’s turning into something I didn’t expect — a genuine rethinking of what it means to have ideas and the ability to act on them.