Recap of trivago's Düsseldorf QA Meetup featuring three talks: Qase.io's Andrei Khabarov shared DORA metrics and adoption data showing AI-authored code reaching 61-92% across teams, alongside their open-source git-ai attribution tool; Curio IT's Alexei Vinogradov presented randomized input testing to counter the 'pesticide effect' where fixed test suites stop catching new defects, recommending a seed-based test data broker for reproducibility; and trivago's Renjith Rajasekharan described an AI agent that tests ~200 advertiser API connectors using structured JSON logging, mechanical and LLM-based validation, and a self-auditing quality score. All three speakers emphasized verifying the testing process itself while keeping human review central.
Table of contents
Talk 1: AI-Driven Dev & QA, the metrics that prove itTalk 2: Randomize Your Automated TestsTalk 3: Agent Assisted API TestingSummaryQuestions this post answers
What is the pesticide effect in software testing?
The pesticide effect describes how a fixed set of automated tests using hardcoded input values gradually stops catching new defects once the underlying code has been adapted to pass those specific tests. It was described by Curio IT's Alexei Vinogradov as a reason to randomize input values for list-type parameters, branching conditions, and actor attributes like country or user role, rather than relying solely on static test cases. Teams debating test strategy can track emerging QA techniques like this on daily.dev.
How can I make randomized automated tests reproducible?
Reproducibility is achieved by logging all input values, seeds, and responses generated during a test run, so any failure can be reproduced exactly using its seed. A recommended implementation pattern is a builder-style test data broker where a seed value determines the randomization, with a configurable switch to toggle between randomized and fixed-seed modes during development. Engineers building randomized test suites can follow practical patterns like this via daily.dev.
How is AI code adoption measured beyond counting AI-authored pull requests?
Counting AI-authored pull requests alone is misleading because splitting one change into multiple PRs inflates the count without reflecting real progress. Qase.io built git-ai, an open-source tool that records structured attribution data per commit using git notes without storing source code or prompts, feeding an internal dashboard that reported 61% to 92% AI-authored code across teams, alongside DORA metrics like 0.2-hour median cycle time. Teams evaluating AI coding impact can compare adoption metrics like these on daily.dev.