AGENTIC SDLC
THE CLEVERBIT WAY
THE CLEVERBIT WAY
Nothing ships because it's fast. It ships because it's checked.
We’ve spent the last few years delivering software for enterprise and regulated clients, often stepping in where other partners failed. What we learned came from watching agentic development fail in specific, expensive ways, not from theory. That left us with our own methods and a few convictions we hold firmly.
Our method has two parts. Neither one works without the other
The path
The order work moves in, from a written requirement to a released feature.
The checking
Everything that stands between an agent's output and your customers.
Two ways agentic development fails without a system
1. Ungoverned speed.
AI writes code fast. Without a system around it, nobody can explain why a given piece of it exists, changes do not trace back to a decision and security or compliance find out what shipped after it is already live. This is fast until the first incident.
2. Governance bolted on afterward.
The instinct to fix this is more reviews, more manual gates layered on AI-generated output. It does not work. Manual review was not built for this pace: it gets skipped under deadline pressure, or slows delivery back to pre-AI speed. You have paid for AI and gained nothing.
The convictions behind the system
A review after the fact is a review that is already too late. By the time a person looks at what an agent produced, the system should already have caught the cost of a mistake.
You should never end up stuck with us. If we have built something you understand, can challenge and could eventually run yourself, that is the system doing its job.
Cheap engineering compounds hidden cost. Structured engineering compounds enterprise value. Speed that cannot be explained, audited or traced back to a decision is not speed. It is risk with a head start.
AI is probabilistic. We treat it like anything else that is. We do not think AI replaces judgement, and we are wary of anyone who tells you it does. It is a fast, capable, occasionally wrong collaborator, which is exactly why the system around it matters more, not less.
THE PATH
Structure before code
Every feature is scoped and specified before an agent touches it. Nothing starts from an open-ended prompt, and nothing gets built against an ambiguous brief.
The spec is the contract the AI works against, and a person signs off on it before generation starts.
The order work moves in is fixed, not improvised session to session: requirement, specification, generation, release.
THE CHECKING
Enforcement while it happens, not after
Every AI-generated change is checked, scanned and tied back to a decision as it is produced. Automated validation and security and compliance checks run at every step. By the time a person reviews it, they are reviewing a digest of what happened and why, not raw output they have to reconstruct the reasoning for themselves.
A human owns the call. AI can generate. Only a named person can decide something ships. There is no autonomous shipping path in the system, and every release has an accountable owner, with every decision traceable back to them.
Risk-based control
- Throwaway. One-off experiments and disposable prototypes that never reach customers, so there's nothing here to check deeply.
- Low risk. Small, easily reversible changes. These get a plan sign-off and one person's review before release.
- Standard. Most everyday feature work. These get a full plan sign-off and a dedicated code review before release.
- High risk. Anything touching money, access or regulated data. These get the most reviewers, the most testing and the closest watch after release.
Not locked to one model
The path and the checking are not tied to one AI model or vendor, because a system built around a single provider’s quirks becomes a liability the day that provider changes terms. That’s the harness at work: the structure around the model matters more than the model itself, so getting it right turns a model swap into a configuration change, not a rebuild.
You are not locked into us either. You can see the system working, understand it, challenge it and eventually run it yourself.
None of that works without visibility. Not a black box, and not a raw activity log either: structured visibility into what was built, what was checked and who approved it.
Not just a claim: Nissy
Clear evidence of how we think about this – Nissy. Nissy started inside Cleverbit’s own AI R&D function, to solve a problem we kept hitting ourselves: most of the reasoning behind an agent’s decisions disappears the moment its session ends. Source control records who committed. It does not record who decided, or why.
Nissy sits inside the session, alongside whichever agent you use, Claude Code, Codex, Copilot and others, and does three things:
- Surfaces the decisions nobody asked about: a dependency added, a retry pattern chosen, an error quietly swallowed. Flagged before it ships, not discovered weeks later.
- Captures the why, not just the what, writing constraints and trade-offs into the artefact where they belong, an ADR or a PR description, while it is still fresh.
- Shows where trust is thin across a team: where intent is fully captured, and where code is running on assumptions nobody has checked. Raw conversations stay private.
How engagement works
STEP 1
The Foundation Engagement
Want to plan and just get started? A scoped diagnostic workshop first, mapped to the same setup questions the method uses internally. It produces a gap report and a named rollout plan.
STEP 2
Execution
STEP 3
Maintain
What we configure for your team
The method is fixed. The configuration isn’t. Six areas decide how it gets set up for your team, and we default to the lightest setup that meets the bar. Anything heavier has to justify itself.
1. How stories get defned.
Who writes them, how much of the domain lives in people’s heads rather than on paper, and what a wrong requirement actually costs here.2. What agents run.
Which models and agents are approved, what they’re allowed to reach, and what evidence a run has to leave behind.
3. What the pipeline is.
What already runs on every merge, what it actually catches, and what the current baseline looks like.
4. What the codebase can carry.
Whether something other than a person can build and test it today, and how safely an agent can orient itself in it.
5. The people.
Which roles exist, who holds them, and whether the people carrying the most load have the time for it.
6. Risk and the organisation.
What the worst case looks like, how fast anyone would know, and where our responsibility stops versus yours.
More on agentic SDLC, from the team who built this one
This page covers how our method works. These go further into the thinking behind it.
FREE DOWNLOAD
The Agentic Software Development Field Guide
WEBINAR