Clojurians Log v2
biff 2026-09-13
Currently working on getting LLMs (codex) to generate biff code that doesn't suck. My first approach of having a short paragraph in agents.md that says basically "look at the biff docs and make sure new code you write is doing stuff the right way" was sadly way too optimistic. next attempt was a skill that says "here's a big bulleted list of specific things you should make sure to do/not do". That worked a bit better but has been pretty unreliable. Also potentially related to me using gpt 5.6 low effort. If I can get this "write good biff code" thing to work with cheaper models than astra/fable etc that'd be preferable, though I've at least bumped gpt 5.6 up to medium effort. we'll see if that's sufficient. My latest iteration takes more of a human-in-the-loop approach. the review skill has a numbered list of all the review rules, and there's a template checklist with one line per rule. when the skill runs it copies the checklist template to .biff/review/<current date>/<n>.txt and then reviews the code and checks off rules in the checklist that it thinks are already being fully observed. Then you can go over the checklist and check/uncheck things and tell the agent to start fixing stuff when you're ready. After that point the agent never edits the checklist, so you can go through it and check the points off yourself.
I'm using a ~4,000 line diff (newsletter app) to iterate on this. Hopefully for a non-brand-new project it's able to write code following the existing code's patterns alright. i.e. if you have to do a bunch of careful review up front but then things get more automated from there, that wouldn't be too bad. I am also hoping that I can get the rules good enough that the human-in-the-loop bit isn't really required. Nice to have as a fallback though either way.
example of the checklist (still need to add a bunch of stuff to it):
Project structure
[ ] A1. model namespace contents
[ ] A2. model resolver namespace placement
[ ] A3. app namespace contents
[ ] A4. one page-rendering handler per app namespace
[ ] A5. work namespace contents
[ ] A6. uicomp namespace contents
[ ] A7. external API namespace contents
[ ] A8. module namespaces only expose modules
[ ] A9. shared functions belong in lib
[ ] A10. single-module functions belong in that module
[ ] A11. domain data is computed by resolvers, not lib functions
[ ] A12. database reads are done by resolvers
[ ] A13. semantic namespace names
[ ] A14. keep state in the system map
Library usage
[ ] B1. authorization rules
[ ] B2. authorize user-initiated writes
[ ] B3. effectful functions use biff.fx
[ ] B4. DB reads and writes use biff.fx
[ ] B5. SQL queries use HoneySQL
[ ] B6. route templates use defpath
[ ] B7. defpath location
Tests
[ ] C1. test namespace naming
[ ] C2. biff.fx state function coverage
[ ] C3. model resolver unit tests
Code style
[ ] D1. biff.sqlite columns map formatting
[ ] D2. lint and formatter configuration
I'm also liking that these "review files" give you a convenient place to write up additional feedback. I generally try to write most of my instructions to agents in files rather than typing directly into the prompt.