For the past two years, the standard prompt has been some variation of “Design me a system that does X.” And the models dutifully produce a Kafka cluster here, a Redis cache there, a perfectly reasonable microservices diagram that slots into the architectural monoculture.
But something shifted. A growing cohort of developers is flipping the script, using AI not to generate architecture, but to interrogate it. They’re treating LLMs like a relentless, well-read senior engineer who responds to every design decision with “Why?” until you either defend it or abandon it.
And the results are making people think more, not less.
The Wrong Way: AI as Architecture Vending Machine
Here’s the uncomfortable truth about asking AI to design your system: it will give you the consensus answer. Not the right answer for your constraints, your team, your traffic patterns, or your failure modes. The consensus answer.
As Dan Chuparkoff put it in a recent keynote, AI is a “B-minus student” across a wide range of subjects. It’s excellent at raising your baseline ability in unfamiliar territory. But it tends to produce the most statistically likely response, not the genuinely original or contextually appropriate one. When you prompt “design an event-driven system”, you’re going to get the most common pattern found in its training data, not necessarily the pattern your business actually needs.
Worse, there’s a hidden danger that nobody talks about: when an AI agent picks Kafka inside a plan you skimmed, it never registers as a decision at all. The architectural choices become invisible. One developer on r/softwarearchitecture described it as the difference between decisions being visible versus merely frequent, and that’s a different class of problem entirely.
The Socratic Flip: AI as Architectural Adversary
The alternative approach is deceptively simple. Instead of asking AI to design, you present your design and instruct the model to tear it apart.
The questions that emerge in practice look something like:
- Why Kafka here? Would a plain queue be sufficient?
- What happens when this service goes down? Have you modeled the failure cascade?
- Why are you caching this at all? What’s the actual read-to-write ratio?
- What’s the consistency requirement you’re trading away with this eventual consistency choice?
- Have you quantified the cost of being wrong about this scaling assumption?
That last one is the kicker. Because here’s what the pro-AI-architecture crowd misses: the cost of being wrong has fundamentally changed. When implementation took weeks, architecture mistakes were catastrophically expensive. Months of rework, burned budgets, career-limiting postmortems.
When AI can rebuild a flawed system in days, getting the decision wrong becomes much cheaper. The skill shifts from making the perfect upfront call to knowing how fast you can afford to be wrong, and designing for reversibility.
The Frequency Shift Nobody Prepared You For
There’s a deeper structural change happening that most architectural discussions ignore entirely.
In the pre-AI world, architectural decisions were rare events. Each one was followed by days or weeks of implementation effort, so they happened deliberately, in formal review meetings, led by designated architects. The average full-stack developer needed solid JS framework skills and competent SQL, and that was mostly sufficient.
Now? Implementation velocity means architecture questions surface across days or even hours. The responsibility shifts from “ivory tower architects” to the people interacting with agents daily. Decision processes move from group consensus reviews to ad-hoc inline judgment calls.
This is what one commenter meant by architecture becoming a “decentralized, near-realtime process.” The average developer now needs to think like a team lead of agentic teams, multitasking across architecture, design, resource management, and coordination. Not because they’re being promoted, but because the AI accelerated their implementation throughput to the point where architecture decisions are a daily occurrence.
If you’re skeptical that this matters, consider the alternative framing from a skeptic on the same thread: “Great, so we’re going to get bad code just faster.” That’s a legitimate fear. Plenty of developers in the wild struggle with SOLID principles, let alone nuanced distributed systems trade-offs.
But here’s the counterargument: the AI doesn’t have to be right. It has to be useful. And a tool that relentlessly questions your assumptions, even when its suggestions are mediocre, forces you to articulate reasoning you might otherwise skip.
The Infrastructure Gap: “Everyone Is an Architect Now” Means Nobody Is
Let’s get uncomfortable for a second.
The shift to daily architectural decisions has a dark side that the “AI makes everyone an architect” crowd conveniently ignores. When architectural choices become invisible, picked by agents inside plans you skim, you get five services disagreeing about error shape with no record of why. The fix isn’t more consensus meetings. It’s making constraints machine-checked so crossing a boundary fails a build.
If you’re working with agentic development flows and haven’t considered this, you’re replicating the exact failure mode the cautious crowd warns about. The tools exist, architecture decision records written by agents, automated ADR validation, spec-driven development with modular gates. But they only work if you enforce them from the outset.
One developer described the pattern that works in practice: harshly enforced standards on Spring Boot projects produced dramatically better outcomes than looser “make me a website” requests. Adding features to a standards-enforced codebase was easier and broke fewer things. The structure isn’t optional, it’s what makes AI development efficient in the first place.
DRY Is Still DRY, Even When Code Is Free
Here’s where the Socratic approach becomes genuinely valuable rather than merely intellectually satisfying.
The “code is cheap” era created a perverse incentive problem. Duplication feels free when AI can generate it in seconds. But it isn’t free, it’s deferred debt with compound interest. When you change behavior in one copy, the AI fixes that copy and leaves the other four broken. Or worse, it fixes them in subtly different ways that violate your domain invariants.
The developers who’ve been in the trenches longest are unanimous on this point: AI generates technical debt at light speed, in ways that make human-generated debt look quaint. The old gate on thoughtless code was effort, you had to type every line, so you thought about what you were adding. That gate is gone.
What replaces it? Deliberate architecture from the outset, regular DRY and best-practice reviews, and, critically for this discussion, architectural scrutiny powered by the same AI that generates the code in the first place.
Making It Practical: The Socratic Prompt Patterns
If you’re sold on the philosophy, here’s what it looks like in practice. The Superpowers plugin for Claude Code has formalized this as “Socratic Brainstorming”, reflective design before any code gets written. Its /superpowers:brainstorm command walks through technological alternatives, defines functional and non-functional requirements, identifies constraints, and crucially, presents the design in digestible sections for approval rather than generating a complete architecture in one shot.
The pattern generalizes beyond that specific tool. Here are the prompts that work:
For existing designs:
“Here’s my proposed architecture for [system]. Assume I’m wrong about at least three things. Tell me what they are and why, using specific failure scenarios relevant to my context.”
For technology choices:
“I’m choosing [technology] for [purpose]. What are the conditions under which this is the wrong choice? What would need to be true about our workloads for a simpler alternative to suffice?”
For failure analysis:
“Given this architecture, walk through what happens when [component] fails. Where are the single points of failure I haven’t considered?”
For reversibility:
“Which of these decisions are hard to reverse later? Which ones can be cheaply changed after seeing production behavior?”
The last prompt is the most important. In a world where being wrong is getting cheaper, the premium shifts to making decisions reversible. AI is remarkable at identifying which of your decisions are expensive-to-change, partly because it’s seen the patterns play out in training data, and partly because it has no incentive to defend the status quo.
What AI Gets Wrong (So You Don’t Have To)
Let’s be clear about the limitations, because this approach fails badly if you outsource your judgment entirely.
AI has a documented bias toward “roll-your-own” solutions. Even top-tier models will prefer reimplementing functionality over pulling in well-tested libraries, particularly when libraries require version resolution or API research. For small projects this is fine. For anything beyond a toy, it produces unmaintainable slop at alarming speed.
The solution that practitioners have converged on isn’t “trust AI more” or “trust AI less.” It’s installing structure that constrains what AI can do before it gets the chance to make architectural choices. This means:
- Writing module-level skills that encode your house architecture, patterns, and rules
- Enforcing spec-first development where AI must produce a plan before writing code
- Making ADRs and documentation mandatory outputs, not optional nice-to-haves
- Running automated architecture reviews as part of CI, with the same rigor as code reviews
This is challenging AI’s role in generating system architecture versus supporting human-driven design decisions, and it’s the only framing that survives contact with production reality.
The Accountability Problem
There’s one more dimension that separates the useful Socratic approach from dangerous delegation: accountability.
When you write the design and AI critiques it, you remain the author. When AI generates the design and you skim it, authorship, and responsibility, becomes murky. This isn’t a philosophical concern. It’s a practical one.
Every architectural decision has a cost structure. The person who can articulate why a decision was made, what alternatives were rejected, and under what conditions it would be revisited is the person who can fix it when it breaks. Empowerment, accountability, and decision-quality are inseparable.
If you hand architectural authority to AI, you get all three problems compressed into one: nobody owns the decision, nobody can explain it, and nobody knows when to revisit it. The architecture becomes a frozen artifact instead of a living structure.
The Verification Mindset
The most honest framing comes from the “assistant, not automator” school of thought. When someone suggests your AI might be delusional about a design choice, they’re right. AI produces consensus answers, not verified truths. Its confidence levels are poorly calibrated, underneath every answer is a probability calculation that might be 40% confident while sounding 95% sure.
That’s precisely why the Socratic approach works. You’re not using AI for its conclusions. You’re using it to surface questions you might not have asked yourself. The verification burden stays with you, which is exactly where it belongs.
For system design specifically, this means:
- Ask AI to attack your design, not design for you. Structure the prompt to force adversarial analysis.
- Ask for failure modes, not feature lists. The value is in what breaks, not what works.
- Ask for reversibility assessments. Know which decisions are cheap to change before you commit.
- Ask for quantified trade-offs. “Would a queue suffice?” isn’t enough, you need “Here’s what you lose by using a queue instead of Kafka, given your throughput and retention requirements.”
- Ask for the counterfactual. “What would this look like if we deliberately chose the simplest possible option?”
The last one is the most powerful question in the Socratic arsenal, because it forces you to confront your own complexity bias. The simplest system that meets requirements isn’t the easiest to design, it’s the hardest, because it requires genuinely understanding what you need versus what you want.
The New Architectural Literacy
There’s a legitimate worry hiding under all the enthusiasm: not everyone is prepared for this shift. The developer who can’t apply SOLID principles won’t suddenly become an architect because AI asks them pointed questions. The “everyone is an architect now” framing doesn’t fix that, it makes it worse by pretending everyone has the foundation to make the calls.
But here’s the thing: the alternative isn’t better. Going back to hand-coding everything to slow down architectural decisions isn’t just impossible, it’s the sunk-cost fallacy applied to an entire industry. The genie is out of the bottle. AI accelerates implementation whether you like it or not. The question is whether you’re going to use it to think more about architecture or less.
For teams building anything beyond a weekend project, the architecture decision frequency is going up, not down. The only way to survive that shift is to systematize architectural thinking, making it a daily practice rather than a phase at the beginning of the project. AI as a Socratic partner is a tool for exactly that, provided you treat it as a sparring partner and not a surrogate.
The alternative is having your architectural choices made invisibly by an agent that picked Kafka in a plan you skimmed, with no record of why and no one responsible for revisiting it when it inevitably fails. That’s not an architecture practice. That’s a lottery ticket.
Start the conversation with your AI assistant. Not “design this system”, but “here’s my system. Tear it apart.” You might be surprised what survives.
