Maxims for AI assisted coding

15 Mar 2025

Shreyas Prakash headshot

Shreyas Prakash

AI-assisted coding has this strange phenomenon of making the 10x developer, a 100x one. For the rookie, it’s either a hit-or-miss, and you usually end up with a lot more slop and hallucinations. I’ve been building various tiny apps, scripts, and projects by vibe-coding it, and I seem to have got marginally better at it. I’ve developed maxims that have proven effective in ‘taming the dragon’:

These principles are framework-agnostic and can be applied across different projects:

  • Run multiple instructions simultaneously by pressing CMD + T. If you’re on the Pro plan and terminal commands are slowing you down, this parallel approach saves valuable time. Some developers even open Cursor for the same codebase in multiple windows to provide instructions in parallel.
  • When you’re new to an existing codebase, ask Cursor to create mermaid diagrams of the codebase and chat with it. This helps you get familiar with the structure. If you have a github repo which you want to understand, replace ‘hub’ with ‘diagram’ to get a mermaid visualisation.
  • Create AI-generated commits consistently to help retrace your steps if things go wrong. I’ve set up a keybinding to generate commit messages and commit all changes in one keystroke:
{
"key": "ctrl+enter",
"command": "runCommands",
"args": {
"commands": [
{
"command": "git.stageAll"
},
{
"command": "cursor.generateGitCommitMessage"
},
{
"command": "git.commitAll"
},
{
"command": "git.sync"
}
]
}
},
  • Store Documentation Locally: Following Karpathy’s advice, store relevant documentation and example code in a .cursor/documentation directory for quick reference. Helpful to store a variety of documents in this folder such as PRD, App flow documents, design system, user schema, styling document etc
  • API integrations are often challenging with AI assistance due to hallucinations or outdated information. Use “@web” to fetch the most current documentation, then create dedicated markdown files for each API you’re using. For services like Stripe, either include the Stripe MCP server in Cursor or add code snippets from the latest documentation.
  • For simpler apps, focus on articulating your goals rather than providing precise instructions. This approach gives the AI room to suggest optimal solutions and frameworks it’s confident in.
  • Goal-Oriented Prompting: As one Reddit post wisely suggested:
Provide goals, not specific commands. 

Unless you can code, odds are you won't know the right instruction to give the agent. Give it a problem statement and outcomes. Then ask questions: > How would you make this? > What do you need from me? > What are your blind spots?
  • At the end of the lengthy conversation on the Cursor chat window, I tend to use this prompt to summarise what just happened. I (have to admit), that I sometimes don’t really read all the details of the code generated, so this prompt is helpful to summarise without shortening:
Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions.
This summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context.

Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process:

1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify:
   - The user's explicit requests and intents
   - Your approach to addressing the user's requests
   - Key decisions, technical concepts and code patterns
   - Specific details like file names, full code snippets, function signatures, file edits, etc
2. Double-check for technical accuracy and completeness, addressing each required element thoroughly.

Your summary should include the following sections:

1. Primary Request and Intent: Capture all of the user's explicit requests and intents in detail
2. Key Technical Concepts: List all important technical concepts, technologies, and frameworks discussed.
3. Files and Code Sections: Enumerate specific files and code sections examined, modified, or created. Pay special attention to the most recent messages and include full code snippets where applicable and include a summary of why this file read or edit is important.
4. Problem Solving: Document problems solved and any ongoing troubleshooting efforts.
5. Pending Tasks: Outline any pending tasks that you have explicitly been asked to work on.
6. Current Work: Describe in detail precisely what was being worked on immediately before this summary request, paying special attention to the most recent messages from both user and assistant. Include file names and code snippets where applicable.
7. Optional Next Step: List the next step that you will take that is related to the most recent work you were doing. IMPORTANT: ensure that this step is DIRECTLY in line with the user's explicit requests, and the task you were working on immediately before this summary request. If your last task was concluded, then only list next steps if they are explicitly in line with the users request. Do not start on tangential requests without confirming with the user first.
                       If there is a next step, include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there's no drift in task interpretation.

