An AI can write a plausible bug fix in seconds. That's exactly the problem.
Plausible is cheap now. A model will happily hand you a diff, a confident explanation, and a test that passes — for a bug that was never a bug. Maintainers of popular open-source projects have started to feel this as a new kind of spam: a stream of AI-generated pull requests that look right, read well, and quietly waste an afternoon of review before someone realizes the "fix" changes documented behavior, duplicates an existing PR, or corrects something that was working fine.
So when we built Coretexa — a pipeline that finds real bugs in open-source libraries and submits fixes — we decided the interesting engineering wasn't the finding. It was the filtering. Here's the discipline we settled on, and what a single day of it actually looks like.
Doer ≠ verifier
Every finding goes through two independent agents. The first — the doer — reproduces the bug on the current HEAD of the real repository, writes a minimal fix, adds a regression test, and runs the full suite. Then a second agent, which did not write any of that, is handed the finding with one instruction: refute it. Try to prove it isn't a bug. Find the input where the fix is wrong. Show the behavior is intended. Default to "not a bug" unless the evidence is undeniable.
Only findings that survive a genuine attempt at refutation get anywhere near a maintainer. The rule is enforced structurally, not by good intentions: nothing can be marked ready-to-post until an independent verification has passed. This sounds like overhead. It is. It's also the entire product.
A day of results — including the rejections
The honest way to show a verification pipeline works is to show what it throws away. Here's a real slice.
Shipped
We found a boundary bug in croniter: an expression like 59/15 (every 15 minutes starting at minute 59) was expanding to the whole field — firing at :00, :15, :30, :45 — instead of just :59. An internal inconsistency: 58/15 worked, only the field-maximum case broke. The doer traced it to a normalization edge case, wrote the fix plus a regression test; the verifier confirmed it holds across every cron field, seconds, alpha month/day names, and the from-timestamp path, with zero regressions on 221 tests. That went out as a pull request. A separate round-trip data-loss bug in tomlkit went the same way.
Rejected — and this is the point
In the same stretch:
- A
croniterfinding about day-of-week scheduling didn't reproduce under independent check. The claimed misbehavior simply wasn't there. Dropped. - Two
aiocachefindings turned out to be intended behavior — one relied on a serializer being applied where the library deliberately uses an atomic native operation; the other treated a documented key prefix as if it were an isolation boundary. Real reproductions, not real bugs. Dropped. - A
tomlkitfinding was verified as a genuine round-trip bug — and then, in the pre-submission duplicate sweep, we found the maintainer had already opened an issue for exactly that class of bug, with a fix attempt in flight. Posting it would have been noise. Dropped before it reached them.
That last one is worth sitting with. The finding was correct. We dropped it anyway, because correct-but-already-known still wastes a maintainer's attention. Trust is built as much by the PRs you don't send as by the ones you do.
The lane is crowded, and that's clarifying
Two things became obvious this week. First, the easy wins are mostly gone: we ran property and differential fuzzing across a dozen mature, well-tested libraries — cron parsers, URL normalizers, JSON patch, SQL round-trippers, YAML — and they came back clean. These libraries have been fuzzed to death already.
Second, we're not the only automated pipeline out there. On one of the very bugs we'd verified, we found a pull request from another AI agent — its own metadata disclosed it — working the identical issue. The ecosystem now has multiple machines racing to fix the same clean, obvious bugs.
If everyone can generate a plausible fix, and everyone is racing the same shrinking set of easy bugs, then speed and volume are worthless. The only thing that compounds is trust: a track record of contributions that were real, were verified, weren't duplicates, and didn't waste anyone's time. That's a slower game, and it's the only one worth playing.
What Coretexa is
Coretexa is an integrity-first pipeline for AI-assisted open-source contribution. It originates findings, reproduces them on real HEAD, has a separate agent try to break each one, sweeps for duplicates and races before anything is posted, and keeps a full ledger of every finding — including the ones it killed. Every submission carries a disclosure and a "verified by Coretexa" mark that means a second agent tried to prove it wrong and couldn't.
We publish the rejections on purpose. In a world where plausible is free, the scarce thing is a "yes" you can trust — and you only earn that by being willing to say "no" to your own work.
Coretexa contributions are prepared with AI assistance and independently verified — by a different agent than the one that found the issue — before submission.