Book a demo

01 — Position

It writes the code.
You decide if it ships.

Developer Bot reads a Jira ticket, writes an implementation plan with its reasoning attached, and then stops. A named engineer approves the plan in Slack. Only then does it write code and open a merge request.

It is never granted merge scope. Not as a policy — as a token. The constraint is visible in the install output below.

developer-bot — first run

$ docker compose up -d

✓ postgres ready :5432
✓ webhook listening POST /jira/webhook
✓ approvals → #eng-approvals
✓ gitlab scope project 4471 · mr:write

# merge scope not requested — by design

Running inside engineering teams at

NORTHWINDHELIOGRAPHMERIDIANBASALTKESTRELORBIT LABS

02 — Method

Four steps, and a person stands in the middle.

  1. 01

    A ticket arrives and gets cleaned

    Jira fires a webhook. Before a single token is spent, the ticket is sanitised — injected instructions, pasted secrets, and junk are stripped out.

    POST /jira/webhook

    PAY-1187sanitised

    Add idempotency keys to refund endpoint

    Duplicate refunds fire when clients retry on timeout. Refunds must be safe to replay.

  2. 02

    It reads your codebase's rules first

    Your workspace files — conventions, endpoint notes, patterns learned from past reviews — go in before the model writes anything. The plan cites which ones it used.

    workspace/CODEBASE.md

    PLANreasoning attached

    1. 01Add an idempotency_key column to refunds, unique per merchant
    2. 02Read the Idempotency-Key header in POST /refunds
    3. 03On conflict, replay the original response — never double-charge
    4. 04Backfill migration, plus tests for the retry race

    Matches the pattern in workspace/endpoints/payments.md — refunds already dedupe on charge_id upstream.

  3. 03

    A named engineer says yes, in Slack

    The plan and its reasoning post to your approval channel. Nothing becomes code until a person presses Approve. The gate is in the architecture, not a settings toggle.

    SLACK_APPROVAL_CHANNEL_ID

    #eng-approvalsSlack

    Plan ready for PAY-1187. Approve to open the merge request.

    ApproveRequest changes

    sara.eng approved · 07:41

  4. 04

    A merge request, opened for review

    It writes the branch and opens the MR against the one project you named. Your engineers still review and still merge. It has no merge rights at all.

    GITLAB_PROJECT_ID

    !482 · feat: idempotent refundsOPEN

      def create_refund(req):
+     key = req.headers["Idempotency-Key"]
+     if prior := refunds.by_key(key):
+         return prior.response

    +118 −12 · 6 files · pipeline passed

0

merges without a human approval

4 min

median ticket to reviewable plan

100%

runs on infrastructure you own

1

project it can open MRs against

The plan cited our payments doc, not a generic pattern. That is when I stopped reviewing it like a stranger's code.

sara.eng — staff engineer, payments

03 — Constraints

What it is not allowed to do.

Self-hosted
Docker Compose up inside your network. Point it at your Jira and GitLab. Nothing leaves except the model API call you configure.
Scoped
A separate token per system, each scoped to one project. Blast radius is a config value, not a promise.
Audited
Every ticket, plan, approval, and merge request is a row in your Postgres. Queryable, exportable, yours.
Sanitised
Inbound tickets are stripped of injected instructions and secrets before any model sees them.

04 — Beginning

Judge it on the merge requests, not the demo.

Put it on one repository for thirty days. If the merge requests it opens do not earn the reviews they cost, walk away — we would rather you learn that in four weeks than four quarters.

For the team evaluating it

30-day pilot · one repository · no merge access granted

For the engineer trying it

git clone git@gitlab:platform/developer-bot && docker compose up -d

Runs on your infrastructure. Postgres and a webhook URL are the only prerequisites.