Most people are trying to write better prompts.

Wrong layer.

The real advantage is knowing which model to use, what context to give it, what to remove, what to automate, what to verify, and when to stop asking AI altogether.

Here are the rules I’d keep.

The 25 Rules That Matter Most

1. Give AI the outcome, not the deliverable.
“Get the client to pay without burning the relationship” beats “write a follow-up email.”

2. Tell it what winning means.
If success cannot be measured, the model will optimize for sounding useful.

3. Use the strongest model for decisions, not chores.
Buy expensive intelligence where one good decision changes everything downstream.

4. Context is a drug.
Enough improves the answer. Too much makes the model derivative.

5. More context does not mean more intelligence.
Sometimes the clean chat wins.

6. Separate creation from evaluation.
One pass generates. Another pass attacks what was generated.

7. Never let the same prompt defend its own answer.
Ask a fresh context to critique important work.

8. If the AI should ask questions first, tell it.
Missing context destroys more outputs than bad prompting does.

9. Stop asking AI to “think harder.”
Tell it what deserves deeper thought.

10. Tell it when to stop thinking.
“When you have enough information to act, act.”

11. Ask for a recommendation, not an options cemetery.
Seven alternatives without a decision is intellectual procrastination.

12. Never confuse AI confidence with evidence.
A perfectly written hallucination is still a hallucination.

13. Force evidence boundaries.
“Only claim what you can support. Mark everything else as uncertain.”

14. Open the citations.
AI-generated references deserve suspicion until verified.

15. If you explain the same process twice, systematize it.
Repeated instructions belong in a Skill, SOP or reusable workflow.

16. Do not systematize creativity too early.
You will turn your previous work into your future ceiling.

17. Keep permanent instructions small.
Every permanent instruction quietly biases every future answer.

18. Do not make AI remember everything.
Make it remember what matters for this problem.

19. A Project is context. A Skill is behaviour.
Stop using them interchangeably.

20. Cheap software can still be expensive distraction.
AI making something easy to build does not make it worth building.

21. Prototype to answer a question.
Not to prove you can prototype.

22. Build less than you use.
Three hours building an automation that saves ten minutes is not leverage.

23. AI reduces implementation cost. It does not create demand.
Nobody caring faster is still nobody caring.

24. Connect the minimum number of systems required.
Convenience is not worth unlimited data exposure.

25. Judgment stays human.
The machine can remove the busywork. Accountability does not leave with it.

Prompting

26. Lead with the actual problem.
Background → objective → constraints → success condition.

27. Stop prompting with job titles alone.
“You are a world-class marketer” means almost nothing without an objective.

28. Roles work best when they change the decision lens.
Reliability engineer. Prosecutor. CFO. Security reviewer. Product lead.

29. Never end a factual question with “right?”
You just paid the model to agree with you.

30. Do not smuggle your conclusion into the prompt.
“This strategy is clearly working, explain why” is self-deception with an API.

31. Ask neutral questions when you want truth.

32. If you want disagreement, explicitly reward disagreement.

33. Tell the model what would change your mind.

34. Give constraints that matter.
Budget. Deadline. Risk. Audience. Existing assets.

35. Delete decorative constraints.
Every unnecessary rule competes with the important ones.

36. Three hard constraints beat fifteen soft ones.

37. If twelve rules matter, run multiple passes.

38. Prompt for decisions before prose.

39. Ask for the answer in the first sentence.

40. Ask methodology after the conclusion when methodology matters.

41. Do not ask for “something amazing.”
Define amazing.

42. “Make it better” is not feedback.

43. Show the model what you hate.
Negative examples create sharper boundaries than adjectives.

44. Edit the original prompt when the conversation takes a wrong turn.

45. Stop arguing with a poisoned thread.

46. Restart when the context becomes more expensive than rebuilding it.

47. Batch related work.
One context load beats five repetitive turns.

48. Ask for assumptions before large executions.

49. Correct bad assumptions before the model builds on them.

50. Ask: “What are you assuming that I never told you?”

Context

51. Context should earn its place.

52. Every file changes the probability distribution of the answer.

53. Archive is not context.

54. Upload the gold. Leave the warehouse outside.

55. Old drafts can contaminate new thinking.

56. Your best previous work can become the model’s favourite cage.

57. Start original thinking in cleaner rooms.

58. Load examples after ideation when possible, not before.

59. Examples create imitation pressure.

