From issue to merge request — the bridge is built

Back in July we wrote here that development tasks can be handed to an AI agent via Signal or through GitLab. At the time one gap was left open, and we said so: our own task management system, ocTask, was not connected. Anyone who created an issue there had to pass it on by hand.

That bridge is now built.

How a run works

A human describes the issue. As always: title, description, priority, attachments. Nothing AI-specific.

A human approves it. Two steps, and both are deliberate: assign the issue to the agent's account and set the release label. If either is missing, the task does not exist for the agent.

The agent claims it. It checks at regular intervals whether anything is waiting for it and takes exactly one issue — bindingly. If somebody else claimed the same issue in the same second, it leaves it alone rather than doing the work twice.

It works. In the GitLab repository linked to the project. It reads its way in, changes code, builds and tests its own work.

It delivers. A merge request, plus a comment on the issue summarising what it did and linking to the merge request.

It sets the issue to “Testing”. Not to “Done”.

The most important sentence comes last

The agent never sets an issue to “Done”. That is not modesty, it is the boundary the whole procedure hangs on: a human says done. A machine allowed to sign off its own work does not have quality assurance, it has a logbook.

Three further things it does not do:

• It does not write to the main branch. Creating the branch, committing and opening the merge request is not done by the coding tool but by the agent itself — under control, with no history rewriting and no forced overwrites.
• It does not go looking for work. Without an assignment and a release label a task is invisible, however obvious it may look.
• It does not guess. If something is unclear it asks as a comment on the issue and stops. The answer — also a comment — is picked up and the work continues.

Why this is more than convenience

The link between task and source code is the issue key. It appears in the branch name, in the merge request and in every comment. Six months later that is what lets you answer, for any change in the code, which question it came from — and who approved it.

That is the real gain. Not that a machine writes code; plenty of things do that now. But that what remains at the end is a trail that still holds up once nobody remembers the conversation.

For our clients it means something concrete: we work with them in the same system. They describe a task, see the implementation plan as a comment before any code exists, and see at the end what came of it. No ticket number at a service provider, no status enquiry by email.

Staying honest

The autonomous run is young and we treat it accordingly. Not every task is machine-ready — the selection is still made by a human, and that is exactly what the release label is for. Tasks that need a lot of context from conversations we would rather finish describing ourselves than let the agent guess.

And the merge request gets read. Every time.