gluntyCursor Hacks: The Operator Deck
Stop babysitting the AI and start directing it - you will ship faster because you own every line, not in spite of it.
- 01
It is a junior, not a senior
Cursor is a fast, tireless engineer with no taste and no memory of what you decided last week. It moves at ten times your speed and has zero judgment about what should be built. That gap is your job. You are the lead. It is the intern.
Before you prompt, decide: am I asking it to think, or asking it to type? It is only good at one of those. - 02
It only knows what you show it
The model is not reading your mind or your whole repo. It reasons from the files, the error, and the goal you put in front of it. Vague context in, plausible nonsense out. Feed it the real stuff and the quality jumps immediately.
Paste three things every time: the file that is broken, the exact error, and the outcome you want. - 03
Fix it is not a spec
Fix it lets the model guess what fixed means. Describe the behavior you want and the constraints it must respect - what should happen, what must not change, what pattern to follow. You are writing a ticket for someone who takes everything literally.
Try: 'Make X do Y. Do not touch Z. Match the existing pattern in this file.' - 04
It lies with a straight face
Cursor will hand you confident, clean-looking code that is quietly wrong - a wrong assumption, a hallucinated function, a subtle off-by-one. It has no idea it is lying. The polish is not proof. The diff is where the truth lives.
Never accept a change you have not read line by line. The whole diff, not the headline. - 05
Small asks, clean diffs
Ask it to rewrite the whole module and it drifts - renaming things, dropping edge cases, inventing scope you never wanted. Small scoped changes stay reviewable and stay correct. Big asks feel powerful and quietly wreck your afternoon.
One change per prompt. If you cannot review it in a minute, the ask was too big. - 06
Write the rules down once
You should not be re-explaining your conventions every session. A project rules or instructions file (check what your version calls it) pins your stack, style, and hard nos so the model starts every chat already knowing the house rules.
Add one rule after every session where it got your conventions wrong. Let the file grow teeth. - 07
Make it explain its own change
Ask the model why it did what it did, before you ship. Reading its reasoning back is how you catch the bad assumption while it is still cheap. If the explanation is hand-wavy or contradicts the code, you just found the bug for free.
Ask: 'Walk me through what this change does and why, line by line.' - 08
When it loops, break the loop
It will confidently try the same broken fix three times in a row. Stop feeding it try again. That is your fault, not its. Give it the actual error text and a list of what you already ruled out, and the loop usually snaps.
'Here is the real error. I already tried A and B, they did not work. What else could cause this?' - 09
Speed on the boring, judgment on the shape
Let it grind out the glue code, the boilerplate, the tedious refactor - things where being fast beats being clever. Keep the architecture, the data model, the tradeoffs for yourself. Never outsource the decisions you would be fired for getting wrong.
If a choice will be expensive to reverse, you make it. Let the AI fill in the cheap parts. - 10
You cannot review what you cannot read
If you do not understand the code it wrote, you are not reviewing - you are gambling. The rule is simple: do not accept anything you could not defend in a code review to a skeptical human. Not understanding it is not a shortcut, it is the debt.
Hit a block you cannot follow? Ask it to explain, or make it simpler, until you can. - 11
Tests are how you trust the speed
Moving fast only works if something catches the regressions. Have Cursor write the tests too - then you read them, because a model will happily write a test that asserts the bug. Real tests are the seatbelt that lets you keep the pace up.
For every feature it builds, ask for the tests, then verify each one actually checks the real behavior. - 12
Accept is a signature
The moment you click accept, that code is yours. Not the model's, not Cursor's - yours. It ships under your name and breaks in your on-call rotation. Treat the accept button like signing off on a pull request, because that is exactly what it is.
Before accepting, ask yourself one question: would I put my name on this in review? - 13
The reviewer wins
Two people use the same tool. One reads every diff and understands what ships. The other accepts everything and ships bugs at scale, faster than ever. Same AI, opposite outcome. The tool did not decide that - the operator did. Be the reviewer.
Slow down at the diff, speed up everywhere else. That trade is the whole game.
Reading is not doing. Wire every node - do it with the tool, log the proof, mark it done. Finish them all to seal DECK COMPLETE (+10).
DECK COMPLETE - +10 banked. Grab another and keep ranking up.