TL;DR

• AI is a reviewer, not a creator (yet): LLMs struggle to generate complex system architectures from scratch but are exceptionally good at evaluating existing High-Level Designs (HLDs) against strict reference rules.

• Single-agent vs. Multi-agent workflows: When evaluating architectures, a single-agent hierarchical workflow proved far more cost-effective than a parallel multi-agent workflow, avoiding redundant token consumption and context overhead.

• Model comparison (Claude Opus vs. Gemini Pro): Both models successfully identified core architectural gaps. Gemini Pro acts as a strict rule enforcer, while Claude Opus provides broader, unprompted contextual awareness.

Will AI replace software architects? For now, the answer is no.

While teaching a comprehensive Software Architecture course, I decided to run an experiment. I converted my architecture material into a set of agentic skills covering major architecture domains: microservices, layered architecture, databases and storage, networking, messaging, big data, security, and more. Each skill included architecture patterns, trade-offs, and guidance on when to use them based on system requirements.

I then fed these skills alongside system requirements to high-performance LLMs and asked them to generate a High-Level Design (HLD) from scratch.

The results were mixed. The models struggled to differentiate between patterns like Microservices and SOA, they frequently made poor technical choices for analytics data storage, etc. LLMs easily get confused by the sheer breadth of software architecture when asked to generate a design from a blank canvas.

However, LLMs are exceptionally good at evaluating an existing HLD against a strict reference architecture.

When reviewing dozens of HLDs, architects must enforce mandatory patterns: API Gateways, public/private network separation, technology restrictions, and existing security paradigms. Once you establish this reference architecture, LLMs excel at validating the proposed solution.

Specifically, AI is highly effective at:

• Evaluating functional requirements and Quality Attributes (See the article discussing quality attributes evaluation).

• Extracting architecture entities and relationships by parsing formats like Markdown or PDF.

• Interpreting static diagrams (e.g., C4 models) and dynamic flows (e.g., sequence or activity diagrams).

• Evaluating the proposed architecture against constraints and reference architectures.

• Providing concrete, actionable recommendations to fix architectural gaps.

Evaluating Agentic Architectures: Single-Agent vs. Multi-Agent

To build the evaluation engine, I tested two different agentic architectures for performance and cost.

1. Single Agent with Hierarchical Skills A main orchestrator sequentially calls specialized evaluation skills. The context window compounds and increases from skill to skill during the sequential flow:

• hld_document_review_skill: Reviews structural completeness.

• functional_requirements_skill: Validates functional requirements.

• quality_attributes_skill: Evaluates non-functional constraints.

• project_hld_system_design_review_skill: Reviews core design (C4, system flows) against reference rules.

• system_design_additional_sections_skill: Checks schemas, sizing, and upgradability.

2. Multi-Agent Workflow Five specialized agents run in parallel. Each agent uses an isolated context window to focus on a single skill, and a final synthesizer agent combines the output at the end.

Side-by-Side Comparison

Why Do Multi-Agent Workflows Consume More Tokens?

Despite being faster, the multi-agent workflow incurred significantly higher token costs for three reasons:

1. Redundant Document Loading: With no shared memory, every single agent must independently load and process the full HLD document.

2. Double-Billing on Synthesis: The final synthesis agent re-ingests all five outputs as its new input, meaning phase 1 output tokens are billed again as phase 2 input tokens.

3. Baseline Overhead: Every sub-agent requires its own system prompt, tool schemas, and framework scaffolding. The single-agent setup pays this overhead once; the workflow pays it six times.

The Conclusion: Because my primary goal was cost optimization rather than execution speed, I chose to stick with the Single-Agent architecture.

Model Evaluation: Claude Opus vs. Gemini

I evaluated these agentic architectures using the Antigravity framework across three major models: Claude Opus 4.8, Gemini 3.1 Pro, and Gemini 3.6 Flash.

Note: Gemini Flash was quickly ruled out, as its comprehension of complex architectural components and system flows was insufficient for this use case.

Here is how the heavyweights compared:

The Verdict: The two models are highly consistent—yielding the same overall grade, identifying the same headline problems, and suggesting identical fixes.

Their differences are complementary. Gemini Pro acts as a strict enforcer of reference rules (such as the database-per-service constraint), while Claude Opus possesses broader architectural awareness (identifying unprompted gaps like a missing Auth-service container and an unprotected on-prem entry point).

The optimal review combines the strict rule-following of Gemini Pro with the broad contextual awareness of Claude Opus—yielding a comprehensive, enterprise-grade architecture evaluation.

Conclusion

So, will AI replace software architects? The reality is that the blank-page creation of complex, context-heavy enterprise architecture still requires human intuition, business alignment, and strategic compromise. LLMs cannot yet shoulder that creative and structural burden alone.

