Rules
Reference
intermediate
The Golden Rules of Prompting for Code
Rule 1: Be Specific About What, Not How
Tell the AI the outcome you need. Let it choose the implementation unless you have a specific reason to constrain it.
| Weak (Over-specified How) | Strong (Clear What) |
|---|---|
| "Write a for loop that checks each item" | "Filter items where status is active" |
| "Create a class with a constructor that takes..." | "Create a service that manages user sessions" |
| "Use reduce to accumulate the total" | "Calculate the order total including tax and discounts" |
Exception: Specify "how" when you need a particular algorithm, pattern, or library for compatibility reasons.
Rule 2: One Task Per Prompt
Each prompt should have exactly one clear objective. Compound prompts lead to partial completions.
| Multi-task (risky) | Single-task (reliable) |
|---|---|
| "Create the form, add validation, connect to API, and style it" | Prompt 1: "Create a user registration form with fields: name, email, password" |
| Prompt 2: "Add Zod validation: email format, password min 8 chars, name required" | |
| Prompt 3: "Connect the form to POST /api/register with error display" |
Rule 3: Provide Examples of Desired Output
The most reliable way to get what you want is to show what you want.
Create a function that formats currency.
Example:
formatCurrency(1234.5, 'USD') => '$1,234.50'
formatCurrency(1000, 'EUR') => '€1,000.00'
formatCurrency(99.9, 'GBP') => '£99.90'
Rule 4: State Your Constraints Explicitly
Constraints prevent over-engineering and ensure compatibility.
Essential constraints to specify:
- Language version and strict mode settings
- Framework and library versions
- Performance requirements (time, memory)
- Compatibility targets (browsers, Node versions)
- Size limits (max lines, max dependencies)
- What NOT to use (banned patterns, deprecated APIs)
Rule 5: Include Relevant Context, Exclude Noise
Include:
- Type definitions the code must satisfy
- Interface contracts from adjacent systems
- Example data matching real shapes
- Error messages when debugging
Exclude:
- Entire files when only 5 lines are relevant
- Build configuration (unless build-related task)
- Unrelated code from other features
- Previous conversation about different topics
Rule 6: Use Positive Instructions Over Negative
Positive instructions are clearer and produce better results.
| Negative (ambiguous) | Positive (actionable) |
|---|---|
| "Don't make it slow" | "Response time must be under 100ms for 1000 items" |
| "Don't use bad variable names" | "Use descriptive camelCase names: getUserById, isAuthenticated" |
| "Don't over-engineer it" | "Maximum 30 lines, no abstraction layers" |
Rule 7: Specify Output Format
Be explicit about what the response should look like.
Return only the function implementation.
- No explanatory text before or after
- Include the import statements
- Include TypeScript types
- Use named export
Rule 8: Progressive Disclosure for Complex Tasks
Start with the high-level structure, then drill into details.
Prompt 1: "Design the module structure for a notification system
(just file names and their responsibilities)"
Prompt 2: "Implement the NotificationService class from the structure above"
Prompt 3: "Add the delivery strategies (email, push, in-app)"
Prompt 4: "Write the integration tests"
Rule 9: Anchor with Working Code
When modifying existing code, always provide it as the starting point.
Here is my current implementation:
[PASTE CODE]
Modify it to also handle [NEW REQUIREMENT] while keeping
the existing behavior for [EXISTING CASES].
Rule 10: Verify Assumptions Explicitly
When the AI must make assumptions, tell it to state them.
If any requirements are ambiguous, list your assumptions
before generating code. I will confirm before you proceed.
Rule 11: Match Prompt Complexity to Task Complexity
| Task Complexity | Prompt Style |
|---|---|
| Trivial (rename, typo) | One sentence |
| Simple (small function) | 2-3 sentences + example |
| Moderate (feature) | Structured with requirements list |
| Complex (system) | Multi-step with progressive detail |
| Architectural | Discussion-first, code-second |
Rule 12: End with a Success Criterion
Tell the AI how to know it succeeded.
The implementation is correct when:
- All items in the test array are sorted by date descending
- Null dates sort to the end
- Original array is not mutated
- Works with arrays up to 100,000 items without noticeable delay