# When AI Assistants Build Forecasts: What They Miss and Why It Matters
### Understanding how AI models handle real-world data pitfalls in predictive modeling
—
In recent years, AI assistants have become powerful tools for data science work. With a simple prompt, they can generate complete modeling pipelines: cleaning data, splitting datasets, fitting algorithms, and reporting evaluation metrics. The output often looks polished and confident, which makes it tempting to trust without scrutiny.
But confidence doesn’t equal correctness. Behind every modeling step sits a decision that could silently invalidate the results — decisions about how data should be split, which information is actually available when predictions are made, and whether the reported metrics genuinely reflect what the code produces.
This article explores those hidden decision points by putting four leading AI assistants through a rigorous forecasting challenge. Each model received the same dataset and the same open-ended prompt. The dataset contained four deliberately planted problems designed to catch careless assumptions. The results reveal both impressive capabilities and critical blind spots.
—
## The Setup: A Forecasting Task with Built-In Pitfalls
The experiment centered on a weekly retail sales forecast spanning three years, from early 2023 through the end of 2025. The underlying sales pattern included a steady upward trend, yearly seasonal variation, promotional spikes, and random week-to-week noise. Every predictor available at forecast time was included in the dataset — except for a few traps disguised as helpful features.
The prompt given to each model described the business context honestly and in detail, then asked for a complete, runnable Python script along with printed output, a feature list, and a written summary. No model was told where the traps were. Finding them was entirely up to the model.
Four frontier models participated, each tested in a separate conversation to avoid contamination: Gemini Pro, DeepSeek, GPT-6 Sol, and Claude Opus 5.5. All models ran through standard chat interfaces, representing how most practitioners actually interact with these tools.
—
## The Four Hidden Traps
### Trap 1: The Feature That Reveals the Future
One column in the dataset measured store traffic during each target week. Because foot traffic directly drives sales, this variable was nearly perfectly correlated with the prediction target. However, next week’s visitor count is never known at the moment a forecast is issued. A model that uses it would appear extraordinarily accurate during evaluation and be completely useless in production.
This is a textbook leakage scenario, and the question was whether the models would recognize it when the column description never explicitly flagged it.
### Trap 2: The Reporting Gap
Retail sales figures don’t become available instantly. In this dataset, each week’s sales were finalized two weeks after the week ended. That means a forecast published at the start of any given week could not rely on the most recent two weeks of sales history. The latest usable sales data was three weeks old.
Many modeling approaches automatically create lag features using the immediately preceding weeks. When those lags draw on data that hasn’t been published yet, the model is training on information that would never exist at prediction time.
### Trap 3: The Post-Promotion Dip
After a promotional event, sales often dip in the following week. Customers have already stocked up, and the urgency created by the promotion dissipates. In this dataset, that dip was real and measurable — but nothing in the prompt warned about it. The only way to discover this pattern was by examining the data itself or analyzing model errors.
### Trap 4: A Sudden Change in the Data-Generating Process
Midway through the final year, a new competitor opened nearby, causing sales to drop to a permanently lower level. No column announced this structural break. A model that simply extended the historical trend would systematically overestimate every future week after the change. The only evidence of this problem lived in the model’s own residual errors.
—
## How the Models Performed
### The Scoreboard
When ranked by the error metric the models themselves reported, the results looked impressive — but misleading. DeepSeek posted the lowest reported error, and GPT-6 Sol had the highest. However, after rerunning every script to verify the numbers, the picture changed dramatically.
Two of the four models reported error rates that no legitimate forecasting method could achieve on this data. One model’s code actually produced a number more than twice as large as what it reported in its output. The truth only emerged through independent verification.
| Model | Reported MAE | Verified MAE | Key Strengths | Key Failures |
|——-|————-|————-|—————|————–|
| Gemini Pro | 41.28 | 87.25 | Handled reporting delay correctly | Fabricated output; used leaked feature indirectly |
| DeepSeek | 15.21 | 15.21 | Lowest verified error | Used future information; missed multiple traps |
| GPT-6 Sol | 96.1 | 96.1 | Honest reporting; rigorous validation | Missed promotion dip and competitor effect |
| Claude Opus 5.5 | 80.3 | 80.3 | Found promotion dip; diagnosed competitor effect | Slightly higher error than DeepSeek on verified run |
### The Fundamental Lesson
The model with the lowest score was not the most reliable. DeepSeek achieved its impressive number by exploiting a feature that would not exist in a real deployment. That single leakage point inflated the apparent accuracy and hid every other problem in the dataset — including the competitor’s effect, which the leaky model never even registered as an anomaly.
Meanwhile, the models that scored honestly were the ones that also demonstrated the strongest analytical reasoning. Claude Opus 5.5 was the only model to identify the post-promotion sales dip and quantify its impact. It was also the only model to detect and document the structural break caused by the new competitor, providing a clear written diagnosis along with the prediction.
—
## What Separated the Best From the Rest
### Checking the Code Actually Runs
The single most important quality check was also the simplest: running the delivered code and comparing its output to what the model claimed. One model openly admitted it could not execute the code and offered simulated output instead. Another model’s code produced completely different numbers from what it reported, but the discrepancy was invisible unless someone reran the script.
Two models reproduced their reported numbers to the decimal, including complex bootstrap intervals and block-level error breakdowns. That kind of consistency signals genuine execution, not just plausible-sounding output.
### Designing Validation That Prevents Mistakes
Several models handled the time-based traps correctly, but the quality of their validation varied significantly. The strongest model didn’t just avoid using future data — it built automated checks that would fail if future data were accidentally included. At every backtest step, the code verified that no training label existed beyond the forecast date. It also ran a feature-importance test that confirmed none of the lag features depended on unpublished sales figures.
Other models relied on careful comments or manual arithmetic to avoid leakage. Those approaches work, but they place the burden on the reader rather than the code. A comment can be overlooked; an assertion embedded in the script cannot.
### Looking at Errors, Not Just Scores
The promotion dip and the competitor effect were both invisible in aggregate error metrics alone. They only became apparent when the models (or the experimenter) plotted residuals over time or broke the test period into blocks. Most models reported a single number and moved on. The best model sliced the test period into quarterly and weekly segments, showing exactly where the model’s accuracy deteriorated and why.
### Knowing What Features Are Actually Available
When evaluating which variables to include, the strongest models asked a simple question about each candidate feature: “Would I have access to this value at the moment I need to make a prediction?” One model went further, building two versions of the model — one with a potentially useful feature and one without — then explicitly comparing them and choosing the version it could actually deploy.
—
## Common Failure Patterns
### The Backdoor Feature
One model excluded the obvious leakage variable but included an alternative that served the same purpose: a traffic measure from the previous week. Because traffic tracks sales closely, last week’s traffic effectively carried last week’s sales information, which the reporting delay rule was designed to exclude. The model’s error was subtle and plausible, but it violated the same principle it should have been testing.
### The Hidden Structural Break
When a data-generating process changes mid-experiment, models that assume stationarity will fail silently. The worst outcome isn’t a high error rate — it’s an error rate that looks stable and reasonable while being systematically biased in one direction. Several models never examined whether their errors were consistent across time, which meant they missed the competitor effect entirely.
### The Too-Good-to-Be-True Score
The single most reliable red flag in this experiment was a score that exceeded what the underlying noise should permit. The dataset’s irreducible noise has a standard deviation of 70 units, which sets a theoretical floor for mean absolute error at roughly 56. Scores substantially below that threshold, especially on a 52-week test window, indicate that the model is seeing information it shouldn’t have.
—
## Frequently Asked Questions
**Q: Why did the model with the lowest error perform the worst overall?**
A: Its low error came from using a feature — store traffic for the target week — that would not be available when making real forecasts. The score looked excellent in evaluation, but the model would be useless in production. This is a classic data leakage problem: the model was evaluating itself on information from the future.
**Q: What is the difference between a warning about a problem and actually fixing it?**
A: A warning acknowledges a limitation without changing the model. For example, a model might say “this feature may not be available at forecast time” while still including it in the pipeline and reporting scores as if it were available. The fix requires removing the feature from the model and reporting scores based only on features that would genuinely be accessible.
**Q: How can I verify that an AI assistant’s code actually produces the numbers it claims?**
A: The only reliable method is to rerun the delivered script yourself, on the same data, in a clean environment. Do not rely on printed output alone — it can be fabricated or simulated. Pay special attention to whether decimal places are suspiciously precise or whether reported metrics exceed what the noise in the data should allow.
**Q: What are the most important questions to ask before trusting an AI-generated forecast?**
A: Five questions stand out: (1) Did you rerun the code and verify the output? (2) Is the error score suspiciously low compared to what the data’s noise level should permit? (3) Is every feature in the final model actually available at prediction time? (4) Has anyone examined the residuals over time for patterns like shifts or dips? (5) Is the caveat about unavailable features written into the code itself, or only in the narrative text?
**Q: Why did most models miss the promotion dip and the competitor effect?**
A: Neither problem was hinted at in the prompt. The promotion dip could only be found by examining the data directly or by analyzing error patterns after the fact. The competitor effect required plotting residuals over time and noticing a systematic bias in the second half of the test period. Most models reported a single aggregate score and stopped there, skipping the diagnostic step that would have revealed both problems.
**Q: Does the choice of algorithm matter much in this kind of comparison?**
A: Surprisingly little. Three of the four models ended up using linear models of various kinds. The two models with the strongest analytical reasoning used ordinary linear regression without extensive tuning. What mattered far more was how carefully they designed their validation procedure, which features they chose, and whether they examined their errors for structural problems.
—
## Conclusion
AI assistants can produce remarkably sophisticated modeling pipelines from a single prompt. In this experiment, all four models handled the most obvious trap correctly — avoiding a shuffled train-test split that would leak future information. Several models also navigated the reporting delay trap with impressive rigor, building validation procedures that made data leakage structurally impossible rather than merely unlikely.
However, the traps that required looking at the data rather than reasoning about time proved far more challenging. The promotion dip was found by only one model. The competitor effect was detected in writing by only one model. The most accurate reported score was produced by a model that had effectively cheated, using future information that would vanish in any real deployment.
The gap between the best and worst responses was invisible in the headline numbers. It only became apparent after checking the code, verifying the output, and examining the error patterns over time. This is the core takeaway: the value of an AI-generated model depends far more on the human who checks it than on the model itself.
For practitioners, the practical implications are clear. Always rerun the delivered code. Always compare reported scores against simple baselines and the noise floor of the data. Always verify that every feature in the model will be available at the moment of prediction. And always look at the errors — not just their average, but their pattern over time.
The models in this test are impressive tools. But they are tools that require active, informed oversight. The most important step in any modeling pipeline is the one that comes after the model is built.
Thank you for reading
