Cursor, the most prominent AI-fueled IDE, has a rules feature. You can set project-based rules and global rules for how AI handles your requests. Here are my Ten commandments for Cursor.

The intention of these rules is to prevent some of the LLM's better intentions (pleasing the user) from producing bad consequences like complicated code, dead code, and infinite implementation loops.

10 Commandments

These instructions are written to give you (the LLM) a clearer picture of how to respond to my requests. I appreciate your help and know you are always trying to do the right thing for me.

1. Start with a test

Test driven development is not dead. Write a test first. Watch it fail. Get it passing. Then refactor to make it performant and beautiful. If the test fails more than twice, pause and ask is this test testing important functionality? If not remove the test. Next ask, is this testing difficulty an indication of a code smell? If so, resolve the smell and write a better test.

2. Keep it short

Classes should be single responsibility. They should expose only one or two public methods. Methods should be single responsibility and have testable interfaces.

3. Respect the Law of Demeter

Do not chain calls between objects in order to keep boundaries and responsibilities clear.

4. No meta programming or monkey patching

Never ever reach for meta programming or monkey patching. There is always a better way to solve the problem.

5. Favor the command pattern and service objects

The command pattern and service objects lend themselves to encapsulation. They are easier to reason about and change than many other design patterns.

6. Keep logic out of views

There should be almost no logic in the view layer. Anything more complicated than the simplest condition should be delegated to the commands and helper methods.

7. Keep logic out of controllers

There should be almost no logic in the controllers. Anything more complicated than the simplest condition should be delegated to service objects, commands and models.

8. Prefer logs to comments and comments to nothing

Debug level logging is a great way to codify an explanation of our systems. When debugging, add info level logs freely. Comments are helpful documentation, but have the danger of growing stale.

9. Avoid primitive obsessions

Do not unnecessarily reach for object primitives like hashes and arrays. It's often a better design decision to use higher level objects. The benefits are validation, encapsulation, and code readability.

10. YAGNI

You aren't going to need it. Do not build things that we do not need right now. If we follow the rest of the commandments, it should be easy to add new features and systems when the real need comes up.