Cursor vs Copilot vs Windsurf: How Different AI Agents Write Code from the Same Instructions

Recently, I demonstrated how to accelerate the development of the admin panel using Admiral, a React-based back-office framework developed by the dev.family team. Explore it on GitHub: https://github.com/dev-family/admiral.    

Initially, I used Cursor rules, which are plain-text instructions that AI agents can interpret and convert into actual code. However, I then realized that this approach isn't exclusive to Cursor. These rules are just .md files – essentially prompts – that you can read or reuse across other AI tools, such as GitHub Copilot, Windsurf, Replit, Zed, Continue, and more. 

I decided to run an experiment to test how well three tools – Cursor, Copilot, and Windsurf – handle the same set of admin panel rules. My goal? To adapt the Cursor-based rule set for each platform and see if I could get similar results.

To start, I compiled a table that breaks down the key features of each tool, including rule types, storage location, activation modes, and length limits.

Each tool has its own level of rule application. Here's how they work:

• Project-wide rules apply to the entire codebase within a specific project;
• Project-local rules also work within the same project but can be scoped to specific files or directories;
• Global rules are available across all projects where the tool is installed.

👉 In Copilot, you can define one or more project-wide rule files or use glob patterns to target specific files or folders. However, Cursor and Windsurf offer more: they support global rules that apply across all projects in your IDE and allow rules to be triggered by direct mentions.

As a result, Copilot offers fewer options compared to its competitors when it comes to rule flexibility and activation.

This refers to where each tool stores its rule files, which is usually in a dedicated folder or a specific file in the root of the repository. Ideally, there would be a unified structure compatible with different AI tools. But in practice, each tool uses its own format. However, Windsurf supports importing rules from the .cursor directory if it’s already present in the project.

This refers to the ability to place rule files in subdirectories, which is a particularly useful feature for monorepos because different parts of a project may require different sets of instructions.

While Copilot doesn't directly support nested rule files, it lets you configure the context in which a rule applies, such as using glob patterns.

[object HTMLPreElement]

All three tools allow you to apply multiple rules simultaneously, which is a key feature for complex projects that require different types of logic or constraints.

Each tool has its own methods for determining when and where a rule should apply:

• Mention-based – the rule is triggered via direct mention or reference;
• Persistent – the rule is always active, with no additional conditions;
• Glob pattern – the rule only applies to files that match a specified pattern;
• Agent decision — the AI determines whether to apply the rule based on its own internal logic.

Each tool may have recommendations or limits for rule length. These constraints can affect performance, usability, and the number of tokens consumed, which impacts the tool’s cost and efficiency.

We also explored referencing one rule inside another. This could be helpful when handling certain logic variations conditionally. For instance, one rule could outline the general process for creating a page while delegating type-specific logic to distinct rules.

Let's create two simple example rules to test this concept.

Now, let's move on to the fun part: testing how well each tool handles our custom instructions for generating CRUD structures in projects built with the Admiral library.

We’ll add the rule to the appropriate location so the tool can recognize it, and then try using it in practice.

The rule expects a list of seven input points, which I’ve prepared in advance:

1. clients.

2. clients.

3. id, full_name, phone, email, created_at, actions.

4. surname, phone, first_name, email, patronymic, gender, birthday, previous_surname, password, uuid_1c, deleted_at, document_type, document_number, document_expiry_date, birth_address, settings_is_notify_upcoming_payments.

The rule itself contains all the necessary instructions. It was designed so that simply mentioning it in the chat would prompt the agent to request all the necessary information. Let's try that and see if the agent reads the rule file and provides a brief summary.