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.
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.
It's an interesting idea; not having to stash messages in the actor implementation when doing an async call. I did a little experiment what that could look like using Akka and kotlin suspend functions https://github.com/joost-de-vries/akka-kotlin
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.
Are you in the EU? I'm a developer in the EU and that is patently not true. Developers have to have mechanisms in place to delete gdpr data when required and not store data that's not required for you goals.
In my experience gdpr puts a real and meaningful curb on the strong impetus to gather everything and sell it.
In 1969 the national TV news broadcast in the Netherlands reported that inspectors would be driving through the streets to catch people who hadn't paid their license fee. "Surely people won't be wrapping their tvs in aluminium foil. So we'll catch them!" Aluminium foil was sold out the next day. The date was april 1st.
Your word of caution is important. For some projects it's not initially clear what the right data model and bounded contexts are. And for some projects it's just overhead.
But the converse is also true: for some projects/systems it turns out that it being events first is the _only_ way for it to work. I've encountered that the last few years with systems in logistics that show an integral view across parties.
The way we approached that is that we started with a standard system and refactored to event processing approach when the decomposition into bounded contexts was clear.
So in that sense it's similar to the right way of approaching microservices: start out with a 'monolith' that you split up.
When designing C# Anders Heljsberg decided against following Java's checked exceptions. You can find his argument against in the interview from 2003 https://www.artima.com/intv/handcuffs.html
The monadic approach to exceptions like it's done here has the downside of having to encode all your business logic in maps and flatmaps. All the intermediary functions will have to return Try. And all the Try values have to combined into one. That type fidding code feels like cruft that doesn't add much value.
And I say that having developed in Scala for years and years.
Of course there's still sometimes when you want processing of other items to proceed, even though this one has failed. And that's where Try is really essential. So that's where we use it only: at the topmost level.
It's only at that top level that we wrap the call in a Try. And that works rather well.
One reason to do it like this is that we want to leverage the design philosophy of Kotlin. And not be writing Scala or Haskell in Kotlin ). And Kotlins philosophy when it comes to exceptions turns out to be: exceptions. Which is apparent in Kotlin coroutines, channels and flows.