Cursor vs Copilot: Which AI Editor Is Better for Python?

Installing Cursor

Head to the Cursor download page and download the installer for your operating system. When you launch Cursor for the first time, it can import your existing VS Code settings, extensions, themes, and keybindings, letting you get started without reconfiguring your environment.

However, not every VS Code extension is available in Cursor. Microsoft’s Pylance extension, for example, is licensed for use only with Microsoft products, so it won’t run in Cursor.

If you’re new to Cursor, Real Python’s video course on Tips for Using the AI Coding Editor Cursor covers the multi-agent interface, project-aware chat, and inline edits, all of which provide useful background before you compare it with Copilot.

Enabling GitHub Copilot in VS Code

GitHub Copilot adds AI assistance directly to VS Code, letting you build projects and speed up development without switching editors. Follow these steps to activate it:

1. Open VS Code.
2. Open the Extensions view and search for GitHub Copilot Chat.
3. Select the GitHub Copilot Chat extension and click Enable AI Features.

The image below shows the extension page:

If you haven’t signed in to VS Code yet, sign in with your GitHub account to use GitHub Copilot. Click the Copilot icon in the bottom-right corner of the VS Code Status Bar and follow the prompts shown below:

Once you authenticate, GitHub Copilot becomes available in VS Code through a chat interface. Open it with Ctrl+Alt+I or Ctrl+Cmd+I, as shown below:

The Chat view opens with an empty session and a prompt box at the bottom. The row beneath the prompt holds the mode and model selectors, which you’ll use in the next section to put both editors on the same model.

Setting Up the Project

Create two empty project directories from your terminal:

$ mkdir notes-manager-cursor-test notes-manager-copilot-test

Open the first project in Cursor:

$ cursor notes-manager-cursor-test

Since the project is empty, there’s no code to index yet. As you add files, Cursor reads and indexes the codebase so it can find relevant code across the project. You can control what Cursor indexes with .cursorignore and .cursorindexingignore files.

Then open the second project in VS Code:

$ code notes-manager-copilot-test

Copilot behaves similarly. As you add files, VS Code automatically builds and maintains a semantic index that Copilot can use to find relevant code across the workspace. You can check the indexing status from the Copilot status dashboard in the VS Code Status Bar.

Once you’ve launched both projects, compare the chat modes available in each editor before sending your first prompt.

Both Cursor and Copilot provide the same three chat modes for different types of interactions. The table below summarizes them:

GitHub Copilot also includes an Edit mode. It’s now hidden by default in favor of Agent mode, but you can re-enable it by setting chat.editMode.hidden to false in your VS Code settings.

To begin, select Agent mode in both editors.

In Cursor, press Ctrl+I or Cmd+I to open the chat panel, then press Shift+Tab until Agent mode is selected.

In VS Code, press Ctrl+Alt+I or Ctrl+Cmd+I to open the Chat view, then press Ctrl+. or Cmd+. to open the mode picker and select Agent.

With both editors ready, send the following prompt to each one:

Set up a Python project in this directory following standard Python
packaging conventions:
- Create a virtual environment
- Install pyyaml==6.0.2 and pytest==9.0.3
- Add a tests/ directory
- Use the directory name as the package name
- Only include the dependencies listed above

As each editor works, pay attention to how it interprets the prompt. Notice what project structure it creates, whether it requests approval before running terminal commands, how it presents code changes, and how it verifies the setup.

Observations: Cursor

Cursor works through the setup as a sequence of distinct steps, explaining what it’s about to do before each stage and keeping you informed of its progress throughout.

As it creates the project, Cursor presents every generated file as a reviewable diff before applying the changes. It automatically runs the required terminal commands as part of the setup, including creating the virtual environment, installing dependencies, and verifying that the project works.

The animation below shows Cursor setting up the project:

After finishing the setup, Cursor summarizes the generated project along with the verification results.

Observations: GitHub Copilot

GitHub Copilot handles the setup as a sequence of tracked tasks, updating its progress as it completes each step and reporting its status directly in the chat.

By default, Copilot asks for permission before running terminal commands. Once you approve, it runs them and displays the output inline.

The setup process is shown below:

After finishing the setup, Copilot provides a concise summary of the generated project along with the results of its validation checks.

