From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id ADC8F5944; Fri, 21 Aug 2026 16:08:48 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 0F0CB5925; Fri, 21 Aug 2026 16:08:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Received: from fout-a3-smtp.messagingengine.com (fout-a3-smtp.messagingengine.com [103.168.172.146]) by atuin.qyliss.net (Postfix) with ESMTPS id 4B5F55921 for ; Fri, 21 Aug 2026 16:08:44 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 9E2ABEC01DE; Fri, 21 Aug 2026 12:08:42 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Fri, 21 Aug 2026 12:08:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1787328522; x=1787414922; bh=5LLxfET53X wCYMqiTTqLrXRpVUBU5a5XCQAGSoBY/Bs=; b=cLoHieeaWpUasdZNP8dzMY0I/f lVytTu3trWvEEwzFxb1EtPBIQtA2jHpIVwGJ9C0DlOUR4O5c+S9wFZv6DAoM3O9H as96Ed36nKm+XkwXGZe6XJ9kLbUa1iPc0FxhQAWkekoaZ/5XIB2Ye+kjhqzEYV5W Lj39JfF2ga7NqQn9WRi1VMZDMtU3c+zB1n9jufZmzYH5idKfOa0I33OSG58MgCRl IBTDtNnnxg4qjSEemjCYT5Jg6Bqi3yvFLGM0qN4mTp821QWsI+WQpCpOEKd6w1Ot z5dRfuBx6OoiygUIgsyGhR9qFsamrxS8MPU7zm3NT612smWLGJam43RdVo7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1787328522; x=1787414922; bh=5LLxfET53XwCYMqiTTqLrXRpVUBU5a5XCQA GSoBY/Bs=; b=aoxcPG7mF+/SFODoLG2DqKcYz8tcKJEAMZEimB3K/HS/SZUE7MV znXhb7djJ/4TnMY0TpseGgLfajDxSE+SzNdSWoQSuqrZVaP0TfdLHXaUnj36drqz PHcUU96fMm7vPe/ltP+xqOom2XEAsDjXI633+FAhbMJYZuWDFtlnbEeV6bgGxdkl P1S098qMET37FZJD63WF8bOddIV82jE2faM66HZFFc0aCAhayjM/G1tAcqR+zttS 9a4sxVxPqxBrtsr2o0PXvYpjNq3cp7NqGNpaxkeL+f01A2NrW9L2rOB/KpVEuVEc 58kq6q52Y50EWLpl0gnXFY6pjtgpjrQoLHw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTF46026+JVcYaXVtQhAE+uNUjFWJvU2GbAhgTresgqsWGhyaYuatt+DdeHxmnjQ3Z 073d0ef4ap2HYXNbBvFdIBDM/eyYs9ovIZ9Ko5pR4Cb2d+7tzCezMFNvPEpVh/qGkCdrU+ t+jnh0mHviWQfFAO25vR4QAY4e/rtbF0ibC+h/zmlIqFuZ75FW7PA6hBd5onSC4QTD5CHM DtDqLLXMMYaH6dHCNPDyzQ+AJ3sd9Cls65LJcR2ErP/LBZ5M6CDMt32q0WfvWP84RTHR7s sITrHDTjkVZCMQhcGp8eSovp8hRvrH594ILI/O5HkPXOoWWkga1KlMQcgBc7cKdUTwQ/bn 5eP9o3RBGYO0yI5MN6xCa2D30j4A/5KkA29JcoGWdkqwLg1zCoHQiZPk8CvlvafsTz+jUN ViGsWXK9GdwZnhJG07MME0lDE5usW91en4jny68zb2nbtpKve+PA34D0dt8B0PbKYvDGGG DOUJ+R/s9aHuzq0w5OCiVUoDxU5zFF4mCSubAmHa6Kx9xjuE+R1ybiV+EX3gF1zV0wAZrG 7lT/HY2UlyICYDWBJIUbjdFn9PtG+oGe3RlTLfQS312cS60jMWSJE9lbHY8SaYfoo4FUce u4Isfivk3zy72/gH+5mALywo0qdRio+fnxJhZt0ESIBm+U9uxU8ngsI3CVwA X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 21 Aug 2026 12:08:42 -0400 (EDT) Received: by fw12.qyliss.net (Postfix, from userid 1000) id A46B3C80F363; Fri, 21 Aug 2026 18:08:40 +0200 (CEST) Date: Fri, 21 Aug 2026 18:08:40 +0200 From: Alyssa Ross To: Valentin Gagarin Subject: Re: [PATCH] Documentation: document expectations around AI use Message-ID: References: <20260804164109.175987-2-hi@alyssa.is> <05840f25-32fd-4953-885e-4a11845d102c@gagarin.work> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t5upmld2itajnnmy" Content-Disposition: inline In-Reply-To: <05840f25-32fd-4953-885e-4a11845d102c@gagarin.work> Message-ID-Hash: SD7BZ6ZIX3ZI3SDDEN2FEWJJCD2K7DOI X-Message-ID-Hash: SD7BZ6ZIX3ZI3SDDEN2FEWJJCD2K7DOI X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: devel@spectrum-os.org X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --t5upmld2itajnnmy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 05, 2026 at 10:15:06AM +0200, Valentin Gagarin wrote: > I like the nature of the argument, but from my own experience would > suggest a different policy: don't submit LLM output. > > One piece of rationale behind that is in essence the same as yours, > something along the lines of "contributors are assumed to understand > what they're writing". But even that still feels vague, because of > course one can understand a given LLM output and package that as a > contribution. Therefore I would like to sharpen that line of reasoning > before committing to that. I don't think this is a feasible position for us to take into the future. Our goal is to create a secure desktop operating system, and in the field of computer security we are currently facing a new reality where an automated vulnerability discovery and exploitation machine exists. As the cost of vulnerability discovery and exploitation has sharply declined, the task of delivering a "secure enough" system has become much more difficult. If the cost of exploitation reduces while the cost of defense is held constant, eventually it's not going to be realistic to even try to defend. That doesn't mean we have to lower our quality standards and fill Spectrum with slop, but it does mean that we have to be open to new possibilities enabled by automation when they would let us improve defensive robustness. More on that below. For other kinds of intellectual work, slower, but more thoughtful, 100% human development is a tradeoff that can be worth making! 100% artisanally human=E2=80=90created security software that is eventually outp= aced by ever more efficient attackers, though, is not useful to anybody. (Am I happy to find myself in this position? No, but it is what it is.) > The other piece of rationale has more weight for me: you wouldn't submit > search engine output verbatim either. LLM output is qualitatively the > same as generated code, plus randomness. Why would you check that into > version control? That would also still need a constructive formulation > for people further from this bubble to make sense immediately, but do > you see what I'm getting at? I've been thinking about this point in particular a lot over the last couple of weeks. I think it comes down to current form of collaboration being source code, and so we expect LLMs to meet us where we're at, by producing source code of equivalent quality to what we'd expect of humans. One can imagine a future world where our collaboration form has changed =66rom program source code to a formal specification of a program, and LLMs are used like a compiler to generate source code implementing that specification. (This is very appealing for security software, because the generated code could be written in a way that it proves certain security properties hold =E2=80=94 this is possible today, but it's mostly = too expensive for humans to do. It might even be that this sort of method is both the only way to produce software that is robust against ever more capable adversaries, and only feasible with "AI" automation!) In that world, we don't care about the specifics of the source code, much like we don't much care about the machine code produced by a compiler, and we just track the specification in version control. That's quite a way off, though. For now, we want source code to be our canonical collaboration form, and we care about the exact content of that source code, and we want it to be deterministic, so we keep source code in version control. > Certainly we should emphasize the part that sending LLM output > needlessly shifts more burden onto reviewers, and the threshold to > consider that spam is very easy to cross. It doesn't necessarily do that. One can use an LLM to produce the exact same diff that could have been typed by hand. Whether an LLM is used or not, contributors have a responsibility not to overwhelm reviewers with poor quality contributions. LLMs do make it easier to do that, especially without realising, so we might want to call attention to that. > This deliberately leaves open which tools you use and how you use them > to arrive at your contributions. Another thing also worth mentioning is > that the contributor may be liable for all the legal implications of > labeling LLM output as one's own contribution. What if a particular > piece turns out to violate copyright? For that reason, maintainers > should therefore not let into their codebase what is marked as LLM > output, and otherwise take authorship claims for granted. Yes, contributors have a responsibility to ensure (attested via the DCO) that they have the necessary rights to submit their contributions. Again this is the case regardless of how the contributions are produced. I'd expect that most Spectrum contributions would be Spectrum=E2=80=90speci= fic and (strongly encouraged by me to be) small enough that it would be implausible for them to be substantially copying any prior creative work. > But again, I agree with the spirit of your proposal, which to me reads > like that the project's communication channels are for people, period. > Still figuring out how to state it so that spirit gets across despite > cultural differences. Maybe this would even allow us to bypass the LLM > debate in documentation altogether, ideally without having to re-explain > why e.g. checking in any sort of machine output is not a good idea in > general. If, some time in the future, a personable robot starts identifying and fixing problems, without being extremely annoying, forgetful and time=E2=80=90sucking to interact with in the way that today's technology is= , I'm not going to reject those fixes! We don't have that today, though, and experience from other projects shows that contributors are not necessarily good at realising that, hence the part about generated prose being the most prescriptive part of my proposal. But my hypothetical robot demonstrates to me that "for people, period" is not quite the principle I'm coming from. We're probably close enough for the time being, though. > Thinking about it a bit more, the underlying theme is actually that of > engineering, contribution, and communication culture. It's easy to get > along with people who happen to share it, but it's a lot of work for > both sides when implicit assumptions don't match. We may be even better > served than by just policing LLM use if we state at least some of the > core assumptions which drive the project, provide some guidance for how > to soak up that culture, and ideally explicitly state positive examples. > That may substantially reduce the need to play catch-up with instances > of the same phenomenon. Yes, it would certainly be good if we could communicate the desired culture effectively enough that people (and LLMs) can pick up what to do =66rom the principles without needing to be instructed on every specific instance! --t5upmld2itajnnmy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQQGoGac7QfI+H5ZtFCZddwkt31pFQUCaoh3/gAKCRCZddwkt31p FYTIAQDNMyTno5+k0LQWihMGQ5o1HYE4ifrsEgqejHUgvP6BIwD/QWaiGbn9OOQU n4ebtZNu7cir9gtwaUs+ZsoR5OCsxAc= =809c -----END PGP SIGNATURE----- --t5upmld2itajnnmy--