LLM-Assisted Coding: Building a Championship Probability Predictor with Elo and Monte Carlo

With a single sentence—“Use Elo ratings and Monte Carlo simulation to build a champion-probability predictor”—it is possible to get a small but complete tool up and running in the time it takes to brew a cup of tea. The tool can simulate a 48-team tournament schedule, output championship probabilities and score distributions, and even generate a shareable link. The entire process may consume only a modest amount of money in model calls.

This kind of experience is becoming common in AI-assisted development: the path from requirement to runnable code is greatly compressed, and developers increasingly act as requirement definers and result validators. But “it runs” is not the same as “it is trustworthy.” Whether the model understands the tournament format correctly, whether the probabilities are reasonable, whether results are reproducible, and whether costs are controllable—all of these still require human judgment. Using this kind of predictor as an example, this article breaks down the modeling approach, engineering implementation, result validation, and cost-control methods. With core code generated by an LLM, developers can quickly build a verifiable and reusable prototype.

1. Requirements Breakdown: Why Elo and Monte Carlo?

A one-sentence requirement looks simple, but technical choice often determines whether the solution succeeds. Predicting championship probability is a multi-stage stochastic problem: given the strength of the teams and the tournament schedule, what is the probability that each team completes the entire competition and lifts the trophy?

1.1 Why Use Elo Ratings?

Elo ratings originated in chess and are widely used in football, esports, and other competitive domains. After each match, the system adjusts both teams’ scores based on the difference between actual results and expected results. The core formula is the expected score:

E_A = 1 / (1 + 10^((R_B - R_A) / 400))

Here, R_A and R_B are the teams’ pre-match ratings, and E_A is Team A’s expected score rate. A 400-point rating gap means the stronger team’s expected score rate is about 10 times that of the weaker team; when the teams are evenly matched, both sides have an expected score rate of 0.5.

Elo is suitable as an input for the predictor for several reasons:

• Explainable: Team strength is compressed into a single scalar, making results easy to explain to others.
• Easy to obtain: There are several community-maintained public football Elo ratings, so snapshot data can be used as input.
• Well aligned with betting markets: Academic studies suggest that Elo ratings, especially when adjusted for home advantage, can predict football match outcomes with accuracy comparable to bookmaker odds.
• Zero-sum updating: One team gains points and the other loses the same amount, avoiding scale drift where both teams’ scores rise after a win.

Elo also has clear limitations. It measures only historical match outcomes. It does not directly reflect injuries, current form, or roster changes, and it does not distinguish between a large win and a narrow win. Therefore, it is better suited as a baseline model than as the final answer.

1.2 Why Monte Carlo Simulation?

A 48-team tournament with 12 groups of four teams has a complex structure. In the group stage, each team plays a single round-robin within its group. The top two teams from each group advance, along with the eight best third-placed teams, forming a 32-team knockout stage. The knockout stage then proceeds through the round of 32, round of 16, quarterfinals, semifinals, and final.

To obtain the exact probability of a team winning the championship, one would need to sum over all possible bracket paths. The number of branches grows exponentially with the number of matches. On top of that, tie-breaking rules and the selection of the eight best third-placed teams add combinatorial complexity. Analytical solving is therefore nearly impossible, making random sampling the most practical option.

This is the basic idea behind Monte Carlo simulation. The law of large numbers guarantees that, with enough simulations, observed frequencies converge to probabilities. The central limit theorem further shows that the standard error of a Monte Carlo estimate is inversely proportional to the square root of the number of simulations: increasing simulations by 100 times reduces the error to one-tenth of the original size.

2. System Design and Implementation

The generated code can be divided into five layers. Each layer has a single responsibility and clear interfaces, making it easier to test individually.

Layer	Responsibility	Core data
Data layer	Load Elo rating snapshots, validate them, and normalize team identifiers	Team IDs, names, ratings
Tournament-format layer	Generate group-stage and knockout-stage fixtures according to the competition rules	Group fixtures, knockout bracket
Simulation layer	Sample match scores and simulate a full tournament	Match scores, advancement paths
Statistics layer	Aggregate results across simulations and compute probabilities and confidence intervals	Advancement, championship, final-appearance probabilities
Presentation layer	Display results in front-end tables and charts, support parameter adjustment and result sharing	Probability rankings, score distributions