60. Separate “understand my voice” from “invent something new.”

61. One Project per durable context is usually cleaner than one giant universe.

62. Client context belongs with the client.

63. Company context belongs with the company.

64. Personal creative exploration often deserves a blank chat.

65. Memory is not automatically personalization.

66. Bad memory is automated anchoring.

67. Save stable preferences. Avoid saving temporary beliefs.

68. Summarize long threads before continuing them forever.

69. A fresh chat plus a sharp summary often beats turn 87.

70. Do not paste the same giant document every message. Point to it.

Models

71. Model selection happens before prompt optimization.

72. Do not send every problem to the largest model.

73. Use high reasoning where ambiguity is expensive.

74. Use smaller models where mistakes are cheap and detectable.

75. Grammar does not require genius.

76. Formatting does not require genius.

77. Extraction usually does not require genius.

78. Strategy sometimes does.

79. Architecture sometimes does.

80. Novel diagnosis often does.

81. The most expensive model can frame the work and hand execution down.

82. Think of models like organizational seniority.

83. Do not hire the CEO to rename CSV columns.

84. Escalate when uncertainty increases, not because the task sounds impressive.

85. Change models when the nature of the problem changes.

Skills, Projects and Repeated Work

86. Repetition deserves infrastructure.

87. If you keep typing the same five paragraphs, you have failed to systematize.

88. Put processes into Skills.

89. Put knowledge into Projects.

90. Put reusable standards into reference files.

91. Put temporary instructions in the prompt.

92. Do not turn everything into a Skill.

93. Skills reduce variance. Sometimes you want variance.

94. Creative ideation should not inherit seventeen SOPs.

95. QA absolutely should.

96. Contract review should.

97. Analytics validation should.

98. Publishing checks should.

99. Repeated research methodology should.

100. Test a Skill on multiple phrasings before trusting it.

101. A workflow that works only when summoned perfectly is not a workflow.

102. Version important Skills.

103. Keep a changelog for workflows that affect money or customers.

104. Build golden test cases.

105. If a new Skill cannot beat the old workflow on those cases, do not graduate it.

Claude Code / AI Coding

106. Vibecoding is not product-market fit.

107. A deployed URL is not traction.

108. A working prototype is not proof that anyone needs it.

109. Build prototypes to kill uncertainty.

110. Ask what hypothesis the prototype tests before writing code.

111. Build the smallest thing capable of answering that question.

112. Screenshot interfaces instead of describing twenty visual problems.

113. Visual input usually beats visual adjectives.

114. Build one surface at a time.

115. Twelve simultaneous UI changes produce twelve places to hide failure.

116. Run tight build → inspect → correct loops.

117. Test mobile before calling something finished.

118. Test ugly states.
Empty data. Long text. Failed API. Slow network. Wrong permissions.

119. Ask AI to attack its own happy path.

120. Maintain a HANDOFF file once a prototype becomes serious.

121. Document what is real, mocked, broken and unfinished.

122. “AI built it” is never an excuse for technical debt nobody understands.

123. Prototype code becomes production code faster than people admit. Treat it accordingly.

124. Never bypass security friction you do not understand.

125. Automation without observability becomes invisible failure.

Research and Verification

126. Research mode is useful only if you verify the important parts.

127. Source count is not source quality.

128. Ten articles repeating one original claim are still one claim.

129. Find primary sources when the decision matters.

130. Separate source facts from model inference.

131. Ask the model to label uncertainty.

132. Ask what evidence would falsify its conclusion.

133. Search against your preferred answer.

134. If you only research confirmation, AI makes confirmation bias faster.

135. Never publish a statistic you have not opened.

136. Never let AI invent precision.

137. “Approximately” is better than a fake decimal point.

138. High-stakes outputs deserve independent review.

Writing

139. AI writing fails from sameness before it fails from grammar.

140. Kill the polished corporate mush.

141. Delete “it’s not X, it’s Y” unless the contrast genuinely earns it.

142. Delete “here’s the thing.”

143. Delete motivational endings that say nothing.

144. Stop making every paragraph the same size.

145. Sentence rhythm matters.

146. Specificity makes writing human.
₹43. 4:30 AM. One customer. A broken webhook. Tuesday.

147. Dictate messy reality before asking AI to clean it.

148. Never clean the personality out with the mistakes.

149. AI should sharpen your observation, not replace it.

150. If the sentence could have been written by anyone, it probably should not be published by you.