biff

2026-02-11T01:56:06.928109Z

so I've not been an early adopter of all this AI stuff, but I started trying it out for real a couple weeks ago and it is pretty awesome. if anyone else hasn't tried it out, now's a good time to get in... I've been using Claude code at work and github copilot agents for biff/side project stuff. Claude code is easier to get going with since it's running in your regular dev environment, but IMO kicking off background agents to do stuff autonomously in their own env (and without having to ask you "can I run this commend" every 90 seconds) seems like where most of the value is gonna be long term. you just have to do some more initial set up work to make sure the agent env has everything it needs installed. some biff-relevant stuff I've been noodling on over the past week: • The possibility of developing apps entirely from my phone with copilot agents is very attractive since I have kids and time at my desk is limited. to aid that, I've got a template hello world clojure project where all you have to do is go into the github repo settings and enter an api key for http://fly.io, then commits to master get auto deployed to a fly app and open PRs get their own ephemeral deployment with a link auto-posted in the PR comments. both environments scale to 0 by default so it's cheap. (and after you've launched, if the cold-start time is too much, you can have the prod deployment keep at least one warm instance running). so the whole dev-test-deploy cycle can happen from a mobile web browser. • I'm writing up a big markdown file with clojure web dev recommendations for coding agents. like a next-gen version of biff that's just docs, no code... except for agents, docs are code, so Bob's your uncle. application repos can depend on that via git submodules which github's dependabot understands, so whenever I update the markdown file, app repos will get an automated pull request to upgrade. and the app repo's Claude.md file can have a note to look at the markdown file in that other repo. I'm still thinking through implications of the biff-as-markdown thing... e.g. maybe I'll end up moving toward putting any code I write into separate libraries instead of one big com.biffweb namespace. agents can probably handle the mixing-and-matching of libraries pretty well, so maybe it becomes more important to just explain what the recommended parts are, then agents can figure out which parts they need. which also means that the experience of swapping out parts could get better: you just say "make me a biff project but use reframe", or "use datomic", or any combination of whatever you want. in the biff markdown thing I can have sections like "if you want to use reframe then look at this guide and/or helper library" etc, but there wouldn't have to be someone maintaining an alternate starter project that uses whatever alternate parts you're wanting to swap in.

🙌🏼 1
🚀 2
2026-02-11T02:09:08.380459Z

this could give me an interesting/tighter feedback loop for what docs are needed: I'm planning to start out with this doc being somewhat minimal (a bunch of bullet points rather than fully fleshed-out reference docs like on the biff website), and then start developing a few different apps with agents. then I can see what things the agents actually need extra guidance on instead of guessing. for the sake of humans, I could then have the agents generate the fully-fleshed-out docs by looking at both the recommendations doc and the biff apps I've been developing, since those apps will be verified to be doing things the recommended/Jacob-approved way.

2026-02-11T02:10:11.816979Z

and keeping that tutorial project up-to-date will be a lot easier!