Caylent · DevBench · Executive summary
DevBench lets AI do a large share of software delivery work without giving up the controls the business runs on.
Work is specified before it is built, independently reviewed before it merges, and recorded at every step. The process stops at the merge and hands off to the release process you already run.
The decision on the table
The question is not whether AI writes code here. It is whether you can stand behind what it produces.
AI-assisted coding is already happening inside most engineering organizations, with or without a policy for it. What is usually missing is the part a regulated business cannot operate without: a written record of what was asked for, independent proof that it was reviewed, and a human decision on the way to your main branch.
DevBench supplies that missing part. It is the governance around the AI, not the AI itself.
The controls
Five controls that hold whether anyone is watching or not.
-
The worker cannot approve its own work
The agent that writes the code is structurally barred from recording any of the five required review verdicts on its own work: the attempt is rejected before it reaches the record. The reviewing agents are separate, they are given no file-editing tools, and the agent that dispatches them is restricted to read-only commands. Segregation of duties is enforced by the system, not by a rule in a handbook.
-
Five independent reviews run before the merge
Four independent reviews of the code, the tests, the documentation and the declared scope, plus a mandatory security review. The pipeline runs all five before it merges anything, and a failure sends the work back to the agent that wrote it. The work item itself cannot be closed unless the latest review round carries a recorded pass from all five.
-
Every decision is recorded on the work item, not in a chat window
Every action and every verdict is appended to the work item as it happens, stamped with the time and with the agent that took it. That record is the system's own working state rather than a summary written afterwards: the gate that closes a work item reads it. The backlog is normally kept in its own repository, so the history is versioned and reviewable long after the run. Making that history cryptographically tamper-evident is a proposal on the Enterprise Vision page, not something the system does today.
-
The approval gate sits wherever you put it
Out of the box DevBench opens a pull request for each work item and merges it itself once the build passes. Requiring a person to approve work before it starts, to release each new work item into the queue, to perform each merge, or all three, is something you switch on. Moving the line is a configuration choice, not a software change.
-
No code reaches production on its own
The software delivery pipeline ends at the merge. There is no deployment, release or promotion stage anywhere in it, so your release process, your change management and your sign-offs are untouched. The same loop can also be pointed at operational runbooks such as audits or teardowns, where a work item performs live actions directly and the deliverable is an evidence record instead of a merged change. That is a mode the operator configures deliberately.
What changes operationally
The scarce work moves up a level.
Typing the code stops being the constraint. What becomes scarce is deciding what should be built and judging what came back. One person supervises several streams of work in parallel instead of making one change at a time, and spends their attention on the specification and the exceptions.
The system is built for those exceptions. Work that cannot proceed is sorted into one of seven defined blocked states; three of them always stop and wait for a person, and each one names what has to happen next.
How adoption works
Start fully supervised. Widen only on evidence.
-
Step one
Approve everything
Switch on the settings that hold every new work item until a person releases it, and that hand every pull request to a person to merge. Both are choices you make when you configure the bench, not the shipped defaults.
-
Step two
Spot check
Once the review record has earned trust on real work, sample it instead of gating on it. The mandatory reviews keep running underneath.
-
Step three
Widen the scope
Let the pipeline run end to end where the risk profile allows it, and hold the tighter setting where it does not.
Every step is reversible: each one is a setting, so tightening back up takes effect on the next run.
Honest limits
What it is today, and what it is not.
- Open source, not a product you buy
- DevBench is licensed under Apache 2.0, copyright Caylent. No license to negotiate, no vendor lock.
- It runs on a workstation or a VM
- One team, one workspace, run by an operator who can run several sessions against it at once. No managed service, no web portal, no single sign-on.
- It stops at the merge
- Release, deployment and change management stay exactly where they are now. DevBench does not touch them.
Running it at enterprise scale is a proposal, and is labelled as one
The Enterprise Vision page sets out what it would take to run this as a governed internal service: work queued across teams, an interface instead of a machine to log into, and the same evidence trail under single sign-on and audit. None of it exists today; that page is written and marked as a proposal throughout.
Read the enterprise visionWhere to check our work
Everything above is verifiable in public.
Every count on this site is a count of something in the open-source repository. No projections, no benchmarks, no savings claims: none of those have been measured.
Technical overview
The same story at more depth: what each gate enforces, where the human sits, and how a team adopts it.
Read the overview → TodayArchitecture
The interactive map from specification to merge. Every component links back to the file it lives in.
Open the diagram → TodayThe source code
Read it, run it, or have your own engineers audit it. Apache 2.0 on GitHub.
View the repository →