Sometimes the cleverest answer is not a clever shortcut. It is to try many possible answers until one works. Under the right conditions, a large number of capable problem-solvers can outperform a single brilliant one.

1. Many small searchers, one smart result

Nature offers a useful example in the way honeybees choose a new home. A swarm does not appoint a master bee to study the landscape. Several hundred scouts inspect possible sites and advertise good ones through waggle dances. Better sites receive stronger support, attracting more scouts until the swarm reaches a quorum.

No bee sees the entire problem. Each makes a limited observation and follows simple rules, yet the colony usually selects the best available site. Researchers call this a distributed, nonhierarchical process: the colony solves a “best-of-N” problem that no scout solves alone. (Royal Society research; Annual Review of Entomology)

This is not pure brute force, but it reveals the larger principle: many inexpensive searches generate options while a shared process selects among them.

In computer science, brute force, or exhaustive search, means systematically checking every candidate in a defined space. Its usual alternative is informed or heuristic search, which uses knowledge or rules of thumb to examine promising candidates first. A heuristic saves work but can overlook an answer when its assumptions are wrong. (University of British Columbia AI textbook)

Many effective systems combine the two: explore broadly, then use feedback to narrow the search. Honeybees do this, as do optimization programs and AI-agent systems.

2. The problem must have the right shape

Brute force is not a universal answer to unsolved problems. Candidates must be enumerable or at least sampleable, each attempt must finish, and the result must be testable.

Cryptographic key search has nearly the ideal shape. The Data Encryption Standard, or DES, used a 56-bit key, creating 256, or roughly 72 quadrillion, possibilities. A program can divide that range among workers and test every key independently. When the correct key produces recognizable plaintext, success is clear.

A finite space helps because completing it can prove that nothing was missed. But finite does not mean feasible. Consider ML-KEM-1024, the largest parameter set in NIST’s primary post-quantum key-establishment standard. Its public encapsulation key is 1,568 bytes, or 12,544 bits, and its private decapsulation key is 3,168 bytes, or 25,344 bits. NIST places it in its highest security category, using the difficulty of breaking AES-256 as the comparison point. (NIST FIPS 203)

Those encoded key sizes should not be mistaken for simple 212,544 or 225,344 brute-force spaces. ML-KEM’s security depends on a structured mathematical problem, so the size of the stored key is not the same as its effective security strength. That distinction reinforces the point: even when candidates can be described mathematically, we still have to understand the structure and practical size of the search.

Other problems have an infinite space, a changing target, or results that are difficult to judge. A scientific question may require a new way of describing the problem rather than one answer hidden in a known list. Before asking whether brute force will be fast, we should first ask whether the problem lets us generate candidates, divide the work, and judge the results. Not all problems have that shape. For the ones that do, three conditions tell us whether broad search is likely to work well.

3. Three conditions favor brute force

The following conditions do not guarantee that brute force will win. They are a practical diagnostic. When all three are present—and the effective space fits the budget—broad search becomes attractive.

First, attempts must be cheap. What matters is the cost of making enough attempts to have a reasonable chance of success. A one-cent experiment is still unaffordable if the search requires a quadrillion of them.

Second, attempts must be independent enough to run in parallel. The space should divide so that adding workers increases coverage rather than conversation. Cryptographic keys have this property, but so do many noncryptographic searches. A route-planning program can give each worker a different first stop and have it explore every route beginning there. The workers do not need to coordinate until they report their best results. A problem in which every step depends on the previous result does not divide so cleanly.

Third, success must be easier to recognize than to produce. A key decrypts the message, but the pattern extends beyond cryptography. A completed Sudoku is much easier to check than to solve: scan the rows, columns, and boxes for the required digits. A candidate program can be checked against a well-designed test suite, and a proposed route can be measured against the best one found. Without a dependable judge, more attempts produce more uncertainty.

These conditions allow quantity to be converted into probability. More attempts buy more chances—but only when they explore different possibilities and the system can identify a winner.

