Journal
All articles
Notes on AI, coding, and programming. Newer pieces are listed first.
Keep the model inside the decision you already made
Write the decision before the draft. Then cut every sentence that crosses it, even when the extra sentence is fluent.
Read the diff before you accept it
An assistant can draft a change in seconds. The review is still the part that decides whether the change is yours.
What belongs in the chat, and what stays out
A useful coding chat carries four things: the error, the file, the constraint, and one example. The rest of the repository can wait.
Review a generated diff in three passes
Look at the file list, then the behavior of each hunk, then what the change left behind. Do not mix the passes.
Write the failing case before the fix
Name the ordinary case, the empty case, the boundary, and the failure. Watch the failure fail. Then change the code.
Give a module one public edge
Callers should have one door. If cache, retry, and helpers are reachable from outside, the next change will couple to them.
A repository map you can say aloud
Five paths you can name are a map. A tree of folders you cannot explain is a pile the next change will make deeper.
A test plan for code you did not type
Generated code needs a smaller test list than people write, and a stricter one. Name the cases before you ask for the implementation.
Ask for a function, not a feature
A feature prompt invites a small application. A function prompt invites a change you can review in one sitting.
What belongs in the repository
A model will happily add files. The repository should only gain a file that a later change will still want.