Here's an example of how your output should be structured:

<example>
<analysis>
[Your thought process, ensuring all points are covered thoroughly and accurately]
</analysis>

<summary>
1. Primary Request and Intent:
   [Detailed description]

2. Key Technical Concepts:
   - [Concept 1]
   - [Concept 2]
   - [...]

3. Files and Code Sections:
   - [File Name 1]
      - [Summary of why this file is important]
      - [Summary of the changes made to this file, if any]
      - [Important Code Snippet]
   - [File Name 2]
      - [Important Code Snippet]
   - [...]

4. Problem Solving:
   [Description of solved problems and ongoing troubleshooting]

5. Pending Tasks:
   - [Task 1]
   - [Task 2]
   - [...]

6. Current Work:
   [Precise description of current work]

7. Optional Next Step:
   [Optional Next step to take]

</summary>
</example>

Please provide your summary based on the conversation so far, following this structure and ensuring precision and thoroughness in your response.

There may be additional summarization instructions provided in the included context. If so, remember to follow these instructions when creating the above summary. Examples of instructions include:
<example>
## Compact Instructions
When summarizing the conversation focus on code changes and also remember the mistakes you made and how you fixed them.
</example>

<example>
# Summary instructions
When you are using compact - please focus on test output and code changes. Include file reads verbatim.
</example>
  • According to Claude’s whitepaper on agentic coding tools, positioning your most important goals at both the beginning and end of your prompts can be effective, as LLMs give more “attention” to these positions.
  • Use models with larger context windows (like Gemini 2.5 Pro, o3) when starting a new codebase that needs comprehensive understanding. For smaller, well-defined tasks, Claude Sonnet 3.7 or Claude 3.5 Sonnet can be more efficient.
  • For frontend implementations, v0.dev produces high-quality React/Tailwind components.
  • When words aren’t enough to convey your design intent, use Frame0 for low-fidelity mockups or Figma for higher-fidelity ones. That said, I’ve found I rarely need Figma these days—clear verbal direction is often sufficient.
  • Follow the Explore-Plan-Code Workflow: The TDD approach works best for side projects. Instead of jumping straight to code, have your AI assistant review the plan first, break it down into a prompt-plan.md file, and provide targeted instructions. Once the code generated for each section is done, run rigorous tests to check if everything is working as planned, move forward, only after successful completion of tests.
  • In case through iterative prompting, if I was able to fix a key issue, I do want to store the learning in the memory in the format of a Cursor rule. To do this, I add this to the end of the chat conversation:
Please review our entire conversation in this thread, especially the debugging process we just went through.

Now create a new `.cursor/rules/*.mdc` rule that summarizes the mistake, the fix, and a reusable pattern that prevents future hallucinations like this in the same codebase.

Use this JSON format:

{
  "description": "One-line summary of the problem this rule prevents",
  "when": "Where or when this kind of bug would occur",
  "rule": "What to do instead, including any assumptions or validations needed",
  "examples": [
    {
      "before": "[Cursor's initial incorrect code]",
      "after": "[The working, correct code we ended up with]"
    }
  ],
  "tags": ["hallucination", "bugfix", "[add tool or domain name]"]
}

Only return valid JSON. Be concise and generalize the pattern so it applies anywhere in the codebase where similar logic is used.


Include a precise `when` clause scoping the rule to specific file paths or module names.

Include how to validate that the fix worked—such as a unit test, console output, or specific log check.

