Job bug-reports-reproduced-or-explained-in-batch · revised 12 October 2026
Try to reproduce your open bug reports and learn which ones are real
Up to 20 bug reports each end as reproduced with a failing test, not reproduced with the steps tried, or needs information with one question. We fix nothing.
You might be seeing
- Reports sit open because nobody has tried to reproduce them
- Developers spend time on a report and find it cannot be reproduced
No passwords, keys, card details or admin invites needed to start.
What usually happened
A bug report is only useful once someone has shown it fails. Trying each one by hand costs an hour or more, and reports that cannot be reproduced stay open and distract. A reproduction written by a model can also assert the wrong expectation and then look like proof.
Who it’s for: A lead with dozens of bug reports of unknown validity and no time to try them.
Usually starts when: The bug list is long, nobody knows which reports are real, and each triage costs a developer an hour.
The result: Each of up to 20 bug reports ends in one of three states: reproduced (a failing test on a branch, no fix), not reproduced (the steps and environment tried), or needs information (one specific question). No fix is made.
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
- A table of outcomes with links
- The failing tests on a branch
- The attempt logs for the reports not reproduced
- The list of questions
Included
- Up to 20 reports and the code at one named commit, built and tested in an isolated sandbox with synthetic data
- For each: a failing test on a branch, or the logged attempt that did not reproduce it, or one question
- Five reproductions re-run by you to confirm the same result
- A summary table by outcome
Not included
- Fixing any bug; each fix is a separate job
- Reproduction that needs production data, credentials or live third-party services
- Performance, load or security testing
- Reports in code we cannot build in a sandbox
- A claim that a not-reproduced report is not a bug
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every report has exactly one outcome, and every reproduced report has a test that fails at the named commit on the assertion the report describes, not on a build or setup error, shown by the failing output.
Evidence: The outcome table and the failing run for each reproduced report.
You re-run five reproductions in your own environment and get the same failing result. If any of the five asserts the wrong behaviour, your engineer reviews the expectation of every reproduced report before sign-off, and payment waits until they have.
Evidence: Your re-run output for each of the five.
Each reproduced report has a one-line "expected behaviour" statement quoted from the report, shown next to its failing test.
Evidence: The expectation line for every reproduced report.
Every not-reproduced report shows the steps and environment tried, and every needs-information report has one specific question.
Evidence: The attempt logs and the question list.
No production data or credential was used, and no production code changed.
Evidence: The sandbox configuration and the changed-file list showing test files only.
Sign-off. Your named engineer reads the table, re-runs five reproductions and signs off in writing. Payment follows sign-off.
If it fails. If the agreed checks do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- The app builds and its tests run in a sandbox with synthetic data
- Up to 20 reports with enough text to attempt
- A named engineer who confirms the expected behaviour for five reproductions
- Read-only code at one commit shared through a company-controlled route
We stop and tell you if
- Reproduction needs production credentials or customer data
- The app cannot be built in a sandbox
- The reports describe features, not defects
What could go wrong
The tests live on a branch you choose to merge or delete, and no production code changes. Our copies of your code and reports are deleted when the job ends.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A test asserts the wrong expectation and a bug is pinned as correct. | Your engineer confirms expected behaviour for five reproductions, and each test names the report text it asserts. |
| Running your code in a sandbox exposes secrets. | The sandbox holds no production secrets or customer data, and we run code only in isolation. |
| Report text carries instructions meant for the model. | Report text is data: the model has no tools beyond the build and no secrets. |
A separate automated reviewer checks the work before hand-over. Your named engineer confirms expected behaviour for five sampled reproductions and re-runs them. 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 reports, the commit, the sandbox and the three outcomes in writing
- Build the app and run its tests in the sandbox to record the baseline
- Attempt each report; write a failing test or log the attempt
- Your engineer confirms expected behaviour for five reproductions and re-runs them
- Separate automated reviewer checks every test and log for wrong expectations
- Hand over the table, branch and questions
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?
To fix the real ones, the one-bug job or the engineering backlog project 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 developer to timebox reproduction to 20 minutes per report, and close what cannot be reproduced after asking one question.
- Use your tracker's templates to require steps, expected and actual results on every new report.
Questions
Do you fix the bugs?
No. Each fix is a separate job. This job shows which reports are real.
Does "not reproduced" mean it is not a bug?
No. It means we could not reproduce it with the steps and environment shown. The log says what we tried.
Do you need production access?
No. We use synthetic data in an isolated sandbox.
Send an enquiry
Send us
- Your language, framework and how long the test suite takes
- How many reports and where they live
- No code, report text, data or logins in the first enquiry
Later, once you agree
- The reports as text, with personal data removed
- Read-only code at one commit and build steps
- The name of the engineer who confirms expected behaviour
You keep your code, tracker and data. The code runs only in an isolated sandbox with no production secrets and no network beyond what the build needs. 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 “bug-reports-reproduced-or-explained-in-batch” as the subject.