Skip to content

How it works

Your ask goes in. A merged pull request comes out.

We do the architecture pass, dispatch the work, review the pull request and merge it through the machine gates you configure, around the clock. The code itself is written by an agent running on your own machines, under your own keys. You keep the ideas, the boundaries and the business.

Request accessRead the quickstart

01The run

From an ask to a deploy, one stage at a time.

Every stage is logged, and a human is pulled in only for a decision that is genuinely theirs.

  1. InputaskThe ask arrives as a GitHub issue, an MCP chat message or a webhook, and it stays the source of truth for everything that follows.
  2. ScoutplanThe scout reads the repository and the thread on a machine that has the code, then writes one plan, or stops as blocked or declined and says why. By default, a plan your agent started goes straight to the machines without passing through triage.
  3. Triageexecutable workEvery filed ask, from an issue, a tracker, an alert, your own agent or the scout's own rounds, is judged on your own key: routed to a lane, dropped with a reason, or sent back to the asker with a question. Nothing disappears quietly.
  4. Assignerpulled, not pushedWork is pulled, never pushed: an idle machine claims the next ready task. Two tasks in one repository that touch the same files wait for each other, unless a task is marked safe to run alongside others.
  5. WorkerPRYour AI dev writes the code on your own machine, with your own keys, and opens one pull request for the task. The harness, not the model, owns git.
  6. CI + reviewerfix loopEvery push runs CI, the reviewer judges what is new since its last review, and the worker fixes and pushes again until the checks are green.
  7. Merge lanemergeThe merge is a machine decision: required checks, unresolved findings and policy refusals are all weighed before the button is pressed. Keep a human lane if you want one.
  8. Your deployproductionYour own pipeline ships the merge, exactly as it does today. We never deploy your software.

Four asks, one per row, each followed to its end. An issue is judged, pulled by a box, sent back once by review and shipped. A Linear item waits while you are asked for more, is judged again and runs. A Sentry alert is dropped with a reason. A plan your agent starts goes straight from the scout to a box, and this one is held at the merge gate for a human.

  • in flight
  • waiting on a human
  • dropped with a reason
  • merged, in your pipeline
An illustrative animation, not a live feed: the asks, their references and their timing are made up, and nothing here is measured from our fleet.

Every transition is loggedPolicy refusals and escalations replay against a new policy, without re-executing

02Guardrails

Boundaries are part of the brief.

Your maintainer.yml defines what the dev may touch: versioned, reviewed, and enforced on every run.

  • Allowed repositories
  • Protected file paths
  • Required CI checks
  • Human approval gates

03Proof

One feature, built two ways.

The comparison takes one issue and builds it twice: once with a developer driving Claude, once by handing it to developerz.ai. Same repository, same starting commit, same model. The method is registered in public before either arm runs, and both receipts are published whatever they say.

See the comparison and its method

04Questions

Frequently asked questions

Whose API keys does it use?

Yours. BYOK is the only mode: your own key from Anthropic, OpenAI, Gemini, DeepSeek, Kimi, GLM, MiniMax and more, or any OpenAI-compatible endpoint. We never resell tokens.

Does it write the code?

On Solo and Enterprise, yes, and it maintains it: your AI devs write the code on your own enrolled boxes, with your own keys, and developerz.ai orchestrates the work, reviews every pull request and gates the merge. An issue you hand to Copilot is written where GitHub runs Copilot. On OSS Free no AI dev writes code: it triages issues and cuts releases on your public repositories, on your key.

Can I see what it did?

Yes. Every tool call and decision is logged. If it isn't logged, it didn't happen.

What about CodeRabbit or Dependabot?

It never converses with another bot: no bot-on-bot loops. It waits for a CodeRabbit review to settle before acting, and it reviews, fixes and merges Dependabot and Renovate PRs through the merge gate when your policy covers them.

Ship more. Maintain less.

We expect software to be written faster than any team can review it. Bring your repos, your boxes and your keys. We bring the org that keeps up.

Request accessmcp.developerz.ai