Rendered at 11:03:00 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Rexxar 1 days ago [-]
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!
GrayShade 23 hours ago [-]
> file explorer display the "loading" icon infinitely on some directories
Nautilus had that feature 10 years ago, good to hear they've reached parity.
edg5000 23 hours ago [-]
I love Nautilus, but the one I run (42.6) still has that ocasionally. May be fixed in latest stable by now though.
chrischen 24 hours ago [-]
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…
Icathian 23 hours ago [-]
Your reply misunderstands the parent comment, I think. MS devs clearly don't understand their output given how garbage it is.
fingerlocks 23 hours ago [-]
We’re not allowed to understand it. Gotta hit your PR quota to keep your job. I wish I was joking.
solarkraft 22 hours ago [-]
That just sounds like normal Microsoft software to me, since way before vibe coding.
szatkus 22 hours ago [-]
Random infinite loading in Explorer has been there for years at least.
pjmlp 19 hours ago [-]
While I partially agree, it seems to have paid out, including among several key projects that Web development nowadays cannot live without.
sharktheone 23 hours ago [-]
Even if they wouldn't be vibecoding. They were able to write slop before AI
tecoholic 1 days ago [-]
One of the thorniest conversions was the session.ts file, which was over 30,000 lines of TypeScript that touched all aspects of the runtime.
This can’t be real. Single file with 30K lines? Which human being is working on it and how much RAM does it take for a code editor to load that with full symbol tree? I am genuinely curious. Is this common? I think most files I come across stretch to maybe 2-3k lines max.
Rexxar 1 days ago [-]
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).
skrebbel 23 hours ago [-]
Copilot isn’t “very old”.
solarkraft 22 hours ago [-]
I’m sure it has changed a lot since inception
Zanfa 23 hours ago [-]
Behold the View.java[0] at 34k lines of human code. IIRC it’s slimmed down a bit these days and used to be more.
Wow. Somehow I feel my software creds just went by a notch by the mere existence of these files.
brewmarche 23 hours ago [-]
Until recently the .NET garbage collector used to be a single 30,000+ line C++ file. And it was maintained by one person if I remember correctly.
tecoholic 13 hours ago [-]
Amazed and horrified at the same time.
wayvey 1 days ago [-]
I recently saw a ~60k lines / 3mb .cpp file in one vibe coded project (and yes I was a bit horrified) Surprised it works at all but it apparently does. Not really for a human though and even for an LLM it would be more beneficial for it to be split up.
NewsaHackO 1 days ago [-]
This has to be 1) early LLM vibe coding or 2) “hand” vibe codingwhere the user asked the LLM to code sections and stitches them together manually, and the programmer is a novice. The second part I speak from experience; got to ~2k before realizing this is out of the script range and started to break it up. Regardless, it would be almost impossible to get an SOTA LLM agent to ever do this.
applfanboysbgon 23 hours ago [-]
It is very possible. Sol Max created a 17k line monolithic file in a prototype not long ago. If I didn't stop it and make it refactor everything it easily would have went to 60k. I think it's the default if you start a new project and don't define the architecture concretely with files and folders beforehand. Models have zero concept of architecture or long-term planning, they just band-aid the fastest immediate solution that gets them the reward.
phoghed 23 hours ago [-]
I find that specifically when you tell it you’re doing a prototype or POC, it takes that as a license to write huge single files and other shit coding practices.
perching_aix 23 hours ago [-]
I have seen 30k line cpp files even a decade ago (World of Warcraft server emulator, gameplay logic of a boss enemy), and was told it is fairly normal in large software (even 100K not being unheard of), so I'm not sure if it's that much of an LLM thing.
dgellow 23 hours ago [-]
In the cpp world that’s indeed relatively normal for complex projects.
sajithdilshan 24 hours ago [-]
The question should be how can they ever let that file grow that big. What kind of engineers were working on that, like I hate seeing any file more than 300-400 lines of code
dgellow 23 hours ago [-]
If well organized the number of lines of code in a file is really irrelevant. 300-400 loc is a tiny file in any professional project. Splitting in a large number of file doesn’t magically make things simpler to manage, in fact you fragment the context by doing that. And very likely end up with unnecessary abstractions
sajithdilshan 23 hours ago [-]
I disagree, that makes it more readable, maintainable and testable. Just because everything is in one file doesn’t mean you’ll be able to build the context, you’d forget what was at the start of the file when you get to the bottom of it if it’s like 3k lines
dgellow 22 hours ago [-]
We don’t read a source file as a book, from the first line to the last one. A file is just a set of classes, functions, types, constants, and you generally navigate it by blocks. Splitting multiple functions, classes into multiple files just to match an arbitrary number of lines is bad engineering, prioritizing a dogmatic approach instead of a thoughtful one. File units should have a meaning. And there are quite a lots of situation where keeping more things tied together in the same file is a meaningful thing to do, even if the file is itself large. There is an argument for avoiding extremely large files based on the impact on the resulting artifact, but lots of tiny files (400loc is really short) pretty much always results in duplicated logic and over engineering
smitty1e 1 days ago [-]
Was the documentation for each function a full-on essay?
formerly_proven 1 days ago [-]
> Which human being is working on it
If you've ever used that tool you wouldn't ask this question, since it's obviously fully vibecoded.
meerita 24 hours ago [-]
I wrote to the post of Andrea (a dev from the Copilot team) about their 800K LoC: 128 PRs, shipped incrementally. Existing end-to-end tests ran against the new code at every step.
Total: ~1,301,378 lines of Rust.
Production: 832,378
Unit tests: ~469,000
Combined: ~1.30 million lines
On top of the 832K LoC are mostly tests she answered:
> Yeap, 832,378 lines of production Rust. the +800K number is production only; unit tests are another +469K on top.
> Half of the 832K LoC are mostly tests she answered:
No? That quote is clearly saying the opposite of your summary.
meerita 23 hours ago [-]
True! I edited.
dmix 1 days ago [-]
> agents converted 430,000 lines of TypeScript into 800,000 lines of production Rust
The +400k new lines were probably code comments the agents added to everything
meerita 23 hours ago [-]
832K + 469k of tests.
23 hours ago [-]
23 hours ago [-]
Havoc 23 hours ago [-]
Can they port their m365 chat UI too?
Don't know what tech stack it is but I'm guessing electron judging by how buggy and slow it is
hollowturtle 24 hours ago [-]
> The original TypeScript implementation completed 7.55 of those lifecycles per second, while Rust running in-process managed 120 per second - representing a 15.9x speedup on that particular workload.
Does this impresses/surprises anyone? Two folds: 1) I believe the most optimized JavaScript code could near the performance of this phase 1 port without optimizations. I would have gone with that first, many would think that would not be as cost efficient but: 2) optimizing the rust code will require 10x the effort of the 1 by 1 conversion, just because you now need idiomatic rust code that likely has nothing to do with a plain translation. So defeating the initial gain, there's nothing to do the bottleneck gets just pushed elsewhere
mixxit 17 hours ago [-]
I'm slowing moving everything to kubuntu and have for some time has it in my non work life
Really nothing works anymore as great a product full fat visual studio and windows 7 was I don't have time to deal with your bugs
aniceperson 23 hours ago [-]
they ported their coding harness, something known for being simply an extensible http and subprocess wrapper, into a monolithic blob. They took their bloated and slow coding harness, and turned into an un-maintanable blob.
amelius 1 days ago [-]
Still hoping for a company to agentically port the python ecosystem to GIL-free python.
rienbdj 24 hours ago [-]
If runtime performance is the goal it’s easier to port the required libraries to another language at this point.
amelius 22 hours ago [-]
I'd certainly like to see more of this, yes. It would be great if scipy, numpy, pytorch, etc. would be available universally, if only because you'd use the same function names in every language.
And if LLMs are as great as they make us believe they are, then this should be easily possible.
andrewstuart 1 days ago [-]
I did a lot of benchmarking of Gil free python.
Greenlets were much faster.
Gil free python gets stuck on all sorts of python locks. It’s slow.
Either would have worked, but rust's fussy compiler & memory features is an advantage for LLMs. The more bug catching you can shift out of runtime and into compile time the better since the LLM can fix it
hollowturtle 21 hours ago [-]
go is even more straightforward for llms imo. It's a dead simple language with a good garbage collector, where you can still do a lot memory management
Havoc 4 hours ago [-]
Simplicity is a feature too.
> you can still do a lot memory management
That’s kinda my point - you don’t really want to trust the LLM to get any sort of memory management right. A system where hard constraints are baked into the language itself and the LLM fights the compiler at compile time removes a lot of hoping the LLM got it right.
Ultimately either works though so use whatever you enjoy
asp_hornet 23 hours ago [-]
> The software engine underpinning GitHub Copilot and a growing number of Microsoft products
I’m guessing so it can interop easier with C/C++ codebases? Just a stab in the dark, I have no idea.
OutOfHere 20 hours ago [-]
I wouldn't say it has lost. Big firms like Microsoft and Amazon are just afraid to use Go since it's by Google, a known evil firm. This doesn't hold back smaller firms that need to move fast.
turowicz 19 hours ago [-]
They really built that shit in TS? Mad!
jdw64 23 hours ago [-]
Now I'm starting to really feel that I should use Rust, but I have no idea where to actually apply it.
baxuz 23 hours ago [-]
The fuck does "agentically" mean
mg74 23 hours ago [-]
Probably that they used dynamic workflows to run long agent sessions to do the conversion, like Anthropic did when they ported Bun from Zig to Rust. Minimize Human in the Loop workflows, maximize Agents in the Loop workflows.
supermatt 23 hours ago [-]
It’s the adverb of agentic, which is an adjective to describe something as having agency. I get it was a snark on the word, but it’s actually a legitimate pre-ai term.
dgellow 23 hours ago [-]
That’s they used Claude code
OutOfHere 20 hours ago [-]
Nope, that's the incorrect answer. One can do agentic development without using Claude. Any coding model with tools will do.
dgellow 15 hours ago [-]
Obviously…
14 hours ago [-]
alex_duf 22 hours ago [-]
Using agents?
OutOfHere 20 hours ago [-]
Did you just wake up after a multi year slumber? Agentically means using tools. It means the workflow isn't predefined. It also spawned subagents.
perching_aix 1 days ago [-]
Is that why session compaction stopped working for me in VS Code at the end of this week, or is that just the integrated extension itself having a normal one?
Though it's the same extension that can't keep its session timestamps straight, randomly hides sessions I was just in (then suddenly remembers them after going in and out of a session), and completely shits itself visually when using OpenAI's models, so maybe it really is just the latter.
- 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!
Nautilus had that feature 10 years ago, good to hear they've reached parity.
For example, until recently the main file for donet runtime GC was more than 50000 lines (it has since been split).
[0] https://android.googlesource.com/platform/frameworks/base/+/...
If you've ever used that tool you wouldn't ask this question, since it's obviously fully vibecoded.
Total: ~1,301,378 lines of Rust.
Production: 832,378 Unit tests: ~469,000 Combined: ~1.30 million lines
On top of the 832K LoC are mostly tests she answered:
> Yeap, 832,378 lines of production Rust. the +800K number is production only; unit tests are another +469K on top.
https://x.com/acolombiadev/status/2100660224298193081?s=20
No? That quote is clearly saying the opposite of your summary.
The +400k new lines were probably code comments the agents added to everything
Don't know what tech stack it is but I'm guessing electron judging by how buggy and slow it is
Does this impresses/surprises anyone? Two folds: 1) I believe the most optimized JavaScript code could near the performance of this phase 1 port without optimizations. I would have gone with that first, many would think that would not be as cost efficient but: 2) optimizing the rust code will require 10x the effort of the 1 by 1 conversion, just because you now need idiomatic rust code that likely has nothing to do with a plain translation. So defeating the initial gain, there's nothing to do the bottleneck gets just pushed elsewhere
Really nothing works anymore as great a product full fat visual studio and windows 7 was I don't have time to deal with your bugs
And if LLMs are as great as they make us believe they are, then this should be easily possible.
Greenlets were much faster.
Gil free python gets stuck on all sorts of python locks. It’s slow.
> you can still do a lot memory management
That’s kinda my point - you don’t really want to trust the LLM to get any sort of memory management right. A system where hard constraints are baked into the language itself and the LLM fights the compiler at compile time removes a lot of hoping the LLM got it right.
Ultimately either works though so use whatever you enjoy
I’m guessing so it can interop easier with C/C++ codebases? Just a stab in the dark, I have no idea.
Though it's the same extension that can't keep its session timestamps straight, randomly hides sessions I was just in (then suddenly remembers them after going in and out of a session), and completely shits itself visually when using OpenAI's models, so maybe it really is just the latter.