Cursor for Data Scientists: Notebooks, Pipelines and Analysis

Data scientists use Cursor both to write new data code and to understand code they inherited. The work falls into these groups:

• Wrangling data from a plain-English description.
• Building ETL and feature pipelines, and fixing them when they break.
• Explaining and refactoring analysis code someone else wrote.
• Scaffolding ML experiments, from training loops to evaluation and plotting.

Check the two kinds of work differently. Code that Cursor generates for you is easier to check, because you wrote the prompt and know what you asked for. Cursor's explanation of inherited analysis is harder to check. It rebuilds intent from someone else's variable names, and a wrong reading looks the same as a right one until the number lands in a deck.

The presenter of Cursor's data science workshop pointed new users to the data science cookbook, one of Cursor's role-specific workflow guides. By her account, it covers notebook development and connecting databases, and she named Supabase, Postgres, BigQuery, SQLite and Snowflake.

The cookbook itself is Cursor's data science guide, published on its site. It describes two ways to connect a database and doesn't mention Supabase. Through an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server, the agent can write and run queries against your database as part of a task, and the guide's example connects Postgres. Database extensions for PostgreSQL, BigQuery, SQLite and Snowflake let you execute queries without leaving the editor.

We recommend this order: context, then a rule, then a plan, then code. Hand the agent your schema or a sample row before you ask for any code. Add a Python rule so the output matches your stack, and plan anything longer than a couple of cells.

Each step prevents an error that would otherwise carry into the next one. Without the schema, the model guesses plausible column names, and created_at reads fine until your table turns out to use created_ts. Without the rule, the code works but arrives in a style nobody on your team writes, so review becomes an argument about style instead of the analysis. Without the plan, you get a notebook that runs, which is a lower bar than a notebook you can defend when someone asks why rows went missing.

Don't skip the plan. Cursor's Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. docs recommend it for work with several valid approaches or many files, and an analysis often has both.

The same docs say when to skip it: a quick change, or a task you've done many times, can go straight to Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition.. A one-off lookup against a table you know well doesn't need a rule and a plan around it. Our test is whether anyone else will quote the output. If they will, do the full setup, because it is what lets you defend the number a month later.

Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. turns an analysis into a plan you can read and edit before any cell changes. The presenter of Cursor's data science workshop recommended it as a first-time user's starting point, and she used it as a design doc that sits next to the code.

Her plan opened inside Cursor beside the code, and each step could point at the files and lines it would change. To change course, she edited the plan itself. Deleting a step such as "sleep charts" removed that work, and a new step could ask for tests or another chart. She added that a plan can be checked into GitHub for the team, and that separate agents can run several plans at once, such as a notebook and a web app that read from one database.

Spend model strength on the plan. The presenter put the agent's ease with venv and version problems down to how heavily Python is represented in the models' training data. In our view, the model matters less for writing the code than for planning the analysis. Planning happens before any code exists, when the open question is which comparison a chart should support.

For notebook support, Cursor's data science guide points to one extension: Jupyter (ms-toolsai.jupyter). Add it from the Extensions panel once you have confirmed that ms-toolsai is the publisher. Cursor installs third-party extensions from the Open VSX registry, and its help center warns that the same extension ID there can belong to a different publisher than on Microsoft's marketplace. The workshop presenter checked publishers and download counts, then installed the related notebook extensions as well.

Generated data code can run without an error and still produce a wrong number. Build these habits in before the first run:

• Give the agent your schema or a sample row with an @ mention, so column names are right.
• Add a Python rule in .cursor/rules for typing, linting and your libraries.
• Read each generated cell before you run it.
• Pin seeds and library versions, so results reproduce.

Notebooks also change the usual review loop. Elsewhere, the agent edits files and you review the diff, then reject what you don't want. In the workshop, the presenter ran the cells herself, so each edit and its result arrived at different moments. Blind execution creeps in through that gap. Read each cell, then run it, and expect a slower loop than the demos suggest.

When the code looks fine and the answer looks wrong, check the row count on both sides of every join, then the dtypes after each read. Both checks are cheap, and a join or a type conversion can change results without raising an error. Also check that each filter matched something, because an empty data frame still renders a chart.

Very little changes, apart from how much you write down. Working alone, a rule file and one or two skills are enough. On a bigger analytics team, put the effort into the files other people depend on: the rule belongs in the shared repo, and the schema lookup belongs in a skill instead of your chat history.

On a bigger team, agreeing on what an analysis did costs more than producing it. A plan that colleagues can read before the notebook exists gives them something cheap to disagree with. The plan improves the agent's output too, but its larger effect is on the reviewer, who argues with a document instead of a finished notebook and a lost afternoon. For that reason, write the plan even when you already know what to build.

If you invest in one thing, make it a skill. Have the agent explore the database once and pay for that exploration, then ask it to turn the lookup it worked out into a skill. Cursor's agent decides when a skill is relevant, so later runs can use it instead of exploring again. On a team, the skill also works as onboarding, because a new analyst can run it instead of reading a wiki page that describes it.