Two things: this is phrased as if each change by another developer ruins your theory of the codebase. This is an oversimplification. Changes to the core engine of the codebase can change the theory of the product but many changes are cross cutting concerns. This is why new developers on large codebases are commonly assigned integration work. You develop a theory with a real lower stakes output.
Second the llm thing. Putting aside hallucinations you could get a start of a theory from an llm but you’ve conditioned yourself to be reliant on the llm. To put things in similar terms of tech job stuff like this article does: prior to llms most teams had at least one SME on the whole codebase. They’d get bombarded with questions and if you had any politeness you wouldn’t bother them with every single question about the code or product as a whole. Occasionally you would need to but there was a natural social forcing function to figure stuff out on your own. Llms are the complete opposite: they tell you “good question” “good insight” etc. brains like short cuts so now there is no forcing function.
What's stopping people from doing that today is network effects. There are enough differences today between bsd coreutils and gnu coreutils that substituting one for the other doesn't work out of the box.
The chain of events that would cause a problem are: due to Ubuntu popularity rust MIT core utils overtakes gnu coreutils and people drop support for gnu coreutils, then a large and we'll funded corporate entity could privately fork rust coreutils and lock people in.
There's a lot of manual calibration on ender 3's I would not suggest taking it apart until you are more comfortable with the machine and then only if you really needed to do that.
Rip dia
lowers barriers to adoption of the language and its ecosystem
Picture - darktable lens correction - inkscape - import bitmap - trace bitmap - cleanup in inkscape - freecad svg import - symmetrize it. Most of those steps will require manual tweaking.
Two things: this is phrased as if each change by another developer ruins your theory of the codebase. This is an oversimplification. Changes to the core engine of the codebase can change the theory of the product but many changes are cross cutting concerns. This is why new developers on large codebases are commonly assigned integration work. You develop a theory with a real lower stakes output.
Second the llm thing. Putting aside hallucinations you could get a start of a theory from an llm but you’ve conditioned yourself to be reliant on the llm. To put things in similar terms of tech job stuff like this article does: prior to llms most teams had at least one SME on the whole codebase. They’d get bombarded with questions and if you had any politeness you wouldn’t bother them with every single question about the code or product as a whole. Occasionally you would need to but there was a natural social forcing function to figure stuff out on your own. Llms are the complete opposite: they tell you “good question” “good insight” etc. brains like short cuts so now there is no forcing function.
Like many other social media sites it's partially network effects.
Only had dialup when hedgehog was released and could not for the life of me figure out how to enable PPP
What's stopping people from doing that today is network effects. There are enough differences today between bsd coreutils and gnu coreutils that substituting one for the other doesn't work out of the box.
The chain of events that would cause a problem are: due to Ubuntu popularity rust MIT core utils overtakes gnu coreutils and people drop support for gnu coreutils, then a large and we'll funded corporate entity could privately fork rust coreutils and lock people in.
There's a lot of manual calibration on ender 3's I would not suggest taking it apart until you are more comfortable with the machine and then only if you really needed to do that.
Another reason that star count is a terrible metric for quality / authenticity. Fake stars are a huge problem that not a lot of people take seriously.