Cursor for Data Scientists: Notebooks, Pipelines and Analysis

Writing fresh code is the part people expect, and it's the part that matters least. Cursor will turn a plain-English description into wrangling code and scaffold the boilerplate around an ML experiment, sure. But the reading-and-fixing work earns its keep: making sense of analysis someone else wrote, untangling an ETL or feature pipeline that broke. The full list is below.

• Data wrangling from a plain-English description.
• Pipelines for ETL and feature work.
• Explain & refactor inherited analysis code.
• ML scaffolding for training loops, evaluation and plotting.

Generated code is the cheapest kind to check, because you wrote the prompt and you know what you asked for. Inherited analysis is the expensive kind, since you are reconstructing intent from somebody else's variable names, and a wrong reconstruction looks identical to a right one until the number lands in a deck. I'd hand a new user the inherited-notebook case first for that reason, even though generation makes the better demo.

Context first, then a rule, then a plan, then let the agent write. Hand it your schema or a sample row before you ask for a line of code, add a Python rule so the output matches your stack, plan anything longer than a couple of cells, and execute last.

Each of those steps removes a class of error the next one would otherwise carry forward. Without the schema the model picks plausible column names, and plausible is the dangerous outcome here, because created_at reads perfectly well right up to the moment your table turns out to say created_ts. Without the rule the code works and arrives in a dialect nobody on your team writes, so review becomes an argument about style rather than about the analysis. Without the plan you get a notebook that runs, which is a lower bar than a notebook you can defend when somebody asks why those rows went missing.

The plan is the step that actually gets dropped. Cursor's own guidance points plan mode at work with several valid approaches or many files in play, and a real analysis is usually both.

There is a case for breaking the order, and Cursor's docs name it. For a quick change, or something you have done many times, going straight to agent mode is fine. A throwaway lookup against a table you already know cold does not need a rule and a plan wrapped around it. The test I use is whether anyone else will quote the output. If they will, do the setup, because the setup is most of what makes the number defensible a month later.

Install the Jupyter extensions from the same marketplace Cursor inherits from VS Code. Pick the ones published by MS Tools AI (verify by publisher and download count) and grab all the relevant notebook extensions while you're there.

Reproducibility comes from feeding the model your real context up front and never running its output blind. Give it the schema so the column names are correct, encode your stack in a Python rule, read every cell before you execute it, and pin seeds and versions so the numbers come back the same tomorrow.

• Give it your schema/sample via @-context so column names are right.
• Add a Python rule (.cursor/rules) for typing, linting and your libraries.
• Review before running. Do not execute generated cells blind.
• Pin seeds and versions so results reproduce.

One piece of the standard Cursor loop does not survive contact with a notebook. Everywhere else you let the agent run, read the diff and then keep or reject. Here you are the runtime, since Cursor cannot reliably execute cells for you, so the edit and the result arrive at separate moments and you hold both in your head. That gap is where blind cell execution creeps in. Read the cell, then run it, in that order, and plan for a loop that is slower than the demos make it look.

Model choice matters less on this work than on most Cursor work, or that is my read of it. Python is heavily represented in what these models trained on, which is why they handle venv and version tangles so well. A stronger model earns its cost at the planning end, before any code exists, where the open question is which comparison the chart is supposed to support.

When the code looks fine and the answer looks wrong, check the row count either side of every join, then the dtypes after each read. Both checks are cheap and between them they catch most of it. A filter that silently matched nothing is the other one worth a glance, since an empty frame will render a chart quite happily.

Not much, beyond how much you bother writing down. On your own, a rule file and one or two skills cover it. On a bigger analytics team the artifacts other people depend on are the ones worth real effort, which in practice means the rule lives in the shared repo and the schema lookup lives in a skill rather than in your chat history.

The expensive part of a bigger team is not producing the analysis, it is agreeing on what the analysis did. A plan somebody can read before the notebook exists gives them something cheap to disagree with. I used to think the point of writing the plan was better output from the agent. It does do that, and the larger effect turns out to be on the reviewer, who now argues with a document instead of with a finished notebook and a sunk afternoon, so these days I'd write the plan even on work where I already know exactly what to build.

Skills are where I would spend the effort if you only pick one thing. Let the agent crawl the database once and pay for that exploration, then ask it to write a skill covering the lookup it just worked out. Later runs reach for the skill and skip the rediscovery. On a team the same file doubles as onboarding, because a new analyst can run it instead of reading a wiki page that describes it.