AlphaCode,
explained.

Competitive programming problems aren't like the tidy functions of HumanEval. They're puzzles: a clever problem statement that hides an algorithmic insight, a strict time and memory limit, and hidden tests that punish any edge case you miss. Solving them requires genuine reasoning — pick the right algorithm, get the complexity under budget, implement it without bugs. For a long time this looked like a stronghold of human ingenuity.

AlphaCode's insight was that you don't need a model that gets it right on the first try — you need one that gets it right somewhere among many tries, plus a reliable way to find that right answer in the pile. So it split the job into two halves: a model that generates a huge, diverse set of candidate programs, and a selection pipeline that separates the wheat from the chaff. Brilliance in aggregate, not per sample.

The first half is a large transformer trained on public code and fine-tuned on competitive-programming problems, used to sample candidate solutions — but at a scale most systems never attempt. For a single hard problem, AlphaCode generates up to millions of candidate programs, using high sampling temperature and metadata conditioning to keep them diverse.

Why so many? Because for a genuinely hard problem, the per-sample probability of being correct is tiny. But "tiny per sample" across a million samples still yields a healthy number of correct ones — if some correct solution is within the model's reach at all. Massive sampling is a way of buying coverage of the solution space. The whole strategy rests on it: you can afford to be wrong nearly every time, as long as you're right often enough in absolute terms and can identify the winners.

A million candidates is far too many to submit — and contests punish wrong submissions and cap how many you can make. So the pile must be cut down, hard. The first cut is filtering: every problem comes with a few public example tests, so AlphaCode runs each candidate on those and throws away any that fail. This is cheap (just execution) and brutally effective — it eliminates the large majority, often ~99%, of the samples, because a program that can't even pass the given examples is certainly wrong.

Filtering is the workhorse that turns an unmanageable flood into a manageable shortlist. It costs almost nothing — no model, just running code against a handful of tests — yet removes nearly everything wrong. What's left has cleared the lowest bar (it works on the examples), but there are still far too many to submit, and many are duplicates. That's where clustering comes in. The runnable version below filters candidates and shows only the passers survive.

The thousands of surviving programs aren't thousands of distinct solutions — many are syntactic variations of the same underlying algorithm. AlphaCode clusters them by behavior: it generates additional test inputs (with a separate model), runs every survivor on them, and groups programs that produce identical outputs. Programs in the same cluster are effectively the same solution; different clusters are genuinely different attempts.

Then it submits one program per cluster, prioritizing the largest clusters, until it hits the submission budget. The logic is a form of consensus: if many independently-sampled programs converge on the same behavior, that behavior is more likely to be correct than a lone outlier. Clustering both deduplicates (don't waste submissions on the same solution) and ranks (agreement is a signal). It's the same "sample many, take the majority" idea that powers self-consistency in reasoning — here applied to whole programs judged by what they compute.

Evaluated on real Codeforces contests, AlphaCode placed at roughly the 54th percentile — median among human participants:

The result recalibrated expectations: an algorithmic-reasoning task thought to need human creativity fell to a mix of scale and clever selection. And it demonstrated a general recipe — sample broadly, verify cheaply, select by consensus — that applies wherever generating many candidates is easy and checking them is cheap.

AlphaCode is a landmark case of test-time scaling for code: rather than a smarter single generation, throw compute at many generations and select well. That pattern — sample-and-select — recurs across the field, from self-consistency in reasoning to best-of-N with a verifier, and it foreshadowed the reasoning models that spend heavy compute exploring many solution paths before answering. AlphaCode made the case, on a hard task, that quantity plus good selection can substitute for one-shot brilliance.

Its deeper idea is the generate-and-verify asymmetry taken to an extreme. Generating a correct competitive-programming solution is very hard; checking whether a program passes tests is trivial. AlphaCode leaned all the way into that gap: generate absurdly many, let cheap execution filter, and let behavioral agreement rank. When you can verify far more cheaply than you can produce, flooding the problem with attempts and sieving them is a startlingly effective strategy — one AlphaCode proved could reach human-competitive performance on a task that seemed to demand genius.