Lots of people are not tech savvy. It’s entirely believable that someone who doesn’t understand why their stuff is in OneDrive in the first place also wouldn’t understand that they could move data somewhere else to fix the issue.

Most people I know who don’t work in tech have 90% of their stuff sitting in their Desktop and the other 10% in Documents. These people don’t know how to create a folder named “c:\stuffidontwantinonedrive”.

Docker is hard to setup. The author made a nice solution but not sure if he know devcontainer and what he can do. You do the setup once and you roll in most dev tools. I'm still surprised the effort people put in such solution ignore the dev's core requirements, like sharing the env they use in a simple way. You used it to have custom env and isolate the agent. You want to persist your credentials? Mount the target folder from home or sl into a sub folder. Might be knowledge. But for Linux or even Windows/Mac as long you don't need desktop fully. Devcontainer is simple. A standard that works. And it's very mature.

I'm surprised from reading these comments that more people aren't chiming in to ask why this solution is better than a dev container. That seems like the obviously best way to setup security boundaries that don't require you to still trust that AI will do what you ask it. You can run it remotely and it's portable etc.

Please use a dev container! Empirically, a lot of people don't, and some people regularly enable YOLO mode on their actual laptops. So if you've never run a code assistant outside of a dev container, that's fantastic and I don't want to change your behavior. But be honest with yourself--if you aren't 100% consistent about using a container, then jai may be for you, because it just works in every single scenario.

I can honestly say that since developing jai, I haven't run an assistant outside of a container. In fact, I now only have the assistants installed inside containers, so if I run `claude`, command not found, it has to be `jai claude`. The only place I have to run outside of jai is for testing jai itself, for which I use a virtual machine and just let the assistant have root, but that's a heavyweight environment I'm forced to use for this particular problem domain.

Isn't this mainly a skill injected in the context? Rather a model/platform specific feature?

Lovely you discovered devcontainers.

Ollama is quite a bad example here. Despite popular, it's a simple wrapper and more and more pushed by the app it wraps llama.cpp.

Don't understand here the parallel.

TBVH I didn't think about naming it too much. I defaulted to Ollama because of the perceive simplicity and I wanted that same perceived simplicity to help adoption.

This is the vLLM of classic ML, not Ollama.

I guess the parallel is "Ollama serve" which provides you with a direct REST API to interact with a LLM.

llama-cpp provides an API server as well via llama-server (and a competent webgui too).

You can improve a lot the success rate with providing HELM and clear instructions with the tool description.

Over a year ago had a lot of issues and the description and example was the difference between 30-50% failure to 1%!

So I'm surprised a bit about the point. May be I'm missing it.

Why in nushell? Not in go?

But I like the idea and principle. OSS need this and it's traded very lightly.

Mitchell has really enjoyed Nu essentially. If it is implemented in a shell script, it probably also means that general shell tooling can work with the format.

Devcontainer is not docker and do the trick!

How to do agentic workflow like 2 years ago.

What would SOA be?

Claude Code is perfectly able to access your git/jj history directly. Just ask it to review a commit.

Claims as always misleading as they don't show the context length or prefill if you use a lot of context. As it will be fun waiting minutes for a reply.