It's sort of like the opposite of this idea:

https://en.wikipedia.org/wiki/Roger_Fisher_(academic)#Preven...

> Fisher [...] suggested implanting the nuclear launch codes in a volunteer. If the President of the United States wanted to activate nuclear weapons, he would be required to kill the volunteer to retrieve the codes.

>> [...] The volunteer would carry with him a big, heavy butcher knife as he accompanied the President. If ever the President wanted to fire nuclear weapons, the only way he could do so would be for him first, with his own hands, to kill one human being. [...]

>> When I suggested this to friends in the Pentagon they said, "My God, that's terrible. Having to kill someone would distort the President's judgment. He might never push the button."

> — Roger Fisher, Bulletin of the Atomic Scientists, March 1981[10]

There should be two knives so the volunteer can defend themselves if they don't think starting a war is worth it.

That's so idealistic. We should know by now the reality of power and what kind of people end up in power. Anyone who could climb all the way to the top would kill the volunteer without a second thought, and then go smile on TV.

You're confusing lazy cynicism with realism. Patrick Bateman is a fictional character. The vast, vast majority of people, including even most soldiers, and definitely pretty much all businesspeople, no matter how unscrupulous, do not have the capacity to violently murder a person they know and harbor no ill will towards with their own hands on short notice.

maybe they should make the person with the codes black. I think several cold-war presidents probably wouldn't have a problem with that

The whole damn point behind the idea is to achieve the exact opposite. Make it someone, through whatever criteria, whom the president will have a problem killing, so he'll only do it under the most extreme circumstances.

The "RPG Game" is hard to judge since it was produced over "multiple turns". The impressive version would be if it basically got a working game on the first attempt, and the prompter gave some follow-ups to tweak feel and style.

However, I think what actually happened is that a skilled engineer made that game using codex. They could have made 100s of prompts after carefully reviewing all source code over hours or days.

The tycoon game is impressive for being made in a single prompt. They include the prompt for this one. They call it "lightly specified", but it's a pretty dense todo list for how to create assets, add many features from RollerCoaster Tycoon, and verify it works. I think it can probably pull a lot of inspiration from pretraining since RCT is an incredibly storied game.

The bridge flyover is hilariously bad. The bridge model ... has so many things wrong with it, the camera path clips into the ground and bridge, and the water and ground are z fighting. It's basically a C homework assignment that a student made in blender. It's impressive that it was able to achieve anything on such a visual task, but the bar is still on the floor. A game designer etc. looking for a prototype might actually prefer to greybox rather than have AI spend an hour making the worst bridge model ever.

The whole point of the bill is to create a cause of action for the Attorney General to sue companies. In the bill, they say the damages are up to $2,500 per negligently affected child ($7,500 if intentional), so it doesn't matter how many non-children it affects. E.g. if the OS/appstore/accounts/application is in the context of a workplace that only employs adults, none of this matters.

The bill doesn't define "accounts", so it's entirely possible local users that a human signs into would count.

The saving grace is that obviously they have no idea what a Linux distribution is, and only the Attorney General can bring action, so there isn't much risk of the AG suing Debian.

"User" in the bill actually means child, so cups etc. don't apply.

The crazy people depend a lot on routes, the part of the city, and the time of day. E.g. the 1 (Sacramento St/California St) is basically fine all the time. The 38 (Geary) and 14 (Mission) are OK during the commute rush since they are packed full of commuters, but outside of those times, you will eventually see all kinds of unsocial behavior (shouting, fights, defecation, etc.), especially closer to civic center/tenderloin/mission.

I've previously struggled getting LLMs to manipulate tscn/tres files since they like to generate non-unique uids. Despite being text files, the godot tscn/tres files are normally meant to be manipulated by the editor and need to define and reference unique ids. The editor always generates completely random alphanumeric strings, but LLMs like to use names or placeholders (e.g. "aaaaa1", "example", or "foobar") for the ids.

The linter in the article that detects duplicate uids is interesting. Obviously the article is about creating a bunch of harnesses for the LLM to be productive. I wonder how many problems can be transformed like this from something LLMs just can't do reliably to something they just need to burn credits for a while on. The LLM probably can't tell if the games are fun, especially with it's rudimentary playtesting, but who knows.

regarding the non-random ids: I had this issue with uuids. Now I have "Never write your own ids. Always use uuidgen to generate real ones" in my AGENTS.md and haven't had this issue for a long time now.

I'm playing around with a tool to generate the IDs for me. I'm honestly not sure if it'll be an improvement since it likely means more tokens/context than just letting it YOLO IDs.

The model makes a huge difference. I tried this about a year ago and Claude occasionally got it right. These days, it seems to get it right on the first try most times and then always self corrects after. Codex 5.2 (I haven't played with 5.3 enough yet) gets it wrong more often than not, and frequently doesn't call the linter; I'm willing to accept that my bloated CLAUDE.md might be a bad fit for Codex and causing this to fail.

Generally yes, but if you use e.g. the parallel consumer, you can potentially keep processing in that partition to avoid head-of-line blocking. There are some downsides to having a very old unprocessed record since it won't advance the consumer group's offset past that record, and it instead keeps track of the individual offsets it has completed beyond it, so you don't want to be in that state indefinitely, but you hope your DLQ eventually succeeds.

But if your DLQ is overloaded, you probably want to slow down or stop since sending a large fraction of your traffic to DLQ is counter productive. E.g. if you are sending 100% of messages to DLQ due to a bug, you should stop processing, fix the bug, and then resume from your normal queue.

Their options should be priced lower, but the common stock isn't valued according to the $5.15B. They raised $300M at $12B and $425M at $7.4B, which are both under water, so those shareholders will use their liquidation preference to get paid at least 1x. Assuming those rounds owned 7% of the company, there is at most $4.4B left for the remaining 93% of shareholders. That's about 8% less. If they deducted fees, legal services, or retention packages or had worse liquidation preferences or more underwater rounds, then it gets even lower.

You have to exercise the options or let them expire. You normally have 10 years not 7, but if a company comes up on 10 years after they issued their first options, they might try a tender offer to buy some employee shares. If your 10 year old "start up" shares can't be sold anywhere, then they probably aren't worth exercising. A company that can't provide liquidity to employees for 10 years will probably never do it.