Most teams install Cursor, watch it autocomplete a function, feel a small thrill, and then quietly go back to working the way they always did.
Six weeks later someone asks whether the AI tooling was worth it. Nobody has a clear answer. The speed gains that looked obvious in the demo never showed up in the sprint velocity.
The problem is almost never the tool. It is that Cursor was bolted onto an unchanged workflow. Used as a faster autocomplete, it gives you a faster autocomplete. Used as part of a deliberate system, it changes how much a small senior team can ship. We deliver 40 to 60 per cent faster than our previous baseline, and Cursor is a real part of that, but only because of how it is wired in.
Here is the actual setup we run on production projects.
Autocomplete Is the Least Interesting Thing It Does
If your mental model of Cursor is "GitHub Copilot with a nicer sidebar", you will underuse it by a wide margin.
The value is not in finishing your line of code. It is in operating over your whole codebase with context. Asking it to refactor a pattern across fourteen files. Generating a full test suite from a spec. Explaining a gnarly module a client handed you with no documentation. Making a targeted change that touches the API layer, the types, and the component in one pass.
Once you start using it for multi-file work, the review burden shifts. You are no longer reading one suggested line. You are reviewing a diff the AI produced across your project. That changes the discipline you need, which is the rest of this post.
Rules Files Are Not Optional
The single highest-leverage thing we do is maintain a rules file in every repository. This is the difference between Cursor guessing your conventions and Cursor knowing them.
Without rules, the AI defaults to the average of everything it has seen. Average is generic. Average uses a different state pattern than the rest of your app, imports a library you deliberately avoid, and writes tests in a style your team abandoned a year ago.
Our rules file states the stack explicitly, the folder structure, the state management approach, the naming conventions, the libraries we use and the ones we have banned, and the testing framework with an example test in our house style. We keep it short and specific. A rules file that tries to encode every preference becomes noise the model ignores. A rules file that nails the ten decisions that actually matter gets followed.
When we onboard a codebase from another team, writing the rules file is one of the first things we do. It doubles as documentation for the humans.
Context Is Something You Manage, Not Something You Hope For
The quality of what Cursor produces is downstream of the context it has. Most disappointing output is a context problem wearing a capability costume.
We are deliberate about what the model sees. For a focused change, we point it at the specific files and let it work with a tight scope. For a feature that spans layers, we give it the type definitions, the relevant API route, and one existing component that follows the pattern we want mirrored. The example matters more than the instruction. Show the model one component built the right way and it will match it far more reliably than any description.
We also keep sessions scoped. A long, wandering chat that started as a bug fix and drifted into a refactor accumulates contradictory context and the output degrades. When the task changes, we start fresh. Cheap habit, large payoff.
Where We Deliberately Turn It Off
This is the part most AI-tooling advocates skip, and it is the part that keeps our quality up.
We do not let AI generate anything security-sensitive without a senior developer writing or rewriting it by hand. Authentication flows, permission checks, anything touching payment or personal data, cryptographic code. The model produces plausible security code, and plausible is exactly the failure mode you cannot afford here. Plausible-but-wrong auth passes a casual read and fails in production.
We also switch it off for architectural decisions. The AI is excellent at executing a pattern and poor at choosing which pattern the system should use in the first place. Deciding how a new service should be structured, where a boundary should sit, what the data model should be. Those are human decisions made deliberately, and then the AI helps execute them fast.
Knowing where the tool stops being an asset is what separates a team that ships fast from a team that ships fast and breaks things. We wrote more about that boundary in Is AI-Generated Code Production Ready.
Review Gets Harder, Not Easier
Here is the uncomfortable truth about AI-assisted development. It shifts effort from writing to reviewing, and if your review process is weak, the AI amplifies the weakness.
When a developer writes code by hand, they build a mental model as they go. They know why each line exists. When the AI writes it, that model does not form automatically. It is easy to accept a diff that looks right, compiles, and passes the tests, without truly understanding it. That is how subtle bugs and quiet inconsistencies enter a codebase.
So our rule is simple and non-negotiable. You own every line you commit, regardless of who or what wrote it. If you cannot explain why a piece of AI-generated code works, you do not merge it. You read it until you can, or you rewrite it. Our review process treats AI-authored code with more scrutiny, not less, precisely because it did not pass through a human mind on the way in. Our full approach lives in The Code Review Process We Run on Every Project.
A Concrete Pass Through a Feature
To make this tangible, here is roughly how a mid-sized feature moves through our workflow.
A senior developer designs the approach first. Data model, API surface, component structure. This is human work and it happens before the AI touches anything. Then we set up context: the types, the relevant existing patterns, the rules file already in the repo. The AI generates a first pass at the API route and the types. The developer reviews it closely, corrects the parts that drifted, and commits with understanding. The AI generates the test suite from the spec, which is one of its genuinely strong uses, and the developer checks the assertions are meaningful rather than tautological. The UI component gets built with AI assistance, mirroring the example component we pointed it at. Final review reads the whole diff as if a junior developer wrote it, because in terms of accountability that is exactly the standard.
The speed comes from compressing the mechanical middle. The design and the review stay human, and stay rigorous.
The Prompts That Actually Work
Vague prompts produce vague code. The prompts that earn their keep are specific about the outcome and rich in context.
"Add error handling" gets you generic try-catch noise. "Add error handling to this route that returns our standard API error shape, logs to our logger, and distinguishes a validation failure from a server error" gets you something you can almost ship. The difference is that the second prompt encodes the decisions. We keep a small library of prompt patterns for common tasks, which we cover in The AI Code Generation Prompts We Actually Use.
The Speed Gains Are Real, But Not Where People Expect
When we say we deliver 40 to 60 per cent faster, people assume the saving comes from the AI writing code quickly. That is part of it, but it is not the biggest part.
The larger gains come from the tasks around the code. Generating a thorough test suite that would have taken a developer an hour now takes minutes, and those tests are often more complete than a tired human would have written at the end of a long day. Understanding an unfamiliar codebase, the kind of legacy project a client hands over with no documentation, goes from days of reading to hours of asking targeted questions. Boilerplate that used to be a mechanical slog gets generated and reviewed rather than typed. Refactoring a pattern across an entire codebase, historically a tedious and error-prone chore, becomes a scoped operation with a reviewable diff.
None of these are the glamorous "AI writes the feature" scenario, and that is exactly the point. The reliable, repeatable speed comes from compressing the surrounding work, the tests, the comprehension, the refactors, the boilerplate, while keeping the genuinely hard parts, the architecture and the review, firmly human. A team that promises speed by having the AI replace senior thinking is selling you risk. A team that gets speed by having senior engineers spend less time on mechanical work is selling you leverage. We break down the honest numbers in AI Development Timeline and Budget.
What This Means If You Are Evaluating an AI-Leveraged Team
If you are a founder or an agency owner weighing up a development partner who claims AI-powered delivery, the questions worth asking are not about which tools they use. Everyone uses the same tools now.
Ask how they handle review of AI-generated code. Ask what they refuse to let the AI write. Ask whether senior developers design the architecture before the AI executes it. A team that treats Cursor as a way to skip senior engineering is a team that will hand you plausible code with subtle problems. A team that treats it as a way to let senior engineers move faster is a team that ships more, sooner, without lowering the bar.
The tool is the same for everyone. The workflow around it is the whole game.