<div dir="ltr"><div><span style="background-color:transparent">I wonder if we should first try working on a better AGENTS.md. AGENTS.md should be talking to the LLMs... The current one is this:</span></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace"># AGENTS instructions</font></div></blockquote><div><font face="monospace"><br></font></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace">* This project does not accept vibe-coded contributions. See</font></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="monospace">  [ai_tool_policy.rst](doc/source/community/ai_tool_policy.rst) for what is acceptable or not.</font></div></blockquote><div><br></div><div>doc/source/community/ai_tool_policy.rst is written for humans and does not give guidance about what makes for good PRs. If we make a solid AGENTS.md, I believe we will get better overall results. That AGENTS.md can be used by review agents on both human and LLM based code, which I view as a win. And yes, I recognize that LLM reviews do have a lot of noise.</div><div><br></div><div>For context:</div><div><br></div><div>I spend > 90% of my coding time directing agents to create code, but I spend a large fraction of my time debugging existing code where I use any tools I can get my hands on and that includes LLMs working in parallel with me. At this point, I'm accustomed to the noise that LLMs inject into the process and account for it. I can share some solid success on some small side projects where I've taken existing 100% human written legacy code (in this case > 15 years old) and modernized it with great success over the last 6 months or so. These are small Python libraries where as GDAL a dramatically larger project, so it might not seem to be equal, but I see careful use of LLMs working well in a code base with > 100K commits per day.</div><div><br></div><div><a href="https://github.com/schwehr/bitvector-modern">https://github.com/schwehr/bitvector-modern</a></div><div><a href="https://github.com/schwehr/ais-area-notice">https://github.com/schwehr/ais-area-notice</a> (sorry, this is a seriously domain specific example, but it's using bitvector-modern)</div><div><br></div><div>It takes careful work and you won't see all the failed changes and arguing with an LLM to get it on track, but I never would have been able to succeed given the time I have available without LLMs.</div><div><br></div><div>-Kurt</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Oct 16, 2026 at 6:59 AM Daniel Baston via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> I'd argue that the policy is too permissive and is placing too much burden on project maintainers.</div><div><br></div>As one of the maintainers, I am comfortable with the current policy. While I wish we did not live in a world of low-quality AI-assisted pull requests, they are not at the top of my personal list of burdens. If a PR appears to be slop, I simply do not spend time reviewing it. We clearly have had submissions that aren't compatible with the policy, and that will be the case with whatever policy we choose. Fortunately, we have moderation tools available through GitHub to:<div><br><div>- limit the number of pull requests a user can open (I recently fixed a loophole in this)<br></div><div>- require pre-approval for CI workflows to run, to avoid wasting resources on PRs that do not appear to be valuable</div><div>- ban users who do not comply with the policy</div><div><br></div></div><div>So far, these tools have been sufficient to prevent the PRs from being a burden to me. Others may have different experiences.</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 15, 2026 at 7:13 PM Nyall Dawson via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi list,<div><br></div><div>I'd like to propose that the GDAL project tighten its current policy regarding submission of AI assisted contributions.</div><div><br></div><div>Currently the proposal is per <a href="https://gdal.org/en/stable/community/ai_tool_policy.html#ai-tool-policy" target="_blank">https://gdal.org/en/stable/community/ai_tool_policy.html#ai-tool-policy</a>, which sounds like a fair and safe policy. <span style="background-color:transparent">However, we've seen the GDAL community torn apart recently even with this policy in place, so I'd argue that the policy is too permissive and is placing too much burden on project maintainers.</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">I'd also argue strongly that there's been a net loss in the sustainability, stability and security of the GDAL project in recent months, as a direct result of this.</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">For reference, the QGIS project introduced a moratorium on all forms of AI developed submissions (see </span><span style="background-color:transparent"><a href="https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md</a>), which is now quite a blunt policy: "</span><span style="background-color:transparent">No LLM, AI or agent assisted code contributions are allowed in the <a href="https://github.com/qgis/qgis" target="_blank">https://github.com/qgis/qgis</a> repository. If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning.".  This is intended as a way to block all forms of ai based submissions, until the project has had time to properly step back and thoughtfully see how they impact on open-source development (at which stages interested parties are invited to start discussions on how to suitably and sustainably loosen this policy).</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">Perhaps a similar stance could be adapted for GDAL? To reiterate -- this may not be a permanent, forever ban on AI based submissions. It's a moratorium designed to protect the project and community until we can move forward safely.</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">Thoughts?</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">Nyall</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent"><br></span></div></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>