Last month a friend walked me through a system she built for her business. She’s a developer marketing and social media strategist who has worked with large clients and small ones, and she knows how to make a post go viral. Her system takes a client’s idea and has an AI rewrite it in her voice, using years of her own writing as examples. Then it tailors each post to the client’s goals, adapts it for every platform they care about, and publishes on a schedule. She isn’t a software engineer. She had a clear idea, an AI assistant, and the persistence to keep going until it worked.

I was genuinely impressed. And somewhere underneath that, I felt a small, uncomfortable question I suspect a lot of people in my position are feeling right now: if she can do that, what exactly is my job?

I’ve been building software for nearly forty years. I started when compiling meant going to get coffee, and I’ve lived through client-server, the web, SOA, the cloud, microservices, and now this. Every one of those shifts lowered the barrier to entry. None of them lowered it like this one has.

Is architecture king, or do I just need it to be?

My first instinct was the comfortable answer: architecture is king. The AI can write the code, but someone still has to decide what the system should be. That someone is me.

I want to be honest about that instinct, because it’s exactly what a person with my résumé would want to believe. Architecture is where my advantage lives, so of course I think it matters most. Every blacksmith thought horseshoes were the hard part.

So I tried to argue the other side. Maybe architecture is just another thing the models will learn. Maybe in two years you’ll describe your business and get back a well-structured system, tested and deployed, no greybeard required.

Here’s where I landed. The models will get much better at producing architecture. What they won’t do, at least not anytime soon, is own the consequences of it. And that is the part that was always the actual job.

Code got cheap. Decisions didn’t.

AI has collapsed the cost of turning an idea into working code. That’s real, and pretending otherwise is just nostalgia.

But think about what a system like hers has to survive. Years of her writing and every client’s goals, schedules and drafts live wherever the assistant decided to put them on the first afternoon. What keeps one client’s content from ever showing up in another client’s feed? What happens when a platform changes its API or its rate limits, or a scheduled post silently fails at 2 a.m.? What happens when she hires a second strategist with a different voice? None of that is a criticism of her; the system works, and it’s clever. It’s simply that every one of those questions is a decision, and unless someone makes it deliberately, the AI makes it silently, optimizing for “make the demo work right now.”

That’s the shift I think matters. The bottleneck in software has moved from writing to deciding. When code was expensive, bad decisions were partly hidden by how slowly we could act on them. Now you can build the wrong thing at astonishing speed. You can also build a perfectly reasonable thing that quietly paints you into a corner six months from now.

An AI assistant is an extraordinary engine. It is not a map. It will happily drive you anywhere you point it, very fast, including off a cliff.

What forty years actually buys you

When people talk about experience, they usually mean knowledge. I don’t think that’s the valuable part anymore. The AI knows more patterns, frameworks, and APIs than I ever will. What experience gives me is three things the model doesn’t have.

  1. I know where I’m going before I start. I don’t fumble through options or let the assistant make the big calls by default. I’ve built this shape of system before, more than once, and I can see the finished thing while it’s still a sentence.
  2. I’ve already made the mistakes. I’ve shared a database between services and spent a year untangling it. I’ve built the clever caching layer that made every bug impossible to reproduce. I’ve trusted a vendor’s “we’ll never change that” and rewritten the integration twice. Those scars are a list of gotchas I check against without thinking.
  3. I know which decisions are expensive to reverse. This is the big one. Most choices in software are cheap: rename it, refactor it, move on. A handful are load-bearing walls: your data model, your identity and tenancy story, your boundaries between services, how you handle failure. Knowing which is which is most of what architecture is.

The AI treats every decision as equally weighty, which in practice means it treats them all as equally light. I don’t.

So how does that show up?

If my value is judgment, it isn’t worth much locked in my head. The real question is how to share it with everyone who can now build software.

This blog is my answer. Every post here is a piece of what I’d tell you if you sat next to me before you started: the load-bearing decisions, the mistakes I’ve already made so you don’t have to, and the questions I ask before I write a line of code. Who owns this data? What happens when this fails? What will be hard to change later? What does the second customer need that the first one didn’t?

The job now: know where the road goes

So where do I fit? Not as the person who types the code. That job is being automated, and honestly, I won’t miss most of it.

I fit as the person who knows where the road goes. Who can look at a weekend project and say: this part is fine, this part will hurt you in six months, and here’s the one decision you need to get right today.

Maybe architecture is king. Or maybe it’s just that judgment always was, and for a long time we confused it with the ability to write code. AI has separated the two. That’s unsettling if your value was the typing. If your value was the thinking, it’s the best tool we’ve ever been handed.

If you’re one of the many people who can now build software, stick around. I’d like to help you build it to last.