If AI scares you, learn software architecture

AI demos are getting scary good.🥶

I've seen developers use AI to migrate an infrastructure of over 200 lambdas to Flask code in days instead of months. That's not a minor productivity boost – that's the kind of work that used to justify entire teams.

If you're worried about your job, you're paying attention.

But here's the thing: AI can only replace developers when stakeholders know exactly what they want and users know exactly what they need. And we all know that's never happening. Still, some developers are already getting replaced.

It's not the best developers getting replaced. It's the ones who only know how to write code. The ones who can't make decisions. The ones who've never learned software architecture.

Can't AI just become a software architect too?

You'd think so, right?

It depends.🧐

And "it depends" is the most powerful phrase in software architecture. It's also the phrase AI struggles with most.

When I read "The Fundamentals of Software Architecture" by Mark Richards and Neal Ford, one section stuck with me: the eight core expectations of a software architect. I started checking them against what I've seen AI actually do:

What AI can handle:

• Make architecture decisions – It can generate options and trade-offs, but it doesn't understand your business constraints or politics.
• Analyze the architecture – Actually pretty good at spotting dependency issues and technical debt.
• Keep current with trends – Trained on everything public (though its knowledge has a cutoff date).
• Ensure compliance – Can check rules, but doesn't feel the weight when things break.

Where AI falls apart:

• Business domain knowledge – Needs you to explain everything explicitly, can't pick up on unspoken context.
• Interpersonal skills – Can't mentor a junior dev through a tough bug or read the room in a meeting.
• Navigate politics – And this is the big one.

Here's what navigating politics actually looks like: You're in a room proposing microservices. The CTO wants them because they're trendy. Your team lead hates them because of past trauma. The product manager doesn't care but needs the project done in 3 months. You know microservices will take 6 months and cost 3x more to run, but a modular monolith could ship in 2 months (you'll say 3 to the PM anyway – things can go wrong).

Can you hold your ground? Can you explain the trade-offs without making anyone feel stupid? Can you find the compromise that gets everyone on board? Can you take responsibility when you're wrong?

AI can't do any of that. It doesn't have to live with its decisions. It doesn't have to look someone in the eye and say "I was wrong, here's how we fix it." It can't mentor the developer who's struggling to implement the architecture. It can't lead a team through a failed deployment at 2am.

Those skills require something AI doesn't have: stakes, consequences, and the ability to actually care about the outcome.

So yes, AI will be a limited software architect. A very useful tool, but a limited architect.

And if you're worried about your job as a software engineer, learning software architecture might be the best career move you can make right now.

So how do you actually become a software architect?

Start by reading. You need to know if you'll actually like this work before investing months into it. I started with "[The Fundamentals of Software Architecture](https://a.co/d/dl18Yen)" by Mark Richards and Neal Ford. It's not a promotion—it's just what worked for me. The book taught me two things: the technical patterns (microservices, event-driven, layered architectures) and what the job actually involves (spoiler: it's a lot of meetings and explaining the same decision five different ways).

If you finish it and think "yes, I want to do this," move to "Designing Data-Intensive Applications" by Martin Kleppmann. Then the "System Design Interview" books (both volumes). These aren't just interview prep, they're where you learn to think in systems, not just code.

Then get your hands dirty with certifications.

Here's why you need them: certifications force you to learn the full toolkit of a platform, not just the three services you use at work. And whether you like it or not, having AWS Solutions Architect plus database and orchestration certs proves to clients and employers that you can actually integrate these systems.

Pick one cloud provider and go deep. AWS, GCP, Azure – doesn't matter which, but commit to one. I used ExamPro for my AWS Solutions Architect cert. The certification itself matters less than the process of learning how these systems actually work at scale.

Get certified in databases. MySQL or PostgreSQL for relational, MongoDB for document stores. Then explore the big data side – Clickhouse, Cassandra, whatever's relevant to your domain.

Learn the orchestration stack: Docker, Kubernetes, Terraform. You need to understand how systems get deployed and managed, not just designed.

Don't skip security either. Read up on it, understand the fundamentals. You don't need a CISSP, but you need to know enough to not design systems that leak customer data.

But here's the part most people skip: practice with real constraints.

AWS gives you $1,000 in credits for startups. Use them. Don't just build a todo app, reproduce the problems big companies actually face.

Build a system that handles 10,000 writes per second. Watch it struggle. Then figure out how to fix it – sharding? Caching? Different database? Let it run under load and see where it breaks.

Or pick a real company problem: How does Twitter handle the timeline for users with millions of followers? How does PayPal process payments without double-charging? How does Netflix serve video to millions of users without going bankrupt on bandwidth costs?

Try to implement those solutions in AWS or your favorite cloud platform. You'll fail. That's the point. Then you'll understand why those companies made the architectural decisions they did.

This is how you learn what "it depends" actually means. A solution that works for 100 users dies at 10,000. A database that's fast for reads becomes a nightmare for writes. You can't learn this from books, you have to break things.

And use AI as your sparring partner.

I have a favorite prompt: I tell Claude to act as "a software architect with 20+ years of experience who thinks he knows everything, hates change, and is extremely difficult to convince."😅

Then I pitch my architecture decisions to him.

If I can convince a stubborn AI that my approach is sound, I have a better shot at convincing a real skeptical CTO. It forces me to think through every trade-off, every edge case, every "but what about..." question before I walk into a meeting.

Start with the book. Try the prompt. See if this is the work you want to do.

If you've got questions about software architecture or want to talk through a decision you're wrestling with, leave a comment below. I'm always up for a good "it depends" conversation.

If you enjoyed this article and want more insights like this, subscribe to my newsletter for weekly tips, tutorials, and stories delivered straight to your inbox!