The Humans Building AI Forecasting Bots Are Flying Blind — and They Know It

Qualitative study of 15 successful forecasting-bot builders reveals systematic overengineering, ad-hoc testing, and fundamental evaluation gaps. The bottleneck isn't AI capability — it's human process.

You know that feeling when you're tuning a recipe you've never tasted? You adjust spice levels, swap ingredients, change cooking times — but you never actually eat the dish until you serve it to guests. That's what building an AI forecasting bot looks like, according to a new qualitative study of 15 people who did it competitively and did it well. The core mechanism: builders are constructing multi-stage inference pipelines (research → reasoning → prediction) where the feedback signal is so delayed and so noisy that rational tuning is nearly impossible. They're optimizing in the dark. The committed claim here: this is the first detailed qualitative account of the human labor involved in constructing AI forecasting systems, drawn from interviews with successful participants in a competitive AI forecasting tournament. The authors — Dhawka, Wilson, and Head — aren't proposing a new model or a benchmark. They're doing something rarer: documenting the craft knowledge and systematic failure modes of the humans in the loop. Their finding is that builders faced three interlocking challenges — getting bots to gather relevant facts, implementing coherent multi-step reasoning, and understanding whether any of it actually worked. The research-gathering problem is deceptively hard. Builders reported that their bots would retrieve information that was superficially relevant but factually stale, misattributed, or hallucinated. Tuning retrieval meant deciding what sources to trust, how much context to feed the model, and when to stop searching — all decisions that required domain expertise the builders often didn't have for every question domain. Several participants described adding retrieval complexity (more sources, more sophisticated filtering) that produced no measurable improvement or actively degraded performance. The reasoning challenge is where things get structurally interesting. Forecasting requires chaining multiple uncertain inferences — assessing base rates, weighing evidence for and against, calibrating confidence. Builders tried prompt engineering, multi-agent architectures, chain-of-thought scaffolding, and explicit reasoning templates. The recurring pattern: added complexity rarely paid off. Simpler pipelines frequently matched or beat elaborate multi-stage systems, but builders couldn't tell this in advance because their evaluation methods were inadequate. This is the paper's sharpest insight — the complexity trap isn't about AI limitations but about human inability to diagnose what's working. Evaluation was the deepest hole. Forecasting questions resolve slowly (days to months), sample sizes per question type are tiny, and Brier scores aggregate across wildly different question difficulties. Builders reported testing on small convenience samples, sometimes just a handful of resolved questions. Several admitted to 'vibe-checking' — reading a few bot outputs and judging whether they seemed reasonable. The authors note that this piecemeal, opportunistic testing is structurally similar to problems documented in software engineering research on undertesting, but with the added difficulty that the ground truth arrives late and is domain-specific. The study's method is straightforward qualitative research — semi-structured interviews, thematic coding, iterative analysis. The sample of 15 is appropriate for the method but inherently limits generalizability. Crucially, participants were drawn from a competition context, meaning they were more motivated, more technically capable, and had more structured feedback than builders working in deployment settings. The challenges documented here are likely a floor, not a ceiling, for what real-world forecasting-bot construction looks like. What this paper actually contributes to the field is a problem specification. If you're building tools, IDEs, evaluation frameworks, or human-AI teaming protocols for forecasting, this is your requirements document. The three challenge areas — retrieval tuning, reasoning implementation, and evaluation methodology — map cleanly to tool opportunities. The complexity-doesn't-pay-off finding is a direct signal that current builder workflows lack the feedback mechanisms to support rational architectural decisions. The next useful artifact from this line of work isn't another interview study — it's an evaluation harness that gives builders fast, reliable signal on what pipeline changes actually improve calibration.