Fixed that for you.

The input is sooo much more than your prompt, that's kind of the point.

Where does that come from?

"And no, I wouldn't ever give it a year of changelog.md."

No, instead you'll "[run] your git history through a cheap model". Except it's "overkill and error prone". So you're writing it up yourself? You didn't do the work, how do you know what the pitfalls and traps are?

It also just feels a little nefarious. There isn't much reason to change between those licenses in question beyond to allow it to be more tightly integrated into something commercial and closed-source. In which case, having an LLM write a compatible rewrite _in a new project_ seems reasonable at the current moment in time. It's this intentional overriding of the original intentions, seemingly _for profit_ as well, that is the grossest part, because the alternatives are just so easy and common.

Don't limit, notify.

Has worked for TV (and movies to an extent, though theaters do limit somewhat, must have been some litigation around that...) pretty much forever.

I think your example exemplifies this. Among Us is not inherently adult-only, but since it's multiplayer, they don't control what other player say and do. Definitively mixed content. They should not be asking you to verify, they should be telling you and letting you decide if your kid can play.

I kinda can't beleive their lawyers decided to go that route and assume all the PII responsibility that comes with collecting that data, instead of just making the "it's online and there might be d-bags on our servers" rating much more obvious and explicit.

Hint: it actually doesn't work at real depth, and why not is fairly well explained in TFA: they hype always overestimates the depth of the field. So these advances do help to make easy thing easy (in the case of LLMs because they have been trained on a billion examples of the easy stuff), but don't really end up helping with the hard things (because they really only make new things that weren't encompassed in their training by getting lucky, and because tedious things are different than hard things).

Just as keeping most of the structure of a 4-novel-long story in your head is not something everyone can do, hence why being a successful author is not something that everyone can do. Start telling everyone that being a novelist is easy money, though, and you'll see Comp 101 courses filling up and the attrition rate correspondingly go through the roof.

Real democratizing or programming is free access to compilers, SDKs, etc. AI coding does nothing to help that. In fact, it hurts it, because those non-programmers only get access to the AI tools on the terms of the AI companies. Sure they could train their own models, but then we're back to having to learn things.

(From GP) "AI coding sometimes sacrifices correctness or cleanness for simplicity, but it will win and win big as long as the produced code works per its users' standards."

Those user's standards are an ephemeral target for any software beyond a one-shot script or a hobby project with minimal user:dev ratio. That incorrect and unclean code simply isn't conducive to the many iterations needed when those "users' standards" change. And as we all know, that change is _inevitable_, and oftentimes happens before the software in question has even had a single release! Get ready to throw ever more tokens at trying to correct and clean if you ever really "win big" and need to actually support the product.

It's very much gross short-sighted thinking that goes right along with the gross short-sighted thinking providing all the [fake] value around this crap.

So instead you give it a years worth of changelog.md?

"Better to have pre-processing steps, that find (and maybe summarize) what's relevant, then only bring that into context"

So, not a list of commits that touched the relevant files or are associated with relevant issues? That kind of "preprocessing" doesn't count?

"You can do that by running your git history through a cheap model, and asking it to extract the relevant bits for the current change. But, that can be overkill and error prone, compared to just maintaining markdown files as you make changes"

And somehow extracting the same data out of a [relatively] unstructured and context-free (the changelog only has dates and description, that will need to be correlated to actual changes with git anyway...) markdown file is magically less error-prone?

However Win2K wasn't really marketed to consumers as there were still some minor compatibility issues: particularly the DOS emulation was not great, so getting things like older games to work often required lots of tweaking to the launch process, and some things still might never work. Those compatibility settings got more options, saner defaults, and more automatic settings, in XP and later to go along with the full commitment of NT for everyone.

So, while DOS-based WinMe was actually released after Win2K, it was just a stop-gap to bring some more internet things, directx, and media player stuff, to home users while NT 5.x got it's compatibility and driver model in order. Except it was notoriously unstable, generally hated, and mostly forgotten.

In fact, putting buttons along either _side_ of the windows would be a better fit on the wider aspect screens we use nowadays.

Your bad UI example of resizing windows is way less about the round corners or lack of obvious grab area (handle). It's more that the handle is way too small. It's a couple pixels (maybe just one?) wide/tall on screens that are thousands of pixels wide! It's just too easy to overshoot. I'd say it comes from the obsession with minimalism and flat design such that there is almost no visible seperate border to act as a target. Combined with trying to remove ambiguity as to which window the click should go to (if you click two pixels "outside" a window, should the click go to the window beneath or be interpreted as trying to grab the border?), the grab handles are tiny, almost matching the actual (lack of) pixels of the border, instead of being a usable target to click on.

To me it points to a lack of usability testing, or at least lack of generalized usability testing, ie: they tested their own workflows, which seem to be just always leaving windows as the OS creates them initially, or maximizing everything, not much resizing at all. Similarly, generally testing a [mostly] keyboard interface is tough to do thoroughly without providing a thorough cheat sheet. You know the commands because you made them, easy to test how you work, but others need to learn them first.

This could be the biggest takeaway: iterating without a goal is silly. Though, honestly, it should be the default. If you're creating a new paradigm without ever knowing the problems you're supposed to fixing, you're doing it wrong!