Testing Cursor Composer: The AI Coding Model Built for Speed

Cursor released their new AI coding model (Composer) last week. The main pitch is speed - turning natural language into working code faster than before. I wanted to see what it's actually good at, so I spent some time putting it through different scenarios.

Cursor claims this model to be a competitive AI close to the most frontier models in intelligence, which is why I wanted to test it out, it's the first time we have a model that can compete in both speed and intelligence.

I tested Composer across a few key areas: executing tasks of varying complexity, searching codebases and documentation, and planning. These are common software engineering tasks that developers face daily. I'll walk through what worked and what didn't.

Simple Coding Tasks: Building a REST API with Cursor#

I started with a straightforward prompt to build a REST API in Rust with CRUD operations:

Prompt for building a REST API

It executed the entire task in 20 seconds, writing the code and running cargo check to verify everything compiled without any errors.

First time trying this, I didn't expect it to be this fast! I mean I expected it to be fast, but not this fast 🙂.

Completion summary

Gave Composer a broad instruction and let it choose whatever framework it thinks best. It chose Axum obviously as every model seems to be using it these days.

The code compiles without warnings and the server app is ready to run on port 3000.

For developers doing this 3 years ago, it would mean hours of work, especially if you were new to Rust. Twenty seconds from natural language instructions to working code without any compiler errors is bonkers. No runtime errors as well.

I tested all the endpoints - creating tasks, listing them, getting by ID, updating, and deleting. Everything works exactly as it should.

Okay, this task was very simple: It was a completely new repository with no existing code, no complexity to make difficult decisions, we'll try something a little bit harder in the last section.

Codebase Search: Finding Relevant Files with Cursor's AI#

Before planning my tasks when developing features, sometimes I do a codebase search using a fast model to find the relevant file paths for a specific task that needs to be implemented. Then, I'll use the results to plan out the task using a more intelligent model, this helps in speeding things up and saving tokens. So, let's try and do exactly that with Cursor's Composer.

I tested this with a real GitHub issue from the shuttle-hq/shuttle repository. The task was to add a --quiet flag to suppress non-error output from the shuttle run command. I wanted to see how fast Cursor's Composer can find all the relevant files in the codebase.

Cursor's model search request for GitHub issue

Composer scanned the entire codebase and returned results in 15 seconds:

AI search results

Everything was spot on, and only in 15 seconds. Crazy fast and crazy good.

From Search to Strategy: Creating an Implementation Roadmap#

Creating plans is a common process when developing software. Let's see if Composer can take those search results and create an implementation plan? I started a fresh chat and fed it the issue description along with all the file paths and locations it had just found.

The model's planning instruction

Composer generated a well-structured plan:

Implementation plan

The plan included an overview, clear implementation steps, specific file locations with line numbers, and code examples showing exactly what needs to be added. It broke down the task into logical steps, pretty much like any other AI model would do.

The structure looks solid, but the real test is execution and I don't really know if the approach is actually good or not. So, let's see if Composer can complete the task.

Complex Tasks: Implementing the Solution#

Opened a new chat and fed Composer the implementation steps and asked it to implement the changes. It completed the task in 40 seconds, making changes across multiple files.

Implementation in args.rs

But speed doesn't matter if the code doesn't work. Time to review what it actually did.

The code review looked clean. Cursor's reviewer agent didn't flag any issues either. The implementation added the quiet field to the RunArgs struct, properly wrapped the print statements, and compiled without errors.

I created a new Shuttle project using the official Shuttle Axum template. Then, I verified the flag works as expected by running shuttle run without the flag:

shuttle run without --quiet flag

All the build logs, runtime startup messages, and info logs appear - the default behavior. Now with shuttle run --quiet:

shuttle run with --quiet flag

The build logs from cargo-shuttle disappeared. Only runtime logs remain visible. Exactly what the issue asked for - suppress non-error output from cargo-shuttle while keeping the runtime output.

Perfect. The implementation works.

Final Thoughts: Natural Language to Code at Speed#

After testing Composer across different scenarios, here's what I think about it:

Codebase search: Excellent. This is where Composer really excels. Fifteen seconds to scan an entire repository and find every relevant file with specific line numbers is incredibly useful.

Simple to medium tasks: Really good. The in-memory REST API took 20 seconds and worked perfectly. The GitHub issue implementation worked across multiple files in 40 seconds. For well-defined tasks with clear requirements, it can generate and deliver fast, working code.

Complex architectural decisions: I wouldn't trust it here. For tasks that require deep technical reasoning, evaluating tradeoffs, or making non-obvious choices, you want a more capable model like Sonnet 4.5.

The practical takeaway for software engineering is that Composer gives us an AI tool that's both fast and smart enough for real work. That's a useful combination. I can see developers using Composer every day - searching codebases, making config changes, implementing straightforward backend or frontend features. The kind of tasks where waiting 1min+ for a heavier model feels unnecessary.

It's not about replacing more intelligent models. It's about having the right tool for different jobs. For quick, well-scoped tasks, this approach gets you from natural language instructions to working code faster than anything else I've tried.

Conclusion: The Future of AI-Assisted Development#

Speed matters in modern software engineering and development work. Cursor's new AI coding assistant (Composer) proved it can handle everyday tasks - searching codebases, implementing features, fixing bugs - in seconds rather than minutes. It's not perfect for everything, but it doesn't need to be. Having a fast model that's reliable for common software development tasks changes how I think about using AI tools in my workflow.

Get started with our backend API template and let us know what you'll build with Composer:

shuttle init --template axum