Agentic SDLC Framework
A framework guiding delivery from requirements to deployment through three specialised agents with built-in quality guardrails — with patterns held as a single source of truth and support across multiple IDEs.
Three specialised agents and a shared pattern library that let a whole engineering organisation work the same way, in whichever IDE they use.
Three agents map to the real division of labour — product owner, architect, developer — each invoked explicitly, so an engineer chooses the mode of help rather than hoping one assistant infers it.
Generation patterns live in a shared core as a single source of truth, so improving a pattern improves output for everyone rather than for one person's prompt.
Technology stacks are declared as swappable profiles, letting teams on different stacks share the same framework and guardrails.
The workflow enforces sequence: requirements produce stories, stories constrain design, design constrains code — so generated code traces back to an agreed requirement.
Individual engineers using AI assistants produced wildly varying output. The same task done twice yielded different architecture, different conventions and different quality, depending on who wrote the prompt.
Good prompting stayed personal — the engineer who worked out an effective approach had no way to share it beyond telling colleagues.
Teams also used different IDEs, so any solution tied to one editor would have fragmented the organisation further.
A framework guiding delivery from requirements to deployment through three specialised agents with built-in quality guardrails — with patterns held as a single source of truth and support across multiple IDEs.
If your engineers are all using AI differently and quality varies by individual, the fix is shared patterns and explicit roles — not more tooling.
The constraint that shaped it
One core, many editors
Tying the framework to a single IDE would have split the organisation between those who adopted it and those who could not. A shared core with thin per-IDE integrations was what made org-wide consistency possible without dictating anyone's tooling.
Patterns as a single source of truth
Improvements accumulate centrally instead of living in individual prompt histories — which is the difference between a team capability and a personal trick.
Explicit agent invocation
Engineers name the agent they want. Explicit routing produces far more predictable behaviour than one assistant guessing which mode of help is needed.
Stack profiles, not a fixed stack
Declaring the technology stack as swappable configuration let teams on different stacks share one framework.
- Shaped the framework concept and the three-agent division of labour
- Defined the pattern library structure and the workflow guardrails
- Drove adoption across engineering teams and iterated on real usage
How We Solved the Problem
Product-owner agent
Analyses business requirements and produces epics and user stories with acceptance criteria, establishing what is actually being built before any design work starts.
Architect agent
Turns agreed stories into API contracts, UI specifications and data models — the layer most often skipped when engineers prompt for code directly.
Developer agent
Generates full-stack implementation with tests and CI configuration, following the shared patterns rather than improvising conventions.
Shared pattern core
Language and framework patterns held once as a single source of truth, consumed by every agent and every IDE integration.