Skip to content

Writing code

The most developed piece of work in the product is the coding controller: hand it an issue, get back a merge request. The interesting part is that how far it goes from there is your decision.

What it is for
An issue in, a reviewable merge request out.
Who uses it
Developers, and the review agents policy hands it to.
Where in the UI
Chat, an @mention on a merge request, or a schedule. Jobs under Settings › Code › Work.
What it writes
A branch and a merge request on GitLab or GitHub.
Which gate governs it
The plan gate, then the merge gate.

Full map: Map of Neutron Core

Issueor epicOwn checkoutat an exact commitPlanneeds approvalVerify · review · repairbounded — cannot loop foreverMerge requestidempotentretries, up to a limitMerge gatehuman or review agentsBy default a human reviews the merge request like any other. Policy can hand review, approval,and publishing to review agents instead — every step still gated and on the record."Idempotent" means running it twice updates the same merge request instead of opening a second one.
The pipeline always produces a reviewable merge request. What happens next is a governance setting, not a hard-coded stop: hold every merge for a human, or let review agents review, approve, and publish — under the same gates, separation of duties, and audit log.

Why each step is there

An exact commit, not a branch name. The checkout is pinned to a specific commit, so the work the agent reviewed is the work it changed. A branch that moved underneath it would silently invalidate everything after.

A plan before code. The agent writes what it intends to do and that plan passes the gate. Reviewing an intention costs a minute; reviewing a finished 40-file diff costs an afternoon.

Bounded repair. Verification failures trigger a retry loop with a hard limit. Without the limit an agent can burn budget indefinitely on a problem it cannot solve.

Idempotent output. Running the job twice updates the existing merge request rather than opening a second one, so a retry after a crash does not litter the forge.

Autonomy is a dial, not a fixed stop. Out of the box the pipeline ends at the merge request and a human ships. Grant review agents the right to review, approve, and publish, and it goes all the way to production — under the same gates, the same separation of duties, and the same audit log. How far autonomy runs is a policy you set, never a default you inherit.

Where the work comes from

An agent can be handed work three ways: a person asks in chat, someone mentions the bot on a merge request or issue in GitLab or GitHub, or a schedule fires and starts a turn with no human present at all. The third case is why the audit log and the interrupt governor exist — proactive work needs the same record and the same manners as work you asked for.

Last updated on