Only one commencement speech about AI is going to get applause: https://www.smbc-comics.com/co... .

"I want to use claude code to run 10 unattended Chrome beta testers [more info about what is being tested and specifics]. Write me one or more md files to execute and give me instructions for enabling Chrome mcp, then give me an sh script to launch 10 separate Chrome instances on macos."

I wrote that exact prompt, more or less, a month or two ago, and then other iterations since then, and it's been working very well.

Using LLMs to create prompts for LLMs to use was a good realization.

This makes me laugh! I see classes at universities and colleges on using AI. Not just in the tech arena either, I'm talking liberal arts--med school, law school, you name.

As best as I can tell, "how to use AI" is more or less "don't be a dumbass."

To be succesful with AI, you need the same skills you need to be successful otherwise. Analyze problems, test solutions, think critically, etc. Unattended vibe coding or turning in of AI slop is the same as people who cribbed essays, copied and pasted from Wikipedia, etc.

IMHO, you still need to be a developer to be able to use AI effectively. If you start with a really solid schema, or an existing framework, AI is great at building on top of that. If you give it specific guidance for what and how you want it to develop code, it can do a good job. It is NOT just "lol write me a network utility lol" -- that is a path to disaster.

I've also had good luck with updating and modernizing older code, migrating to a new frameework, and refactoring.

If i'm using claude code, my steps go something like this.

1. Using plan mode, analyze the code base, create a thorough plan and testing strategy for XYZ (Or I provide SQL schema, or I provide a thorough plan of what I want to do, etc.)
2. Refine Claude plan mlutiple times until I'm happy with it
3. Start with writing a set of unit tests to confirm current behavior
4. Implement the first part of the project (this is not coding the whole thing in one shot)
5. Run unit tests, check for regressions.\
6. Rinse and repeat..

Steps 1 and 2 -- with no code being written -- are probably the most important parts.

I should also add that, imo, this will be a relatively short moment in time. I've seen people who are spinning up dozens of agents at the same time -- backend designer, frontend designer, security consultant, css specialist, etc -- that all work together and iterate amongst themselves.

We've been running a beta test of some new software, and one beta tester out of ~30 people hit an error. We could not reproduce it. Claude took ~5 hours, but using Claude to remote control Chrome, in conjunction with analyzing the state of the backend database, and auditing the codebase, Claude was able to reproduce the error and suggest a fix. In this case, we disagreed with the fix (rather, we went for a bigger logical change as opposed to a bandaid), but we've had really great luck with using Claude Chrome mcp as a beta tester.

Failing that, stroke something else.

You can't pass a law that affects only one person or corporation, not directly. If the law affects a definable group that happens to have only one member, that's constitutional, I think.

So the next president and congress can just pass a 90% wealth tax on wealth over $100B, no?

But, the next president and congress can also declare the SpaceX, for various good reasons known only under national security seals, can't have any more government contracts - isn't that about 90% of its value?

You are correct to recognize that cell phones don't work well for a bunch of reasons as the cause. But your causes suffer some of the same problems. In particular, fertility rates are going down throughout the world, and have been since the 1970s, while almost everything you've listed is US specific in the last 30 years.

Hmm. Just from my own bullshit experience, if you find yourself in an empty room, you probably look to the right and then, naturally, you're moving counterclockwise.

By your powers combined, I am... the British Colonies!

You mean countries who had escaped Russia's grasp asked to join NATO so they wouldn't get invaded by Russia. Fear of Russia made the Baltics ask to join NATO. And of course, Russia then invaded Ukraine, a country not in NATO, showing the Baltics were right to be worried. On top of that, to invade Ukraine and then continue its car with Ukraine, Russia had to remove troops along the borders with NATO countries, showing that the Russian government, for all its claims otherwise, understands that NATO is not a threat to Russia except in so far as it stands in the way of the Russia government's imperialist ambitions.

The main aim of Stop Killing Games is to ensure the practice of rug-pulling eventually comes to an end. They are not trying to save MMOs, for example.

Moreover they don't demand that every game currently on the market comply with open-sourcing requirements: at a minimum, companies always have the option of simply providing customers with adequate notice before shutdown. Open-sourcing the server would be nice, but it's hardly the only way to protect consumers' interests. Scott has, for example, suggested game boxes being marked with an estimated expiry date for online service functionality.

But most importantly: because this is about future games, not the present, the market has time to change. If studios and publishers are designing their games with a fair EOL in mind, then they can make decisions from the get-go to avoid licensing dependencies that they won't be able to release in a possible 'afterlife' version of the game. As suggested by your example of GameSpy in C&C: Generals, when a commercial dependency is crucial to a game's success, it tends to be a client-side library, but typically the problematic dependencies aren't crucial; they're e.g. add-ons for Unity or Unreal that the studio bought to save time. In a world with SKG laws, the providers of these dependencies aren't going to be a stagnant target either—demand for compliant libraries will motivate development of open-source versions.

Interestingly, the will for doing this does exist among game developers; they just need the institutional support from legislation to twist the arms of the studios and publishers. Ross Scott has talked to a lot of devs who are burnt out from having their projects cancelled, leaving them with huge gaping holes in their resumes and portfolios where they've spent years on unreleased projects that are stuck under NDA. In general they tend to see SKG as a path to ensuring the games that do see the light of day aren't also scrapped, which would erode their work histories even further. (Apparently it also just plain feels bad to have your work erased from history. Shocking, I know.)

...it really is the only thing that can suck and blow at the same time.

This is a 30 year old module. It was originally made for MIR and has now been in space for 25 years. Even good engineering is in space is going to start having leaks at that point. Space is really hard.

Fear not! It's entirely possible the category was chosen by an AI. Editorial automation would probably reduce the error rate here.

So then what is the point of Yoda being immensely old? Is he basically 63 in Yoda years?