AI Coding Workflow for Python

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Hand the agent exactly what you ran. Copy the failing cell or its error output and use Add to Chat, so Cursor sees the real code and the real traceback instead of your paraphrase. The presenter of Cursor's data-science webinar called it the most effective habit for finding where an issue happens. Terminal errors work the same way: copy the error, add it to chat and ask. You can't always copy a notebook's rendered output straight into Cursor, so copy the whole cell instead.

The cause is almost always the environment. A common case is pandas import could not be resolved or matplotlib not installed, because the package is installed in your system Python but not in the virtual environment the notebook uses. Add the error to chat, and the agent finds the root cause, installs the package into the virtual environment and checks the import itself. When the presenter set up the environment, Cursor asked whether to install into a virtual environment or the project, and the presenter chose the virtual environment.

The check step. In Cursor's data-science webinar, the agent wrote and edited notebook cells well but couldn't reliably run them, so the presenter ran the cells by hand. Any workflow that ends with "run the check and read the output" assumes the agent can close its own loop, and in that notebook it couldn't.

That changes the size of the task you should hand over. If you are the one running cells, a ten-cell rewrite means ten manual runs before you know whether any of it worked. So the done state has to name the cell you will run and what you expect to see when you run it.

The presenter thought someone might have built 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 that runs cells, but hadn't found one. Plan the loop around running cells by hand.

Because two of the first errors you hit come from the environment, not the logic. One is the notebook import failure above. The other is a hard-coded path that a notebook brings with it from the machine it was written on. Neither is a logic mistake, but both show up as errors in your code.

So state the interpreter first, and choose it on purpose instead of taking the default. A virtual environment keeps the notebook's dependencies reproducible, and choosing it up front prevents the same import error the next time someone opens the file.

In the webinar, a "no such file or directory" failure turned out to be a path hard-coded from wherever the notebook was first written. 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. rewrote the path to detect whether it was running locally or in the original location, and to resolve it relative to the notebook.

Watch the context ring next to your prompt input. In the same webinar, the presenter saw a slower agent and weaker answers once the window passed roughly 70 to 80%.

Notebook debugging gets there faster than service work, because every traceback and every cell you hand over adds up. The habit that makes the debug loop work, handing over the real cell and the real traceback instead of your description of them, is the same habit that fills the window. So add only the context the agent needs: the failing cell and its traceback, not the cells around it.