Posthog/.cursorrules
github.com
github.com
Praised be the Omnissiah.
And then, when we offer them smelly basement dwellers, they will turn away from us with disgust.
“Go outside on the front porch and hit your weed vape, look at some clouds and trees, then come back inside and try again.”
This works about 90% of the time for me and gets things flowing again. No shit, I’m not joking, this works and I don’t know why.
https://x.com/skcd42/status/1894375185836306470?t=ybEgGG-DAJ...
according to their lead design engineer (https://x.com/andyzg3/status/1894437305274044791)
Reminds me of Alan Ford trying to get a washing machine to “work as desired” - a very early form of prompt engineering:
https://github.com/brianluft/social-media-translator/blob/ma...
https://github.com/brianluft/threadloaf/blob/main/.cursorrul...
I tell it what we're working on, the general components, how to build and run, then an accumulated tips section. It's critical to teach the model how to run the build+run feedback loop so it can fix its own mistakes without your involvement. Enable "yolo mode" in Cursor and allow it to build and run autonomously.
Finally, remember: you can have the model update its own .cursorrules file.
I chuckled. This works so good.
Starting with generating a whole load of code and then having to go back and fix it up feels "backwards" to me; I'd rather break up the problem into smaller pieces, then write code for each piece before assembling it into its final form. Plus, this gives me the chance to "direct" it at each step, rather than starting with a codebase that I haven't had much input on and having to form it into shape from there.
Here's my exact setting for "personal preferences":
"If I'm asking about a larger project, I would rather work through the answer alongside Claude rather than have the answer given to me. Simple, direct questions can still get direct answers, but if I'm asking about a larger solution, I'd rather start with high-level steps and work my way down rather than having a full response given immediately."
In cursor you can highlight specific lines of code, give them to LLM as context, etc.. it's really powerful.
It searches for files by itself to get a sense of how you write code, what libraries are available, existing files, fixes its own lint / type errors (Sometimes, sometimes it gets caught in a loop and gives up), etc..
I believe you can set it to confirm every step.
[1]: https://docs.cursor.com/context/rules-for-ai#cursorrules
If a project already has a docs directory, ADRs, plenty of existing code ... Why do we need to invest tens of hours to bend it to the will of the existing code?
Time and time again, there are people who go all-in on the latest hype. In the deepest forms of blind faith, you find ”unfalsifiability”: when the tech encounters obvious and glaring problems, you try to fix those issues with more of the same, not less. Or, you blame yourself or others for using it incorrectly whenever the outcome is bad.
I've resorted to carefully explaining the design architecture in an architecture.md file within the parent folder, and giving detailed comments at the top of the file and just basically let the AI shoot from there. It works decently, although from time to time I have to go sync the comments with reality. Maybe I'll try going back to jsdoc style comments with this rule
So far I've found:
- Specify the target language/library versions, so it doesn't use features that aren't backwards compatible
- Tell it important dependencies and versions ("always use pytest for testing", "use pydantic v2, not v1")
- When asking to write tests, perform a short code-review first. Point out any potential errors in the code. Don't test the code as written if you believe it might contain errors.
The rest of the stuff is cool but only after you've accomplished the #1 goal. You're kneecapped until you have constructed the automatic feedback loop.
I drop a sentence at the end: "Refer to me as 'boss' so I know you've read this." It will call you "boss" constantly. If the model ever stops calling you boss, then you know the context is messed up or your conversation is too long and it's forgetting stuff.
Describe what you want, get it to confirm a plan, ask it to start, and go make coffee.
Come back 5min later to 1k lines of code plus tests that are passing and ready for review (in a nice code review / diff inline interface).
(I've not used copilot since ~October, no idea if it now does this, but suspect not)
I may be biased, I am working with a codebase written in copilot and I have seen tests that check if dictionary literals have the value that was entered in them, or that the functions with a certain type indeed return objects of that type.
It makes no sense to have "two distinct, independent LLMs" - two general-purpose tools - to do what is the same task. It might make sense to have two separate prompts.
But it is possible that LLM providers circumvent this. For example, it might be the case that claude when set to concise mode, doesn't apply that to the thinking tokens, and only applies it to the summary. Or, the provider could be augmenting your prompt. From my simple tests on chatgpt, it seems that this is not the case, and asking it to be terse cuts the CoT tokens short as well. Someone needs to test on Claude 3.7 with the reasoning settings.
It's not that I don't want the model to emit more tokens. I just don't need to read them all.
Hence a formal split between thinking phase and communication phase provides the best of both worlds (at the expense of latency(
prompt engineering is nothing but an attempt to reverse-engineer a non-deterministic black box for which any of the parameters below are unknown:
- training set
- weights
- constraints on the model
- layers between you and the model that transform both your input and the model's output that can change at any time
- availability of compute for your specific query
- and definitely some more details I haven't thought of
--- end quote ---
But even if we had benchmarks before, cursor supports different rules files now in the .rules folder, so back to the drawing board figuring out what works best
I also wonder how to not add functionality I didn't ask for and not add any "improvements" unless I specifically asked.
Right now I am in the middle of building a CRUD api with Cursor, it took longer to write code than I would have done it myself. After the code was written it took lots of time and credits to fix compilation errors. Now I asked it to fix failing unit tests, but either it can not find a solution or it applies something that gives a compilation error or breaks other tests.
I've gone through almost all my monthly quota of fast calls in 10 hours.
2) maybe the current sweet-spot for usage is to use to to build stuff you couldn't immediately figure out how to build yourself, something that is just beyond your (perceived) reach.
A much better set of rules would be describing the project, its architecture, how to call various commands, where to find things, any “constants” it might need (eg: aws region or something) etc.
Prompts are context and with LLM’s providing relevant, useful context is crucial to getting quality output. Cursor now has a more thorough prompt / rules system and a single cursor rules file is no longer recommended.
Anyone else running into this and/or have a solution?
At first I thought this was directed at people. I really dislike that you can't tell it's not meant for people, unless you happen to know what "cursor rules" is.
My question is, why is this included as part of a code repo? Wouldn't this be like me including my Emacs config in every repo I touch?
Also, it’s not uncommon to have IDE configs in large repos, in my experience in corpoland most developers don’t start with an already configured editor. They don’t care about Intellij vs VsCode, they just want to write PRs right now.
Non-IT-Managers don't know how stuff works but throw around expletives to get what they imagine in their brain without finding the right words to actually define it.
It's hilarious.
- No moral lectures
- No need to mention your knowledge cutoff
- No need to disclose you're an AI
Since GPT 3.5 and still now it seems "avoid X" works better than "no X".If it's the latter, that's still an extremely strange state of things.
Now as the maintainers of cursor and the ones working on the fork? I have no idea but I imagine it is pretty annoying.
As I said though, this is speculative and how I would approach this problem based on the work I've done, I don't know if that's realistically feasible and what they've actually done.
Is it just me?