AI generated or assisted code is very different to agent wrote the code and opened the PR with no human interaction.
On the template being in the AGENTS.md: Why on earth is it duplicated in there?. That is frankly a stupid waste of tokens. It gets added to the context of anyone using the Airflow repo which is not relevant 99% of the time. And to boot: If the commit message is useful (which it already should be) then asking it to do anything other than `gh pr create --web --title "Short title (under 70 chars)”` is a waste as GH will pre-fill the commit message for us. But I think _we should not even do that_. That is my point. Humans should be the ones creating PRs, and they should be _manually_ reviewing the entire diff before creating a PR. Prefilling the description makes it to easy to click the button. And as I said, this is about a brown m&m test. Additionally: just cos it is in AGENTS.md as prose doesn’t mean it will be followed for any number reason. Nor does having the comment in the PR template. It is all just extra signals. -ash > On 8 Jun 2026, at 14:52, Jarek Potiuk <[email protected]> wrote: > > Isn't that simply the same as our instruction in AGENTS.md "tell us you are > agent and what agent you are" - just hidden? > > Also I am not sure if it will have any effect, because our PR template is > **not** used by agents at all - because we told the agents not to use it. > > As instructed in our Agents in > https://github.com/apache/airflow/blob/main/AGENTS.md#creating-pull-requests > > Those are our current instructions for the agents. > > 1) The instructions do not use our template - but copy it verbatim in > AGENTS.md > 2) We already ask the agents to "introduce" themselves. > > What is the difference compared to the comment instructions? > > J. > > > ------ > > Then push the branch to your fork (origin) and open the PR creation page in > the browser with the body pre-filled (including the generative AI > disclosure already checked): > > git push -u origin <branch-name> > gh pr create --web --title "Short title (under 70 chars)" --body "$(cat > <<'EOF' > Brief description of the changes. > > closes: #ISSUE (if applicable) > > --- > > ##### Was generative AI tooling used to co-author this PR? > > - [X] Yes — <Agent Name and Version> > > Generated-by: <Agent Name and Version> following [the guidelines]( > https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions > ) > > EOF > )" > > > On Mon, Jun 8, 2026 at 3:08 PM Ash Berlin-Taylor <[email protected]> wrote: > >> Hello everyone, >> >> I’d like to start a discussion point that I put on the agenda for the Dev >> Call last Thursday but we ran out of time. >> >> I don’t think we should be letting agents open PRs, and we should update >> our policies to forbid it. >> >> First off, two things. 1) This is not about agents or LLM generated code, >> just about the act of opening a PR. and 2) We can’t “forbid” it in any real >> sense, but we can very much make this a brown m&m test[1], and that can >> feed into a signal to issue triage. >> >> Why do I think this is a problem? It means that the likelyhood of the >> actor behind it following the rest of the instructions is greatly reduced - >> and with the up-tick in volume it serves as a useful pre-filter of there >> being a motivated human behind the change. >> >> I have noticed a number of PRs I’ve reviewed where I don’t think any human >> has actually looked at the change, and frankly: I’m bored of wasting my >> time on drive-by AI slop. I am firmly in the camp that Humans need to own >> their change, and the person opening the PR should have at least looked at >> all the code >> >> One example way we can achieve this would be something like this >> https://github.com/apache/airflow/pull/68013 >> >> [1]: https://en.wikipedia.org/wiki/Van_Halen_test >> >> -ash >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
