2 min lesson
Driving Cursor through the analysis itself
Explain the practical point behind "Cursor has a number of different cookbooks - basically workflows for different types of roles."
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 - 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 because the package sat in system Python but not in the venv the notebook was using, which Cursor will diagnose, 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 - 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 (the GPT-5.x line, or whichever Claude Opus is current - today Opus 5) when the cheap one stalls. 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 - 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 ("launch three chart-builder sub-agents" spins up three side-by-side workers, each visible in the sub-agent UI). One hard constraint: sub-agents need a reasoning model to drive them - the fastest execution-only Composer variant can't run sub-agents, so point them at a reasoning model.
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 routes when you'd rather not decide.
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 - 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.
In a SQL screen, 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." Interviewers for an at-scale role weight that judgment as heavily as a correct join.
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?