I must have missed some trends changing in the last decade or so. People have production secrets in the open on their development machines?
Or what type of secrets are stored in the local .env files that the LLM should not see?
I try to run environments where developers don't get to see production secrets at all. Of course this doesn't work for small teams or solo developers, but even then the secrets are very separated from development work.
I think having API keys for some third-party services (whatever LLM provider, for example) in a .env file to be able to easily run the app locally is pretty common.
Even if they are dev-only API keys, still not great if they leak.
If you can't trust the "agent" with a secret to the LLM which is practically like access to its runtime, what the hell... others propose mitming yourself...
Usually, some people change their .env files in the root of the project to inject the credentials into the code. Those .env files have the credentials in plain text. This is "safe" since .gitignore ignores that file, but sometimes it doesn't (user error) and we've seen tons of leaks because of that. Those are the variables and files the llms are accessing and leaking now.
Sure, but it's probably unwise to have your production credentials on your development machine at all. It's far more likely to be compromised than your locked down production environment.
Sometimes it can be handy for testing some code locally. Especially in some highly automated CICD setups it can be a pain to just try out if the code works, yes it is ironic.
It's interesting, because a few years ago I would have put this strictly under the "not invented here" fallacy, where we'd now be stuck maintaining another project for the foreseeable future. I used to press pretty hard to avoid it.
Now I wonder if the maintenance cost for this type of internal system has gone down to a level where that is no longer an issue.
I can see it going both ways.
If knowledge work continues to roughly look the way it looks then I think maintenance is going to be an issue. Both in terms of keeping the spaghetti together but also in terms of all the bad design decisions you get from everyone bolting on their ideas.
If however knowledge work becomes just talking to LLMs and occasionally interacting with an on the fly generated UI then maintenance becomes a non issue
Quick googling gave that Stockholm is deeper on average, although the deepest point of London metro is currently deeper than Stockholm. No drastical differences that should affect this question I think.
(This will change when they are done with Sofia station, a new station in Stockholm that they are building 100 m below the surface.)
Of course, majority is not very cleanly applicable yous politics. Less than half (which according to Mirriam Webster is the definition) of the votes cast in the last election went to Trump/Vance, and with such a poor voter turnout it was even further from a majority. Meanwhile the electoral college is working against the idea.
Mostly I just review the chat output. But I also use /diff to see actual unified diffs of the last AI change. Or if I have made a sequence of changes, I'll use my normal git tools to diff the entire branch, etc.
I wonder why Andreessen needs to use disinformation to shape opinion if the actual problem is so bad? I find it very unlikely that he does not know how PEP actually works.
It is so demonstrably false. Anyone who has worked in an finance adjacent industry likely knows the definition of a PEP.
Seems to me that he has crypto-related goals but involves more people to gain political support.
The OP article's last paragraphs make it quite clear IMO.
Does anyone know if Embark are still using a lot of rust in their production games? They seem to be a very well funded studio (lots of employees, big fancy office, competes with other AAA FPS-games). I wonder if these experimental-sounding projects have given way to more classic tech in the churn of building games that are profitable.
According to the article, Rust is (or was) used in the kajiya renderer and in the "creative platform", not in their production games:
> Our Rust project has different requirements than a video game. It’s a platform that will enable everyone — not just professional game makers — to build new small interactive experiences.
The "creative platform" is now apparently available under wim.live (and has a twitter account called @createplaywim): https://wim.live/en/ - but the website only seems to play a video, I couldn't find any other functionality.
One obstacle is that at least one of the major console vendors prohibits using anything other than C++ plus their official compiler. So shipping on that platform using i.e. Rust, Swift, C# is currently against the rules. (Unity gets an out here since they compile C# down to C++ using IL2CPP.)
I expect some studios are just quietly breaking the rule and not telling anyone, but I'd be worried, personally.
People outside of the industry woudn't believe how it is to work with first party such as Sony, just to get SDK / api / documentation / forums access you need to have a very complicated process that involves public IP whitelisting etc..
Even NVidia's GeForce Now cloud gaming service is like that. I tried to get a developer account and they wanted US$10,000 just to talk. It's not like getting an AWS account.
CrossCode was written in JS/HTML5 and was ported over to consoles just fine, though.
They mention stuff like "an interpreter which translates the [JavaScript] code but locks it up in a cage"¹, their presentation² mention JS interpreters and a JS AoT compiler, so I'm not really sure how they did it
My gut says Nintendo, because Microsoft doesn't give a shit what you use as long as you write for them, and Sony doesn't feel like they'd be that petty.
Or what type of secrets are stored in the local .env files that the LLM should not see?
I try to run environments where developers don't get to see production secrets at all. Of course this doesn't work for small teams or solo developers, but even then the secrets are very separated from development work.