2 min read

From issue to merged PR without opening your editor

The full path of one vemlor task: an issue becomes a task, a runner executes your agent, and a reviewed merge request comes back.

guides

An issue goes in, a reviewed merge request comes out. That is the whole product. This post walks through what happens in between, step by step, on one concrete task.

Step 1: something triggers a task

Work rarely starts in an editor. It starts as a signal: a bug report from a customer, a Sentry error, a failing pipeline, a review comment asking for a change. On vemlor, any of these can become a task. Assign an issue, drop a comment, or let a webhook fire. No copy-pasting context into a chat window.

For this walkthrough: a GitHub issue describing a bug, assigned to vemlor.

Step 2: the platform builds the context

The task gets the things an agent needs and a human would otherwise assemble by hand:

Step 3: a runner executes the agent

The runner checks out the repo in an isolated environment and hands the agent the task. The agent explores the code, makes the change, and runs the tests. Every command and every file change is recorded, so you can open the run later and see exactly what happened and why.

Step 4: a merge request comes back

The output is not a chat transcript. It is a merge request on your repo: branch, commits, a description explaining the change, linked back to the originating issue. CI runs like it would for any human PR.

Step 5: you review, you merge

Nothing lands without a human decision. You review the MR like any other. Request changes and the follow-up comment becomes a new task for the agent. Approve and merge when it is right.

You make the calls. The agent does the typing.

Try it on one issue

The fastest way to evaluate this is a single real issue from your backlog, not a toy repo: