joostdevries

Interesting! Personally I'm not eager to spend tokens on having my own harness, sandbox etc. It's much much more feasible by spending tokens. But it does feel like a distraction and that I end up owning it. As in: a continuing distraction.

So I've been experimenting for these purposes with omnigent as a way to be less locked into a single provider and for its sandbox abstraction. And I've also tried openshell for sandboxing. Hoping those two will keep improving.

I'm experimenting with OpenShell / NemoClaw.

It brings some extra sandboxing features compared to just a docker container.

For instance it also maps the secrets that the agent harness has access to. And has an allow list for outgoing http connections. And there's a way for agents to request extra access. And once approved by the user from an external cli the policy is updated and hot reloaded.

It's pretty recent. So time will tell how robust it is / will become. What its longevity will be. After all; in a time of LLMs one off experiments are cheap. Longtime nurturing not so much.

I guess this is a sign that Mistral AI is on to something.

Maybe the pitch is:

git is distributed. Decentralised improvement. Local computers and their users make changes. These steps of local added value are then centrally combined into a shared timeline. A single product. During the improvement the locus of control is local. Which means it is hard to harvest the knowledge of this local knowledge and replace it. And it's hard to make local users serve the central AI.

Not something you put in the public mission statement. Because you might get boycotts.

I keep the context concise by linking from claude.md to markdown files with the hardware architecture, the network architecture, the processing tech stack. Concise and specific. And a current project md. I mix in the parts that are relevant. I don't have a roadmap and session log though. Good idea.

Very nice that there's a coding cli finally. I have a Mistral Pro account. I hope that it will be included. It's the main reason to have a Pro account tbh.

I wonder if MS is aiming to use the conversations about software that employees are having in Teams meetings as training data for AI. To automate them away.

I think Americans pronounce names like Weinstein as 'winesteen'. So perhaps the pronunciation of the latter syllable makes German origin diphthongs confusing.

Or the Steven Soderbergh movie 'Kafka'

The need for flags in itself may be a sign of the wrong approach. You create a shared module. But for some cases the handling should be different. Let's pass in a flag or configuration. So somewhere in the shared component it will handle things differently. Oh wait, there's another case. Another flag. Which combinations of flags are meaningful and which aren't? The nearest improvement is to put all the cases in an enumeration. But wait it's not one 'dimension'. Let's have two enumerations. And the extreme end point is that your shared module has a full blown DSL for the parameters it receives. Or even an interpreter. The other solution that is often more understandable and debuggable in the long run is to not have the shared module call specific code for cases. But to have specific code pull in shared commonalities. No need for flags.