Job small-issues-to-reviewed-agent-pull-requests · revised 12 October 2026
Hand over up to five small issues; get a reviewed pull request for each we can safely do
Each of up to five small, well-described issues we accept gets one pull request with a failing-first test and CI passing. You pay £149 per pull request you accept, and nothing for one you do not.
You might be seeing
- Small fixes wait months because each needs context and a pull request cycle
- Nobody wants to own the tidy-up issues
No passwords, keys, card details or admin invites needed to start.
What usually happened
Small issues are cheap to describe and expensive to start. Handing them to an agent without limits produces pull requests that skip tests, change too much or never get merged: in one large repository about a third of the agent pull requests that were decided were not merged.
Who it’s for: A lead with a pile of small, clear issues that never reach the top of the list.
Usually starts when: There are five or more small issues, each with clear expected behaviour, that keep losing to bigger work.
The result: Each of up to five small issues we accept gets one pull request on a branch or fork, with a failing-first test, CI passing on the same trigger, at most 150 changed lines in at most five files, and no test weakened. You review and merge. You pay for each pull request you accept.
Check whether this job fits
Answer these without sending code, tickets or logins. Nothing is submitted unless you choose to contact us.
What you get
- One pull request per accepted issue with its tests and CI link
- A note per pull request of what changed and how to undo it
- The list of issues turned back and why
Included
- Up to five issues, each with written expected behaviour, in one repository with CI
- One pull request per issue on a fork or branch, with a test that fails before and passes after
- At most 150 changed lines in at most five files per pull request
- One round of revision per pull request after your review
- A list of issues turned back as too big, unclear or unsafe to attempt
Not included
- Features, redesigns, schema changes, payments, authentication or security changes
- Deploying or merging; you do that
- Changing CI, test settings, branch protection or repository settings
- Issues without clear expected behaviour
- A promise that every issue will produce a mergeable pull request
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each pull request contains a test that fails on the unchanged code and passes on the change, run on the same trigger.
Evidence: The failing run, the passing run and the source revisions.
No test is removed, skipped or loosened and no CI step is disabled, and each pull request is within 150 changed lines and five files.
Evidence: The changed-file list and a script check of the diff.
Your reviewer accepts or sends back each pull request, and a returned one gets one revision.
Evidence: Your recorded decisions and the revision commits.
Sign-off. Your reviewer accepts each pull request in writing and merges it under your rules. Payment is per accepted pull request.
If it fails. You do not pay for a pull request you do not accept. If an issue cannot be attempted safely, we turn it back with the reason and agree whether to stop; no surprise work.
When it fits, and when we stop
It fits when
- A repository with working CI and tests
- Up to five issues with written expected behaviour, which we may read
- A named reviewer on your side who reviews within five working days
We stop and tell you if
- CI does not run on a fork or branch pull request
- An issue needs a product decision, a secret or production data
- A change would exceed the line or file cap, so the issue is turned back
What could go wrong
Close a pull request and your default branch is unchanged. After a merge, revert the commit. We change no repository settings and deploy nothing.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The pull request passes because a test was skipped or loosened. | The reviewer checks for removed assertions, skipped tests and lowered thresholds, and a script flags them in the diff. |
| Not every issue yields a mergeable pull request. | You pay only for pull requests you accept, and turned-back issues are listed with the reason. |
| Issue text carries instructions meant for the model. | Issue text is treated as data, never as instructions. The agent works in a sandbox with no production secrets, can only push to a fork or branch, and CI runs before your reviewer reads every diff. |
A separate automated reviewer checks the work before hand-over. Your named reviewer reads each pull request and merges it under your rules. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the issues, the line and file caps and the expected behaviour in writing
- Reproduce each issue; write a failing test on a branch
- Make the smallest change that passes it; never weaken a check
- Run CI on the same trigger and record the result
- Separate automated reviewer checks the diff for weakened checks and secrets
- Open the pull request; your reviewer accepts or sends it back once
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date before you accept, and work starts only after agreed inputs, secure access and permissions are in place. Model usage up to a cap we state in writing is in the price, and an enquiry creates no charge or booking.
Need to keep it working?
For work that is bigger or ongoing, the engineering backlog project or the engineering lane can follow.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Ask a coding agent that works in your own account to attempt the issues, and review each yourselves. Your own subscription and your own review time apply.
- Run a short "small fixes day" with your team and clear them by hand.
Questions
What if you cannot do an issue?
We turn it back with the reason and you pay nothing for it.
Do you merge the pull requests?
No. Your reviewer merges under your own rules.
How is this different from the bigger engineering lane?
This is five small issues with strict caps, paid per accepted pull request. The lane is ongoing, with a monthly plan and larger items.
Why is this cheaper per pull request than the one-bug fix job?
The caps are strict: 150 lines, five files and a clear issue. Bigger or unclear work is turned back, or belongs in the one-bug job.
Send an enquiry
Send us
- How many small issues and what kind, in a sentence each
- Your language, framework and CI
- No code, issue text or logins in the first enquiry
Later, once you agree
- The issues as text and read access to the repository through a company-controlled route
- A fork or branch for the pull requests
- The name of your reviewer
You keep the repository, CI, secrets and merge rights. We use a dedicated bot account with the least access that works (read-only first), work on a fork or branch, and you merge; no pull request is merged or deployed by us. Our automated agents read the files you send in a sandbox; we make no "no training" or "no storage" promise here, and the agreement names the model provider, country, retention and training status before anything is shared.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “small-issues-to-reviewed-agent-pull-requests” as the subject.