I have been writing software professionally since 1999. I've been a junior developer, a senior developer and a CTO, and I've managed engineering teams of more than 30 people across offshore and nearshore time zones. Today I'm a guy with a few Claude Max subscriptions, and I ship more software than I ever have.

This year, agents took over the typing. My latest app was built start to finish by agents. I didn't write a line of its code, and I didn't review one either.

I didn't plan to write a series. It came from three things that kept piling up. I kept reading doom-and-gloom articles about AI and engineering jobs. I kept talking with doubters, and helping some of them come around. And I kept coming back to the same question in my own head: if coding is solved, now what? Part of that question is excitement. Part of it is sadness. If teams aren't needed the way they used to be, what will everyone do?

So here is my answer to the question a lot of people in this industry are quietly asking: writing code is solved. Building software isn't. The job didn't disappear. It moved, and this series is about where it went.

A word on scope, because it matters. I build product software: web apps, internal tools, APIs and services. For that kind of work, producing the code is no longer the bottleneck. I'm not claiming that every kind of software, from flight controllers to cryptography, can now be built without anyone reading the code. And when I say "agents," I mean AI coding tools like Claude Code or Codex that can read a repository, run commands and make changes on their own, not autocomplete in your editor.

What's actually solved

For most of my career, the limiting factor was whether we could write the code: whether the team knew the stack, had the hours, could get it right. Somewhere in the last few model releases, that stopped being the bottleneck. The models can write the code. The limiting factor now is whether we use them well.

I'm not alone in this. At Rails World in September, DHH opened his keynote by announcing that 37signals has gone "pencils down" on hand-written code. Dewayne VanHoozer, who has been programming since APL in 1970, wrote the best take on that keynote I've read: "Each step took something off my hands and left me more room to be creative. Code is going the same way. The part I used to type is now the part I describe."

The part I used to type is now the part I describe. That's the shift in one sentence.

What isn't

Here's the strongest objection, and it deserves a real answer.

Alex Ewerlöf wrote Coding is NOT solved the same week as DHH's keynote. His point is that creating code was never the expensive part: "anyone who has run software in production at scale knows that maintenance, reliability, security, scalability, etc. is the majority of the cost." And the line I can't shake: "AI can explain it to you but it cannot understand it for you."

He's right about what's still hard. Agents can write the code, but they can't decide what's worth building. They can't tell you that you're solving the wrong problem. They can't be accountable when it breaks at 2 a.m. in front of real users. Understanding the system, owning the outcome, and putting your name on what ships: none of that got automated.

Where I disagree is what that means. Ewerlöf reads it as "coding isn't solved." I read it as "coding was never the whole job." Writing the code was the part we spent the most hours on, so we mistook it for the job. Now that it's cheap, we can see what the job was all along.

OpenAI's account of its own research team is a telling example. By its own count, its researchers now run more agent-hours than human hours, and here's how it describes what's left for the people: "People still set our research priorities, judge which ideas and results to pursue, and decide whether to scale, pause, or deploy systems." Swap "research" for "engineering," and that's the new job.

From laborer to architect

For most of my career, I was both the architect and the laborer. I decided what to build, and then I spent most of my hours laying the bricks myself. I liked laying bricks. Squeezing a hot path, shaving milliseconds, rewriting a query until the plan looked right. That was the fun part.

For the kind of software I build, the bricks are handled now. What's left is the architect's job:

  • Deciding what to build, and noticing when it's the wrong thing.
  • Describing how it should work, precisely enough that someone else can build it.
  • Building the guardrails: the tests, the checks, the docs that keep it honest.
  • Owning the outcome, including the parts you didn't type.

That job is bigger than it sounds, and harder. It's also where most of the leverage is. An engineer who's good at it can do what used to take a team.

I'd be lying if I said there was no loss in this. The thing I was proud of being good at for 25 years, typing correct, fast code, isn't the scarce skill anymore. That's real, and I don't think engineers should be embarrassed to say it out loud. But mostly I feel like a kid who just got a much bigger box of Legos. I got into this to solve problems, and I'm solving more of them than ever.

Why now

I don't think this shift is slow, and I don't think it stays optional for long.

The early data points the same way. Stanford's Digital Economy Lab found that employment for 22- to 25-year-olds in AI-exposed jobs like software development is 19% below where it would be if it had kept pace with less-exposed work. The researchers are careful to call these early, descriptive findings, not proof of cause. But it's the pressure you'd expect: not mass layoffs, just fewer people hired to lay bricks.

Every wave I've lived through (the web, offshoring, the cloud) came with headlines about programmers being replaced, and every one ended with more software and more programmers. I think this one ends that way too. But those waves took years. This one moves at the speed of model releases, and teams adopt the tools in weeks.

The engineers who make the switch to architect early will do very well. The ones who wait for it to settle down will find it already has, without them.

Now what?

That's what this series is for. Each part takes one "now what?" at a time: how to start, how to work, how to own code you didn't type, how to bring a team along, which skills matter now, and finally, what to build.

It ends on purpose with the good news. Building software has never been cheaper to try, and the best way to learn the new job is to start doing it.

Next up: your first week.