A compressed version of this list lives on my expertise page: six rules, one line each. This is the long version. These are not aspirations or values-poster material. They are the checks I actually run when I write a spec, review an agent's output, or decide whether something is done. Each one exists because skipping it, at some point, cost me something.
| Rule | The check it runs |
|---|---|
| 1. Evidence over inference | Every requirement traces to a source; never infer a status from a date |
| 2. Validate data before asserting it | Run the queries and work the math yourself before making the claim |
| 3. Reversible by default | Back up before editing; nothing ships that cannot be undone |
| 4. Right-sized rigor | Strip over-engineering; test the happy path, the edge case, and the error case |
| 5. Automate the tedious | Anything done twice becomes a tool with a pass or fail check |
| 6. Communication discipline | Concise, direct, get to the point |
1. Evidence Over Inference
Every requirement traces to a source: an interview, a comment, sample data, a decision someone actually made. The corollary sounds small and is not: I do not infer a status from a date. A date tells you when something was supposed to be true. Checking tells you whether it is. Most of the worst surprises in product work are not missing information, they are inferences that were never verified because they looked reasonable.
2. Validate Data Before Asserting It
Before I make a claim about data, I write and run the queries myself, and I work the underlying math myself, whether that is accrued interest or a yield calculation. I traded futures in a prior life, and markets are efficient teachers on this point: an asserted number and a validated number look identical right up until money moves. I look for side-by-side proof before I draw a conclusion, and I distrust any number I could not reproduce.
3. Reversible by Default
Back up before you edit. Keep canonical copies version-controlled. Nothing ships that cannot be undone. This rule is why I can give AI agents real autonomy without losing sleep: every change lands as a reviewable pull request first, including on this website, where the post you are reading went through version control like everything else. Reversibility is what converts risk into experiments.
4. Right-Sized Rigor
Strip over-engineering. Build only the abstractions that earn their keep. Then hold the floor: every feature gets example-based tests for the happy path, the edge case, and the error case. Under-building and over-building are the same failure wearing different clothes, and the failure is not thinking hard about what the thing is for. Three tests per feature is a floor, not a ceiling, and a codebase with no unnecessary cleverness is the cheapest gift you can leave the next person.
5. Automate the Tedious
If I do something twice, it becomes a tool, with explicit triggers, deterministic steps, and a pass or fail check. Over a few years this compounds into dozens of tools and more than a dozen specialized agents doing work I used to do by hand. The count is not the point. The point is that toil compounds quietly, and so does its removal, and the second curve is the one you want to be riding.
6. Communication Discipline
Concise, direct, get to the point. If the decision you need is in paragraph four, most readers will never meet it. I have written about this one before, in a post about pre-reads, and it may be the highest-leverage rule on the list because it taxes or subsidizes every other thing you do.
None of these six require AI. But AI raised the stakes on all of them, because agents amplify whatever you feed them: your evidence standards, your test discipline, your clarity, or the absence of each. That is why this list got sharper this year, not softer. The rules were always good practice. Now they are load-bearing.