4. Computing changed the price of persistence

DES shows how the same problem can move from impractical to vulnerable without changing its mathematical shape.

When the U.S. government adopted DES in 1977, its 56-bit key was considered sufficient for its intended use. The keyspace was known, but searching it was economically out of reach. By 1997, a distributed network of computers cracked a DES challenge through key exhaustion in about five months. In 1998, the Electronic Frontier Foundation built a specialized machine for less than $250,000 and solved another challenge in under three days. Six months later, that machine joined nearly 100,000 computers coordinated by distributed.net. Together they checked 245 billion keys per second and found the answer in 22 hours and 15 minutes. (EFF’s DES project history; distributed.net’s 1999 report)

The cipher had not developed a new flaw. The space was the same. What changed was the cost of traversing it: custom hardware made each test faster, distributed computing supplied more workers, and the work required little communication. NIST withdrew DES in 2005 and now describes exhaustive DES search as trivial with modern computing capacity. (NIST’s history of DES)

This is the economic lesson of brute force. A strategy dismissed as wasteful can become practical when the price of an attempt falls or idle computing can be organized into parallel labor.

Cryptography is only the cleanest illustration. In drug discovery, automated high-throughput systems can test hundreds of thousands of compounds in a day, using parallel assays to identify a small number of promising candidates. (NIH Molecular Libraries Program) In astronomy, Einstein@Home divided the search for weak gravitational-wave signals across approximately 100,000 volunteered computers. (Einstein@Home search report) Neither is identical to key exhaustion, but both share its economic shape: a large candidate space, many relatively independent tests, and enough inexpensive computing to make broad exploration practical.

5. More workers can also produce more waste

Every search system has limits, and the failures are easy to recognize in practice.

Coordination becomes a bottleneck when workers spend more time asking for assignments or waiting for shared resources than testing candidates. A hundred workers cannot produce a hundredfold speedup if one coordinator can feed only ten.

Duplication creates the illusion of coverage. A hundred identical agents given the same instructions may return variations of the same ten ideas. The bill records a hundred attempts, but the search barely expands.

Poor verification rewards the wrong answer. Thousands of programs tested against a weak test suite may pass while failing in real use. The system becomes efficient at selecting false confidence.

Enormous spaces defeat cheap computation. A route through 10 locations has about 3.6 million possible orderings. A route through 20 has more than 2.4 quintillion. Even at one million routes per second, checking all 20-location orderings would take roughly 77,000 years. Small increases in the problem can erase huge improvements in hardware.

Brute force also fits poorly when attempts are dangerous or irreversible, the target adapts, or an explanation matters more than finding one answer that works.

These are also early design requirements for an agentic harness. It needs a scheduler that can keep workers busy, shared memory that prevents duplication, an evaluator that rejects convincing but incorrect results, and a budget that stops the search before the search becomes the problem.

6. Brute force is a strategy for spending uncertainty

Brute force works well when the possible answers can be represented, a useful portion of them can be explored within budget, the work divides cleanly, and a reliable test can identify success. It works badly when the space grows faster than our resources, workers repeat one another, coordination dominates execution, or correctness remains a matter of judgment.

Brute force is therefore not the absence of strategy. The strategic work moves up one level. The intelligence may reside less in each attempt than in the system organizing them.

The attempts happen below; intelligence accumulates above.

The workers make attempts, but the strategy layer decides what counts as useful work and when searching is sufficient.

My interest in this subject grew out of deep work with agentic AI. Once agents can run repeatedly and in parallel, the question is no longer only, “Which model is smartest?” It becomes, “Which architecture turns limited intelligence and money into the greatest useful coverage?”

That leads to two subjects I will explore next: designing an AI-agent colony whose shared memory outlives any worker, and applying organized search to authorized cybersecurity research. The future may not belong only to the smartest machine. It may belong to the system that makes many imperfect machines search well together.