Generation was never the bottleneck
Your engineers can already produce more code than your process can absorb. The queue moved to review, to testing, and to the people who have to sign their name against a change.
Governed AI software deliveryEarly access
Ship internal software
your auditor can
sign off on.
Describe the change you need, or point it at a work item you already have. Intelli-Dev writes the specification, waits for a person to approve it, builds the change across review, QA and security gates, and opens a merge request in your own repository. Every step in between lands on the audit trail.
Runs against your repositories and your CI/CD. Designed to be deployed inside your own network, so your source never has to leave it.
order 4f2c · delivery pipeline
- OrderA work item from your tracker, or a plain-language request typed straight in.
- SpecificationAcceptance criteria, interfaces and scope, written before anything is built.
- Spec approvalHuman checkpointAn engineer signs off the specification. Nothing is written until someone says yes.
- DecompositionThe order is split into stories, each with its own branch and its own gates.
- BuildCode is written story by story, on branches in your own repository.
- Code reviewGateAn automated review pass before a human is ever asked to look.
- QAGateTests are generated and the change is exercised against the acceptance criteria.
- Security reviewGateThe diff is examined for the things that should never reach a merge request.
- Spec completenessGateThe endpoints and behaviour the specification promised are checked against what was actually built. A gate that can see an absence.
- Merge requestOpened in your repository, against your branch rules, for your reviewers.
- Your pipelineYour CI/CD runs the change. Intelli-Dev reports the result and stops there.
The problem
The bottleneck moved, and the tools did not follow.
Every team we speak to has the same shape of problem. There is more code arriving than there is capacity to specify it, check it and take responsibility for it.
The tools stop at the editor
A coding assistant hands you a diff and walks away. Someone still has to write the specification, split the work, run the checks, open the merge request and chase the pipeline.
Nobody can say what the agent did
When an agent commits into a real repository, an engineering lead needs a record of what was asked for, what was checked, who approved it and where it stopped. Most tools cannot produce one.
What it does
One order. Eleven stages.
One merge request.
Anyone can generate code. The hard part is knowing it works.
An order is a unit of work, not a prompt. It carries the original request, the approved specification, every gate result and every approval, and it can be picked up again after a failure instead of being started over.
Larger orders are split into stories, and each story runs the full set of gates on its own branch. A story that fails a gate does not take the rest of the order with it.
The pipeline deliberately ends at a merge request. Your reviewers, your branch protection and your CI/CD are the last word, exactly as they are today.
It stops where you tell it to
The pipeline ends at a merge request and a pipeline run. It does not deploy to your production, and it does not need to own your hosting to be useful.
Humans hold the checkpoints
The specification is approved by a person before code is written. Merge requests go to your reviewers under your existing branch protection. The approval points are the product, not an afterthought.
One tenant, one install
Intelli-Dev is built to run as a single tenant against a single organisation, which is what makes it deployable inside a network that will never allow a shared service.
A gate that can see an absence
Quality gates are good at judging the code in front of them and blind to the code that was never written. The spec completeness gate compares what the specification promised against what the build actually serves.
Where it plugs in
It works where your work already lives.
There is no new board to keep up to date and no second source of truth. Intelli-Dev reads the tracker you already use and commits to the repository you already have.
Azure DevOpsGitLabGitHubJiraYour CI/CDYour branch rulesYour reviewersYour infrastructure
Azure DevOpsSupported
GitLabSupported
GitHubNext
JiraNext
Azure DevOps and GitLab are the reference integrations we build and test against, because they are what we run ourselves. GitHub and Jira are next in the queue.
Whiteboxing
Your code never has to leave.
Whiteboxing is our name for shipping the whole product onto your own infrastructure. Not a private tenant of our cloud. The actual system, running in your estate, against your repositories, behind your controls.
It is built for it. Single tenant by design, with no hardcoded hosts and no assumption that it can reach the public internet to do its job. Model routing can point at a model you host yourself, so a regulated environment never has to send source code to a third party.
In your estate
- Runs inside your network, against your repositories
- Single tenant, one install per organisation
- Point it at a model you host yourself
- No hardcoded external hosts or domains
- Your identity provider, your access rules
- Every order carries an auditable record of gates and approvals
Where this actually is
Early access, and we will say so.
Intelli-Dev is real software that we use ourselves. It is not generally available, we are not taking orders for it, and there is no pricing page here because there is nothing yet to buy.
We are opening a small early access group to teams whose work already lives in Azure DevOps or GitLab, and who have a backlog nobody is getting to. If that is you, the waitlist is the way in. If it is not you yet, joining costs nothing and we will not fill your inbox.
Get on the list.
Tell us where your work lives and what is stuck. We use it to decide who goes first.