2.1 Generating Single-Match Scores

Elo ratings indicate which team is stronger, but score prediction requires goals. In practice, a double-Poisson model is commonly used. Historical matches are used to calibrate two parameters: the expected total goals and the expected goal supremacy, which are then split between the two teams according to the rating difference.

// Compute expected goals from the Elo ratings of two teams.
// totalGoals: prior value for average total goals in a match;
// k: sensitivity that converts rating difference into expected goal supremacy; calibrate with historical matches.
function expectedGoals(ratingA, ratingB, totalGoals, k) {
  const diff = ratingA - ratingB;
  const supremacy = k * diff / 100;
  return {
    lambdaA: Math.max((totalGoals + supremacy) / 2, 0.1),
    lambdaB: Math.max((totalGoals - supremacy) / 2, 0.1)
  };
}
// Sample goal counts from a Poisson distribution.
// Knuth's algorithm is suitable when the expected goal count is relatively small.
function samplePoisson(lambda) {
  const limit = Math.exp(-lambda);
  let k = 0;
  let p = 1;
  do {
    k++;
    p *= Math.random();
  } while (p > limit);
  return k - 1;
}
function simulateMatch(ratingA, ratingB, params) {
  const { lambdaA, lambdaB } = expectedGoals(
    ratingA,
    ratingB,
    params.totalGoals,
    params.k
  );
  return {
    goalsA: samplePoisson(lambdaA),
    goalsB: samplePoisson(lambdaB)
  };
}

The double-Poisson model assumes that the two teams’ goal counts are independent. This slightly underestimates the probability of draws. For higher precision, implementations can use low-score corrections or adopt a match-score model that includes a draw parameter. In engineering practice, it is usually best to expose these parameters as configuration items and calibrate them with historical results.

2.2 Handling Draws in the Knockout Stage

Draws are allowed in the group stage but not in the knockout stage. Penalty shootouts are difficult to model accurately with a simple Poisson framework. Two common approaches are:

• Elo-based estimation: The expected success rate in a shootout can be calculated as:

1 / (1 + 10^(-(R_A - R_B) / 800))

The denominator uses 800 instead of 400, meaning that an 800-point rating gap is needed to create roughly a 10-to-1 expected advantage. This reflects the higher randomness of penalty shootouts.

• Simple 50/50 assumption: Give both teams a 50% chance to advance.

// Knockout-stage match:
// if the regulation-time score is tied, decide the winner with a shootout model.
function simulateKnockout(teamA, teamB, ratings, params) {
  const { goalsA, goalsB } = simulateMatch(
    ratings[teamA],
    ratings[teamB],
    params
  );
  if (goalsA !== goalsB) {
    return goalsA > goalsB ? teamA : teamB;
  }
  const p = 1 / (
    1 + Math.pow(10, -(ratings[teamA] - ratings[teamB]) / 800)
  );
  return Math.random() < p ? teamA : teamB;
}

2.3 Monte Carlo Main Loop

Simulating one tournament means running the full path from group stage to knockout stage. The outer loop repeats this process tens of thousands of times and accumulates the results.

Two implementation details deserve attention:

• Reproducible randomness: Use a seeded pseudo-random number generator. Algorithms such as xoshiro128** are often preferable to built-in random-number functions because they are fast, have long periods, and support seeded streams.
• Parallel simulation: Each tournament simulation is independent, so the workload is naturally suitable for parallel execution.

// Monte Carlo main loop
function runSimulation(tournament, ratings, params) {
  const wins = Object.fromEntries(
    tournament.teams.map((team) => [team, 0])
  );
  for (let i = 0; i < params.runs; i++) {
    // Derive a reproducible seed for each run from the base seed and run index.
    const rng = createRng(params.baseSeed + i);
    const champion = runOneTournament(tournament, rng);
    wins[champion]++;
  }
  // Convert win frequencies into probabilities and calculate 95% confidence intervals
  // using the normal approximation.
  return tournament.teams
    .map((team) => {
      const p = wins[team] / params.runs;
      const margin = 1.96 * Math.sqrt(p * (1 - p) / params.runs);
      return {
        team,
        probability: p,
        ci95: [p - margin, p + margin]
      };
    })
    .sort((a, b) => b.probability - a.probability);
}