Both editors complete the setup correctly and produce comparable project structures using the same model. The difference is in how they present their work. Cursor stages every file as a diff that you review before applying, while Copilot tracks its progress through a running task list in the chat.

Implementing the Application

With the project set up, use the following prompt to implement the application:

Build a command-line Markdown note manager for this project.

Requirements:

- Store notes as Markdown files with YAML frontmatter containing a
  title and tags.
- Represent each note as a dataclass with title, body, tags, and
  created_at fields.
- Create a SQLite-backed NoteStore that can add notes, search notes,
  list notes by tag, and retrieve notes by title.
- Build an argparse command-line interface that exposes those
  operations.

At this stage, you’re evaluating more than whether each editor produces working code. You’re comparing how each editor translates the same specification into a complete application and how readily you can inspect the generated implementation before you continue development.

As you review the generated implementation, check whether each editor:

• Implements the requested functionality
• Organizes the application into clear modules
• Explains its progress throughout the task
• Presents the generated changes for review before you accept them

Observations: Cursor

Cursor organizes the application into dedicated modules for the data model, Markdown serialization, storage, and CLI, and generates a corresponding test suite.

The generated project structure is shown below:

Cursor presents its changes as reviewable diffs and groups them into a single review session. Open it with the Review button to inspect the implementation across every modified file from one place.

The animation below shows Cursor building the application:

After finishing the task, Cursor keeps the changes available in that review session, so you can revisit them before you move on.

Observations: GitHub Copilot

GitHub Copilot also organizes the application into dedicated modules for the data model, Markdown serialization, storage, and CLI, and generates a corresponding test suite.

The generated project structure is shown below:

Copilot reports its progress in the chat as it works, listing the files it creates and edits, and then summarizing the generated modules once the implementation is complete.

The animation below shows Copilot building the application:

To review the implementation, you open the modified files individually, since Copilot doesn’t provide a dedicated review session like Cursor.

Both editors produce a working, similarly organized implementation from the same prompt using the same model. The exact project structure and test coverage may vary between runs, but the clearest difference is in their review workflows.

Cursor collects its edits in a single review session, so you can inspect the proposed changes before applying or discarding them. Copilot reports its progress in the chat and applies changes directly to your files as it works. You then inspect the completed implementation in the editor before keeping or undoing the edits.

To see that difference in motion, replay the same agent task in both editors below and watch exactly when each edit reaches the files on disk:

In Cursor, the edits stay staged in the review session until you apply them, while Copilot’s edits are already on disk by the time the agent finishes.

Cursor: Predicting Edits With Tab

Cursor Tab predicts code as you type and can also identify related edits elsewhere in your project. When a change affects multiple files, pressing Tab jumps you to each suggested edit one at a time.

Locate the Note dataclass and start adding a new updated_at field. As you write the declaration, Cursor suggests the remaining code, including the inferred type annotation and default value. Press Tab to accept it:

Notice that Cursor completes the declaration from the surrounding context rather than from only the text immediately before your cursor. In this example, it infers that the new field should follow the same pattern as the existing timestamp field.

Next, rename the search_notes() method. After you update the method declaration, Cursor Tab automatically suggests updates for the remaining references throughout the project, and you can press Tab again to jump to each location:

Cursor presents one suggested edit at a time, so you can review each one before you accept it. This keeps you in control and eliminates the repetitive work of tracking down each call site yourself.

GitHub Copilot: Predicting Edits With Tab

GitHub Copilot predicts code as you type and extends those predictions with Next Edit Suggestions (NES).

Locate the Note dataclass and start adding a new updated_at field. As you write the declaration, GitHub Copilot suggests the remaining code, including the inferred type annotation and default value. Press Tab to accept it:

Like Cursor, GitHub Copilot uses the surrounding code as context to predict the rest of the declaration.

Next, rename the search_notes() method. After you update the method declaration, GitHub Copilot displays an indicator in the editor margin to show that an NES is available. Press Tab to move to the suggested edit, and then press Tab again to accept it. Continue until you’ve applied the remaining suggestions:

Like Cursor Tab, GitHub Copilot’s NES guides you through related edits with the Tab key instead of applying every change automatically.

Both editors extend code completion beyond the current edit by predicting related changes elsewhere in the project and guiding you through each one.

Cursor: Planning and Project Guidance

Press Shift+Tab until Plan mode is selected, then submit the following prompt:

