1. we trained custom models to predict LLM performance (this performs much better than asking LLMs directly to predict performance)

2. we cut off model responses early if they are not performing well, saving on costs versus running them to completion

3. finally we serve the unmodified output of the chosen model, instead of synthesizing the outputs into one, which makes us a model router

But in either case the boundary between the two types of async work is never easy to cross.

What I wanted to build is a way for Claude Code to automatically receive reviews and CP failures from a Github PR and automatically revise code and respond to comments. It looks like with a custom Github PR channel I can get very close to this, although I do wish that a channel can be opened in a running session instead of having to create a new one. Hopefully they add that soon.

The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.

Im curious about what kinds of workloads you see GPU-accelerated compute have a significant impact, and what kinds still pose challenges. You mentioned that I/O is not the bottleneck, is that still true for queries that require large scale shuffles?

At the moment the convention is to only specify the tag, which is not only a security issue as we see here, but may also cause workflows to break if an action author updates the action.