Architecture-Driven and Specification-Driven Engineering in Practice
How architecture-first and specification-driven practices are the discipline that separates Tool Users from Solution Providers.
- By
- Anders Bendtsen, Enterprise Architect / Consulting Manager at Consid Copenhagen
- Published
- December 2025
AI amplifies what is already there.
Without the right structure and processes, AI can turn speed into chaos. — DORA 2025
Over the past four months, I delivered more code than in the previous five years combined — thanks to Agentic Engineering. But speed amplifies what's already there — both good and bad. The question isn't whether AI will change software delivery. The question is whether we stay above the algorithm — steering it — or drift under it.
| Tool User | Solution Provider |
|---|---|
| Use AI to do the same thing faster. | Fundamentally change how you work. |
| Commoditization. Lower margins. | Differentiation. Sustained value. |
Directed Agentic Engineering — staying above the algorithm.
- 1Think before you act
Understand what and why before the agent begins.
- 2Make intention explicit
Specs and architecture as living documents — thinking not written down is invisible.
- 3Codify knowledge in skills and playbooks
Don't rely on guesswork or tribal knowledge.
- 4Humans take the critical decisions
Not the agent.
- 5Small, reversible steps
So you can validate and course-correct.
The score, the conductor, and the instruments.
The spec is the score. The architect is the conductor. The agents play the instruments. Playbooks for different contexts, skills that codify methods, roles that define ownership. All in markdown files in your repo — no new tools, no new platforms.
Architecture-driven and spec-driven: architecture as a living contract, specs precise enough for agents to implement.
For every role in the team.
- For Developers
Onboarding in days instead of weeks. Playbooks show you how we work.
- For Architects
Time spent writing specs and architecture docs that agents actually use — not presentations no one reads.
- For Teams
Knowledge that accumulates instead of starting over with each project.
Exploration surfaced pain. Structure contained it.
- Exploration surfaced pain
The code showed us what hurts and where — without guessing.
- Assessment prioritised the real problems
Not everything was broken equally; we focused on what mattered.
- Architecture made every component intentional
Every boundary justified, every dependency explicit.
- Traceability validated end-to-end
Code → spec → architecture → capability. No orphans, no mystery code.
Frequently asked
- What is architecture-driven, specification-driven engineering?
- An engineering approach where architecture defines the target state, specifications define how each part behaves, and agents — human or AI — implement against those specifications. The architecture is the control surface.
- How does this differ from documentation-first engineering?
- Documentation describes what was built. Specifications govern what gets built. The difference matters when AI agents are the ones executing, because they need machine-readable intent, not retrospective notes.
The winning move is being over the algorithm.
Not by using AI less, but by building the discipline to stay in control. Architecture-driven, spec-driven, skill-based delivery at scale.