I'm just talking about statistical patterns. I know little about Microsoft patches. I abandoned Windows in 2001, right around the time XP was released, and have never looked back.

Not remotely similar to my experience. Granted I'm writing Rust, and the Rust compiler is *really* picky, so by the time the agent gets something that compiles it's a lot closer to correct than in other languages. Particularly if you know how to use the type system to enforce correctness.

Yes, you have to know how to write tests. A few decades of experience helps a lot. I find I actually spend a lot more time focused on the details of APIs and data structures than the details of tests, though. Getting APIs or data structures wrong will cost you down the road.

Also, I suppose it helps a bit that my work is in cryptography (protocols, not algorithms). The great thing about crypto code is that if you get a single bit wrong, it doesn't work at all. If you screw up the business logic just a little bit, you get completely wrong answers. The terrible thing is that if you get a single bit wrong, it doesn't work at all and gives you no clue where your problem might be.

Of course that's just functional correctness. With cryptography, the really hard part is making sure that the implementation is actually secure. The AI can't help much with that. That requires lots of knowledge and lots of experience.

Deep experience is absolutely required. My antennas are quite good after 40 years.

You really have to know what questions to ask, and what answers not to accept. It also helps to know what kinds of errors the LLM makes. It never outright lies, but it will guess rather than look, so you have to know when and how to push it, and how to manage its context window. When stuff starts falling out of the context window the machine starts guessing, approximating, justifying. Sometimes this means you need to make it spawn a bunch of focused subagents each responsible for a small piece of the problem. There are a lot of techniques to learn to maximize the benefit and minimize the errors.

Yeah, I am definitely not doing UI work.

Speak for yourself. I wrote Android's Keymaster implementation in less than a month, and it was about that size, and then re-wrote most of it in a week when it turned out I'd made some core assumptions that Qualcomm couldn't match in their implementation. It was relatively bug-free for a decade -- even when a third-party security research lab spent a month scrutinizing it. They found a handful of things, but nothing serious. I was amazed, especially since I'd seen the reports they turned in on some other code.

That's just one example. In my nearly 40-year career I've had a half dozen crazy-productive weeks like that, and usually when working on particularly-complex bits. If you haven't had that experience, that's unfortunate. It's not something I could do frequently (or would want to), but it's a glorious feeling when you're that deep in the zone.

When Gmail was invite only, was sent a note for that, so grabbed it. No complaints ever since.

The github page that's being pointed to has already taken down the code. Unlike the fools that posted the WinAmp source code, they actually know how to wipe out the commits. However, I found that searching github with leaked Claude Code language:TypeScript was enough to find several mirrors of the code.

That's the challenge for the source selection/proposal evaluation. It's tough to write independent criteria that allow you to throw out a bid as "implausible". (I remember one where the total travel budget for the 3 year period of performance was 2 people, 1 week, 1 trip per year. This was on the same project where I was on 75% travel. I asked, 'How do we mark this as bullshit?' and was told, "Well, that goes into the overall evaluation criterion for 'cost realism'. That group won the bid, by the way.)

Stuff like this seems to be asking for the result is a beefing up of TOR-like networks. You can't levy tariffs on something you can't show happened, and if streaming is taxed, people will just head to the high seas, perhaps have a connection to a private channel that is brokered by a cloud service, similar to how a lot of remote access systems work. Maybe even something like TailScale, but bigger, where people can get keyed access to tagged servers, with the SDN handling encryption, even routing of packets on top of normal ISP routing.

That surprised me, too. TypeScript is a very poorly-congealed ("designed" seems a bit strong) language.

Of the two popular scripting languages - python and ruby - python probably makes more sense as you can compile into actual binaries if you want.

For speed and parallel processing, which I'd assume they'd want, they'd be better off with Tcl or Erlang, both of which are much much better suited to this sort of work.

Then they should have used Tcl.

The entire code is there to view. If worried about a backdoor, feel free to do a clone and go examine it.

I am all for office suite, be it OpenOffice, Libreoffice. I prefer if at least 1-2 would get backing/funding/devs to work on it, preferably more than one, but a F/OSS office suite will be a major gain. Especially if it supported storing documents via various cloud providers, as well as document versioning. Microsoft Word used to allow one to have one document with a ton of versions in it, which made it easy to find an "oops", and go back to it, or go back to a line of thinking before it was erased and changed.

This is important, as an Office app is one of the things used the most on the job.

hey, not everyone follow AI development and are up to date with all the details

for me, most of the info was new

That's because I know better. You'll figure it out someday as well. It's a little surprising you haven't figured it out already.

I suspect you might know already, even if you don't want to admit it. That's why you're attacking me instead of addressing my claim.

There are other dangers to using AI far worse than just some shoddy code and sketchy documentation, such as cognitive atrophy and loss of brain plasticity, that should concern you as well.

There is also a growing body of evidence that calls the productivity gains into question. Is AI really worth the cost?

ED: "But it doesn't work for gravity with linear curvature"

Relativity = gravity is represented by the curvature of spacetime. Curvature is linear, R. The formula treats curvature linearly. As things get closer and curvature spikes, the math just scales at a 1:1 rate

Quadratic gravity = Squares the curvature. Doesn't really change things much when everything is far apart, but heavily changes things when everything is close together.

Pros: prevents infinities and other problems when trying to reconcile quantum theory with relativity ("makes the theory renormalizable"). E.g. you don't want to calculate "if I add up the probabilities of all of these possible routes to some specific event, what are the odds that it happens?" -> "Infinity percent odds". That's... a problem. Renormalization is a trick for electromagnetism that prevents this by letting the infinities cancel out. But it doesn't work with linear curvature - gravitons carry energy, which creates gravity, which carries more energy... it explodes, and renormalization attempts just create new infinities. But it does work with quadratic curvature - it weakens high-energy interactions and allows for convergence.

Cons: Creates "ghosts" (particles with negative energies or negative probabilities, which create their own problems). There's various proposed solutions, but none that's really a "eureka!" moment. Generally along the lines of "they exist but are purely virtual and don't interact", "they exist but they're so massive that they decay before they can interact with the universe", "they don't exist, we're just using the math out of bounds and need a different representation of the same", "If we don't stop at R^2 but also add in R^3, R^4, ... on to infinity, then they go away". Etc.

The theory isn't new, BTW. The idea is from 1918 (just a few years after Einstein's theory of General Relativity was published), and the work that led to the "Pros" above is from 1977.

The hope is to lock in the contract with totally unrealistic cost/schedule, and then make up the financial risks through Engineering Change Proposals. Those ECPs reflect both requirements instability and cost/schedule "rebaselining" instability. I think managing ECPs is what separates the really good Program Managers/System Program Officers from the merely competent PM/SPO.