The best way to stop this is to make those safeguards stronger and completely shut down the chat to refer users to seek help from a better service. Unfortunately those services don't really exist yet.
There would be false positives and that'll be annoying, but I think it's worth it to deal with some annoyance to ensure that general purpose AI assistants are not used for counseling people in a vulnerable mental state. They are not aligned to do that and they can easily be misaligned.
When you find a rigid workflow that is both widely applicable and useful, that's how the most valuable companies are made. Those workflows can scale up with little intervention giving them incredibly high yield.
I think the new challenge is introducing flexibility in a controlled manner so we can minimize the added inconsistency needed to achieve broader goals. That way the workflow can find the right balance between robustness and flexiblity for the task at hand.
The pilot was not part of the conference call!
What froze was not hydraulic fluid for actuators (in some hydraulic line), but hydraulic fluid in the shock absorbers.
The last paragraph of the article and seems to be missing a few words and reads as the investigators blaming the people directly involved, which is essentially a complete opposite of what conclusions of the report say.
somewhat sensationalistic?! The article clearly tries to give the impression the pilot was on the call:
> A US Air Force F-35 pilot spent 50 minutes on an airborne conference call with Lockheed Martin engineers trying to solve a problem with his fighter jet before he ejected
Knowing the quality of media these days, it wouldn't surprise me if it CNN just got it really wrong, but also wouldn't surprise me they'd do some brazen lie for clicks.
Edit: Reading the report, it seems like you, dear fellow HN commentator, got it wrong in this case, sorry to say :) Seems indeed the pilot itself was on the call:
> The mishap pilot (MP), assigned to the 354th FW, ejected safely before impact. [...] The MP initiated a conference call with Lockheed Martin engineers. The MA held for approximately 50 minutes while the team developed a plan of action
Page 35 from https://www.pacaf.af.mil/Portals/6/documents/3_AIB%20Report....
I'd compare it to being in the room with someone on a conference phone call and they're relaying the conversation to you and them both ways. I would still say you were participating in the call even though you weren't directly on the call.
Also, he did initiate the call so "F-35 pilot held" is imprecise, but not totally wrong. Either way, the pilot was in an active tech support session with the plane engineers, making this one of the most intense tech support calls in history.
How does the overhead of managing the 50 agents affect overall resource utilization? Also, how does the system handle errors in one of the child streams? Does it cascade and halt the entire process, or is there a mechanism for retrying or gracefully degrading?
Looking forward to seeing how this develops!
Of course, more streams means more resource utilization, there's not getting around that, but that's the cost of parallelism. The use of `yield*` should keep the overhead to a bare minimum. Since the streams are being left alone and aren't consumed until needed, that should preserve some of the back-pressure behavior, although I do need to look into that more deeply.
How the system handles errors probably doesn't have a single solution that works for all frameworks, so I think it should be up to the specific requirements of each use case, but there's also definitely more work to do to explore the options and the patterns.
These are all things I definitely want to hear ideas for as well!
The next thing I'm exploring is applying these patterns to web rendering which will be a real stress test for how they can be used.