Software Architect · Module 22
AI doesn't replace architectural thinking. It accelerates exploration, critique, and documentation — if the architect knows how to set the frame and verify the output.
AI-assisted design · critique · verification · quality gates
AI is useful as an amplifier of reasoning, and dangerous as a source of unverified confidence.
AI is good at widening the option space
An assistant can bring back ten route maps in a minute. The driver still owns the choice of road.
The architect can use AI to generate alternatives, risk checklists, ADR drafts, trade-off comparisons, test scenarios, security threats, and review questions. That speeds up preparation.
But AI doesn't know the full system context, can hallucinate APIs, underestimates operational cost, and sounds confident where data is actually needed. So the output has to pass through verification: the codebase, the docs, the metrics, the constraints, the team's knowledge.
The prompt has to carry constraints
Asking an architect to "design a house" is meaningless. You need the site, the budget, the climate, the family, the timeline, and the constraints.
For architectural work, AI needs context: the domain, the current architecture, team topology, load, compliance, budget constraints, product goals, existing decisions, and success criteria.
Without constraints, the model tends to default to generic best practices: microservices, Kafka, Kubernetes, event sourcing. That can be beautiful and harmful at the same time.
AI-native work should reinforce engineering discipline, not route around it.
Example: AI as ADR reviewer
The first officer doesn't fly the plane instead of the captain — they help check the instruments and catch the things the captain missed.
The team is writing an ADR about moving to async processing. AI receives the context, the ADR, the constraints, and the list of known incidents. The task: find missing risks, unclear assumptions, migration gaps, and test scenarios. The architect reviews the output and adds the real items into the document.
That way AI helps surface blind spots without making the decision for the team.
Anti-example: accepting AI design without verification
A beautiful bridge drawing is useless if nobody checked the soil, the load, and the materials.
AI proposes event sourcing and CQRS for a simple CRUD system. The team accepts it because the explanation sounds professional. A month later, the complexity of replay, schema evolution, debugging, and team onboarding shows up — and the business value hasn't moved.
AI can accelerate over-engineering when the architect doesn't hold the quality bar.
- What constraints did I give the AI? - Which facts need to be verified against the code or docs?
- Where could the AI have produced a generic solution? - Which quality gates protect us from unverified output?