AI-Assisted Development > AI-assisted design & architecture > AI-assisted architecture exploration
What This Covers
AI-assisted architecture exploration for a real product team, focusing on how to explore alternatives while staying grounded in operational and organizational realities.
The System
Current State
- A platform team supports ~35 services on Kubernetes (EKS) across 3 AWS accounts (dev/stage/prod).
- Architecture decisions are documented in ADRs; reviews happen weekly with senior engineers and security.
- Teams frequently use an “AI architecture explorer” (LLM + internal templates) to propose options and generate ADR drafts.
- Typical scale: ~18k requests/sec peak across the platform; ~220 engineers consume the platform.
Proposed Change
- Integrate the AI explorer into the ADR workflow so it can automatically generate 2–3 viable architecture options per proposal, with pros/cons and risk notes.
- Add optional “context packs” (links/config snippets) so the AI can tailor suggestions to the org’s existing stack.
- Goal: reduce ADR cycle time from ~10 business days to ~4.
Worked Example: Design Tradeoff
A prior initiative used the AI explorer to propose a “clean-slate” event-driven architecture for a new billing pipeline. The AI recommended adopting a managed streaming platform and reorganizing ownership into domain-aligned teams, arguing it would simplify scalability and decouple releases.
During evaluation, a few signals prompted a design review: the team spent multiple days validating the option, only to learn late that procurement timelines and existing vendor commitments would prevent adopting the suggested managed service within the quarter. Additionally, several engineers noted the proposal assumed operational expertise the org didn’t currently have on-call.
The design adjustment wasn’t “stop using AI,” but to change how options were generated and filtered. The team introduced an explicit “feasibility gate” in the template: required inputs (approved vendors, supported runtimes, compliance constraints, on-call ownership) had to be present before the AI could recommend certain classes of solutions. The workflow also shifted to producing one “aspirational” option and two “within-current-constraints” options, with a short checklist indicating what would need to change for the aspirational path to become feasible.
The Design Question
You’re now rolling out “context packs” so the AI explorer can tailor architecture alternatives using internal docs and configs. The tradeoff: richer context can produce more relevant options, but it may also bias exploration toward what’s already documented, and can still miss constraints that exist outside the docs (contracts, approvals, unwritten standards). How would you design the context-pack system and the exploration workflow so that options are both creative and realistically actionable for this organization?
Anchor Data
Pilot results (20 ADRs over 6 weeks; 10 with context packs, 10 without)
| Metric | No Context Pack | With Context Pack |
|---|---|---|
| Median time to first draft (hours) | 14.2 | 3.6 |
| Median time from draft → approved ADR (business days) | 9.1 | 5.0 |
| Avg. # of architecture options generated | 3.1 | 2.4 |
| Reviewer “relevance” score (1–5) | 3.6 | 4.4 |
| % ADRs requiring “major revision” after first review | 30% | 20% |
| Avg. engineer-hours spent evaluating discarded options | 11.5 | 7.8 |
Context pack contents (when enabled): 6–12 Confluence links, 1–2 Terraform module references, a “standard services” catalog excerpt, and last quarter’s top 5 incident summaries.
Current Observations
- Several teams report the AI suggestions “fit our stack better” with context packs and require fewer review comments.
- A few staff engineers feel the AI is “less imaginative” and repeats familiar patterns when context packs are enabled.
- In 3 of the 10 context-pack ADRs, reviewers asked late in the process for changes due to “non-technical constraints” that were not referenced in any provided links.
- Some teams want the AI to recommend bolder options “as long as it clearly flags prerequisites,” while others want only options that can ship this quarter.
Constraints
- Rollout decision needed in 4 weeks; platform leadership wants a measurable ADR cycle-time reduction this half.
- Security requires that any retrieved context be access-controlled and auditable (who accessed what, when).
- No additional headcount; implementation must fit into ~2 engineer-months.
What You’ll Be Evaluated On
- Tradeoffs: Identify competing goals (speed vs breadth of exploration, relevance vs novelty, automation vs review burden) and justify your design choices.
- Gaps: Surface what’s missing from the pilot data and proposal (inputs not captured, untested assumptions, edge cases).
- Prevention: Anticipate how the workflow could go wrong in practice and propose safeguards (process gates, checks, fallbacks, instrumentation).
- Clarity: Communicate a coherent design with understandable components and interfaces.
- Prioritization: Focus on the highest-impact decisions given time and resource constraints.
- Reasoning quality: Use evidence-based arguments and make uncertainty explicit where needed.