Comment by stevefan1999
1 month ago
The problem is, container (or immutable) based development environment, like DevContainers and Nix Flakes, still aren't the popular choice for most developments.
I self-hosted DevPods and Coder, but it is quite tedious to do so. I'm experimenting with Eclipse Che now, I'm quite satisfied with it, except it is hard to setup (you need a K8S cluster attached to a OIDC endpoint for authentication and authorization, and a git forge for credentials), and the fact that I cannot run real web-version of VSCode (it looks like VSCode but IIRC it is a Monaco fork that looks almost like VSCode one-to-one but not exactly it) and most extensions on it (and thus limited to OpenVSIX) is a dealbreaker. But in exchange I have a pure K8S based development lifecycle, all my dev environment lives on K8S (including temporary port forwarding -- I have wildcard DNS setup for that), so all my work lives on K8S.
Maybe I could combine a few more open source projects together to make a product.
Uhm, pardon my ignorance... but wouldn't restricting an AI agent in a development environment be just a matter of a well-placed systemd-nspawn call?...
That's not the only stuff you need to manage. Having a system level sandbox is all about limiting the physical scope (the term physical in terms of interacting with the system using shell and syscalls) of stuff that the LLM agent could reach, but what about the logical scope that it could reach too, before you pass it to the physical scope? e.g. git branch/commit, npm run build, kubectl apply, or psql to run scripts that truncate your sql table or delete the database. Those are not easily controllable since they are concrete with contextual details.
These you surely have handled already, as a human is able to fat-finger a database drop as well.
1 reply →