"a short description of the current functionality, and a well-trimmed list of 'lessons-learned'"
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?
If Theseus recreated the ship from the original plans but all new parts, created new plans, and then burned the original plans and original parts, it is the same ship? If yes, what if they (with some ship building magic) converted to the second one to have a completely open floor plan inside? Still the same ship?
I think the reimplementation in question rubs people the wrong way because of the intentions of parties on both ends and the ignoring of one of them by the other (erasure of, from some POV). The original author of the code obviously chose the license they did intentionally (copyleft "keep it open" reasons, seemingly). And the the rewrite author has their intentions as well (unknown beyond "less restrictions on derivative"). The problem comes when those intentions conflict, and in this case the rewrite author basically just ignored the usual convention to resolve the conflict, which is forking or just starting a new project. Claiming "I've maintained it for a while so I can do whatever I want" is kinda gross because is just completely overrides the original authors' intention with their own. They're basically saying "my intentions as maintainer are more important than the creator's", and that doesn't feel even. The "is it a real clean-room" due to prior exposure due to LLM training and working on the codebase is always going to be contentious. But "should I override erase someone else intentions?" question is easy to answer. No. Especially since we have come up with so many ways to make it easy not to (forking is practically free, the abstraction of APIs is powerful, etc).
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.
That's not a mistake. You'd be getting spam marketing anyway, why not make sure it's something obvious? I always pick the oldest possible age when asked, just to mess with their data, because they shouldn't fucking care.
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.
If the content is mixed, it makes even more sense to have the content supply the age data. This is how it has worked with broadcast media pretty much forever. TV shows and movies gain their ratings based on the worst case on display. IE: a show doesn't have to consist entirely of swearing to gain a "language" warning, it just has to have some. Definitively mixed content.
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.
Because programmers made the LLMs, and they first applied it to the problems they know, so the examples of "replacing a programmer" are abundant. Then the hype train rolled in and now it's suddenly going to replace everything, just that software engineering is the low-hanging fruit since they already have "proof" that it works in that domain.
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).
CS programs have high attrition rates because programming or "coding" has been touted as easy money for a couple few decades now. When people find out it's not so easy, they bail. Holding a few layers of abstractions in your head is not something that everyone does easily.
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.
Anyone could make their own tools before this as well. Just needed to learn something first.
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.
Then those "upgrades" will come down to just using an LLM as a lexer/parser for natural language and then calling a compiler on the generated AST. Except natural language is often very very ambiguous and removing that ambiguity by limiting the possible inputs just brings you closer and closer to a high level programming language. So why not just start there and use something way more efficient than an LLM for lexing/parsing? I'm not saying current high level languages are the endgame, they can certainly be improved and specialized and made faster. Just that the current architecture does not need to be replaced by statistical modeling, especially when you talk of making them deterministic with starting seeds... why bother forcing an LLM to follow the same deterministic path when we already know how to make tools to do that?
I hope people can see that "winning big" using that process is very unlikely NOT to be "winning long term".
(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.
But at least the coder has potential to have learned something. The future agent needs to be given all the context the past agent had, or else it's basically starting from scratch and is likely to make all the same mistakes.
"You want to avoid dumping in a bunch of data (like a year's worth of git logs) and telling it to sort out what's relevant itself"
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?
Why doesn't this apply to human collaborators as well? If you need all this extra metadata to comprehend the changes, isn't that kind of going backwards? You spend time (setting up the agents, building extensive prompts that explain soooo much of how to do things, adding to whatever markdown file you think controls the parrot) and money (so many token$), to get code that you don't comprehend, and just decide to fill your repo with all of the above to... what exactly does all this accomplish? So you can later ask another parrot to "fix" something?
Actually I'd say Win2K was the merge point: its internal version is NT 5.0, while XP is NT 5.1 & 5.2. The Win2K UI is the first NT truly usable in a home situation, and last and best iteration of the Win95 UI before the plasti-color of XP. (Yes, that UI was last available as XP's "Classic Theme", but I'm giving it to 2K because XP doesn't really change anything.)
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.
How is it more logical? Upper right places them close to the other window controls. Also continues the down-then-right order of most of the other controls.
In fact, putting buttons along either _side_ of the windows would be a better fit on the wider aspect screens we use nowadays.
Pointers are still very useful for many paradigms. Think about something like Blender or a game level editor: there can be _a lot_ of controls visible at once, trying to navigate them all with the keyboard is just unfeasible. And doing a fully context sensitive setup to limit visible controls, like the MS Office Ribbon, is also infeasible because the changes would be happening almost continually as different objects are selected and modes are chosen.
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.
"From the first lab studies it became clear that we needed a baseline with Windows 3.1, to better understand what problems existed prior to Windows 95 and what problems were unique to the new design."
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!
Every major first party product has been using their own siloed UI framework since like 2003-ish. Visual Studio has always been one of the worst offenders. Sometimes the new UI components in a VS became the new normal for the rest of the first party stuff, but it was usually right about the time a new VS came out with a new paradigm. That's slowed a bit with the last bunch of VS releases being basically the same UI with different toolchains and default plugins, but it's still quite different from the rest of the OS. It's really pretty silly.
Fixed that for you.
The input is sooo much more than your prompt, that's kind of the point.