Assign the issue to the agent and development starts on its own.
Just assign the issue to the agent: it analyses it, opens the branch and the draft merge request, and implements it. A person reviews and merges.
The problem
“That issue has been sitting there since it was opened and nobody has read it.” “Before writing a line you have to analyse it and open the branch.” “The small things never get started.”
It happens to any development team with more issues than hands: each one waits for someone to have a gap to start it, and that start is work nobody sees.
How it is done today
Every issue waits for someone to read it, analyse it and open the branch. Until then nothing happens. And whoever picks it up spends the beginning preparing the ground before they can code.
How we solve it
- You assign the issue to the agent, just as you would assign it to someone on the team. There is nowhere else to ask.
- The agent writes the functional analysis of what is being asked.
- It creates the working branch for that issue.
- It opens the merge request as a draft, so the work is visible from the start.
- It implements the change on that branch and leaves it in the merge request for a person to review.
Result
It is how we work every day: an issue assigned to the agent stops waiting for someone to start it.
What it takes
Your repository and your issues
An agent user on your code platform, with permission to create branches and open merge requests. No permission to merge.
Well-described issues
The agent starts from what the issue says: what is wanted and how you know it is done. If that is missing, the analysis makes it visible.
Project rules, in writing
How work is done in the repository: branches, conventions, what must not be touched. If they are not written down, we write them with you.
A person who reviews and merges
Someone on your team with the judgement to accept or reject the change. The agent prepares; the person decides.
How it is built
The trigger is the assignment itself: the issue is assigned to an agent user on the code platform (GitLab in our case). There is no other command to give and no other tool to open.
The agent writes the functional analysis, creates the feature/ branch with the issue number, opens the draft merge request and implements it there. What it does is written on the issue and on the merge request.
The agent does not merge or publish. It works in its own isolated copy of the code and passwords never reach the model. Before production, the change goes through the same review as any other.
Frequently asked questions
What do I have to do for the agent to start?
Assign it the issue. From there it writes the functional analysis, creates the branch, opens the draft merge request and implements it.
Can the agent merge its own change?
No. A person reviews the merge request and merging is always done by a person.
What happens if the issue is badly described?
The agent starts from what is written. That is why the functional analysis comes first and in plain view: the reviewer sees what it understood before looking at the code.
Related automations
Agent orchestrator
A director splits each goal between several agents working in parallel. A person approves.
Code review
Four agents review every change before production. A person decides whether it goes in.
Part of AI agent development