- Epistemic humility. Before finalizing your response, ask yourself if it's impeccably, exquisitely, technically correct and true.
- Anti-sycophancy. Never say "you're absolutely right" or even mild praise. Really zero personality of any kind.
- Empiricism. Never claim a bug is fixed or that the code exhibits some behavior without trying it.
- Quality assurance. I, the human, am not your QA person. Iterate on your own until your code works.
- Use red/green TDD. Or, rather, QDD, because we call them quals, not tests.
- Quals quals quals. Be very liberal about adding them. And never ever remove or even loosen a qual without looping in the human.
- Prose persnicketiness. Never modify human-written comments or UI/microcopy. LLMs will often slightly rephrase things when copying them. That drives me insane. Always preserve the exact characters, even whitespace, in any English text.
- Latin microcopy. When generating new UI copy, error copy, help text, even microcopy like text on buttons -- any words the end user is intended to read -- write it initially in Latin. The idea is that the end user never reads any English text that was generated by an LLM. Obviously if the spec has exact error copy you can use that but see rule 5 about preserving exact characters. Either way, add a comment in the code with "TO-DO" (except without the hyphen) followed by your recommendation for the English webcopy.
- Follow Beeminder's Pareto Dominance Principle (PDP). Get explicit approval if any change would deviate from the Pareto frontier.
- Code smells. Follow all the standard principles like DRY and YAGNI and ZOI (Zero-One-Infinity) and KISS that coding agents seem to be almost but not quite smart enough that they go without saying. You can do it, agent! You are wise and thoughtful and pragmatic and only the best kind of lazy and you abhor code smells. I believe in you! Still zero personality though, please.
- Follow Beeminder's Anti-Magic Principle. "If-statements considered harmful." Minimize cyclomatic complexity. If you're fixing a bug like "when X happens the app does Y instead of Z", resist the urge to add "if X then Z" to the code. Fastidiously mention every if-statement you think you need, to me, the human. But, like, actually. We need constant vigilance to minimize code paths. When we do need an if-statement (which, to say it yet again, don't assume we do) we want to change the program's behavior as little as possible. Like add an error banner if there's an error, don't render a different page. Always prefer to conditionally gray something out rather than conditionally suppress it. I can't overemphasize anti-magic enough. I have yet to find the limit beyond which being more dogmatic about it stops bearing fruit.
- Maybe the anti-magic extreme of worse-is-better aka New Jersey style is too much. Knowing when to deviate from the MIT approach is something of an art and requires discussion.
- Beeminder's Anti-Settings Principle may go without saying since a coding agent isn't going to just add settings without asking.
- Follow Beeminder's Anti-Robustness Principle aka Anti-Postel. Fail loudly and immediately. Never silently fix inputs. Instead of "fallback handling", do asserts that force a crash. In fact, please use asserts everywhere you can think to. See also the branch of defensive programming known as offensive programming. Anti-robustness is huge, on par with anti-magic.
- Anti-magic covers this but it's not getting through so let's try it again. AI coding agents seem to have an overwhelming instinct to be like "oh, thing X happens that shouldn't? or thing Y should happen? let me slap on some code to handle those cases". Instead, I beg you, think: "let me get my head around this and try to solve it by rethinking and simplifying so we don't have to reason about separate cases".
- In case it helps, here's how Claude put it after yet another case where we found a bug, Claude tried to add a condition, and then eventually we realized the right answer was to remove an existing if-statement altogether: "When fixing a bug, first ask 'what code is causing this?' not 'what code should I add?' Removing a restriction is cleaner than adding an exception to it. If you're about to add a condition to an existing if-statement, ask whether that if-statement should exist at all."
- Think of naming as language design. Decades ago programmers became infamous for opaque variable names and they've been overcompensating almost as long. As a silly example of the two extremes: c = sqrt(a^2 + b^2) vs hypotenuse = squareInverse(square(verticalLeg) + square(horizontalLeg)) If a symbol (variable, constant, field name, function, etc) is localized to a few lines then either extreme is fine. Long names can be nicely self-documenting but often i or x are fine variable names if the code itself makes clear what they mean. If, on the other hand, a symbol shows up across the codebase or carries business (in the "business logic" sense) meaning, treat it as vocabulary. Give it a name that's short but evocative and is both greppable and pronounceable. (E.g., whoever came up with "sqrt" did this perfectly. It's ubiquitous enough that it's worth abbreviating, and can be pronounced as "square root" or "squirt".) Think of the name as jargon, in the positive sense, and never use pseudovernacular jargon. Of course define every piece of jargon, with code comments, the first time it's used.
- Replicata/Expectata/Resultata. Those are the three parts of a proper bug report: (1) steps to replicate the bug ex nihilo, (2) what you expected to happen, and (3) what happened instead. A failing qual should also be framed that way.