Notes on building some rapid prototypes with Cursor AI

[UPDATE] - I am using Claude Code exclusively now (and testing Zed for an IDE). Please use the following with caution as it may be out of date and limted.

I’ve been using Cursor AI for a while now. I’ve had mixed luck with it. The biggest warning here is that everything I’ve done has been on proof of concept/green field projects.

It can do a lot. It types way faster than me and that’s really good for tedious things like CSS.

However, it also really needs execellent guardrails and someone paying VERY CLOSE attention.

• It’s excellence at a given language is defined by how much of the language it was able to ingest…and the quality of that code. This may seem obvious - that’s how LLMs work - but you can see it very clearly. Trying to have it help me with LISP in my Emacs/org mode setup is painful.
• I’ve found that mixing thinking and regular models is like smoking pot while studying for a test - keep in the same state of mind. Mixing thinking and regular doesn’t seem to work well for me.
• You have to make good use of rules.
• It gets cd happy and then gets completely lost.
• It doesn’t learn from mistakes (yet).
• It moves too fast…almost like it has to solve the immediate problem ONLY and forgets everything it’s built up to that point.

Tips & Tricks

1. Get some good global rules set up - there will be patterns you run into that are things we all experience, but also things that are unique to you and your approach. Codify those for it.
2. Tell it NOT to use cd or cd or `cd`
3. Have it use the tooling you prefer - like for Python, why would you use anything other that uv on a brand new project? Make those choices binding in the rules.
4. Tell it not to put secrets in files…always use a library/approach like dotenv
5. Have it always create a README and a gitignore that fits your project from standards
6. Have it build throwaway tools to help you understand the shape of your project. It doesn’t care if you just toss code…that’s liberating and you can get a feel for the edges of a project much faster by doing this.
7. Be prepared to throw it all away in 2-3 days and start over fresh with what you have learned. It’s still a short time cycle over all and each time you get better at it and better at understanding the problem you’re trying to solve.
8. I tend to struggle with being too verbose and I think it’s gotten me into more trouble. So I try to tell it to use a summary of what I say.
9. The LLMs tend to want to go more complex than simple. Bigger scope, than tighter scope. You have to coax it to resist that urge.

My Global Rules

Don't write the code at first — just write a fantastic, detailed implementation spec. Then, when I approve, implement the code perfectly.

Do not under any circumstance ever include env vars and especially sensitive keys in code that's committed and not in the .gitignore. Use a library/approach like dotenv.

Please always use `uv` for installing anything python and getting venv's running. Basically lean on uv before anything else.

Do NOT use `cd` unless I specifically mention it. Let's run ALL commands from project root with DIRECTORY refs.

Do NOT delete directories or run major git command changes without making a CLEAR and SHOUTY message with something like "=====DANGER=====" in it.

After every commit I make or every branch change, I need a copy of the entire root folder (hidden items and all), sent to /Users/$username/PARA/ARCHIVE/PoC_BACKUPS with a date/timestamp in the file name.

When I write something more than 300 characters, please take that prompt and your first reply and put them in a suitably named markdown file in the root of the project.