Autonomous software engineering, your firm can stand behind.
Vibe coding gets you a demo. CDS gets you to production. A small team working in CDS delivers what used to take a department — with every change governed, traced and approved by a person at your firm.
Feature: settlement retry policy
Seven agent stages · a gate between each- ProductRequirementsApproved
- ArchitecturePre-reviewAdvisory
- EngineeringImplementation planApproved
- CTOPeer reviewApproved
- EngineeringBuildRunning
- CTOPre-releaseWaiting
- ReleaseRelease notesWaiting
Must be fixed. Nothing moves on.
Signed off by a named person.
Recorded, not blocking.
You don't have a talent problem. You have a speed problem.
AI has made your developers faster than your review, your controls, and your ability to stand behind what ships. Hiring more people doesn't fix that. It multiplies it.
The queue
More changes than your senior people can read.
The exposure
Speed, with nothing a board will accept as a record.
The cost
Headcount that grows with the backlog, when AI was supposed to break that link.
The hype says AI writes code. The question is whether you can run it.
Production-grade systems have been built with CDS — designed, reviewed, tested and released through the same governed pipeline described on this page. Not a prototype. Not a demo.
Details of systems built with CDS are shared with prospective clients on request.
Five layers. One engineering organisation that never forgets.
Code generation is the easy part. CDS is the system around it: the understanding, the memory and the operating model that let a small team ship like a large one.
- L1CodeWhat exists
The repositories themselves — every file, dependency and change, read as they are, not as a summary.
- L2ContextWhat matters now
The slice of the system each agent needs for the task in front of it, managed across long, multi-session work.
- L3SemanticWhat it means
How the parts relate: which service owns which behaviour, which change touches which contract.
- L4KnowledgeWhat the firm has decided
Requirements, plans, reviews, decisions and release history — kept as files in your repositories, so agents build on them.
- L5OrchestrationWho does what, in what order
Specialist agents — product, engineering, CTO review, audit — run in sequence, with a governance gate between every stage.
Your whole delivery organisation, run as agents.
Product, engineering and CTO review, each a specialist agent, handing work to the next in a fixed order. Your people direct it and approve it.
- 01 · ProductRequirements
Turns a story or defect into a requirements document.
- 02 · ArchitecturePre-review
Finds design problems while they are still cheap.
- 03 · EngineeringImplementation plan
Writes a technical plan tied to the requirement.
- 04 · CTOPeer review
Reviews the plan. Blocking findings stop the run.
- 05 · EngineeringBuild
Writes code and tests — only against an approved plan.
- 06 · CTOPre-release
Security, development and integration review. Red or green.
- 07 · ReleaseRelease notes
Generated, and linked back to every earlier step.
Lean by default, full when it matters
Every stage checks whether the work is simple enough for its lean path. If not, it escalates to the full path on its own — the run doesn't stop.
Work that spans days
Large requirements and plans are written to disk in phases, with a clean handoff between sessions. The file is the source of truth, not the chat.
Build waits for approval
The build agent refuses to start without an approved peer review. There is no shortcut around it.
It audits itself
After each release, a read-only audit agent sweeps the system for gaps and flags them to a person. It never edits anything.
Every stage passes a gate. Every gate leaves evidence.
Governance isn't a review at the end. It is wired into each stage, so speed and control arrive together.
Seven governance blocks
Five always apply. Two switch on when the work calls for them.
- Security & privacyEvery stage
- Test scopePlan to release
- Testing & quality gatesPlan to release
- Release & rollbackReviews
- Documentation & traceabilityEvery stage
- AI prompting & cachingWhen AI is involved
- API contractWhen an API changes
Findings are named, not scored
No percentages, no readiness index. Each finding is one of three kinds, with a clear consequence.
The stage cannot be approved until it is fixed. No exceptions.
Can proceed only with a documented sign-off from a named person.
Recorded in the output, carried forward, never lost.
An unbroken evidence chain
Every link named, stored and cross-referenced in your repository- User story
- Requirements
- Plan
- Peer review
- Code + tests
- Pre-release
- Release notes
Ask why a line of code exists and the answer is a link away: the release, the review, the plan, the requirement, the story. That is what your board, your risk function or your quality team will ask for.
The heritage behind CDS: enterprise architecture, not just prompts.
CDS is built on decades of experience in enterprise architecture, software delivery and information risk. The starting point wasn’t how much code AI could write. It was what an organisation needs to understand, review and stand behind that code.
That is why the five layers work together — and why governance is part of the delivery process, not something added after it.
Understand before changing
CDS comes from decades of enterprise architecture and engineering work — where every change sits inside a web of systems, teams and dependencies, and treating it in isolation is how things break.
CDS brings Code, Context and Semantic layers together so the task starts with the system around it, not just a prompt.
Keep the decisions, not just the code
CDS comes from a background in software configuration management and enterprise release automation — where the reasoning behind a change matters as much as the change itself.
The Knowledge layer keeps requirements, plans, reviews and release history in your repositories. The reasoning stays with the software.
Automate the work. Retain accountability.
CDS comes from carrying technology and information-risk accountability — the perspective of the people who have to answer for what software does in production.
Orchestration gives specialist agents a defined sequence. Governance gates keep findings visible, and a person approves every change.
Speed your risk and quality colleagues can live with.
Built by an engineering firm, for organisations where someone outside engineering reads what ships.
Your repositories
Work happens in code you own, not in a vendor's copy of it.
A person approves
CDS never merges on its own. Accountability stays where it belongs.
Nothing to unwind
Leave, and the history is already in your repositories.
Built for the leader who is about to be asked for more people.
Your board
Asks whether the speed is under control. The answer is a gate at every stage and a person approving every change.
Your risk and control functions
Ask what changed and why. The answer is an evidence chain from story to release, in your repositories.
Your auditors
Ask to see it for themselves. The record is readable without CDS, long after any contract.
CDS is for technology organisations whose work is read by someone outside engineering. It is not a way to hand accountability to a vendor, or to replace the people who remain responsible.
Tell us about the team you have.
Access is opened for clients. This site will not create an account.
Built by an engineering firm.