A new testing pipeline called STAB writes code-breaking test cases straight from a problem's plain-English description, with no finished implementation required.
STAB splits the job into two parts. A "constraint saturator" reads the problem spec, pulls out its stated limits, and uses rule-based logic plus CP-SAT optimization to push input sizes to the edge of what the problem allows. An "adversarial scenario injector" then pulls known troublemaking input patterns from a curated catalog, matched to the problem through keyword search and k-nearest neighbors. STAB folds the spec, the resolved size boundaries, and the retrieved attack patterns into a structured brief, which an LLM turns into a working Python test generator. On the CodeContests benchmark, this lifted the rate of test cases that actually exposed algorithmic worst-case slowdowns from 50.43% to 73.45% for open-source LLMs and from 57.45% to 71.85% for closed-source ones, with similar gains across Python, Java, and C++.
That's a real gap in how efficiency gets tested. Earlier approaches either threw bigger inputs at code and hoped something broke, or reverse-engineered slow cases from a specific implementation already sitting in front of them. STAB instead reasons about the structural conditions that trigger worst-case behavior before any code exists to test, which matters as more algorithms get LLM-generated and nobody checks whether "correct" also means "fast enough."
A 73% hit rate is progress, not a guarantee - meaning roughly one in four genuine bottlenecks still slips through unnoticed.