For example, suppose a team has a championship probability of about 32%. With 10,000 simulations, the margin of error is roughly 0.9 percentage points at the 95% confidence level. This also explains why the example result might show Spain at “about 31.9%” rather than a precise two-decimal value.

3. Example Run and Result Interpretation

In the example, the input is a snapshot from a publicly maintained football Elo rating site dated June 11. The tournament is simulated 10,000 times. The results are as follows:

Rank	Team	Elo rating	Championship probability
1	Spain	2157	about 31.9%
2	Argentina	2115	about 17.8%
3	France	2063	about 9.2%
4	Brazil	1991	about 6.6%
5	England	2021	about 6.0%

The top five teams account for roughly 70% of the total championship probability. The remaining 40-plus teams share the remaining 30%. This is broadly consistent with mainstream pre-tournament betting odds. However, three results may surprise many fans.

Colombia was undervalued. Its Elo rating is 1982, ranking seventh globally, above both the Netherlands and Germany. Yet in many fans’ predictions, Colombia is rarely mentioned as a title contender. Colombia’s group includes Portugal, the Democratic Republic of the Congo, Uzbekistan, and Colombia itself, so advancing from the group should not be too difficult. Once in the knockout stage, its Elo-based strength is enough to support a deep run. It is also worth remembering that Colombia reached the final of the previous Copa América, and most of the core squad is still available.

Germany drew an unlucky bracket. Germany’s Elo rating is 1932, but in the group stage it is paired with Ecuador, whose Elo rating is 1938—six points higher. In expected-score terms, that is roughly 48% versus 52%, making it almost a coin-flip matchup. By contrast, Canada, another seeded team, faces group opponents with Elo ratings of only 1421 and 1595. Even among seeded teams, the schedule can differ dramatically.

Japan’s rating is higher than many people expect. Japan’s Elo rating is 1906, ranking 14th globally and first in Asia. South Korea, at 1758, and Iran, at 1772, are more than 130 points behind. When Japan faces the Netherlands, whose Elo rating is 1948, the rating gap is only 42 points. This implies an expected score rate of about 44% for Japan. Ignoring draws, a rough conversion suggests something close to 46% versus 54%. For many fans, the stereotype of “Asian teams versus European powerhouses” may need revision in this case.

Another interesting observation is that Spain and Argentina differ by only 42 Elo points, meaning their underlying strength is almost equal. Yet Spain’s championship probability is nearly 1.8 times that of Argentina. The difference comes mainly not from strength, but from the structure of the bracket.

4. Three Principles for Interpreting the Model

A set of probability numbers is meaningless unless it can be interpreted. When explaining the results, three principles should be followed:

1. Separate strength from schedule
   Elo measures how strong a team is. Championship probability measures how far that team can go given its actual path. A favorable group stage and an easier knockout route can raise a team’s probability, while a difficult bracket can lower it.

2. Focus on intervals, not decimals
   For teams with championship probabilities below 1%, estimates can fluctuate noticeably even with thousands of simulations. Results should be presented with confidence intervals, or grouped into ranges such as “above 5%,” “1% to 5%,” and “below 1%.”

3. Clarify the model’s boundaries
   Elo does not include injuries, suspensions, or current form. The double-Poisson model cannot capture tactical or situational changes during a match. The output is a baseline probability based on historical strength, not a prediction of future match results.

5. Where the Cost Comes From and How to Reduce It

When building tools like this, model-call costs are often overlooked. Most mainstream LLM services charge by token, with separate pricing for input and output. Output tokens are usually priced higher than input tokens. Code-generation tasks are output-heavy, so the cost structure is roughly:

Total cost = input tokens × input price + output tokens × output price

Generating a predictor like this usually involves a few thousand lines of code, roughly tens of thousands of tokens. When requirements, error messages, and multiple rounds of revision are included, the total cost may be comparable to ordering takeout. However, for projects that require repeated iteration, this expense should be included in the budget.