However, the days of manual, error-prone HLD reviews may soon be behind us. By encapsulating reference architectures and quality attributes into specialized agentic skills, we can turn LLMs into rigorous, tireless design reviewers. They excel at holding proposed solutions accountable to established standards, ensuring that non-functional requirements are met, and identifying architectural anti-patterns before a single line of code is written.

As architects, our role is shifting. We are no longer just designing systems; we are designing the guardrails, reference patterns, and agentic workflows that will help evaluate and scale those systems reliably. AI won't replace us—but the architects who leverage AI to automate design validation will undoubtedly outpace those who don't.

Early in my career—long before the current wave of AI-assisted development—a product manager handed me a set of system requirements and declared they had "no non-functional requirements."

My response was straightforward: "Without them, I will build the system I want to build. It will likely follow the easiest path for development, but it won't be what you actually need."

That alarmed him—and rightfully so.

In software architecture, capturing efficiency quality attributes—often referred to as non-functional requirements (NFRs)—is arguably the most critical phase of system design. I prefer the term "Quality Attributes." Architecture is fundamentally about defining the quality of a system. The term "Non-Functional Requirement," by contrast, focuses on what a system is not, rather than what it is.

The "What" vs. The "How"

Functional requirements are the easy part. Stakeholders are usually highly vocal about what the system should do, capturing the use cases and features.

However, Quality Attributes define how the system should behave under those functional use cases. How fast is it? How easy is it to use? How well does it scale?

You could write an entire web application in a single file. Functionally, it might do exactly what it is supposed to do. But what about modifiability? Maintainability? Scalability? These are the dozen or so attributes that ensure the long-term viability of your system.

Quality attributes drive architectural decisions. They matter most to the Software Development Life Cycle (SDLC). A lack of clearly defined quality attributes—or poorly articulated ones—inevitably leads to re-architecture, which is the most expensive and painful change a team can make during an SDLC.

Challenging the Stakeholders

Returning to my product manager: when I probed further about performance requirements, he insisted he didn't have any.

"Understood," I replied. "I'll design it so the first page of images takes about five minutes to load." "Oh, no, that’s way too slow," he countered. "Okay, one minute?" "Still too slow." Eventually, we landed on a hard requirement of two seconds.

Now, I had the data I needed to actually begin the architectural design process. As architects, it is our job to challenge our stakeholders—whether they are product managers, security teams, or compliance officers—to extract these boundaries.

The Bass-Style Scenario Framework

Effective Quality Attribute scenarios were well defined by L. Bass, M. Klein, and F. Bachmann, and they have been widely embraced by the architecture community.

An effective quality scenario forces all stakeholders to think about measurable system attributes so the architectural solution can be objectively measured against the requirements. For each relevant quality attribute, you should construct a scenario using the following six elements:

Put together, the template reads:

When [source of stimulus] [stimulus] the [artifact] in [environment], the system should [response], measured by [response measure].

The Framework in Action

Instead of writing a vague availability requirement like "The system should be highly available," a proper Bass-style scenario looks like this:

"When a payment service becomes unavailable [Stimulus] caused by an internal component failure [Source] affecting the checkout service [Artifact] during peak holiday traffic [Environment], the system should fail over to a standby instance [Response] within 30 seconds and preserve a 99.9% request success rate [Response Measure]."

Why Quality Attributes Matter Even More in the Age of AI

With the rapid rise of agentic development and "vibe coding," the traditional SDLC process is fundamentally shifting. As Google recently outlined in their piece on the new SDLC, human-to-AI handoffs are becoming the norm.

During these conversations between humans and AI, explicitly captured architectural requirements become hyper-critical. Large Language Models (LLMs) and coding agents will take the path of least resistance if boundaries aren't clearly defined.

To bridge this gap, the requirement preparation and review phases—whether conducted by a human or an AI agent—must be enhanced. AI agents can be guided to Create, Evaluate, and Fix well-structured quality-attribute scenarios using the Bass-style approach. You can explore concrete implementations of these agent skills for quality attributes and functional requirements on GitHub.

By expressing requirements as measurable stimulus-response scenarios, we can programmatically score and repair existing quality-attribute statements, preventing vague implementation leakage and ensuring that our AI coding partners build systems that scale, endure, and perform.

The Takeaway

As we transition into an era of agentic development, the architect's role must focus heavily on defining precise, measurable boundaries. Challenge your stakeholders, use structured scenarios to capture quality attributes, and ensure your AI tools are guided by rigorous architectural standards rather than vague assumptions.

References

• L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 3rd ed. Upper Saddle River, NJ: Addison-Wesley, 2012

• Quality Attribute Design Primitives and the Attribute Driven Design Method

• Bass Framework Details: EECE417/BASS/ch04

• The New SDLC With Vibe Coding, Google