I don't think the AI instructions would be helpful in this case. They are used by AI coding agents (Claude Code, Gemini CLI, Aider, Copilot, Windsurf, etc) in use by humans.
In the case of those types of PRs, our contributing expectations [1] already cover some of that, such as requiring a valid profile with a real name - although we could, indeed, set even clearer expectations either preventing or setting rules for them. 1. https://camel.apache.org/camel-core/contributing/expectations.html On Tue, Aug 5, 2025 at 5:48 PM Łukasz Dywicki <l...@code-house.org> wrote: > And.. if we get dozen of PRs generated by AI, who is going to review them? > I suppose that in many cases review from third party may be harder than > making PR itself, because author who made PR is usually within the focus > to narrow the issue/feature, while reviewer sometimes has to step into > authors shoes in order to understand reasons for a change. > Will above instructions help with that as well? > > Best, > Łukasz > > On 8/5/25 18:21, Andrea Cosentino wrote: > > Il giorno mar 5 ago 2025 alle ore 16:17 Guillaume Nodet < > gno...@apache.org> > > ha scritto: > > > >> Le mar. 5 août 2025 à 15:19, Otavio Rodolfo Piske <angusyo...@gmail.com> > a > >> écrit : > >> > >>> "I think it's a good idea, my only concern is giving too much trust to > AI > >>> agents." > >>> > >>> +1. > >>> > >>> I think we can possibly include a reference to this in the > instructions. > >> I > >>> know certain AI coding agents tend to try to be more autonomous by > >> default > >>> (i.e.: by authoring commits, for instance) and I think we could include > >>> instructions specifically prohibiting that. > >>> > >> > >> I disagree. The fact that the agent did the commit or raised the PR > does > >> not mean anything wrt the underlying patch quality. I often ask an > agent > >> to commit and raise a PR after multiple iterations (AI and/or manual) > and > >> the fact that the agent did the commit (it can easily write better > commit > >> messages) or raised the PR, is completely irrelevant to the quality of > the > >> patch. Committing / raising a PR does not imply merging to master. > >> > >> On a related note, we have a lot of commits that break the build which > are > >> authored by humans. I'd much rather improve that ! > >> > > > > Indeed, the important part is always passing through a PR and review > > process. > > > > And yes, it's true sometimes we commit code breaking the build, so yes we > > should improve on that side too. > > > > > >> > >> > >>> > >>> I also think it goes in line w/ the ASF instructions in the sense that > >> the > >>> contributor is the ultimate person responsible for the origins of the > >> code. > >> > >> > >> RIght. But if he is responsible for the code, let him be and not add > >> burden. > >> > >> > >>> > >>> > >>> On Tue, Aug 5, 2025 at 12:03 PM Andrea Cosentino <anco...@gmail.com> > >>> wrote: > >>> > >>>> Absolutely, that's what I meant. Don't blindly trust them. > >>>> > >>>> Il giorno mar 5 ago 2025 alle ore 12:01 Guillaume Nodet < > >>> gno...@apache.org > >>>>> > >>>> ha scritto: > >>>> > >>>>> Can that be solved by asking for PR reviews ? > >>>>> > >>>>> Le mar. 5 août 2025 à 11:37, Andrea Cosentino <anco...@gmail.com> a > >>>> écrit > >>>>> : > >>>>> > >>>>>> I think it's a good idea, my only concern is giving too much trust > >> to > >>>> AI > >>>>>> agents. > >>>>>> > >>>>>> They still need to be supervised. > >>>>>> > >>>>>> Il giorno mar 5 ago 2025 alle ore 10:40 Otavio Rodolfo Piske < > >>>>>> angusyo...@gmail.com> ha scritto: > >>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> I'd like to bring to discussion that we add a set of a dedicated > >> AI > >>>>>>> instructions file (e.g., INSTRUCTIONS.ai) to the Apache Camel > >>>>> repository > >>>>>>> (core and other sub-projects). > >>>>>>> > >>>>>>> The purpose of these files would be to define how AI-powered > >> coding > >>>>>> agents > >>>>>>> and tools should behave when generating code for this project. I > >>>>> believe > >>>>>>> this would be beneficial for a few key reasons: > >>>>>>> > >>>>>>> 1. > >>>>>>> > >>>>>>> *Enforce ASF Generative Tooling Guidelines:* It would help us > >>>>> formally > >>>>>>> adopt and point to the standards defined by the ASF on the use > >>> of > >>>>>>> generative AI, ensuring all contributions are compliant. > >>>>>>> - > >>>>>>> > >>>>>>> Apache Software Foundation Legal - Generative Tooling > >>>>>>> <https://www.apache.org/legal/generative-tooling.html> > >>>>>>> 2. > >>>>>>> > >>>>>>> *Maintain Project Coding Standards:* We can use it to instruct > >>> AI > >>>>>> tools > >>>>>>> on Camel's specific coding patterns, conventions, and > >>>> architectural > >>>>>>> principles. This will help maintain the consistency and > >> quality > >>> of > >>>>> the > >>>>>>> codebase. > >>>>>>> 3. > >>>>>>> > >>>>>>> *Define Clear Guardrails:* It allows us to establish a > >>> reasonable > >>>>> set > >>>>>> of > >>>>>>> rules and constraints for generated code, promoting security, > >>>>>>> reliability, > >>>>>>> and adherence to best practices from the start. > >>>>>>> > >>>>>>> This is becoming a standard practice in other major open-source > >>>>> projects. > >>>>>>> For example, the Linux kernel community is already discussing and > >>>>>> defining > >>>>>>> similar guidelines to ensure AI-assisted contributions are > >>>>> constructive. > >>>>>>> > >>>>>>> - > >>>>>>> > >>>>>>> Linux Kernel Mailing List Discussion > >>>>>>> < > >>>>>>> > >>>>> > >>> > https://lore.kernel.org/all/20250725175358.1989323-1-sas...@kernel.org/> > >>>>>>> > >>>>>>> I believe that taking this proactive step will help us harness > >> the > >>>>>> benefits > >>>>>>> of AI tooling while safeguarding the integrity of the project. > >>>>>>> > >>>>>>> I'd like to open a discussion on this. What are your thoughts? > >> Any > >>>>> other > >>>>>>> projects in the ASF that have defined these instructions and that > >>> we > >>>>>> could > >>>>>>> inspire our guidelines on? > >>>>>>> > >>>>>>> > >>>>>>> Kind regards, > >>>>>>> -- > >>>>>>> Otavio R. Piske > >>>>>>> http://orpiske.net > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> ------------------------ > >>>>> Guillaume Nodet > >>>>> > >>>> > >>> > >>> > >>> -- > >>> Otavio R. Piske > >>> http://orpiske.net > >>> > >> > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> > > > > -- Otavio R. Piske http://orpiske.net
