Pilot, 2-3 weeks
€1,500-4,000guide price, refined on the review call
- the loop on your server
- 5 to 10 issues from the agreed list
- acceptance by the number of merged issues
- metrics report
Autonomous development loop
An issue with acceptance criteria goes in. A verified pull request comes out.
A coding agent works through your issues on your server, using your own API keys. Code is written in an isolated copy of the repository, checks decide what passes, and a separate reviewer reads the change. You do the merge.
Pilot: a guide price of €1,500-4,000, refined on the review call. Accepted against a task list we agree on before the start.
Example issuelabel auto-dev
#41Export paid orders from the CRM to the reporting sheet every hour
Acceptance:
pytest tests/test_export.pyexit 0ruff check .exit 0npm run buildexit 0
- copy separate branch, working code untouched
- checks existing tests intact, new ones green
- review a different model, verdict "approve"
Pull request #57awaiting your decision
Illustrative example, not a client task.
The core condition
Your keys, your data, your server
- KeysModels run on your API keys. The contract and the bill with the model provider are yours, and the spending shows up in your own provider account.
- DataYour code and issues are never mixed with other clients. Each client gets a separate instance and its own queue.
- ServerThe loop runs on your server or on a dedicated server set up for you. If you leave, everything stays with you.
What it is
Five steps every issue goes through
This is not a chat with a model and not an editor for programmers. It is a process: an issue becomes a verifiable unit of work, and the result lands in your repository as an ordinary pull request.
-
01
An issue with acceptance
An issue is picked up only if it has an
Acceptance:line and the commands that prove it is done. "Do something" turns into an agreement you can check. -
02
An isolated copy
The agent works in a separate copy of the repository. It does not write to your working branch, and we do not give it access to the production database or production secrets; the list of access rights goes into the contract.
-
03
Checks by exit code
The environment judges, not the model's own words: tests, linter and build either pass or fail. Deleting or weakening existing tests counts as a failed task, not a fix.
-
04
Independent review
Once the checks are green, a separate reviewer on a different model reads the change. It looks for mistakes an agent grading its own work could miss.
-
05
A pull request, no auto-merge
The result arrives as a pull request with a description and check results. Your person has the last word: they merge, not the agent.
Autopilot
Every few minutes it picks up labelled issues from your repository and puts them in a durable queue. An issue without an acceptance line is skipped, not guessed at.
The Butler, our acceptance agent
Untangles stuck tasks, re-checks pull requests before you review them, and writes the summary: what was merged, what came back and why.
A 2-3 week pilot
How the pilot runs, week by week
The goal is to prove on your code that the loop closes issues from an agreed list. Not the whole backlog: a specific set of 5 to 10 issues with acceptance commands.
-
Before the start
Review and the list
- we look at the repository and the issue queue
- we pick 5 to 10 issues that commands can verify
- the contract states how many of them must be merged
-
Week 1
The loop on your server
- we install the coder, autopilot and acceptance agent
- we connect your model keys and access to the listed repositories only
- with your person, we add acceptance criteria to the issues
-
Week 2
Working the list
- the agent takes issues, you receive pull requests
- we untangle stuck issues and sharpen their wording
- interim summary: what was merged, what came back
-
Week 3
Pilot acceptance
- result against the list: how many issues you merged
- report: time to merge, rework requests, model spend
- decision on ongoing support, or handing the loop over to your team
The pilot is accepted when the agreed number of issues from the list has been merged. New issues are added during the pilot only in writing, each with its own acceptance line.
Who it is for
When the work has an owner but no hands
- Companies without their own development teamRetail, services, clinics, schools. The queue of CRM, website, bot and reporting changes grows faster than a contractor can clear it.
- Digital agencies and studiosDozens of small client projects with similar changes that eat into the margin.
- Owners of several projectsSeveral repositories with no process and no checks. You need confidence that a new change has not broken the old ones.
Not a fit
- You want "the whole backlog done" without writing issues. The loop works from issues with acceptance criteria, not from wishes.
- There is no git repository and no way to check the result with a command.
- A strong developer team that needs a tool in hand. Cursor or Claude Code will serve them better.
How it differs
Cursor, Devin and Copilot sell a tool. We set up a process
They are good products for developers. The difference is who buys and what they get.
| Mass-market agents: Cursor, Devin, Copilot | Potential AI Coder | |
|---|---|---|
| What you buy | A subscription seat for a developer | A working process: issue writing, checks, acceptance, reporting |
| Input | Chat, editor or a free-form task | Only issues with acceptance commands |
| Who judges the result | The model and a developer reading the code | Exit codes of your checks, then a reviewer on another model |
| Where it runs | Usually in the vendor's cloud | On your server or a dedicated server for you |
| Models | The vendor's chosen lineup | Swappable engines from several providers, on your keys |
| Reporting | Seat and request usage | Merge rate, rework, time to merge, what got stuck and why |
| Who untangles stuck work | Your developer | The acceptance agent and us, as part of support |
With a developer watching, a single attempt by Devin or Claude Code is more accurate than ours today. We win where there is no developer: with the process around the agent and responsibility for it.
Numbers as they are
Our own loop over 7 days, 18-25 October 2026
Taken from our server across our own projects. This is not a promise for your code. It shows that the loop runs every day, and where it is still weak.
729autopilot runs with no human involved
87pull requests merged
5.3 hmedian from opening a pull request to merge
20%of pull requests merged automatically with zero rework; our target is 60%
That is why a person handles acceptance during the pilot and support, and issues are agreed in advance. You get the same figures for your repository every week.
Security and data
The agent sees only what the issue needs
- A separate instance per clientIts own server or container, its own queue, its own project registry.
- Access to the listed repositories onlyA dedicated GitHub token scoped to those repositories, not the whole organisation.
- No production accessWe do not give the agent production databases or production secrets; the access list is in the contract. The agent works with code and tests.
- Your model keysYou choose the provider and the plan, and you can revoke the key at any time.
- Merging by a human onlyNo change reaches your working branch without a decision by your staff.
Pricing
A pilot, then support. You pay for models directly
Support, per month
€900-2,500guide price, refined on the review call
- issue writing from your queue
- untangling stuck work, loop updates
- monthly issue limit set in the contract
- monthly report
Models
Billed by the providerdepends on issue volume
- you pay the model provider yourself
- no markup from us
- you set the spending limit, where the provider supports it
Questions and answers
What people usually ask on the review call
Will this replace a developer?
No. The loop closes clear issues with a verifiable result and takes routine off people's plates. Architecture decisions and merging stay with your person.
Why run models on our keys rather than yours?
It is more transparent and more reliable. The contract with the model provider is yours, so you see the spending in your own account, control the keys and do not depend on our account.
What do you need from us?
A GitHub repository, the commands that verify a result (tests, linter, build), and a person who regularly clarifies issues and merging pull requests. Without issue writing, the loop sits idle.
What if an issue from the list does not work out?
We find where it got stuck: in the wording, in the checks or in the code itself. We sharpen the issue and run it again. The pilot's acceptance criterion is written into the contract in advance, so there is no argument about what counts as a result.
Can we add issues during the pilot?
Yes, in writing and with their own acceptance line. Verbal "and also this" requests are not part of the pilot, otherwise it cannot be accepted fairly.
Which models do you use?
The loop works with engines from several providers and can switch between them by quality and price. We choose which to connect together on the review call, based on your stack and budget.
How is the contract set up?
Euro contracts are signed with our company in Cyprus. Rouble contracts are possible too; in that case we pick the models available to you on the review call.
What stays with us if we stop support?
All merged changes, the issue history and the reports. The loop runs on your server and the keys are yours, so when you leave, all of it stays with you. The handover procedure is written into the contract.
Review call
Show us your repository, and we will show you which issues the loop can close
On the call we look at your code and issue queue, pick the list for the pilot and name a price for your task list. If the loop is not right for you, we will say so.
- a link to the repository or a description of it
- 5 to 10 issues that have been waiting too long
- how you check results today
Mikhail Zelenin, Telegram @mzelenin, email mikhail.zelenin@gmail.com