Create a plan to add support for archiving notes.

- Archived notes shouldn't appear in normal searches or listings.
- Add an `--include-archived` option to the search and list commands
  so archived notes can be included when needed.
- Integrate the feature cleanly with the existing application without
  introducing duplicate logic.

Rather than modifying the project immediately, Cursor generates an implementation plan and saves it as an editable Markdown file. Review the plan, then approve it to begin the implementation:

Reviewing the plan before execution gives you a chance to catch incorrect assumptions, refine the approach, or adjust the scope before Cursor writes anything to disk.

Project Rules

Project rules let you define your project’s conventions once, so future implementations automatically follow them.

Project rules are stored as version-controlled .mdc files inside the .cursor/rules/ directory. Each rule contains YAML frontmatter that controls when the rule applies, followed by the instructions you want Cursor to follow.

To create a project rule, open Cursor Settings and select Customize from the sidebar. Click the Rules tab, confirm that your active project folder appears in the scope selector, and click + New Rule. Give the rule a name, then add the following instructions:

Language: Markdown Text Filename: .cursor/rules/markdown-note-manager-rules.mdc

---
globs: "**/*.py"
alwaysApply: false
---
# Instructions

- Use type hints for all functions, return values, and dataclass fields.
- Parse YAML frontmatter with `yaml.safe_load()` rather than manually.
- Use `pathlib.Path` for all file and directory operations.
- Use parameterized SQL queries for every SQLite operation.
- Represent notes as dataclasses rather than dictionaries.

After you save the rule, Cursor writes it to the project’s .cursor/rules/ directory:

The globs field limits the rule to Python files, while alwaysApply: false lets Cursor include the rule only when it determines the instructions are relevant.

Cursor also supports rules that always apply, are selected manually, or are attached automatically through file patterns. These rule types let you organize project guidance into multiple focused rule files rather than maintain a single large instruction document.

Alternatively, type /create-rule in the Agent input and describe the rule you want. You can also press Ctrl+Shift+P or Cmd+Shift+P, search for New Cursor Rule, and select it to open the Agent panel with the command prefilled.

GitHub Copilot: Planning and Project Guidance

Select Plan from the mode selector in the GitHub Copilot Chat view, then submit the same prompt:

Create a plan to add support for archiving notes.

- Archived notes shouldn't appear in normal searches or listings.
- Add an `--include-archived` option to the search and list commands
  so archived notes can be included when needed.
- Integrate the feature cleanly with the existing application without
  introducing duplicate logic.

Like Cursor, GitHub Copilot generates an implementation plan before making changes:

GitHub Copilot writes the proposed plan to a plan.md file that you can review and edit before handing the task over to the agent.

Repository Custom Instructions

Like Cursor’s project rules, repository custom instructions provide persistent guidance for future implementations.

Unlike Cursor, GitHub Copilot doesn’t offer a dedicated interface for creating them. Instead, create a .github/copilot-instructions.md file at the root of your repository and add instructions such as the following:

Language: Markdown Text Filename: .github/copilot-instructions.md

# Repository Instructions

- Use type hints for all functions, return values, and dataclass fields.
- Parse YAML frontmatter with `yaml.safe_load()` rather than manually.
- Use `pathlib.Path` for all file and directory operations.
- Use parameterized SQL queries for every SQLite operation.
- Represent notes as dataclasses rather than dictionaries.

Once you save the file, your project structure should look like the one shown below:

Repository instructions apply everywhere by default and become part of the project’s version-controlled files.

For larger projects, you can create path-specific instruction files with applyTo YAML frontmatter to target selected files or directories, allowing different parts of the project to follow different conventions.

Both editors let you review and refine a proposed implementation before any files change, and both provide persistent guidance for future tasks.

Cursor manages that guidance through project rules, using YAML frontmatter to control when individual rules apply. GitHub Copilot manages it through repository custom instructions, using repository-wide or path-specific Markdown instruction files to define project conventions.

Remove ads

Cursor: Reviewing Code and Pull Requests

Locate the parameterized SQL query in the search_notes() method. The example below shows the code generated during this walkthrough. Use it as a reference to modify your own implementation.

The original implementation uses placeholders to keep the search value separate from the SQL statement:

