No one can hear the failure of their consumer platform business over the massive flow of money for their cloud and office businesses.

If they shrugged and canned the entire Xbox and Windows things entirely, that's less than 9% of their revenue, and likely an even tinier portion of their profit. They would probably also lose all their consumer Microsoft 365 except people who never check and cancel subscription services, but that's probably similarly tiny in the scheme of the business.

You basically have a story of robust cloud revenue and also as I understand some 'rotation' in the market as investors decide that the AI darlings are probably going to be already as high as they can get for a while, and it's time to cash in and switch to other companies that either seem plausible for share price growth or at *least* actually profitable today with dividends and/or stock buybacks. So the viable quarter came at just the right time to catch investors looking to cash out of their big AI investments for the short term.

But maybe they have?

Windows+Xbox was less than 10% of their revenue. They note it is in decline and looking at the bulk of the revenue, not much of it seems vulnerable to people just not caring about Windows. Their cloud business is the bulk of their business and it is not particularly sensitive to OS selection on desktops.

One might argue that Microsoft 365 is at least in part tied to the Windows platform, but in my experience non-Windows businesses still buy into it, even if their users are largely relegated to browser based access only. At this point they have businesses so scared of not having it, they would have it even if they were just phones and ipads. You *never* want to risk a customer or partner sending you some office document that can't be read, and whether or not other options are actually capable hardly matters in the face of the *impression* that anything less than Microsoft is a risk.

The biggest unknown that I think would be sensitive would be the 'consumer cloud' portion of Microsoft 365. That's going to be mostly people who clicked through the Windows built-in advertising for using Microsoft 365 as storage and backup for their laptop and add-on software from device sales that prod users to up-sell to Office. The release doesn't make it clear what the absolute number there is, but I seem to recall hearing that's actually a pretty small number too.

Microsoft is primarily a cloud and Office company now, and I'm wagering the markets have largely already accepted that.

They have steering wheels.

Yeah, LLM is tricky since sounding correct is the priority, and being correct is a side effect of sounding correct.

Business executive style behavior.

I'm not confusing anything. I'm saying you are applying a rather picky definition of 'cost' to disagree with the assertion that 'using fewer tokens is a strategy being used to reduce AI cost'. The assertion makes sense so long as you don't get very weird about limiting the definition of 'cost'

Code analysis is a bit more unambiguous in terms of value, as long as the findings aren't taken *too* seriously. It has impossible attention span and can spot real issues, or failing that a mistaken issue can highlight something 'off' and inspire a true finding. It will also indicate lots of false positives, but at least the consequences can be limited to wasting your time so long as you take care to analyze.

