Not quite the history as I remember it. These package managers were often created by small teams of people who originally didn't know they'd turn into Microsoft acquired corporations. The intent wasn't to onboard newbies. People just didn't have a reason to use insanely targeted attacks on OSS Things because OSS being used in such a widespread manner wasn't as common as it is today. It really feels like people have forgotten how things were back then.
Well. Treasure Valley felt remarkably more WS-ey to me this last time visiting home. The time before that was right before the election, so it feels like it's gotten even worse over time.
You are in a bubble. Some segments use essentially no AI, while others have gone all in. Just because the type of engineers you're surrounded by do engineering that is obsolete doesn't mean that's the case across the board. All the best game engineers I know still write at least 90% of the code (probably closer to 99%). The bad ones use AI nearly exclusively - just like yourself. They can't create very complex or performant game systems, and they struggle even with highly unique or interactive game UI systems. I've looked over their code; almost every choice is bad, and it's clear why their projects completely collapse after a certain point. They simply can't build super complex, performant, or novel systems.
I'm going to assume you do the type of engineering where all the hard problems are solved for you already, and you are merely connecting inputs/outputs and hooking up APIs. Because, frankly, the value in "software plumbing" is gone; anyone with a Claude license can do that now.
You're condescending for no valid reason and I will tell you that what you say is not correct. Models superseded "plumbing" tasks and went well into the engineering grounds a generation or two ago already. Evidence is plenty. We see models perfectly capable reasoning about the kernel code yet you're convinced that game engines are somewhat more special. Why? There're plenty of such examples where AI is successfully applied to hard engineering tasks (database kernels), and where it became obvious that the models are almost perfectly capable reasoning about that tbh quite difficult code. I think you should reevaluate your stance and become more humble.
Link me the research on the hard engineering tasks they've done on database kernels, I'd love to see it, sounds interesting.
As long as people comment, "Only bad/stupid engineers hand-write code because LLMs are better in every way," and that's objectively not true in various engineering circles, I'll keep trolling them and being just as hyperbolic in the inverse because it amuses me. Don't take things too seriously on the internet; you'll have a bad time ;)
> They simply can't build super complex, performant, or novel systems.
Neither can single humans.
If you introduce some reasonable constraints AI will come out ahead most of the time, especially for optimization cases where AI will run circles around your average programmer and is perfectly happy to inline some ASM for you.
You still have bespoke cordwainers/cobblers 100 years after that process has been well and truly automated. But they're rare and almost nobody cares.
The pic above is representation of skeleton screen on youtube.com when opened in browser
Placeholder with same dimension or colors as actual content, which will get replaced it keep user engaged rather having a blank screen that suddenly fills or spinners.
This is a rather superlative and tunnel vision, "everything is a nail because I'm a hammer" approach. The truth is this is an exceedingly difficult problem nobody has adequately solved yet.
I think the AI tooling is, if not completely solving sandboxing, at least making the default much better by asking you every time they want to do something and providing files to auto-approve certain actions.
Another layer of AI tooling is the cost of spinning up your own version of some libraries is lowered and can be made hyper specific to your needs rather than pulling in a whole library with features you'll never use.
> Another layer of AI tooling is the cost of spinning up your own version of some libraries is lowered and can be made hyper specific to your needs rather than pulling in a whole library with features you'll never use.
Tell me about it. Using AI Chatbots (not even agents), I got a MVP of a packaging system[1] to my liking (to create packages for a proprietary ERP system) and an endpoint-API-testing tool, neither of which require a venv or similar to run.
------------------------------
[1] Okay, all it does now is create, sign, verify and unpack packages. There's a roadmap file for package distribution, which is a different problem.
> at least making the default much better by asking you every time they want to do something
Really? I thought 'asking you every time they want to do something' was called 'security fatigue' and generally considered to be a bad thing. Yes you can concatenate files in the current project, Claude.
reply