For rule type "Agent requested", also provide "Description of the task this rule is helpful for" so that the agent can use this rule accordingly
  • Use .cursorignore to ignore files that need not be indexed such as /dist in JS projects etc.
  • Use gitingest to get all the relevant files (filtered by extension, directory), which you can then use to feed to ChatGPT and ask questions.
  • Keep the context short, the longer the context, the more hallucinations AI is prone to. Best to keep it to 10-15 conversation replies in the Cursor composer window. If you’re still not landing there, open a new Cursor chat.
  • Claude, Gemini 2.5 Pro etc can help create a clear plan in markdown. Keep asking clarifying questions, do socratic reasoning, and gradually improve the specs doc. Use multiple models to help overcome gaps (if any). In your chats, keep referring to the @product-specs.md created frequently.
  • System prompt in “Rules for AI” in cursor settings:
    • Keep answers short and concise.
    • Don’t be a sycophant and answer always in a agreeable manner, disagree if you think the reasoning is wrong.
    • Avoid unnecessary explanations.
    • Prioritize technical details over generic advice.
  • Use Context7, an MCP for referring to the latest docs
  • BrowserTools MCP can fully automate analysis of browser logs (no longer going to console, copy pasting logs into your chat)

Subscribe to get future posts via email (or grab the RSS feed). 2-3 ideas every month across design and tech

