10 rules I use so Cursor, Claude Code, or ChatGPT deliver quality code
Updated on June 26, 2026
This afternoon I found my first Cursor invoice, dated September 2024. It made me realize that more than a year has passed since I gave myself over to the future that is coming and started fully integrating AI into my day-to-day work. Before that I had used ChatGPT to ask questions about a function that was not working properly, understand an error in the console, or generate tests and mock data. Pretty minor stuff compared with what I do now.
But for me, at that moment I really committed to AI because I was no longer using it only as support; it started becoming a core part of my work. I have to admit that nowadays I write little code, but I am unquestionably 10 times more productive. To get to that point I had to learn how to use this tool effectively, and today I want to share the 10 rules that have helped me considerably improve the quality of the code I get.
1. Read completely every file that affects the problem you are going to solve before making any change
Agents are instructed to optimize resources, so when you ask them for something they go to the lines of code that directly affect that request, and that creates the risk that they ignore context. This is a problem because the piece of code you want to modify will most likely contain a method that calls a function in another file, which in turn uses functions from other files... so to properly understand everything that is happening, we force them to read everything before doing anything.
2. Ask for any clarification you consider relevant instead of making any assumption
This is one of the rules that has most improved the quality of the code Cursor and Claude Code deliver to me. Keep in mind that these tools use an LLM as their engine, which ultimately “generates” text, so the most natural thing is for them to fill undefined gaps with whatever they think might fit, and that is one of the biggest sources of noise in the code.
3. Do NOT refactor unless I explicitly ask you to
It is very important to establish this rule so the AI does not modify code unrelated to what we are working on.
4. Plan before programming
For me this is not only a rule for AI, but for anyone who is going to solve a problem. I remember that at school, in math class, I was taught that to solve a problem efficiently you had to: 1) read the statement and understand it, 2) identify the data you have, 3) define the strategy to solve it, and 4) solve it.
Well, this is the same. Also, this is not just an instruction you give once, but a phase in which you should converse with the AI to ground the problem and define strategies.
5. Apply SOLID principles.
Essential for code that can be maintained and scaled; because even if an AI is writing it, at some point you will have to read it and work on it. No more methods and files that do twenty things!
6. ALWAYS rely on the agents available to you that can help solve the problem you are working on.
With this instruction I achieve 2 main things: tasks are defined with a clear scope by area of expertise (for example, a UX expert agent defines a button and a frontend expert implements it), and from the beginning the work is framed as tasks that can potentially run in parallel so they can be completed faster.
7. NEVER leave “trash” files you used as support; tests, backups, etc.
If you have worked with Cursor, this will sound familiar: you ask it to implement a feature or fix an error, and besides doing it, it creates 8 files among tests, documentation, and so on that it used during the process. This way we tell it to leave only the files that implement what we asked for.
8. Do NOT add comments unless they are JSDoc for documentation or TODOs to remember pending tasks
AI seems to have a strong educational vocation and adds comments explaining absolutely EVERYTHING it does. Personally, that bothers me, because I believe the best-documented code is code that reads easily (hence the SOLID principles).
So I want comments out. I only allow comments that help document the code (I love being able to read what a method does and how each parameter is used) and comments indicating that something remains pending. Since I started using this rule, my code is much cleaner.
9. ALWAYS, when working with dates, CHECK the system date and time to make sure it matches your assumption
AI handles using dates to chronologically sort files quite badly. Especially whenever it created a database migration, it was a disaster, because it used whatever date it felt like. But the solution is very simple: do you need a date? Check what day it is on the system. Zero errors on this point since I started using this instruction.
10. NEVER run 'git add ', 'git commit', or database migrations. If you think it is necessary, ask me for confirmation
I know that systems normally ask whether they can execute certain instructions, but come on; I am not going to stop coding to wait for a button to appear and click accept. So I tell it what it cannot do, and the rest is restricted by this instruction.