2 min lesson
Driving Cursor through the analysis itself
Put this idea into your own words. "Cursor will diagnose it, install into the venv and self-verify."
Step 1 of 2
Driving Cursor through the analysis itselfthe analyst's own loop
This is also the work you'll do inside Cursor day to day, and it pays to set the workspace up like the team does. Cursor ships role-specific cookbooks, workflow recipes for different jobs, and the data science one is the place to start. It walks through Jupyter notebook development, wiring up database frameworks like Supabase and Postgres and the in-editor extensions for Postgres, BigQuery, SQLite and Snowflake so your warehouse lives next to your analysis.
Cursor has a number of different cookbooks, basically workflows for different types of roles. The data science one is honestly just a good place to start if you're figuring out how to incorporate Cursor inside your data science workflows.
For notebooks, install the Jupyter extensions from the same marketplace VS Code uses, and check the publisher (the ones by MS Tools AI) and the download count before you trust one. One honest caveat from the field: Cursor can't always run Jupyter cells for you automatically, so expect to execute some cells by hand. The flip side is that Python frustrations are where the agent shines. Because Python is so heavily represented in training data, models are strong at the pip-version-venv mess. One recurring fix is pandas import could not be resolved, where the package sat in system Python but not in the venv the notebook was using; Cursor will diagnose it, install into the venv and self-verify.
When Cursor offers to install into a virtualenv versus the project, pick the venv. It keeps the notebook's environment pinned and isolated, which is the same reproducibility discipline you'll demand of any number you ship, the slow-burn cousin of parameterizing your queries.
Learn more
Full explanation
Model economics: plan with the smart model, build with the cheap one
Model economics: plan with the smart model, build with the cheap one
The single rule of thumb worth stealing from the team: don't reach for the most expensive reasoning model by reflex. Start with the cheaper, standard model, since the in-house ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. models are fast and genuinely underestimated, and only escalate to a frontier reasoning model when the cheap one stalls. That means the GPT-5.x line, or the current Claude Opus, Opus 5.5 at the time of writing. The exception is when a task obviously needs reasoning: building a plan, or a thorny bug where the model has to reason about where the problem even lives. Skip straight to the strong model there.
Use a high-reasoning model to work with Cursor on the plan, then switch to a simpler, cheaper, faster model for implementation, since the heavy lifting is already in the plan. Using the most expensive model to build out the plan is like taking a Lamborghini to the grocery store. It's nice and it's cool, but it's expensive.
When you batch out work, say generating a wall of charts from a cleaned export, reach for sub-agents. They're "baby Cursors": smaller agents with a clear persona and instructions, running inside a bigger agent, spun up from a create sub agent skill, roughly a 150-line Markdown persona. The Cursor-specific lever is that you set a model per sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition., so a chart-builder doesn't need a frontier model racking up a bill: one of the in-house ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. models or a mid-tier model is plenty. You can launch several in parallel, and "launch three chart-builder sub-agents" spins up three side-by-side workers, each visible in the sub-agent UI. One constraint: sub-agents need a reasoning-capable model, so check that the one you assign can drive them.
Interactive widget. Tab through its controls; the result updates in the panel below as you change them.
Plan and locate hard bugs with a reasoning model; implement and batch-build with the cheap, fast in-house models. Auto can route the choice on plans that include it; Balance and Intelligence routing is Teams and Enterprise only.
QA teammate wants a wall of charts built from a cleaned export and plans to run the frontier reasoning model on every chart-builder sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition.. What do you suggest?
Reproducibility and data quality
An analysis an engineer can't rerun is a rumor. Parameterize your queries, keep the analysis under version control and make the result regenerate from inputs on demand. Then bake data-quality checks into the pipeline itself so a broken metric fails loudly instead of lying quietly.
- Parameterize date ranges, segments and thresholds, with no magic numbers buried in SQL.
- Version-control the analysis so the number has provenance and a diff.
- Assert null, duplicate and skew checks in-pipeline; a metric that silently drops 30% of rows is worse than no metric.
- Pin the query and inputs so "rerun it next month" gives the same shape of answer, not a surprise.
If you get a SQL exercise, narrate your cost reasoning before you optimize syntax. Say "I'll filter the partition key first so this scans a week, not the full history, and use approximate percentiles since exact sort is overkill for a p95." At billions of rows that judgment is part of the answer, not an afterthought to a correct join.
Learn more
Optional practice
Test yourself on Driving Cursor through the analysis itself
QYou need p99 latency by model over the last 90 days from a 5-billion-row partitioned event table. Which approach best balances correctness and cost?