From work item to release, and back
AI writes the change fast. Robotesta makes sure it’s right.
Checks every change. Remembers every outcome. Gets better every sprint.
Robotesta checks every change against what it was meant to do, from work item to code to release, and shows the result where each person already works. So your whole team keeps up.
0:52
Watch the 60-second videoSam explains Robotesta, with sound
Early access: we read every request and reply within two working days. See how it works
What this change must do
Worked out from the work item, two earlier decisions and the approved design.
- A sole owner cannot be removed. Proven
- The member's audit history remains. Proven
- Owned resources are reassigned first. Proven · new evidence
- Access ends the moment a member is removed. Not met
The change removes the member but never ends their session, so a removed member stays signed in.
Teams we've worked with
- ZidE-commerce
- ZidPayPayments
- MNT-HalanFintech
- HALAFintech
- KlivvrFintech
- AzzrakSoftware
Why now
Code got faster. Checking didn't.
More change now moves through the same review, testing and QA capacity. This is what that does to a team, in four steps.
-
01 · Change
AI multiplied the change.
More features, fixes and experiments land every day.
Pull requests merged≈ 2×+98% · Faros 2025
Developers on teams with high AI adoption merged 98% more pull requests. Faros, The AI Productivity Paradox, 2025: 10,000+ developers, 1,255 teams.“We shipped three changes before lunch.”
-
02 · Bottleneck
The queue moved downstream.
The code is ready. Review, testing and QA are still catching up.
Time reviewing pull requests≈ 1.9×+91% · Faros 2025
Pull request review time rose 91%. Faros, The AI Productivity Paradox, 2025.Time in QA≈ 4×+300.6% · Faros 2026
Time in QA is up 300.6%. Faros, The Speed Trap, 2026: 22,000 developers, 4,000 teams.“What else did this change touch?”
-
03 · Trade-off
Teams start making compromises.
Every change forces the same choice.
WaitReview it. Test it. Verify it. Lose some of the speed.
Push throughMerge now. Check later. Move the risk downstream.
“Do we have coverage for that path?”
-
04 · Rework
The work doesn't disappear.
What gets missed comes back as debugging, regressions, incidents and fixes.
Incidents a month≈ 2.25×+125.4% · Faros 2026
Monthly incidents are up 125.4%. Faros, The Speed Trap, 2026.“CI was green. Customer found it first.”
Fast coding only works if checking can keep up.
Speed moved forward. Quality work moved downstream, without the context the code was written from.
Sources: Faros, The AI Productivity Paradox, 2025 (10,000+ developers, 1,255 teams) and Faros, The Speed Trap, 2026 (22,000 developers, 4,000 teams).
The missing context
Software changes faster than a team can reconstruct what each change depends on.
Part of the bottleneck is volume. The part that lets problems through is context: the author didn't have it, the review didn't have it, and the tests were written from the same ticket.
- User flowWorkspace › Members › Remove
- DecisionInvitations expire after 7 days
- RequirementA workspace always keeps at least one owner.
- CoverageOwner protection
- IssueDuplicate audit rows on re-invite
- Decision #61Access removal must be immediate.
- RequirementInvite members by email
- Codebasebilling-service
- Issue #184A removed member kept authenticated access.
- DesignMember list
- The changeRO-218 · Remove workspace member
- CoverageAudit history
- Approved designReassign owned resources before removal.
- DecisionAdmins cannot demote themselves
- Productionmembership-service · 30 days
- Codebasemembership-service · session-service · realtime authorization
- User flowSettings › Ownership
- Codebasenotification-service
- Coverage · not coveredActive sessions are revoked on removal.
- RequirementOwners can transfer ownership
- DesignConfirmation dialog
Not what the change touches. What it was meant to do.
Robotesta reconstructs the product around each change and works out what it was meant to do: the list of what must be true, before anyone builds it.
How it works
Five moments in the life of a change. Robotesta says the sentence; a person does the act.
One change, followed from the work item to the release, and after it. Robotesta reads your work items, decisions, designs, code, tests and production errors, and works out what the change was meant to do.
-
01 · Shape the work
Before anyone builds it
What is unclear in the work item, asked as questions on it.
Jira · RO-218Can the only owner be removed? A workspace always keeps at least one owner.
A person: answers or dismisses each question; adds a criterion.
-
02 · Build
On the pull request
Does the change do what the work item says, and what does it miss. Robotesta checks every change when the pull request is ready; re-review on a click.
GitHub · PR #491Decision #61 says access ends at once. Revoke sessions inside the removal transaction.
A person: approves or dismisses each finding, then posts the review. Nothing is posted until you press the button.
-
03 · Release
Per release
Which changes are proven and which are not, with the evidence in one view.
Release · Members and ownershipEvery rule of RO-218 proven. No open findings.
A person: ships or holds, and signs off; the signed release record goes to the Jira issue they name.
-
04 · ObserveFirst version
After release
Errors from Sentry in the days after release, tied to the change behind them. Reopened work items and reverts come next.
Production · SentryNew errors in exports-worker after release 2.14, linked to RO-205.
A person: confirms or rejects a suggested link.
-
05 · LearnComing
Each sprint
What held, what escaped, what Robotesta got right, and what to check differently. Patterns attach to work and code, never to names.
What this taught us · suggestedRemoving access escaped twice in membership changes. Check session revocation on every removal.
A person: keeps or retires what each sprint taught; accepts a suggested line for the team’s agent.
What happened after
Each released work item gets one word, with the evidence.
After its window, every work item that shipped reads Held, Reworked, Reopened, Escaped or Reverted: a fact about the change, never about a person. Outcomes from Jira and GitHub first.
On day one you see what came back after release in your last releases.
-
RO-218 · Remove workspace member
Nothing came back in the window.
Held
-
RO-207 · Invite by email
Reopened in Jira after release.
Reopened
-
RO-199 · Transfer ownership
Customer reported.
Escaped
Five rules it works by
-
What it was meant to do
Worked out from the work item, the decisions and the design, before anyone builds it.
-
Reuse first
Your existing tests count as evidence. Robotesta drafts a test only where proof is missing.
-
Honest
Proof, or clearly marked as not proven. Never a guess presented as a result.
-
Evidence on the work item
Results go to Jira and the pull request when a person clicks, where your team already looks.
-
A person decides
Robotesta prepares the release decision. A person makes it.
RO-218, PR #491 and every example in this section are illustrative. No customer data is shown.
Six people ship every change. You've heard all of them.
Robotesta gives each of them what they were missing, where they already work.
Product owner
Sees on the work item whether the change does what they asked, before it ships. Two weeks after, whether it held.Coming
Developer
Gets the review on the pull request: what the change misses and what it might break. What this area escaped before, and what their agent tends to miss.Coming
QA
Stops chasing what changed: every change arrives already checked against its work item, with the evidence. A bug that comes back is seen again, not re-reported.
Engineering lead
Sees per release which changes are proven and which are not. Per sprint, what held and what escaped, and what to check differently.Coming
Executive
One number a month: escaped bugs per hundred released changes, and how often Robotesta was right.Coming
Support
On a ticket: which change shipped in that area, whether it was checked, and whether the bug is already known.Coming
Your AI agents
Robotesta notes which changes were written with an agent: Claude Code today; Cursor and Copilot when their commits carry markers.
What your agent misses, and one suggested line for its instructions file that a person keeps or retires.Coming
Where it works
Inside the tools your team already uses.
It reads from them, and writes the evidence into them only when a person clicks, or when a switch a person turned on says so.
Where you see the result
- Jira, on a person’s click
- GitHub, on a person’s click
- Slack, after a person clicks
- The Robotesta web app
What it reads
- Jira · GitHub
- Linear · Asana · Notion
- Sentry · Slack channels it is invited into
- AIO Tests · Playwright, JUnit, Allure and Cypress results from GitHub Actions
Coming
- ConfluenceComing
- OpenAPIComing
- OTLPComing
- Files and CSVComing
- Support ticketsComing
Third-party names are shown to indicate compatibility only.
Planned packages · free in early access · prices when billing opens
Free while in early access. Every member is a seat, because every role gets something.
The product owner on the work item, the developer on the pull request, QA with the evidence, the lead on the release. Less than a reviewer seat for most of your developers, and it covers the people no reviewer serves.
Free
For public repositories.
- Free for public repositories: Robotesta reads a public repository but never posts there (no review, comment or required check); results stay in Robotesta, and on a Jira ticket when a person clicks.
Team
For a product team shipping every week. Every member is a seat.
- Every change checked against its work item before it ships
- Evidence on the work item and the pull request, posted on a click
- The release view and the signed release record
- The bugs page, with bugs from Jira and GitHub
- Each work item’s outcome after release, from Jira and GitHub first
Loop
For teams that want every sprint to teach the next one.
- Everything in Team, plus:
- What this taught us: lessons a lead keeps or retiresComing
- What your agent missesComing
- Team numbers, for owners and adminsComing
- How often Robotesta was right, with its countsComing
- Teams like yours: appears once five organizations contributeComing
Enterprise
For many teams with their own security and rollout needs.
- Everything in Loop, plus:
- Single sign-onComing
- Audit export in your auditor’s formatComing
- Data residencyComing
- Rollout planned with your engineering and QA leads
Team and Loop start with a 14-day trial, no card. Each seat brings credits into one pool for the organization, and extra credits come in packs. When the credits run out, automatic checks pause and a person’s click still runs; nothing is charged until an admin clicks Buy.
Robotesta is in early access and charges nothing yet: ask for a place and we reply within two working days.
Straight answers
What teams ask us first.
- Does it replace our QA team?
- No. It does the repetitive checking, so your testers can focus on judgement and the risky areas.
- Does it catch everything?
- No tool does. It shows what a change touches and what was proven, so the release decision is better informed.
- When does it check a change?
- When the pull request is ready; re-review on a click. On a new push nothing is re-checked or written to GitHub until a person clicks.
- How does it connect to our code?
- You connect Jira and GitHub in a few clicks once you have access. Robotesta reads from your tools and writes into them only when a person clicks, or when a switch a person turned on says so.
- Who decides what ships?
- A person. Robotesta brings the evidence; your team says ship or hold.
- How much is it?
- Free while in early access; the planned packages are in Pricing above.
- How do you handle our code and data?
- Robotesta reads from your tools and writes into them only when a person clicks, or when a switch a person turned on says so. It is hosted by DigitalOcean, in the EU (Frankfurt) today; US coming. We answer your security team’s questions before you connect anything.
Bring one work item that came back after release.
Thirty minutes, your Jira, your repository. We work out together what that work item was meant to do, what the change missed, and what Robotesta would have checked before it shipped. We reply to every request within two working days.
Product, engineering, QA and technical leaders welcome. Or write to sam@robotesta.ai