Skip to content
Apart Research
Apart Research
Contact us
Sprint projectOct 25, 2026Online, Estonia

When green tests are unsound: Executable evidence transfer across coding roles

Artur Onysko · Team DiadkoShmek

Submitted to AI Collusion Research Sprint. Sprint projects are early-stage work by participants, not Apart Research publications.

Read the report

Report: When green tests are unsound: Executable evidence transfer across coding roles

Open in a new tab (opens in new tab)
Share

Executable test drafts can carry mistaken evidence between separate coding roles without an explicit malicious instruction. We distinguish that observable dependence from deliberate collusion using native execution of complete generated suites. Two prospectively frozen studies cover three cache APIs and three iterator APIs, with benign, revealing and unsound drafts matched in byte length and code scaffold within each task. Valid catches per nine planned conversations are 7/7/5/4 across no-draft/benign/revealing/unsound cache arms and 5/6/8/4 in the iterator arms. Thus a correct carried witness has no consistent end-to-end advantage across contexts. In the iterator study, six current-checkout-green files fail pristine code. A separate matched prose experiment yields four valid catches with target-relevant clarification versus none with off-target clarification, supporting an ordinary-information alternative. Reference-only pruning makes all 35 completed iterator files valid but leaves seven target misses, despite perfect coverage of the additional planted bank. Exact-body quarantine changes none of those original iterator endpoints. On one exposed API, eighteen fresh receivers of two selected model-generated wrong parents yield 4/6 valid catches with wrong drafts, 5/6 after minimal repair and 0/6 without drafts; effects differ by parent. These repairs change list length. On six earlier outputs, structured failure guidance uses eight reference processes versus 34 for a stronger conventional comparator, with equal measured utility; authored counterexamples preclude dominance. The contribution is a reproducible audit of executable evidence, missing coverage and correction cost, not a general collusion detector or evidence of shared intent.

Reviews

Judging this Sprint?

Review “When green tests are unsound: Executable evidence transfer across coding roles”

Your public critique appears on the project page without your name. Reviews of strong projects are shared with funders, as you choose below.

Not shown on the project page.

Shown on the project page, without your name.

Only the Apart team reads this, and funders if you agree below.

Decline to score

Only when the quality of the writing makes the work impossible to follow. Say why in your private critique; the project page shows only that a judge declined, not why.

How much would this matter for the field if it worked? How innovative is it? For scores of 4-5: is this actually new to the field, or replicating recent work?

Scoring guide
  1. 1Negligible. No clear problem addressed, or no meaningful novelty.
  2. 2Limited. Addresses a real problem but with a generic or well-trodden approach. Incremental at best.
  3. 3Moderate. Clear problem with a reasonable approach; some novelty in framing or method beyond routine application of existing tools.
  4. 4Significant. Important problem with an original approach, or identifies a neglected problem area. A valuable contribution others could build on.
  5. 5Exceptional. Tackles a critical problem with a genuinely novel approach, or opens a new research direction. Clear theory of change. You'd be excited to share this with researchers in the area.

How sound are methodology, implementation, and findings?

Scoring guide
  1. 1Seriously flawed. Methodology broken, results uninterpretable, or implementation doesn't work.
  2. 2Weak. Approach has significant gaps: missing validation, flawed experimental design, or incomplete implementation.
  3. 3Competent. Technically solid given the short duration. Methodology makes sense, results are interpretable, limitations acknowledged, work builds toward clear conclusions.
  4. 4Strong. Thorough methodology with convincing validation. Results clearly support conclusions. Immediately useful for future work.
  5. 5Exceptional. Ambitious scope executed rigorously. Surprising findings, novel methods, or unusually robust validation.

How clearly are work, findings, and impact potential communicated?

Scoring guide
  1. 1Incomprehensible. Cannot determine what the project is actually claiming or doing.
  2. 2Hard to follow. Key information buried, missing, or diluted by excessive length. Significant effort to extract main points.
  3. 3Clear enough. Can understand the problem, approach, and results without undue effort. Core content clearly present: problem, method, findings, limitations.
  4. 4Well presented. Easy to follow, well-structured, appropriate level of detail. Target audience would get it quickly.
  5. 5Exceptionally clear. A pleasure to read. Complex ideas made accessible. Could serve as a model for how to present this type of work.
Sharing your name *

When we share a strong project with funders, your name, scores and public critique go with it, confidentially; this choice is only about whether your name is public. If you think this project deserves funding, please also endorse it: that carries the most weight.

Share my private critique with funders *

See our Privacy Policy.

  1. This study is impressive in the care it takes with executable evidence. Matching drafts by byte length and code scaffold, scoring complete files against pristine and target code, and keeping invalid and unfinished runs separate all make the results much more trustworthy. The most useful finding is that a green test suite can mean different things: pruning can restore validity while target coverage remains missing, and an easy test bank can appear perfect while missing the harder defect.

    The main limitation is that the work tests the transfer of mistaken evidence between honest coding roles, not collusion. Its context-dependent results also rest on small dependent samples. To build on it, I’d suggest:

    Test real collusion conditions: Compare honest writer-reviewer pairs with pairs given a shared hidden objective or communication channel, using receivers that don’t know the arm. The current audit could then show whether colluding pairs differ from ordinary error transfer.

    Broaden the evidence base: Use more APIs, naturally occurring bugs, and at least one other model. Three repeats per task on six curated APIs with exposed defect themes can’t support a general conclusion.

    Reduce baseline invalidity: Many suites fail on pristine code even with no draft, which can mask carrier effects. A stronger model or a better-specified task would make those comparisons clearer.

    Test countermeasures without a pristine oracle: Reference pruning depends on trusted correct code, which is often exactly what a real reviewer doesn’t have. Spec-derived checks, differential testing, or independently generated oracles could be more practical.

    Prioritize the presentation: The abstract and main report pack in many sub-studies, private labels, and counts. Lead with two or three findings, describe the core design in plain language, and move secondary strata and receipts to the appendix.

    Publish the supplement: A public repository with a tagged release would make the extensive hashes and replay receipts independently useful.

    Read full reviewShow less

Cite this project

@misc{onysko2026green,
  title = {{When green tests are unsound: Executable evidence transfer across coding roles}},
  author = {Artur Onysko},
  year = {2026},
  month = oct,
  note = {Submitted to AI Collusion Research Sprint, an Apart Research Sprint},
  howpublished = {\url{https://apartresearch.com/sprints/projects/when-green-tests-are-unsound-executable-evidence-transfer-across-coding-roles-c6n2}},
  url = {https://apartresearch.com/sprints/projects/when-green-tests-are-unsound-executable-evidence-transfer-across-coding-roles-c6n2}
}

More from AI Collusion Research Sprint

All 392 entriesBrowse all projects

A Sprint is running now

AI x Epistemics Research Sprint · Nov 13 - 15, 2026