Imagine what it would be like if I distilled my AI coding experience into best practice rules that everyone could reuse. So, I spent this afternoon thinking about this, hand-writing and repeatedly refining it before sharing it with everyone, so you and your Agent can learn together. Requirements: 1. Shift from programming with technical implementation details to wish-fulfillment programming. The model's capabilities are already powerful enough; you just need to boldly express your ideas, set sufficiently high requirements and tasks, and don't worry about whether AI can achieve them. 2. Focus on explaining the background and goals of your Agent, and less on worrying about the technical details for them. Tell them why you're doing it, who it's for, and what you consider the best approach. Let them judge the specific technical details themselves; learn to delegate. 3. Prioritize using the best models in the industry. Using inferior models wastes time and effort, leading to unpleasant work and wasting a lot of time. 4. When deciding whether to add a new feature, configuration, or switch, have your Agent consult you first for confirmation. Don't let them add features, switches, or text that no one uses. Gradually let them solidify your product guidelines. 5. Your ideas can be ambitious, but when assigning tasks to your Agent, try to break them down into the smallest usable version each time. Don't have them write a lot of code at once. Even after committing, this allows you to easily revert if problems arise. Rules 6. Let your Agent understand your communication style. For example, when discussing or analyzing a problem, they should only read and analyze the code, not modify it. They should only take action when you suggest fixing or modifying it. Always consult you for confirmation before committing, publishing, or deleting. 7. In the Agent's build details and criteria build details, aside from key project requirements, only include rules not immediately apparent from the code, and previously rejected solutions. For you, never share your key and token with the Agent; doing so is considered a leak, and they should immediately replace them. 8. Don't completely rely on prompts for rules that agents must follow; they might not be able to stop you. Always use rule scripts to restrict them and ensure they actually run the test successfully before considering it complete. Coding 9. Before starting to write code, have the agent clearly explain what needs to be changed and what functionality and effects it will affect. This provides context and facilitates better decision-making later. 10. Always have the agent develop a script to verify various results for the project. Run it at specific times to verify the effect. After completing a function, check it and have it output the results for you. Gradually build your project's agent test suite based on this. 11. If multiple agents are working simultaneously, have each use an independent worktree code directory. When committing, only commit your own changes and don't touch others' code. After everyone has made their changes, merge them together and run a full test. Troubleshooting 12. When fixing bugs, find the cause before taking action. If you can't fix it after two attempts, add logs to observe the actual data and runtime effects. Don't blindly guess where the problem is. 13. If three attempts to fix the issue still fail, clear the context and clearly rewrite your problem, requirements, and attempted solutions, then let the Agent start over. Review 14. Separate the code-writing Agent and the code-reviewing Agent to maintain decoupling, preventing one from being influenced by the other. 15. During code review, run the Agent a maximum of three times to prevent it from running uncontrollably. From the second round onwards, only review the newly changed parts; do not revisit previous reviews. 16. For changes that you and the Agent deem dangerous, the more dangerous they are, the deeper they should be investigated. Especially for one-way door changes like deletion, payment, and releases, you should personally review them, click on them, and observe the actual effects. Release 17. With each commit, have the Agent clearly state what was done, how the change was verified, and how to roll back if problems arise. This provides a valuable context for the Agent during later development, as Git records themselves serve as excellent context. 18. For features intended for external use, allow them to be used by yourself first, or by a select group of users willing to try them out. Avoid releasing them to the entire user base immediately. Include a beta update switch in your software to prevent issues with a full rollout and demonstrate responsibility to users. 18. Use it first with yourself and those willing to try it out; only release it to everyone if it works smoothly. Retrospective Review 19. Agents need to maintain a test case for every online bug and user feedback issue. Run these test cases before each deployment to prevent recurring problems. This includes running these test cases for old issues when changing models to check model performance. 20. When fixing problems, teach Agents to apply the lessons learned to similar issues and fix them simultaneously. The same applies to optimizing features and improving visuals; avoid only fixing one aspect while forgetting others.