Hi, Would love to share my perspective of someone who vibe codes. This email is fully organic produced. I feel like this second change is over-reaction, and the actual issue can be re-traced and fixed under existing policy.
I have not brought AI/LLM pull requests to GDAL yet, but I have done that in other projects, lately on a larger scale. It has been a huge help for me: previously, I was annoyed at many issues in the software, but lacked applied skill to fix them across the diverse stack. In the case of PostGIS I was so annoyed that I had to learn C to fix stuff, and ended up on PSC, because many people were annoyed, but not many had the luxury to learn C. I wish I never had to learn C. Now, in the last couple weeks, I managed to fix build cache issues in ESPHome, fix build issues in the wifi7 driver of my new card, fix a cpu hotspot in htop, fix a metadata evacuation issue in bcachefs, update lora mesh simulator to validate my new assumptions on how to improve stability and get one negative and one positive result, configured redundant multi-isp network, fix all open tickets in h3-pg, and convert an android projector with calibration camera into a cat toy that plays with the actual cat. Previously this volume of changes would take years, and probably my cat will get unattended in the list. All this improved my quality of life too. Latest PostGIS day had a lot of examples of people using AI/LLM around GIS. It's early years still so there aren't many road rules yet so people still bump into each other, but I believe like git solved this for humans there will come some better solutions and traditions in the future. LLMs are also very steerable nowadays. Dropping AGENTS.md into project root and asking to test it [in which conditions] and to write in existing / desired style when coming PRs are doing same mistakes over is really changing what they do. Like, "read AI contributing policy in there: ..." so LLMs know what to aim for. I went so far as created a service that profiles hangs and crashes in the background and tries to stitch together an upstream patch: https://fixer.maumap.com/ While walking this path, I met a different attitude from maintainers: - The true "patches welcome": people give actionable feedback and merge stuff. When they're overloaded, they just reply that they are and pick up later, when they're free. - "Fuck AI" - I had software crashed on my computer, got stacktraces, produced a patch, and got some "it can never happen, fuck your AI hallucination". Often it is rather bystanders than actual maintainers. After some discussion it usually got merged. - "We know better" - a fun thing from OpenAI itself. They don't accept vibe coded patches (actually any patches) because their position is "we vibe code better and also can fix closed source servers instead, just give us prompts as tickets". - "Peer review first" - especially popular in LLM-related projects. Patches just hang in there. Some people (or their AIs) pick them up, check, apply locally, run for a day or two, check if fix/feature is working and post a "we like this, here's evidences:" on a PR. Maintainers just ignore PRs until they're comfortable with what's in them. - "We're not in git[hub] and don't accept PRs there" - annoying one. Sending patches over email seems very archaic, expecially when you need to first subscribe somewhere, can't reply to a thread that was there before you joined, and so on. Sometimes there's a github mirror but PRs are getting just straight rejected by bot, and you need to go serach where and how to register and then get replies in some weird way. -Dead projects, that don't have anyone behind them anymore. I don't know how to handle that properly without saying "here's my fork, it at least works here too. I would love gdal to be a projct where I can still use AI/LLM to fix the issues that annoy me in the same way I do elsewhere. How about reworking this policy change from "no AI" to "need to solve maintainer capacity problem". I think the "Peer review first" policy from the above may actually adjust it better. Just allow to put any PR into this mode, maybe via a tag or comment, and don't look at it until there are some reveiws and their results are fixed. People who have coded something for the project are likely using it, can test, it should not be annoying for them as it's not them doing the local build nowadays, just their llm, and they also likely will be ok to spend some tokens for the automated review in addition to testing. After there are like five of them approving without complaints, maybe it's time to merge. It may also be a good idea to issue something like call for maintainers. It is okay for Even to not want to look at AI code, it should not be creating discomfort, and there are definitely people out there who are more okay with looking at AI code if it improves the FOSSGIS situation (hi!). Thanks, Darafei. On Wed, May 13, 2026 at 2:19 PM Even Rouault via gdal-dev < [email protected]> wrote: > Howard submitted a substantial update / counter-proposal to my initial > one. I've taking it, but with amendments re-introducing points of my > initial version. Please check > > Le 12/05/2026 à 13:34, Even Rouault via gdal-dev a écrit : > > Any further comments before submitting to vote? > > > > Le 06/05/2026 à 18:29, Even Rouault via gdal-dev a écrit : > >> Hi, > >> > >> based on the experience gained from the initial policy, I propose to > >> significantly revise it to drastically limit their use. See > >> https://github.com/OSGeo/gdal/pull/14500 > >> > >> Even > >> > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
