# OneDroid Argus for QA Teams — End-to-End Testing for AI-Written Code > When developers build with a coding agent, QA owns the checks the agent can't see. OneDroid Argus is automated end-to-end testing for AI-written code: plain scenarios written from the ticket before the build, unseen by the coding agent, run on the deployed system, under load and on a schedule. Canonical: https://onedroid.ai/qa-teams OneDroid Argus For QA teams # The AI writes the code. QA owns the checks it can't see. When your developers build with a coding agent, the agent often writes the feature and the tests that judge it, from the same reading of the ticket. OneDroid Argus is automated end-to-end testing for AI-written code: you write plain scenarios from the ticket before the build, the coding agent never sees them, and they run against the deployed system, under load and on a schedule too. Talk to us How OneDroid Argus works What changes for QA ## Green tests from the builder aren't a verdict. A coding agent that writes both the code and its tests can be wrong twice in the same way: if it misreads the ticket, the tests it writes agree with the mistake. A model that can see its checker learns to satisfy the checker. The answer is not fewer testers. It is a tester who is not the builder, working from the ticket, with checks the builder cannot read. ### You get the ticket before the build The tester writes each check from the ticket and the acceptance criteria, before the build starts. "What should happen" is decided before any code exists to argue with it. ### Plain scenarios, not test scripts Each check says what to trigger, where to look and what a healthy answer is. No test scripts to write and keep alive, and nobody clicking through the app before each release. The scenarios stay as regression checks for the next change. ### The agent can't edit what judges it The builder's credential can ask for a run and read the verdict, and cannot read a scenario or an expected value. During the build it learns only which checks failed and what was observed, never what was expected. ### On the running system, nothing mocked HTTP, the message broker, the database, web pages in a real browser, permissions and rate limits. OneDroid Argus never reads the diff; it exercises the system and reports what happened. One feature, start to finish ## Where QA's work sits when an agent builds. ### 1. Write You (or an agent that is not the builder) write the scenario set from the ticket, the acceptance criteria and the shape of the system. An agent skill can turn a plain description of what should happen into valid scenarios. ### 2. Seal You seal the set. Its hash goes on a cryptographic ledger before the work is judged, so anyone can check that the scenarios existed first and never changed. ### 3. Build The developers' coding agent builds and asks for runs. The runner reports failing check ids and observed reality, so the agent can fix things, and never the expectation. ### 4. Judge The final run happens once, against a pinned build. Every scenario ends as passed, failed or errored, and an error is never a pass, so a run cannot go green because nothing ran. ### 5. Keep The same checks run under load and on a monitor schedule, every 15 minutes at the shortest. A system no monitor has measured reads "not measured", never green. ### 6. Show The verdict binds to one build and comes with a certificate anyone can check offline. When you reveal the set, any scenario can be replayed against the same build, by you, your auditor or anyone. What stays yours ## Deciding what "correct" means is the job that doesn't get automated. OneDroid Argus runs the checks, keeps them out of the builder's reach and keeps the record. The judgement around them stays with QA. ### Which checks matter Which scenarios a feature needs, and what a healthy answer is for each, come from the person who read the ticket for what it meant. ### Which reds you keep A set goes on a schedule once a hand-run is green, or every red in it is one you have read and decided to keep. What the system can't fix by itself is listed under "Needs a person", with who acts next. ### What may differ When one sealed set runs against two systems or two releases, what may differ is declared before the run, with a tolerance for numbers, and a difference a person accepts is pinned to the outputs they were shown. Faster and cheaper than end-to-end testing by hand: the scenarios are written once per feature, before the build, and run as often as you need. One measured experiment, its figures and its limits. Stated plainly ## What we don't claim. ### Not "no QA needed" Somebody who is not the builder still has to decide what the software should do. OneDroid Argus makes that decision the one the coding agent cannot see or change. It doesn't make it for you. ### Not proof of no bugs No test proves code free of bugs. Different testers catch different things, and a model can give a different answer on each run. What stays fixed is the record: sealed before the build, run against the build you pinned, replayable. ### Not load on a web page Stepped load ramps exist for message brokers and for one HTTP target at a time, and none drives a web page in a browser. Browser checks run as functional end-to-end scenarios. The full list, including what the ledger proves and what it does not, is on the OneDroid Argus page. The steps to set it up are in the OneDroid Argus docs. ## Bring one feature. Pick a ticket your developers are about to hand to a coding agent. Write the scenarios from it before the build, and see what the agent's own green tests missed. The runner is open source under MIT; the control plane is available by request. michal@onedroid.ai