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. > > +**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 > >