The code gen is a bit more harrowing since it requires human vigilance to correct the problems in ways that humans are just not good at (the AI makes output that *looks* right, and you have to be really used to people lying about what they think they know to not give such output the benefit of the doubt.

In theory, same way they know the submitted code wasn't ripped of from the contributor's closed-source employer without authorization: they don't.

You can still have a policy to enforce, and in the cases where it is blatantly obvious, then it's easy.

In practice, nothing they can do to police the more subtle scenarios if the contributor flagrantly works to fool the policy. Except ban future contributions if they attempt to submit without disclosure and are caught.

So far the plaintiffs have tried going after the providers, and so far the providers have successfully claimed they aren't to blame, but have asserted that it can happen but that if it happens, it's the user who is liable.

So it hasn't come up yet, but it does seem like a company could come out of nowhere and hit you up for infringement because the model generated too-similar a copy. Despite not knowing, you still are on the hook, at least by the logic of the so far successful defense asserted by the AI companies.

Yes, the open source world really gets the short end of the stick in all sorts of way with GenAI.

You want to use an open source project but don't want to incur copyleft or even attribution? Launder it through CodeGen!

Your project has even two or three codegen fanatics? Congratulations, you now have inscrutable tickets and obnoxiously insistent pull requests that make no sense.

You have code unknowingly violating some closed source codebase? You can get hit out of nowhere, with no way of knowing you infringed.

Closed source code ripped off your codebase? Hard to know since you don't get that same visibility.

Yes, non-human code assuming that it does not itself violate any copyright does not earn copyright by itself. However, once combined with human output, the combined work is not exempted from copyright. So the 'no copyright' scenario would be no worse than pulling in code from public domain, the source may not be copyright, but the result after mixing it in would be. You also won't see companies even trying to argue that partial LLM content forfeits copyright for GPL, since the implications for proprietary code would be *far* worse given their near unanimous love of LLM code.

Your second point is the bigger gotcha, that an LLM generated copyright infringement can be a problem while every one actually involved can be genuinely oblivious. Even as an AI company has successfully defended themselves from being liable for infringing output, they essentially throw users under the bus by asserting that while infringement can happen and be facilitated by their models and services, it's the user's liability if that should happen and has nothing to do with their use of material for training and the resultant reality that the model *can* construct infringing copies of material in the training set.

Sadly, the second point is in practice waved away due to the assumption that the corpus of training material is almost entirely open source stuff, and while they do have copyright to respect, in practice they don't expect the open source projects to be resourced enough to detect and litigate infringement. In the "worst case" scenario, remedy is also likely to be easy because the courts will not recognize financial damages and the defendant could probably just LLM up a an alternative invocation, or 'shim' their way to isolate the code if copyleft, or simply credit the plaintiff if it's just BSD/MIT style. Long standing reality that violating open source copyright is "no big deal", only violating closed source copyright carries real risk. Some companies take the open source licenses seriously, but no company that has abused those licenses has faced anything vaguely significant in the way of consequences. I don't think anyone has been forced to copyleft their proprietary code due to a GPL violation by a court, at 'worst' they only have to correct the issue moving forward.

If it is cheaper, then it isn't the same cost. Yes, there are various ways to reduce cost and reducing the volume of work is only one of them. It doesn't work to accuse the article of being 'strange' for saying that using less of the services is cheaper. Because that is obviously one of the ways to be cheaper.

Could you please stop with the condescending tone of acting like people don't know about these things.

One, the severity score in many contexts does not matter because some security group thinks they are being extra secure by having a 'zero tolerance' policy, that the severity doesn't matter, no CVEs shall be detectable.

For another, the score is super subjective. Take CVE-2026-7210 and CVE-2026-41080. The exact same issue (one is in a C library, and one is tracking python wrapping that library). MITRE said the C library one was 2.9, but CISA-ADP said it was 7.5, and the python one was graded 6.3 (despite being the *exact* same issue as the C library was graded at 2.9). So between those two CVE numbers, the same issue is considered 2.9, 6.3, or 7.5, depending on who filled out the form. The score is by no means immune to the poor quality of the 'vulnerability' reports.

Reducing tokens would be a path to cheaper AI.

You seem to assume cheaper AI *must* only be about cost per tokens, but practically speaking they don't care about that detail so much as they care about the overall cost.

This has been playing out in my organization, where the consensus has been that folks burning through tokens like mad are, at their best, doing only as well as people using it in a more curated way. So the guidance has come down that people are only to be using it in a curated way, to reduce expense.

My take is based on pretty nuanced analysis of hundreds of CVEs over the past few years.

A common 'vulnerability' area that I find dubious is that some utility can be made to crash instead of exiting cleanly. Usually the rationale is that "imagine someone is using this in a kiosk-like context and they can crash out unexpectedly to a shell".... For utilities like wget and such that would never ever be in such a position. Even if such a kiosk application existed, the utility would crash back into the calling utility, and hard to imagine that sort of Kiosk design this century anyway.

Or things like "if an attacker just gets you to run this 4GB "script" in vim script then it could run arbitrary code... Except vim script can already run arbitrary commands already by design, so if a user would just run a script blindly, then just malicious commands would be so much easier. If a human does double-check, then the 4GB is even more suspicious than a script with commands. This isn't about issues that are exploitable but not exploited, this is about issues that as far as anyone can figure are not realistically exploitable in the first place.

One vulnerability in curl was that you could pass arguments to get curl to emit c code (but not compile it or run it), and someone could get it to emit arbitrary C code. So the attack scenario would be "you have a user who is somehow allowed to run curl and a compiler but not run anything else and be able to write the intermediate C file". I cannot imagine a situation where the user has free control to curl arguments but cannot simply write a file and also be able to invoke a compiler without having some other more trivial way to write a c file first.

Note that I'm not talking about AI specifically, AI is just continuing the trend. The security industry has long had a human issue that makes people understandably be a bit dismissive of CVEs at first glance because Wolf is cried just constantly. A "security researcher" finds a bug, particularly one where the user has to be explicitly trying to use it wrong, and get a CVE issued instead of accepting it may be "just a bug".

You have CVEs that are very real and very severe. But by the numbers, most of them are like the above, where someone has to invent pretty stupid scenarios in order to fairly consider it a security issue.

Note that while it notes that over 98% of "discoveries" seem to not be exploited, it also notes this is the rate for the pre-AI world as well.

Which is consistent with my experience with security "findings", very poor signal to noise ratio. At least in my time with the security industry, it's always hard to know whether to take something seriously, as they keep coming up with duds and claim victory. They tend to be eternally in "the sky is falling" mode, and sometimes it is very much falling, but most of the time it is nothing of consequence.

It's a pretty nice position because generally it's a bad move to call it out because then you would be branded as "not taking security seriously" if you express doubt over the potential consequences of a "security" finding.