As a developer: yes to the developer and data scientist and data engineer. Scientists and engineers should be responsible for their work.
The BI analyst: maybe, if they're responsible for collecting data that ignores the impact of the service on teens. If they're doing sales-comparisons between Anthropic and OpenAI... eh, I donno.
The janitor: probably not since I don't feel like the deaths are widely publicized and they probably work for a contracting company that handles the building.
Also check out Bubba Ho-Tep. It's a slightly different vibe than Evil Dead, but I enjoyed it.
The "agents" and "agentic" stuff works by wrapping the core innovation (the LLM) in layers of simple code and other LLMs. Let's try to imaging building a system that can handle a request like "find where I can buy a video card today. Make a table of the sites, the available cards, their prices, and how they compare on a benchmark." We could solve this if we had some code like
search_prompt = llm(f"make a list of google web search terms that will help answer this user's question. present the result in a json list with one item per search. <request>{user_prompt}</request>")
results_index = []
for s in json.parse(search_prompt):
results_index.extend(google_search(s))
results = [fetch_url(url) for url in results_index]
summarized_results = [llm(f"summarize this webpage, fetching info on card prices and benchmark comparisons <page>{r}</page>") for r in results]
return llm(f"answer the user's original prompt using the following context: <context>{summarized_results}</context> <request>{user_prompt}</request>")
It's pretty simple code, and LLMs can write that, so we can even have our LLM write the code that will tell the system what to do! (I've omitted all the work to try to make things sane in terms of sandboxing and dealing with output from the various internal LLMs).
The important thing we've done here is instead of one LLM that gets too much context and stops working well, we're making a bunch of discrete LLM calls where each one has a limited context. That's the innovation of all the "agent" stuff. There's an old Computer Science truism that any problem can be solved by adding another layer of indirection and this is yet another instance of that.
Trying to define a "limit" for this is not something I have a good grasp on. I guess I'd say that the limit here is the same: max tokens in the context. It's just that we can use sub-tasks to help manage context, because everything that happens inside a sub-task doesn't impact the calling context. To trivialize things: imagine that the max context is 1 paragraph. We could try to summarize my post by summarizing each paragraph into one sentence and then summarizing the paragraph made out of those sentences. It won't be as good as if we could stick everything into the context, but it will be much better than if we tried to stick the whole post into a window that was too small and truncated it.
Some tasks will work impressively well with this framework: web pages tend to be a TON of tokens but maybe we're looking for very limited info in that stack, so spawning a sub-LLM to find the needle and bring it back is extremely effective. OTOH tasks that actually need a ton of context (maybe writing a book/movie/play) will perform poorly because the sub-agent for chapter 1 may describe a loaded gun but not include it in its output summary for the next agent. (But maybe there are more ways of slicing up the task that would allow this to work.)
As with dating apps, if the mental health recommendations actually worked then engagement would go down. I doubt they even need a human putting their thumb on the scales; the algorithm optimizes engagement in whatever way it needs to.
Not "someone". It has to be the DNC. And it need to show me the text where it broke up with Israel. And it needs to apologize to Bernie. Also I will still not like its candidate.
If I tried to promote a candidate on my own or talked to any other org, than DNC would think I wasn't serious about how much I'm not going to vote for its candidate.
It's basically impossible to tell with these between the example being totally fabricated, true but only happens some small percentage of time, true and happens most of the time but you got lucky, and true and reliable but now the company has patched this specific case because it blew up online.
There are automated checks which can help enforce correctness of the parts of the code that are being checked. For example, we could imagine a check that says "when I add a sprite to the list of assets, then the list of assets becomes one item longer than it was before". And if I wrote code that had a bug here, the automated check would catch it and show the problem without any humans needing to take the time.
But since code can do whatever you write it to do, there's always human review needed. If I wrote code so that adding a sprite also sent a single message to my enemy's Minecraft server then it's not going to fail any tests or show up anywhere, but we need humans to look at the code and see that I'm trying to turn other developers into a DDoS engine.
As others replied, you could choose to find and run someone's branch. This actually does happen with open-source projects: the original author disappears or abandons the project, other people want changes, and someone says "hey I have a copy of the project but with all those changes you want" and we all end up using that fork instead.
But as a tool for evaluating code that'll get merged, it does not work. Imagine you want to check out the new bleeding-edge version of Godot. There's currently ~4700 possible bleeding-edge versions, so which one will you use? You can't do this organically.
Most big projects do have something like beta releases. The humans decide what code changes to merge and they do all that and produce a new godot-beta. The people who want to test out the latest stuff use that and report problems which get fixed before they finally release the finished version to the public. But they could never just merge in random crap and then see if it was a good idea afterward.
I enjoyed watching the X-Files as a teenager, but I keep wondering if it wasn't responsible for a bunch of current-day brain-poisoning.
Inside the US, there's a pretty substantial amount of pro-Russia propaganda. For years the NRA was a dominant force in politics and it was completely compromised by Russia. The current US president is a Russian asset. Etc etc.
Israel is by far the larger threat to us elections
I'm not sure about "by far", but it doesn't really matter. Two things can be true at the same time. Israel and Russia are both significant threats to the US, both have obtained substantial control over US politicians, and both are threats to their neighbors.
And also there's overlap because Israel and Russia are partially aligned. (See for example how reluctant Israel has been to offer any support to Ukraine.)
I'd assume that somewhere later it explains what "N/A" and "*" mean here, but you can see that "Under 55" picks Sanders while "50-64" picks Clinton. So my guess is that "N/A" means that the size of that group is too small for them to have confidence in it. When they combine the two columns together, there's enough (that's why there's data show in "Under 55").
Like (I'm just making up numbers), maybe they determine that they need 100 respondents to have any statistical power. And they got 70 in the 18-34 group and 87 in the 35-49 group, but 103 in the 50-64 and 450 in the 65+.
You can see a hint of this in the sampling error, also: the larger number on 50-64 means that was the smallest of the groups shown. Meanwhile "55 and Older" is clearly a larger group than "Under 55".
Probably, "*" means "no responses". They don't want to say "0%" because they know it's not true that there are literally zero younger voters who had no opinion, but none of the people they surveyed answered that way. That's another hint that the group is small.