Much decision-making is tacit or qualitative. Making our OODA loops more legible is the first step towards observability & steerability. AI systems might help us codify this nebulous process. But how will it be trained to do this, and on what data? We don’t have good primitives or tooling for this.

The article I most want to read right now is a detailed breakdown of prompt engineering project from somebody who hand-wrote their own simple automated evals and then used those to iterate on a prompt over time, measuring the impact each change had on their eval score and shipping an improved app

We used the new @inngest.com test helper library together with @vitest.dev, works smoothly so far! ✨ github.com/inngest/inng... (clerkDeletedAt is our own tombstone flag using event timestamp as proxy—doesn't actually exist on Clerk because the whole record gets deleted there) #buildinpublic

Today: updating our webhook integration tests (going from NextJS route handler -> @inngest.com step fn). Yesterday: manual tests, collating notes+samples of Clerk webhook event payloads which differ from docs (as do the libraries’ exported types) to send to support. #buildinpublic

Collapsible threads would be neat (there’s a feature request for this on GitHub)

Would you look at that. GitHub has added support for Bluesky handles on your GitHub profile.