Anecdotally, a few weeks into a Rust agent-first project, we're still trying to get the agent to maintain a minimum of coding discipline (e.g. don't use sync Mutex in tokio code). So far, the agent seems more interested in deactivating the linters than in complying.
Security? At this stage, I'm a bit afraid that it's a joke more than anything else.
That should be solvable by denying permission to edit the lint files with a message saying lint files cannot be edited and not to use workarounds (sed, scripting etc)
You could also use hooks to block running of scripts for some number of turns after an attempt to cheat.
> Why on earth would AI labs be bragging about how little the product they sell actually costs them to make? You don't want to do anything that reduces it's perceived value to the user, that might make them less willing to pay for it.
Wouldn't they be bragging about it to investors? It feels like something that would matter a lot to them, and at least OpenAI kinda feels desperate to find them.
There's also the small question about whether a drop in inference cost would actually change anything about profitability, when training seems to get exponentially more expensive.
It seems that this era is a marketing experiment for Mythos.
We're running forward without any idea of how we can get agents to write code that is even remotely safe or secure. It _will_ blow up with increasingly large blast radiuses.
Go is pretty good at performance, but pretty bad at expressing domain-specific logics. Python is the opposite, but once you have isolated the parts that need to be optimized, it's quite easy to rewrite them in a native language (in particular, the Rust-Python bindings are really good, although in this project, it's C++).
Pepper was a pun on Native Client (since NaCl = salt). Pepper Plugin API (PPAPI) was Google's more secure version of NPAPI (Netscape Plugin API). Flash Player was essentially the only thing using NPAPI/PPAPI by the end of its life.
The most common plugins were Flash, Silverlight, Adobe Reader, and the Java applet plugin, and I think all of those were in mildly common use when plugins were on their last legs.
When I was a manager in a start-up, ages ago, I argued the CEO against handing a (small) one-off bonus to one of my team members, and rather went shopping for a nice gift with the same sum. One of them was purely a transaction, the other one was a gift.
Of course you were it predates all the way back to OLE in Windows 3.x, but not the extent it is pervasive in modern Windows past Vista.
After Longhorn's failure, Windows team vouched to replicate all the .NET based ideas for Longhorn, as COM in Vista, followed by the Hilo code sample in Windows 7, how modern Windows applications should look like.
Best quote from Hilo, to show how Windows team sees .NET,
> So overall C++ is a good choice for writing Windows 7-based applications. It has the correct balance of the raw power and flexibility of C, and the sophisticated language features of C#. C++ as a compiled language produces executable code that is as close to the Windows API as is possible and, indeed, the C++ compiler optimizer will make the code as efficient as possible. The C++ compiler has many of options to allow the developer to choose the best optimization, and Microsoft’s C++ compiler is one the best ways to produce small, fast code.
WinRT was the next step, coming back to the ideas that predated .NET as the COM evolution, before Microsoft got distracted with J++ and the project pivoted.
Why does it? I'm curious. I think it solves most of the issues of the traditional apps. (But yes, I didn't mention a fundamental aspect: they propose you only a very limited amount of profiles each day, no endless swiping: if you don't fancy any of your daily ~4, tough luck, you can come back tomorrow).
Security? At this stage, I'm a bit afraid that it's a joke more than anything else.
reply