From work item to merge request.

Most AI development tools are built around a conversation. You ask, it answers, and the context lives and dies inside a chat window. That works for a single change and falls apart the moment the work spans a week, a team or a failure.

Intelli-Dev is built around an order. An order is a durable record that carries the original request, the approved specification, the stories it was split into, every gate result, every approval and the merge request it produced. It survives a restart. It can be picked up again after a failed stage rather than being started from the beginning.

That is also what makes the work explainable afterwards. When an engineering lead asks what the agent did and who agreed to it, the order is the answer.

The first thing the pipeline produces is not code. It is a specification: acceptance criteria, the interfaces the change is expected to expose, and an explicit statement of what is in and out of scope.

This is where most of the risk gets removed. A misunderstanding caught in a specification costs a minute to fix. The same misunderstanding caught in review costs an afternoon, and caught in production it costs considerably more.

The specification then waits. An engineer reads it and approves it, and only then does the build begin. This checkpoint is not a setting we expect you to turn off. It is the point of the design.

An approved specification is decomposed into stories. Each story is built independently, on its own branch, and runs the full set of gates on its own.

The practical benefit is blast radius. A story that fails a gate does not drag the rest of the order down with it, and a story that needs a second attempt does not force a rebuild of the work that already passed.

It also keeps merge requests reviewable. A single change that touches forty files is not a review, it is a rubber stamp. Stories keep the diffs at a size a human can actually hold in their head.

Four gates run before a merge request is opened. A code review pass, a QA pass that generates and exercises tests against the acceptance criteria, a security review of the diff, and a spec completeness check.

That last one exists because of a failure we hit ourselves. An application once passed review, QA and security while being functionally empty. The logic had been written, but nothing ever mounted the routes, so every gate looked at correct code and reported that it was correct. None of them could see what was missing.

The spec completeness gate closes that hole. It extracts the endpoints and behaviour the specification promised, compares them against what the built application actually serves, and blocks when something promised is not there. It is a gate designed to detect an absence rather than judge a presence.

Read the full account: Every gate passed. The app did nothing.

When the gates pass, Intelli-Dev opens a merge request in your repository. Not a copy of your repository, and not a repository we host. Yours, against your branch protection rules, assigned to your reviewers.

From there your CI/CD does what it already does. Intelli-Dev watches the pipeline and reports the result back against the order, and that is where its authority ends.

This is a deliberate limit. A tool that insists on owning your build and your hosting in order to be useful is a tool that most engineering organisations cannot adopt without a migration. We would rather be adoptable.