enjoylife
Joined 13 years ago
Joined 13 years ago
Eg from your share, the model output “I prefer it Scotch-heavy rather than 50/50 because otherwise it gets very sweet.”
It’s basically cribbed this from someone; it literally can’t taste.
The frontier labs are not yet able to do rlvr over mixology/meatspace. So maybe think on how to capitalize on that.
Alas, AGI is not yet here. But I feel like if this OS-level of control was good enough, and the cost of the LLM in the loop wasn't bad, maybe that would be enough to kick start something akin to AGI.
Unless it’s interactive or tied to live data the usefulness of the visualization produced is limited.. it’s a shame and it’s something this tools should pivot towards
If I had to guess this is how eng pitched it to the business to carve out the time to build this tooling. As with all these internally built schemas, ui’s, tooling, etc… they’re never gonna post how much this is actually used relative to the work arounds ds and eng use in their day to day.
This sparked a thought in how a large part of the job is often the work needed to demonstrate impact. I think this aspect is often overlooked by some of the good engineers not yet taking advantage of the AI tooling. LLM loops may not yet be good enough to produce shippable code by themselves, but they sure are capable to help reduce the overhead of these up and out communicative tasks.
> So it seems that panic and recover can be beneficial to performance in at least some situations.
Namely top level & centralized recovery handling. I'll also point out its important your panic recovery must happen in a deferred function if your kicking off new goroutines. For example, your server library probably has default panic recovery on the goroutines handling inbound requests, but any new goroutines you create as part of handling the request (e.g. to parallelize work), will not have this handling built in. See https://go.dev/blog/defer-panic-and-recover for more.