There are several practical ways to control costs:

• Generate in stages: First ask the model to produce the algorithmic skeleton and core functions. After confirming the logic, add the UI and styling. This avoids generating a large amount of code at once and then having to rewrite it.
• Return only essential errors: Paste only the relevant error message and the related code snippet. Include a minimal reproducible example when possible, rather than pasting the entire file. This reduces unnecessary input.
• Use different model tiers: Assign architecture design and difficult algorithmic problems to more capable models. Use lightweight models or local tools for mechanical tasks such as comment generation, formatting, and unit-test generation.
• Establish project conventions: Put the technology stack, directory structure, and coding standards into a project instruction file so the model works within a consistent context. This reduces rework.
• Review billing before scaling: Before going to production, estimate the cost per call using actual input and output volumes. Combine this with expected daily active users and call frequency to estimate monthly spending, and set usage alerts.

6. Acceptance Checklist: From “Runnable” to “Trustworthy”

LLM-generated code often “looks correct.” However, for pre-tournament prediction tools, errors can be subtle and hard to notice, yet damaging once the results are shared. At minimum, the following checks should be completed:

• Tournament-rule verification
  Confirm that the implementation matches the official regulations item by item, including 12 groups, the eight best third-placed teams advancing, and the knockout bracket mapping. This is where models are most likely to make assumptions.

• Invariant tests
  Add assertions that do not depend on real-world data:

  • If two teams have the same Elo rating, one team’s win probability in the simulation should be close to 50%.
  • The sum of all teams’ championship probabilities must equal 1.
  • The sum of all teams’ advancement probabilities must equal 32, consisting of 24 direct qualifiers plus 8 third-placed qualifiers.

• Statistical sanity checks
  Stronger teams should have monotonically non-increasing championship probabilities as Elo ratings decrease. If the number of simulations is doubled, the change in estimated probabilities should become noticeably smaller.

• Reproducibility verification
  With a fixed seed, repeated runs should produce exactly the same results.

• Performance benchmark
  A 48-team tournament requires 104 matches in total: 72 group-stage matches and 32 knockout-stage matches. Running 10,000 simulations means about 1.04 million simulated matches. In a mainstream browser, this can usually be completed within a few seconds, making it a reasonable performance baseline.

Using the example data from Section 3 for an invariant check: the top five teams’ championship probabilities sum to about 71.5%, while the remaining 40-plus teams account for about 28.5%, totaling 1. Spain’s probability is about 1.79 times Argentina’s, which is close to the 1.78 ratio implied by their Elo difference. The results are internally consistent.

7. From a One-Off Script to a Reusable Service

If the tool needs to run continuously and serve multiple users, additional engineering work is required:

• Elastic compute
  Large-scale simulations can be split into multiple shard tasks and executed in parallel using cloud functions, container platforms, or other elastic compute resources. Results can be aggregated afterward.

• Static hosting
  The front-end page can be deployed to object storage or a CDN, requiring minimal operations on the user side. If the goal is “open a link and get results,” the schedule and rating snapshot can be encoded into a URL, with the simulation performed in the browser using a Web Worker to avoid blocking the UI.

• Observability and alerts
  Log and monitor metrics such as single-simulation runtime, failure rate, and token usage from model calls. This helps prevent abnormal retries from inflating costs.

• Separate computation from data
  Keep rating snapshots, calibration parameters, and computation logic separate. Record the data version for each simulation round so that it is possible to trace which data produced a given result.

• Deployment flexibility
  The capabilities described here—elastic compute, object storage, logging, and monitoring—are general cloud-platform capabilities. A personal prototype can also run directly on a local machine.

Conclusion: In the AI Era, Judgment Is More Scarce

Returning to the original question: can one sentence generate a complete product? Yes, but more precisely, one sentence can generate a runnable prototype. Models are good at translating clear requirements into code. However, defining the problem, choosing the model, validating the results, and explaining the output still require human judgment.

The real value of a predictor is not just producing a number. It is making each team’s probability evidence-based, reproducible, and explainable. The ability to do that well is the truly scarce resource in the AI era.