Over the past months, I have experimented extensively with using AI in software and system architecture. One pattern became increasingly clear:
We try to use AI like a compiler.
We assume that if we specify enough, the AI should be able to generate an entire system.
But this approach fails consistently.
Not because AI is “too dumb” — but because we are using the wrong model.
In this article, I explain why full specification does not work with AI and which architectural model does.
1. The Core Problem: Full Specification Is a Waterfall Mindset
Many AI experiments fail because we try to describe an entire system upfront:
- Requirements
- ADRs
- Interfaces
- Data models
- Components
- Non-functional requirements
- Compliance considerations
The hope:
“If everything is defined, the AI can generate it.”
The problem:
AI cannot maintain global system coherence across hundreds of artifacts.
Even large context windows do not solve this, because:
- Abstraction levels get mixed
- Invariants get lost
- Cross-cutting concerns drift
- Decisions are not propagated consistently
In short:
Full specification overwhelms AI — and humans as well.
2. AI Needs a High-Level System Map, Not a Detail Bible
What actually works is a system map:
- Domains
- Responsibilities
- Data flows
- Use cases
- Boundaries between subsystems
This overview is abstract, not detailed.
It serves as orientation, not as a construction plan.
Why this matters:
AI can only work effectively when it knows where it is within the system.
Without this orientation, coherence breaks down.
3. Architecture Emerges Through Layering, Not Through Full Text
Classical architecture works because it is iterative:
- High-level structure
- Identify components
- Define interfaces
- Refine components
- Implement
AI needs the same process.
It cannot go from “0 → 100”, but it is excellent at “80 → 100”.
This means:
We must layer architecture so AI can work locally.
4. The Crucial Step: One AI per Component
Once components and their interfaces are clear, something interesting happens:
- Each component has a clear context
- The AI only needs to maintain local invariants
- The interface acts as a contract
- The implementation space becomes constrained
- Consistency emerges naturally
This mirrors how real engineering teams work:
small units, clear boundaries, local autonomy.
With AI, the same model works — only faster.
5. Why This Model Works Better Than Full Specification
Because it leverages AI’s strengths and avoids its weaknesses:
| Problem with Full Specification | Solution in the Component Model |
|---|---|
| AI loses global coherence | AI works locally, with clear boundaries |
| Abstraction levels get mixed | Each level has its own prompts/agents |
| Changes do not propagate cleanly | Interfaces enforce consistency |
| Context window overload | Each AI sees only its relevant context |
| Architectural decisions blur | Decisions remain with the human |
In short:
We design systems in a way AI can understand.
6. What Remains Human?
Even with this model, three things remain irreplaceable:
- Architectural decisions (trade-offs, priorities, values)
- Responsibility (compliance, security, liability)
- System coherence (the meta-level across all components)
AI can implement.
AI can refine.
AI can accelerate.
But AI cannot decide what should be built — only how fast.
Conclusion
The problem is not that AI cannot generate systems.
The problem is that we try to force AI into a model that barely works for humans: full specification.
The right approach is different:
- abstract system overview
- iterative refinement
- clear components
- explicit interfaces
- one AI per component
This creates a process that works for both humans and AI — combining the strengths of both.