On Thu, May 14, 2026 at 8:24 PM Artem Goncharov <artem.goncharov@gmail.com> wrote: Thanks for taking the time to reply. I appreciate that. On Sat, 9 May 2026 at 23:00, Michael Still <mikal@stillhq.com> wrote:
So I wrote it, and by "I wrote it" I mean Claude Code mostly wrote it. Instar is a from scratch rethink of how to handle
For me a statement like this is unfortunately not a quality stamp. While playing around with AI agents I ensured myself that AI does not take care about future maintenance of the code. It proposes the solution to your question (depending on how you ask it) using the statistics - it is not a secret that current AI is nothing else rather than just a statistical probability machine. I have no problem with asking the AI for support but a statement "Claude mostly wrote it" is not a great signal. I recommend you not to use such phrasing if you want to reach acceptance.
Honestly? Meh. If the OpenStack community isn't willing to consider possible new things based on their merits alone then I am not too fussed by OpenStack missing out on new things. Instar is not proposed as a potential OpenStack project, so I see flexibility to do pretty much whatever I want as the author. I think I was also pretty clear that instar is a concept _prototype_. On the other hand, having done this for about six months, I think the "it's just statistical" view is naive. There is much more to it than that: planning frameworks, clear definitions of correctness, good precommits and CI, etc. This is one of the reasons I have started publishing the planning templates and implementation documents I use, as I think those are just as important in terms of review as including a summary prompt in the commit message. Sadly, instar doesn't have a complete history of those because it was before I realised those things, but given one of my goals was to learn about the tools that seems like a success to me regardless. Isn't another way to rephrase your stance simply as encouraging authors using ML coding tools not to disclose that because then their code isn't taken seriously? Instar runs thousands of comparison tests between its output and qemu-img's. There are 121 images in the test suite, including some crafted to specifically trigger previous vulnerabilities. So, as best as I can tell it _works_. It might not be maintainable, but it might also be. I haven't found any evidence yet that it is not. Then again, should maintainability be a primary goal for a _prototype_? Nova has had lots of histocial design missteps we've had to clean up -- surely it's unreasonable to expect machine-assisted code to be perfect at first attempt?
untrusted image data as well as an opportunity for me to become more
familiar with code generation LLMs. All data processing happens in a custom KVM guest which does not run an operating system or have any access to system resources apart from those provided to it by the custom VMM which orchestrates it. The best way to think of this guest is as an embedded system running on a virtual CPU. This is similar in approach to how AWS Nitro Enclaves work in terms of prior art, whilst also being the opposite in intent: Nitro protects sensitive data *from* the cloud; instar protects the cloud *from* malicious data. To be clear, `instar info` doesn't detect or block malicious images -- it processes them safely and reports what it finds. The security comes from containment, not detection. It is then up to the caller to decide how to handle what is reported.
I think the proper strategy would be to do both: protect images from the cloud (confidential computing) and cloud for the image. Nitro (all of them) are giving very useful hints about what could and should be done and we definitely should learn from competitors.
To my current understanding a key underpinning to nitro is hardware acceleration of KVM. Unless deployers want to go all-in on DPUs, much of that remains out of reach for many. Michael