Read more

  1. Home is where the feeling of home residesreflections
  2. Notes on doing most good, doing some good, and living goodphilanthropy
  3. Notes on Londontravel
  4. 18 key ideas from reading Henrik Karlsson this monthwriting
  5. Stop arguing, and start drawing circles togethermathematics
  6. The whole world is just the snake eating its own tailmental-models
  7. Life lessons and hot takes from my 30slifestyle
  8. Building a skill for coherent science illustrationsscience
  9. My agentic engineering workflow (step by step)agentic-coding
  10. Hammock driven developmentagentic-coding
  11. Peculiar ways number three fits into our funny little brainsmental-models
  12. AI sandwich as a defacto principle for anything agentic engineering relatedagentic-coding
  13. Authority in the guise of evidencecritical-rationalism
  14. Map is not the territoryphilosophy
  15. Self hypnosis as a manifestation ritualmeditation
  16. Hegelian dialectic for structured reasoning with AI agentsphilosophy
  17. How I prepare for tough negotiations nowadaysnegotiation
  18. When should we steelthread somethingproduct-development
  19. Breadboarding, shaping, slicing, and steelthreading solutions with AI agentsproduct
  20. Healthy conflict in teams have a tipping pointteam-building
  21. How I deslopify AI writingwriting
  22. How I started building softwares with AI agents being non technicalagentic-coding
  23. Read raw transcriptswriting
  24. Legible and illegible tasks in organisationsproduct
  25. L2 Fat marker sketchesdesign
  26. Writing as moats for humanswriting
  27. Beauty of second degree probesdecision-making
  28. Boundary objects as the new prototypesprototyping
  29. One way door decisionsproduct
  30. Finished softwares should existproduct
  31. How I periodically rank my rough draftsobsidian
  32. Flipping questions on its headinterviewing
  33. Vibe writing maximswriting
  34. How I blog with Obsidian, Cloudflare, AstroJS, Githubwriting
  35. How I build greenfield apps with AI-assisted codingagentic-coding
  36. We have been scammed by the Gaussian distribution clubmathematics
  37. Classify incentive problems into stag hunts, and prisoners dilemmasgame-theory
  38. I was wrong about optimal stoppingmathematics
  39. Thinking like a shipmental-models
  40. Hyperpersonalised N=1 learningeducation
  41. New mediums for humans to complement superintelligenceagentic-coding
  42. Maxims for AI assisted codingagentic-coding
  43. Virtual bookshelvesaesthetics
  44. It's computational and AI everythingagentic-coding
  45. Public gardens, secret routesdigital-garden
  46. Git way of learning to codeagentic-coding
  47. Style Transfer in AI writingagentic-coding
  48. Understanding codebases without using codeagentic-coding
  49. Vibe coding with Cursoragentic-coding
  50. Virtuoso Guide for Personal Memory Systemsmemory
  51. Writing in Future Pastwriting
  52. Publish Originally, Syndicate Elsewhereblogging
  53. Poetic License of Designdesign
  54. Idea in the shower, testing before breakfastsoftware
  55. Technology and regulation have a dance of ice and firetechnology
  56. How I ship "stuff"software
  57. Writing is thinkingwriting
  58. Song of Shapes, Words and Pathscreativity
  59. How do we absorb ideas better?knowledge
  60. Read writers who operatewriting
  61. Brew your ideas lazilyideas
  62. Trees, Branches, Twigs and Leaves — Mental Models for Writingwriting
  63. Compound Interest of Private Noteswriting
  64. Conceptual Compression for LLMsagentic-coding
  65. Meta-analysis for contradictory research findingsdigital-health
  66. Proof of workproduct
  67. Gauging previous work of new joinees to the teamleadership
  68. Task management for product managersproduct
  69. Beauty of Zettelswriting
  70. Stitching React and Rails togetheragentic-coding
  71. Exploring "smart connections" for note takingwriting
  72. Deploying Home Cooked Apps with Railssoftware
  73. Repetitive Copypromptingwriting
  74. Questions to ask every decadejournalling
  75. Balancing work, time and focusproductivity
  76. Hyperlinks are like cashew nutswriting
  77. Brand treatments, Design Systems, Vibesdesign
  78. How to spot human writing on the internetwriting
  79. Can a thought be an algorithm?product
  80. Opportunity Harvestingcareers
  81. Everything is a prioritisation problemproduct
  82. How I do product roastsproduct
  83. The Modern Startup Stacksoftware
  84. In-person vision transmissionproduct
  85. How might we help children invent for social good?social-design
  86. The meeting before the meetingmeetings
  87. Design that's so bad it's actually gooddesign
  88. Lessons learnt interview prepping for product rolesinterviewing
  89. Obsessing over personal websitessoftware
  90. English is the hot new programming languagesoftware
  91. Better way to think about conflictsrisk-management
  92. The role of taste in building productsdesign
  93. Dear enterprises, we're tired of your subscriptionssoftware
  94. Products need not be user centereddesign
  95. World's most ancient public health problemsoftware
  96. Pluginisation of Modern Softwaredesign
  97. Let's make every work 'strategic'consulting
  98. Making Nielsen's heuristics more digestibledesign
  99. Startups are a fertile ground for risk takingentrepreneurship
  100. Insights are not just a salad of factsdesign
  101. Minimum Lovable Productproduct
  102. Methods are lifejackets not straight jacketsmethodology
  103. How to arrive at on-brand colours?design
  104. Minto principle for writing memoswriting
  105. Importance of Whytask-management
  106. Quality Ideas Trump Executionsoftware
  107. Why I prefer indie softwareslifestyle
  108. Use code only if no code failscode
  109. Self Marketing
  110. Personal Observation Techniquesdesign
  111. Design is a confusing worddesign
  112. A Primer to Service Design Blueprintsdesign
  113. Rapid Journey Prototypingdesign
  114. Visualise detailed file structures on CLIcli
  115. Do's and Don'ts of User Researchdesign
  116. Design Manifestodesign
  117. Complex project management for productproducts
  118. How might we enable patients and caregivers to overcome preventable health conditions?digital-health
  119. Pedagogy of the Uncharted — What for, and Where to?education
  120. Future of Equity with Ludovick Petersinterviewing
  121. Future of Ageing with Mehdi Yacoubiinterviewing
  122. Future of Tacit knowledge with Celeste Volpiinterviewing
  123. Future of Mental Health with Kavya Raointerviewing
  124. Future of unschooling with Che Vanniinterviewing
  125. Future of Rural Innovation with Thabiso Blak Mashabainterviewing
  126. Future of work with Laetitia Vitaudinterviewing
  127. How might we prevent acquired infections in hospitals?digital-health
  128. The why to endure any howentrepreneurship
  129. Design education amidst social tribulationsdesign
  130. How might we assist deafblind runners to navigate?social-design