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.

Andric@andric.dev · 2y ago

I don’t really want to prompt an AI system. Instead I want it to passively watch what I do as I do things, talk to me to understand what I’m thinking as I do them, and progressively learn from me. Over time, it should understands tacitly what it’s like to make certain decisions, and then do them.

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)

Wes Bos@wesbos.com · 2y ago

Turned on threaded mode right away. Big fan of this UI. I do wish that chained replies were the same level, and replies to those were threaded though.

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

rob@robschn.com · 2y ago

Skies looking pretty blue @github.com now 😎