The Problem We Solve
Your teams are delivering faster than ever. But is the output cohesive?
Every technology leader we speak to shares the same three pressures:
You're under-resourced. There are more initiatives than engineers to deliver them. Hiring is expensive, slow, and competitive. You need to do more with the team you have.
Deadlines are slipping. Not because people aren't working hard, but because rework is eating capacity. Code that passes review turns out to conflict with another team's work. Integration problems surface late. What looked done isn't.
The regulator is asking harder questions. FCA Consumer Duty, operational resilience (PS21/3), DORA — they all require evidence that technology changes are governed, traceable, and consistent. Assembling that evidence is currently a manual, quarterly ordeal.
AI coding tools promised to fix the capacity problem
And in many ways, they are. GitHub Copilot, Claude Code, Cursor — your developers are genuinely shipping faster. A feature that took a week now takes two days. Individual productivity is up.
But organisational coherence is down.
Every AI session starts from scratch. It doesn't know what the last session decided. It doesn't know what the team next door is building. It doesn't share context across repositories. The result: each piece works on its own, but the pieces don't fit together.
You've accelerated output without governing outcomes.
Your engineering teams will recognise these symptoms
Architectural drift
Repo A uses one pattern, repo B uses another, repo C uses something an AI agent invented from scratch. Nobody decided this. It just happened — one session at a time. Now every new feature needs to work across all three patterns.
Technology sprawl
Three state management libraries. Two logging frameworks. Four approaches to authentication. Each one was a reasonable AI suggestion in isolation. Together, they're a maintenance burden that compounds every quarter.
Invisible rework
A developer finishes a feature, it passes code review, it merges — and two weeks later another team discovers it conflicts with their work. The rework isn't tracked as rework. It shows up as "the next feature took longer than expected."
Lost knowledge
When a senior developer leaves, their understanding of "how we do things here" leaves with them. The AI tools don't have that understanding either. The new hire's AI agent generates code that works but doesn't fit.
Compliance evidence gap
The FCA asks: "Show us which business requirement drove this code change, who approved it, and what systems it affected." Today, answering that question means a compliance officer and a tech lead spending a week grepping through pull requests.
What this costs you
| Problem | Impact |
|---|---|
| Rework from incoherence | 15–25% of engineering capacity consumed by preventable rework |
| Onboarding friction | New developers take 2–4 weeks longer to become productive in an inconsistent codebase |
| Compliance evidence | 40+ person-hours per quarter assembling evidence packs manually |
| Integration failures | Late-discovered conflicts that blow sprint commitments |
| Knowledge concentration | Critical system knowledge locked in 2–3 senior heads |
These are not AI problems. These are governance problems. AI just made them visible faster.
What SGD does about it
SGD doesn't slow your teams down. It makes the speed sustainable by adding a governance layer that:
Maximises your existing team — structured specifications mean AI agents produce coherent code first time, not code that needs rework. Your engineers spend time delivering, not reconciling.
Catches problems at PR time, not production time — every pull request is automatically checked against your standards. Conflicts surface in minutes, not weeks.
Makes compliance evidence automatic — full traceability from business requirement to production deployment. The evidence assembles itself from the audit trail. No more quarterly fire drills.
Preserves and shares knowledge — your standards, patterns, and architectural decisions are captured in machine-readable specifications. When an engineer leaves, the knowledge stays. When an AI agent starts a session, it reads the specs first.
The result: more delivery from the same team, fewer surprises in production, and compliance evidence that generates itself.
Where does SGD come from?
SGD is not a new invention invented in isolation. It is the deliberate synthesis of six established disciplines — each proven independently over decades of enterprise software practice — recombined and re-encoded for a new audience: AI coding agents.
The input to SGD
Capability modelling (TOGAF), living documentation (BDD), architecture decision records (Nygard), design systems (Atomic Design), DAG-based dependency tracking (Make / Nx / Terraform), and specification-driven development (Kiro / Fowler). Six specialists. One constraint framework.
Next: The Foundations of SGD — the six disciplines behind the framework. Or skip ahead to How It Works.