In partnership with
Two weeks ago I was reviewing an architecture diagram for a mentee who wanted feedback before presenting it to his hiring manager.
Three-tier web app on AWS. Application Load Balancer, EC2 in an Auto Scaling Group, RDS Multi-AZ. Clean. Nothing obviously wrong.
I gave him my feedback. He updated it. We went back and forth twice. I thought we were done.
On a whim, I pasted his diagram description into Claude and asked it to review it as a senior solutions architect.
It asked one question I had not.
"What happens to the database connection pool if all EC2 instances scale up simultaneously during peak load?"
We had both missed it.
His RDS instance was sized for normal load. The connection limit would be hit within seconds of a traffic spike — before the Auto Scaling Group could even respond. He would have walked into that hiring manager presentation with a critical flaw sitting in the middle of his design.
AI did not design the architecture. It did not understand his business requirements or his team's capabilities. But it asked the question I had stopped asking because I thought we were done.
That is the real value of AI in technical review: it has no assumptions. Every time you ask it to review something, it starts fresh.
1. Ask it to find single points of failure
Describe your architecture in plain text. Ask: "What single points of failure exist in this design?"
Then ask it to rank them by likelihood and blast radius.
It will not always be right. But it will surface things you have normalised because you have been staring at the same diagram for days. Familiarity is an architect's blind spot. AI does not have familiarity.
2. Ask it to challenge your assumptions
Try this prompt: "What assumptions am I making about traffic patterns, data volumes, and team capability that I have not explicitly stated in this design?"
The answers are often obvious in retrospect. But articulating assumptions is exactly what engineers struggle to do under deadline pressure — and exactly what interviewers test for in system design rounds.
I have started using this before every architecture review I do at work. It takes three minutes. It has saved me from at least two embarrassing questions in front of customers.
3. Review for cost before you build
Before provisioning anything, describe your intended architecture and ask: "Where are the likely cost surprises in this design at 10x current load?"
I caught a NAT Gateway issue on a mentee's project this way. Single NAT Gateway routing traffic across three availability zones. Fine at low scale. Expensive fast when traffic grows — because every cross-AZ byte costs money.
Nobody tells you this in the certification courses. AI spotted it in thirty seconds.
What AI cannot do
It doesn't know your organisational constraints. It doesn't know your team has never operated Kubernetes in production. It doesn't know your legacy system has undocumented behaviour that breaks anything touching it.
Use AI to pressure-test the diagram. Use your judgment for everything the diagram does not show.
The engineers I see getting the most out of AI tools are not the ones using it to generate solutions. They are the ones using it to stress-test solutions they already have.
That shift — from generator to reviewer — is what separates engineers who think AI is overhyped from engineers who genuinely work faster because of it.
Write docs 4x faster. Without hating every second.
Nobody became a developer to write documentation. But the docs still need to get written — PRDs, README updates, architecture decisions, onboarding guides.
Wispr Flow lets you talk through it instead. Speak naturally about what the code does, how it works, and why you built it that way. Flow formats everything into clean, professional text you can paste into Notion, Confluence, or GitHub.
Used by engineering teams at OpenAI, Vercel, and Clay. 89% of messages sent with zero edits. Works system-wide on Mac, Windows, and iPhone.
I put together a free guide comparing the five AI tools I actually use in my technical work — including the ones I reach for when reviewing architecture and code.
💬 What is the most useful thing AI has caught in your technical work — or the most obvious thing it missed?
Reply with REVIEW and I will send you the exact prompts I use when reviewing architecture and code with AI.
Know someone building on AWS or exploring AI tools? Share your referral link — 1 friend subscribes, you get a free LinkedIn Profile Optimisation Checklist.
{{rp_refer_url}}
— Shola
P.P.S. If you are working on a side project or preparing for a system design interview and want a second set of eyes on your architecture — reply to this email. I read every one.