There is a moment in every senior technologist's career where you realize you have not written production code in years. Not because you forgot how. Because the system you built around yourself, the teams, the processes, the review boards, made it unnecessary. Or so you were told.

I spent four decades in software. The first twenty years I built it. Then I built organizations that build it, then strategies about how organizations should build it. Each step up the ladder felt like progress. Each step also added another layer of abstraction between me and the thing I originally loved: making something real.

Then, one evening in February 2026, I sat down with an AI coding assistant and started building a content management system from scratch. Not a proof of concept. Not a demo for a keynote. A real system, in Java, with a real database, a real deployment pipeline, real readers on the other end. I shipped it to production. It runs today. You might be reading this on it.

And something shifted. Not just in what I built, but in what I understood about the relationship between experience, tools, and the craft of software itself.

The Distance We Created

The history of software leadership is a history of creating distance. You start as an engineer. You solve problems directly. Then you become a lead, and your job is to make sure other people solve problems well. Then you become an architect, and your job is to make sure the problems themselves are well defined. By the time you reach CTO, you are three or four layers removed from the act of building. You shape strategy. You set direction. You review what others have built. But you do not build.

We told ourselves this was necessary. And in many ways it was. Complex systems require coordination. Large teams require structure. Enterprise software at scale cannot be a solo act. The org chart was itself a technology, an abstraction layer that let us manage complexity by distributing it across humans.

But abstraction always has a cost. Every layer you add between intent and implementation creates room for misunderstanding, delay, and dilution. The architect draws a diagram. The team interprets it. The code reflects the interpretation, not the intent. Somewhere between the whiteboard and the pull request, the clarity you started with gets negotiated away.

What I did not fully appreciate, until I experienced its absence, is how much that distance had cost me personally. Not just in efficiency. In understanding. When you stop building, you stop learning the things that only building teaches you.

Building Alone, Together

The system I built is called the.feed. It is a publishing platform, written in Java 21 with Javalin, backed by SQLite, deployed on a Linux VPS in Denmark. It handles markdown rendering, RSS feeds, analytics, SEO, an admin interface. It is not large by enterprise standards, but it is complete. It does a real job for real people.

I built it with Claude Code as my pair.

What surprised me first was not the speed, though the speed was startling. The entire Java codebase came together in a single focused session. What surprised me was the nature of the collaboration. I was not delegating. I was not managing. I was not reviewing someone else's interpretation of my intent. I was thinking out loud and watching the thought take shape in working code, almost in real time.

At 11pm on a Tuesday, I was making architectural decisions about database schema design. Not reviewing someone else's proposal. Making them. Seeing the consequences. Adjusting. This is a feeling I had not had in twenty years. The feedback loop between idea and artifact was so short that it changed how I thought. When the cost of trying something drops to nearly zero, you try more things. You explore. You play. I had forgotten that building software could feel like play.

But let me be honest about the other side.

AI did not replace my judgment. It replaced my typing: the hours of boilerplate, the lookup of API details I once knew but had not used in a decade, the mechanical translation of intent into syntax. What it could not do was decide what to build, or why, or know when something was architecturally wrong in a way that would only matter six months from now.

There were moments where Claude Code confidently produced something that looked correct and was subtly, dangerously wrong. The kind of wrong that a junior developer would ship and a senior one would catch in review. My many years of experience were not optional in this process. They were the thing that made the process work. The AI was fast. I was right. Together, we were both.

This is the part that most commentary about AI-assisted development gets wrong. The narrative is either "AI will replace developers" or "AI is just autocomplete." Neither captures what actually happens when a seasoned builder works with these tools. What happens is that experience becomes more valuable, not less. The bottleneck is no longer the ability to write code. It is the ability to know what code should be written, and to recognize when what has been written is not quite that.

What the Hammer Revealed

So what does this mean? Not just for me, but for the craft, for teams, for the way we organize the work of building software?

First, it means the abstraction layer of the org chart is no longer the only way to scale intent. For decades, the only way a senior technologist could multiply their impact was to hire people, build teams, create processes. AI offers a different path. Not a replacement for teams. But a collapse of the distance between the person with the deepest understanding of the problem and the running code that solves it. That changes what it means to lead a technical organization. It does not make teams unnecessary. But it makes the interface between human intent and machine execution the most important design surface in the system.

Second, it means that experience is about to have a renaissance. When code was expensive to produce, we optimized for production speed. We hired junior developers and scaled teams. When code becomes cheap to produce, the constraint shifts. The scarce resource is no longer the ability to write code. It is the ability to know what software to write, to see the failure modes before they manifest, to hold the whole system in your head and know where it will bend. That is what experience gives you. And for the first time in a long time, the tools let you use it directly.

Third, and this is the part that is personal: it means the builder can come back. Not as nostalgia. Not as a side project. As a legitimate mode of working. I am a CTO who built a production system in an evening, not because I was playing, but because it was the fastest, highest-quality path to the outcome I wanted. That sentence would have been absurd two years ago. It is simply true now.

I received my first computer at fourteen. A Tandy TRS-80 with BASIC. I still remember the feeling of typing a program and watching the screen respond. Something from nothing. Intent made real. Four decades of career progression carried me away from that feeling, one promotion at a time. AI brought me back.

The architect picked up the hammer. And it turns out he never forgot how to swing it.