I mean, Google does index and cache most webpages internally already. So yeah, maybe. But after reading the article it doesn't sound like they're doing that.

Can't Google your obscure package's runtime error? Guess you aren't gonna do anything of value for the rest of the day.

Why not? They already do for the vast majority of this stuff. It's not that much and releases of these things are structured and indexed everywhere anyway.

Storing local copies of docs is a thing some companies do. I've worked at a couple of places that did that. And when the next version of $foo is released, and the devs get the go-ahead to use it, wget gets executed to make a new copy. Sucks, but that's the threat model in some places.

If I had access to a good LLM, that'd be enough for 99% of my research. And the other 1% I could probably do on a phone.

Having worked in customer service, if you actually want to help customers, yes.

implying Google has customer service

When you say it like that... it does make sense yeah.

I've worked in "secure" environments for the US military and yeah, open access to the internet while you're on the job is absurd to expect

sudo cat bleach | /dev/eyes

I would think that this would be an approach that absolutely makes sense for corporate infra systems like domain servers, systems with access to network configs, etc.

Maybe adding an additional security tier? Something like "sandbox dev" where new third-party libraries and technologies can be tested and a "production dev" which is more restricted. That might be the "right" way.

The problem that I'd see is that productivity, development velocity, and release cadence would all take a nose-dive as software engineers have to continually repeat work, roughly doubling the real amount of work needed to release any piece of software. This would likely be seen as incompatible with modern business and customer expectations.