I have been using Cursor heavily for the past few months for building report exports, caching layers, workflows, POS features, storefront fixes. Stuff that actually has to work correctly, not just look good in a demo.
And yes, it made me faster. But not in the way most people talk about.
This is not a 10x developer post. It is just what I actually noticed, the habits that helped, the mistakes I kept making early on and what I would tell someone who is trying to get real value out of AI coding tools instead of just feeling productive.
Stop describing the problem. Paste the actual error.
This was my biggest early mistake. I would write something like “the report download is slow, can you fix it?” and get a lot of generic advice about database indexing and pagination.
The moment I started pasting the actual route, the actual error, the actual behaviour, everything changed.
“Getting a timeout on the download report at admin/reports/stock-summary”
That one line gives the AI something to work with. It can trace the route, find the controller, look at the export logic and give you something specific.
If you are vague, you get a generic output. If you are precise, you get a real solution.
Before you ship, ask what else can break
This has always been part of my AI assisted development.
I ask this every single time after getting a fix:
“What is the impact of this change? Which pages or flows should I test before I push this live?”
It takes maybe 10 seconds to type but regularly saves me from production bugs I wouldn’t have caught in manual testing.
Backend code is connected. A change to a report export controller might touch five report pages. A model change might affect three different admin views. AI is actually pretty good at tracing this, if you think to ask.
Write out what you want before asking for code
This one felt annoying when I first started doing it, but it is probably the highest-leverage thing on this list.
When I was building a caching layer for report downloads, instead of saying “add caching to the payment report download,” I wrote out the full expected behavior:
- Month + year selector on the left of the download button, button disabled unless selected
- Keep the existing view filters exactly as they are, this is only for the download
- Build a deterministic cache key from the report type, parameters and the selected month
- Check if a cached CSV already exists in private object storage
- Stream it back directly if it is there
- If not, generate it, upload it privately and then stream it back
- Never expose a public URL
That prompt took me maybe 3 minutes to write. The output needed almost no correction. Compare that to my earlier approach for example writing a vague prompt, getting something close but wrong, spending 20 minutes in back-and-forth trying to get it where I wanted.
The more clearly you define what you want before asking, the less time you spend correcting after.
Read the plan. Correct it early.
Most AI coding tools will show you what they are about to do before they do it. Read it.
When I was building a date-range GST report download, the AI was heading toward using some snapshot columns I had added in a recent migration. It was a good interpretation because those columns exist, they have the right data. But for that feature, pulling from product details directly was the right call.
I stopped it:
“Don’t use those columns. Pull it from product details.”
That is a 10 sec correction. If I had let it keep going, I would have spent an hour fixing code that was built on the wrong foundation.
The lesson: you know your system better than the AI does. When you see it heading somewhere that does not feel right, trust that instinct and redirect immediately. Don’t wait until you are looking at a full implementation that you have to throw away.
“Code exists” is not the same as “feature works”
After I implemented the S3 caching for reports, I asked a question I am glad I thought to ask:
“How do I verify whether the report was served from cache or generated fresh?”
Turns out the answer was a log check, you look for a specific marker in the output that tells you which path was taken. Without asking, I would have shipped it, assumed it was working and had no idea if the cache was ever actually being hit.
For any feature with a correctness requirement like caching, data integrity, compliance calculations, you need to figure out how you will observe the behaviour before you call it done. AI can help you design that observability if you ask for it.
One line of code can be a big architectural decision
Adding .withTrashed() to a model relationship is one line:
public function product()
{
return $this->belongsTo(Product::class, 'product_id', 'id')->withTrashed();
}But the decision behind it is: historical orders need to keep resolving their product data even if that product gets soft-deleted later.
Without this, the moment someone archives a discontinued product, every historical order and invoice referencing that product starts showing gaps. Your financial reports become unreliable.
AI wrote that line in seconds. But the question “what happens to this data when the related record is deleted?” is one I had to ask myself. AI does not automatically think about your data’s relationship with time. You do.
Whenever you are working on anything that touches orders, invoices, reports or audit history, ask that question explicitly. It is easy to miss and expensive to fix later.
Don’t stop at “the frontend is broken”
A real example: the browser was throwing this error on the storefront:
Refused to execute script from '/js/storefront.js' because its MIME type
('text/html') is not executable, and strict MIME type checking is enabled.The error is in the browser. But the cause was somewhere in the build pipeline, the server was returning an HTML fallback instead of the actual JS file. That is a backend/deployment issue showing up as a frontend error.
I have seen engineers stop at “the JS isn’t loading” and file it as a frontend bug without digging into why. Pasting the exact error into Cursor and following the diagnosis wherever it led – build config, asset paths, server routing – got it fixed faster than trying to read the deployment docs from scratch.
When something breaks in production, follow the actual evidence. It will take you somewhere specific. That is almost always faster than trying to guess which layer the problem lives in.
“Another” is doing more work than you think
This is a small one but it has caught me before.
When I wanted to add a second download option to a report page → a date-range download alongside the existing one → I was careful to say “add another download button” rather than “update the download button.”
That one word made the difference between an additive change and the AI rewriting the existing download behaviour. Both interpretations are valid from the AI’s perspective. Only one of them is what you actually want.
When you need to extend something without touching what is already working, say that explicitly. “Another,” “alongside,” “without changing the existing”, words like these in your prompt save you from accidental changes.
What actually got faster
Not the thinking. Not the architectural decisions. Not the verification.
What got faster was the time between “I have a problem” and “I understand what is happening.” Used to take an hour of careful reading to trace a bug through an unfamiliar part of the codebase. Now it takes minutes if I give the AI the right context.
That freed-up time went somewhere useful → thinking about what can break, checking if the feature actually works, catching wrong directions early.
That is the real gain. Not AI doing the work. AI doing the exploration faster, so I spend my time on the parts that actually need judgment.