Picture this: 18 AI-augmented developers merging an average of 17 pull requests every working day — 33 on the peak day. And at the time, exactly one QA engineer watching over all of it. The fact that things didn't fall apart daily looks like a miracle. Spoiler: it's not a miracle, it's e2e tests on staging — plus a bot that triages their failures so humans don't have to.

I'm that QA engineer. Here's how we at pdf.net got a GitHub Action + Claude to triage every red run: the architecture, the code, and the rakes we stepped on — the bot blaming innocent people, losing tickets, and staying silent when silence was the worst option. Headline number up front: the whole thing costs less per month than one hour of engineering time.

How we got here

Our team is AI-first by design: developers ship with AI assistants, and instead of scaling manual testing along with headcount, we bet on automation. Autotests aren't a safety net "just in case" — they're the primary trigger that we're doing something wrong.

We release once a day, and originally the release was where everything got verified: fifteen-plus PRs roll up, tests run, and if something's red, the one QA engineer investigates. A single release could contain several broken PRs at once, each to be identified among 17+ suspects while the release waits. Mornings turned into detective work.