30000 is not that big in very old projects with many contributors. There are always one or two files that no one wants to take the time and responsibility to clean up. And 30000 is not a big number for RAM. The fact that you find it choking is more and of an indication of how bad our tools have become than anything else.

For example, until recently the main file for donet runtime GC was more than 50000 lines (it has since been split).

Copilot isn’t “very old”.

I’m sure it has changed a lot since inception

They don't have to tell us they are vibe coding everything.

- there are now ridiculous vibe coded localisation in VS2026

- task manager started to not report cpu usage correctly recently (the number becomes stalled)

- file explorer display the "loading" icon infinitely on some directories

- and many other things!

> file explorer display the "loading" icon infinitely on some directories

Nautilus had that feature 10 years ago, good to hear they've reached parity.

I love Nautilus, but the one I run (42.6) still has that ocasionally. May be fixed in latest stable by now though.

The line between vibe coding and just coding has now moved. Vibe coding is specifically when the output is not understood by the prompter. Even in the back in the days of the earlier models i used the models to do my basic typing because it was easier than me typing it out…

Your reply misunderstands the parent comment, I think. MS devs clearly don't understand their output given how garbage it is.

We’re not allowed to understand it. Gotta hit your PR quota to keep your job. I wish I was joking.

That just sounds like normal Microsoft software to me, since way before vibe coding.

Random infinite loading in Explorer has been there for years at least.

While I partially agree, it seems to have paid out, including among several key projects that Web development nowadays cannot live without.

Even if they wouldn't be vibecoding. They were able to write slop before AI

  > That is just maths here working

No this is just numerology here, it's meaningless.

I prefer when I see other comments to confirm or infirm my opinion.

  > Would it be an affirmative defense if we had a defendant who said [...] 

Maybe replace it with playing a sort of FPS game then learning you were, in fact, directing a real drone/robot.

I think you just recapitulated the plot of Ender's Game.

Also a subplot in Arrested Development and the movie Toys.

I think we can consider the planet(s) negligible from a mass perspective.

Tell that to butterflies.

What's the chance that either one of the four bodies crash into another?

He just had an accident on "Vuelta a España" : https://www.theguardian.com/sport/2026/aug/29/cycling-tadej-...

Oh I had not heard about this, thanks for the link.

Additionally, if this is true companies that have replaced all their software engineers will discover that they themself can be completely replaced by AI by their former customers.

What narrative has changed ? I just see an experiment with a very perfectible result and some reflections about what capacity are currently missing to have better results.

There is no point to have an LLM do what can be done faster and deterministically by standard algorithms.

> There is no point to have an LLM do what can be done faster and deterministically by standard algorithms

I think using the word "deterministically" in the context of decompilation is not a particularly good idea.

The code generated by a compiler can be arbitrarily complex and arbitrarily varied even before you take into account willful attempts at obfuscation to protect against reverse-engineering (for example, try futzing with compiler optimization flags to see how much the ASM changes).

The "high-level code to assembly" operator is thus not even really a function (same high level code can generate infinite variation of functionally equivalent assembly code) and any attempt at producing an inverse of this operator ... this really does not strike me as an environment where the word "deterministic" seems appropriate.

I would call any traditional decompiler deterministic, though these can rely on probabilistic models to infer how to undo these optimizations.

A talk I did on this at Reverse Con (clipped to the important part): https://youtu.be/VP29biKLoSw?t=891

Many of these decompilers can infer what optimizations occurred by hints/patterns that are left behind.

This can be fundamentally different at times from LLMs, which have shown a degradation on unique architectures. I still believe the best approach will be a mixed method. Get 80% of the way there with traditional methods, and take the last 20% (which is the hardest) home with LLMs.