DEV Community

Michael Lip
Michael Lip

Posted on

# The bug my QA workflow kept confirming instead of catching

The bug my QA workflow kept confirming instead of catching

I found a bug in my own pipeline, and the part that stuck with me wasn't the bug. It was the tool built to catch it.

I run company pages through three layers. First a harvest step pulls every number straight from yfinance. Then a 24-agent research workflow builds out the facts and citations, checked against a guard that flags anything that conflicts with ground truth. Then an 8-agent adversarial QA workflow tries to break what the first two layers produced.

On July 16, 2026, I pushed Playtika, ticker PLTK, live as the 24th company page in the set, commit b742312. It's a deep-value special situation, priced at 4.3x, the kind of name I like precisely because the market has mostly stopped paying attention to it.

The market wasn't the problem that day. My own extractor was.

It turned out my extractor had been cutting its own input short. Not crashing, not erroring, just stopping at a fixed length and moving on like nothing happened. No flag, no warning, nothing in the output to say a chunk of the page never made it through.

Here's the part that should have caught it and didn't. When the pipeline noticed the page looked short, it ran a repair path that re-read the source and tried to expand the content back out. But the repair path called the same extractor, with the same cap built in. So every repair attempt hit the identical ceiling and wrote the identical log line. Same shape, same field, same value, every single time.

Then the 8-agent QA workflow, the layer I built specifically to catch exactly this kind of thing, read that log line and reported success. Every time. In a single pass, it declared victory on the exact signature that proved the page was still broken.

That's the failure that costs the most. Not a bad extraction on its own. A detector that mistakes the shape of the failure for the shape of the fix, and says so with confidence, more than once, in the same run.

I've since pulled the cap out of the repair path so it can't rubber-stamp its own ceiling, and I'm rewriting the QA check to measure the actual page against the actual source instead of trusting a log line to mean what it says. The Playtika page is clean now. But I'm still sitting with how long a truncated page can look finished when the instrument watching for truncation is reading its own echo back as a result.

If you run any kind of extract-then-verify pipeline, the lesson isn't add more verification. I already had verification. The lesson is to make sure your verifier checks the world, not the log line your own repair code writes about itself. A detector that trusts the system it's checking isn't a detector. It's an echo.

Top comments (0)