Best Model for Data Science: Correct Code, Wrong Analysis

Every other article about model selection for code asks whether the output works. In data science that question is close to useless, because the code almost always works. It imports, it runs, it produces a number and a chart, and the failure is that the number answers a different question than the one you asked.

That makes this the one domain where code correctness and task correctness are almost independent. A model can be excellent at pandas and consistently produce unsound analysis.

Statistical validity is not a coding skill

The recurring failures are analytical rather than syntactic, and they have a family resemblance: each one is defensible in some context and wrong in yours.

Dropping rows with missing values is the most common. A model asked to clean a dataset will drop nulls without asking whether the missingness is random, and if it is not, the drop introduces a bias that no downstream check will surface.

Applying a test that assumes a distribution the data does not have is the second. Treating a time series as independent observations is the third, and it makes every confidence interval too narrow. Reporting a correlation without checking whether a confounder explains it is the fourth, and it is the one that ends up in a slide deck.

None of these are caught by running the code. They are caught by someone who knows the data, and the model is not that person.

The model does not know what the columns mean

A dataframe gives a model column names and types. It does not give it units, collection methodology, known data-quality issues, or the fact that everything before a certain date came from a different system.

That context is where analytical judgement lives. A revenue column that switched currency midway, a sensor that reads zero when it fails rather than null, a survey field that was optional for the first six months — every one of those changes the correct analysis, and none is visible in the data.

The practical fix is a data dictionary in the prompt: what each column means, its units, its known defects and its coverage. This is worth more than any model upgrade, and like most context improvements it is cheap and rarely done. It is the same lesson as schema grounding for SQL generation, applied one layer up.

Reading plots needs a multimodal model

A meaningful part of exploratory analysis is looking at a chart and noticing something — a bimodal distribution, a cluster of outliers, a break in a trend line, heteroscedasticity in a residual plot.

A text-only model cannot do that. It can generate the plotting code and it has no idea what came out. Give it the rendered image and it can, which turns a one-way generation into an actual analysis loop.

MiniMax M3 is natively multimodal and Kimi K2.6 is vision-language, so both can take a chart as input and comment on it. The pattern that works is generate plot, render, pass the image back, ask what is notable, then act on the answer. Multimodal models explained covers how images are tokenised, which matters because they are not cheap.

Library churn hits harder here than elsewhere

The scientific Python stack changes its interfaces regularly, and the changes are the kind models reproduce wrongly: methods deprecated and removed, keyword arguments renamed, default behaviours reversed between major versions.

The dangerous subset is the changed default rather than the removed function. A removed function raises an error you will see immediately. A default that flipped — how ties are broken, whether nulls are included in a grouping, whether an operation returns a copy or a view — produces different numbers silently.

Pin your versions and state them in the prompt. Then, for any result that matters, verify a summary statistic by a second route before believing it. The general Python case covers the mechanics of version grounding.

Notebook state is a context problem

Analysis happens in notebooks, and notebooks lie about themselves. Cells can be run out of order, variables persist after the code that created them has been edited, and the file on disk does not record what actually executed.

A model reading the notebook source sees an idealised linear script that may never have run in that order. It will confidently reference a variable whose current value came from a version of a cell that no longer exists.

If you are working this way, include the current variable state — shapes, dtypes, a few summary statistics — rather than only the source. It is a small addition and it removes a whole class of confusion. Context management for agents covers the general principle of feeding state rather than history.

Sample, do not paste

The instinct with a 1M-token context window is to paste the data in. Resist it. It is expensive, attention thins across a long prompt, and models are poor at arithmetic over many rows in context.

The better pattern is to send the schema, the dtypes, a sample of rows and the summary statistics, then have the model write code that runs against the full dataset locally. The model reasons about structure; the interpreter does the computation. That division is more accurate and dramatically cheaper.

Where a genuinely large context helps is reasoning across many analysis artefacts at once, not across raw rows. Context window cost trade-offs covers where the line sits.

Recommendation

For routine transformation and plotting work with a data dictionary in context, a cheap model is enough — this is mostly pandas boilerplate and DeepSeek V4 Flash handles it.

For analysis where the conclusion matters, use GLM-5.2 or Kimi K3, and treat the output as a first draft that a person who knows the data must check. The failure mode here is not a crash; it is a confident wrong answer, and the mechanics of confident wrongness apply to numbers as much as to facts.

Where visual inspection is part of the workflow, add a multimodal model for the chart-reading step. The MiniMax M3 guide covers one option, though pricing sources for it disagree, so check the vendor page before budgeting.

The decision rule: use the model to write the code, never to certify the conclusion. Verify every load-bearing number by a second route, and put the data dictionary in the prompt before you consider paying for a better model.