def search_notes(self, query: str) -> list[Note]:
    """
    Return notes whose title or body contains `query` (case-insensitive).
    """
    pattern = f"%{query}%"
    rows = self._conn.execute(
        """
        SELECT * FROM notes
        WHERE title LIKE ? COLLATE NOCASE
           OR body LIKE ? COLLATE NOCASE
        ORDER BY created_at DESC
        """,
        (pattern, pattern),
    ).fetchall()
    return [self._row_to_note(row) for row in rows]

Modify the query so it interpolates the search value directly into the SQL statement, as shown below:

def search_notes(self, query: str) -> list[Note]:
    """
    Return notes whose title or body contains `query` (case-insensitive).
    """
    rows = self._conn.execute(
        f"""
        SELECT * FROM notes
        WHERE title LIKE '%{query}%' COLLATE NOCASE
           OR body LIKE '%{query}%' COLLATE NOCASE
        ORDER BY created_at DESC
        """
    ).fetchall()
    return [self._row_to_note(row) for row in rows]

This change introduces a SQL injection vulnerability because user input becomes part of the query text instead of a bound parameter.

Switch to Ask mode and submit the following prompt:

Review the database layer for correctness, SQL safety,
and general code quality.
Identify any issues and suggest improvements without modifying the code.

Cursor analyzes the affected file and summarizes the issues it finds:

It correctly identifies the interpolated SQL query as vulnerable to SQL injection and recommends restoring a parameterized query.

Next, review the pending changes by entering the following command into the chat:

/review

The /review command analyzes your recent changes, highlighting the issues they introduce:

Unlike Ask mode, /review focuses specifically on your committed or uncommitted changes, pointing to the vulnerable lines and explaining why they need fixing.

If you’re collaborating through GitHub, Cursor also provides Bugbot for pull request reviews. It automatically analyzes pull requests, leaves inline comments for potential issues, and can generate tested fixes through Bugbot Autofix.

Bugbot uses a usage-based pricing model, with costs depending on the size and complexity of the diff it reviews.

GitHub Copilot: Reviewing Code and Pull Requests

Copilot generated its own version of the search_notes() method, so the code below differs slightly from the one in the Cursor project. Match the change to whatever your project produced.

The original implementation uses placeholders to separate the search value from the SQL statement:

def search_notes(self, query: str) -> list[Note]:
    """Return notes whose title or body contains the given query text."""
    rows = self._conn.execute(
        """
        SELECT * FROM notes
        WHERE title LIKE ? OR body LIKE ?
        ORDER BY created_at
        """,
        (f"%{query}%", f"%{query}%"),
    ).fetchall()
    return [self._row_to_note(row) for row in rows]

Modify the query so it interpolates the search value directly into the SQL statement, as shown below:

def search_notes(self, query: str) -> list[Note]:
    """Return notes whose title or body contains the given query text."""
    rows = self._conn.execute(
        f"""
        SELECT * FROM notes
        WHERE title LIKE '%{query}%'
           OR body LIKE '%{query}%'
        ORDER BY created_at
        """
    ).fetchall()
    return [self._row_to_note(row) for row in rows]

This introduces the same SQL injection vulnerability into the GitHub Copilot project.

Open the Source Control view using Ctrl+Shift+G, then hover over the Changes header to reveal the Code Review button, whose tooltip reads Code Review - Uncommitted Changes. Select it to check your uncommitted changes:

GitHub Copilot analyzes the pending changes and surfaces its findings directly in the editor. It flags the SQL injection vulnerability and adds inline review comments that you can inspect and apply before committing your changes.

GitHub Copilot can also review a specific section of code instead of your entire working tree. Select the code you want to review, then either right-click and choose Review, or press Ctrl+Shift+P or Cmd+Shift+P, search for Chat: Review, and run the command:

Instead of reviewing every pending change, GitHub Copilot analyzes only the selected code and returns inline comments for that region. This keeps the feedback focused when only one part of your work is ready for review.

GitHub Copilot also supports pull request reviews on GitHub. It can analyze the proposed changes, leave inline review comments where it detects potential issues, and suggest improvements before the pull request is merged.

Both editors review your uncommitted changes and your pull requests, catching the SQL injection you introduced. They differ in how the review is billed. Cursor charges for Bugbot by usage on top of your subscription, while GitHub Copilot handles local, selection-level, and pull request reviews within the subscription you already have.