On Fri, May 29, 2026 at 06:17:29PM +0200, Paolo Bonzini wrote: > > > Il ven 29 mag 2026, 17:46 Michael S. Tsirkin <[email protected]> ha scritto: > > > If as a project we want to limit the > > blast-radius if we find we have to rip out a hypothetical tainted > > contribution, shouldn't that mean that we hold that as a project-wide > > line, rather than leaving it up to the opinion of the individual > > maintainer ? > > I guess, the maintainer can judge that the code is unique and qemu > specific enough, and follows from what it is doing automatically enough, > that the chances it is accidentally copying something are nil? > > > One thing that I had in mind was using AI to adjust QEMU code as the kernel > side goes through review and APIs change. The changes at that point may be not > entirely mechanical and, more importantly for traceability, it probably will > not make sense to separate them from the original code; but the code still has > fundamentally a shape and design that was provided by the human. > > Another, which is Rust-specific, is procedural macro code, which is often > boring, or very much tied to the shape of the generated code and human-written > traits, or both. See > https://github.com/qemu/qemu/blob/master/rust/qemu-macros/ > src/migration_state.rs for an example, contrasting the block starting with > "self.conversion = match" with the rest. > > I don't think it makes sense to have a wholesale permission for procedural > macros because that is not *always* true, or true for a whole file. But say a > contributor wrote the overall specification/documentation first, and mostly > one-shotted a skeleton with a prompt like "based on the documentation, > generate > basic attribute parsing code for the MigrationState derive macro, together > with > a code generator that provides empty methods for an implementation of the > trait > ::migration::MigrationState from rust/hw/migration/". Then I would absolutely > not reject it. This is also the intention of the suggestion around prompts—to > favor quick generation of boilerplate code over full "agentic" (blargh) > implementation.
Agreed. > > > > +**Documentation and code comments** > > > + While AI can help draft text, it still requires significant human > > > + oversight. Pay attention to the organization and flow of the > generated > > > + text, and strictly fact-check all technical details as LLMs are > prone > > > + to being confidently wrong. > > > > I think the application to documentation and comments is the part > > I'm least enthusiastic about here. > > But I am very enthusiastic about less agrammatical english in both. > AI is super helpful for non native speakers. > > > I am also not enthusiastic for documentation; the review I gave for Philippe's > unedited experiment was rather scathing. The main challenge for documentation > is the structure of the work, which is really complicated to establish because > the LLM doesn't have a clue about the underlying design. > > But there can be interesting uses nevertheless, such as integrating knowledge > from functional tests into documentation, that are worth exploring. Also for > Rust I am really trying to have *all* functions commented (and tested through > so tests) and AI can produce good results more often than not, especially when > the model has access to a human-written file-level blurb. > > > > For changes to code, we have at > > least some guardrails on the AI output, in the fact that it has to > > compile and to pass tests. For changes to documentation, the > > only guardrails are human eyeballs. > > > > Also both comments and documentation ideally are a record of > > what we intended the behaviour to be. If an LLM is effectively > > autogenerating something documentation-shaped from the code we > > lose that. > > > I agree with both of these observations, for what it's worth. > > Paolo > > > > > > -- PMM > >
