A team wants higher-confidence flags of possible security vulnerabilities in a code diff, so instead of asking one LLM call to review the diff once, they run the exact same review prompt against the same diff three separate times independently, then treat a vulnerability as flagged only if at least two of the three runs report it. Which parallelization variation does this describe, and what is it meant to achieve?
- Sectioning -- breaking the code diff into independent pieces that are reviewed simultaneously by different prompts, meant to speed up the review by dividing the work
- Voting -- running the identical task multiple times to get diverse independent outputs, meant to reach a higher-confidence result by requiring agreement across multiple attempts rather than trusting any single run
- Orchestrator-workers -- a lead call breaking the diff into subtasks and assigning each to a different worker call, meant to let each worker specialize in one part of the code
- Evaluator-optimizer -- one call generating a list of vulnerabilities while a second call critiques and revises that list, meant to iteratively refine a single review rather than combine several independent ones
Why B? And why not the others?
Correct answer: B. Voting -- running the identical task multiple times to get diverse independent outputs, meant to reach a higher-confidence result by requiring agreement across multiple attempts rather than trusting any single run
This is voting, the parallelization variation that runs the same task multiple times to get diverse outputs, applied here so that a vulnerability only counts as flagged when multiple independent attempts agree, which is meant to produce a higher-confidence result than trusting any single review pass. The option describing sectioning is wrong because sectioning divides one task into different independent pieces that are each reviewed once, whereas this scenario runs the identical, undivided task three separate times rather than splitting the diff into parts. The option describing orchestrator-workers is wrong because that pattern has a lead call dynamically decompose a task and assign distinct subtasks to different workers, whereas here every run gets the exact same prompt and the exact same diff, with no decomposition or specialization involved. The option describing evaluator-optimizer is wrong because that pattern is a sequential critique-and-revise loop between a generator and a separate evaluator, producing one progressively refined result, not several independent parallel attempts whose outputs are combined by requiring agreement.
Source: Anthropic, 'Building Effective Agents' (anthropic.com/engineering/building-effective-agents) -- describes voting as 'running the same task multiple times to get diverse outputs,' applied 'when multiple perspectives or attempts are needed for higher confidence results,' citing code vulnerability review by several prompts flagging issues found as an example.