We'll see how this develops, but I suspect it will encourage contributors to post LLM-(re)written walls of text under the pretense of fixing the grammar.

It seems to me that an explicit definition of what consitutes "vibe coding" should be included directly in this policy rather than as a reference to Wikipedia.

There are probably also several degrees of "vibe coding".
A developer might start a work item as "vibe coding" and then spend several hours or days refining the code (with various degrees of AI assistance) to the point that the problems inherent to "vibe coding" may no longer be problems?

I am really concerned that a blanket ban on vibe-coding for open-source projects are problematic, as closed-source solutions would likely allow whatever achieves best development velocity (still taking maintenance cost into consideration).

It seems to me that an explicit definition of what consitutes "vibe coding" should be included directly in this policy rather than as a reference to Wikipedia.

We may argue about the exact definition, but fundamentally using LLMs is an anti-social / anti-ethical behavior in the context of open source software were maintainers are still human. That make them even more the contention point that before. As raised by @dbaston https://lists.osgeo.org/pipermail/gdal-dev/2026-May/061636.html we review code from others in the hope that a small percentage of them will grow as maintainers and will take a bit of that burden. Reviewing LLM generated code is just helping tech giants improve their model and doesn't grow any new maintainer.

as closed-source solutions would likely allow whatever achieves best development velocity (still taking maintenance cost into consideration).

By that metrics, closed-source solutions have always been "better" than us because they can align more developers. Let them do their thing and we'll talk again about the end result they've achieved in 5 years

Why is velocity so important ? Are there so many missing features in GDAL that they need to be rushed ?
Code added is more a long-term liability than an asset.

If velocity of development is so important then people can contribute to Oxigdal, and it is written in Rust. Or create their forked GDAL with agents reviewing & automatically merging code.

By the way, it is great to see so many people reviewing this PR. I'd wish they'd do the same for the more "boring" ones 😜

fundamentally using LLMs is an anti-social / anti-ethical behavior in the context of open source software where maintainers are still human

I strongly disagree with that statement (and indicated as much in the OSGeo charter member survey about LLM usage), but I fully understand where you're coming from as a key maintainer with an unbelievably large number of things to review.

Reviewing LLM generated code is just helping tech giants improve their model and doesn't grow any new maintainer.

While this is true, this should also improve the quality of future PRs.

Isn't maintainers productivity also improved by LLMs?

Why is velocity so important ?

Long term if a closed-source solution becomes much more capable than an open-source alternative, the recent open-source adoption gain trend might reverse. It's also about being able to do more with one's time and being able to make more contributions (which can still be of a certain quality).

I'd wish they'd do the same for the more "boring" ones

I think part of the solution to get more maintainers may actually be through LLM usage for performing human-in-the-loop reviews.

I am not against rejecting contributions where there's clearly no human in the loop, but I think "vibe coding" can actually be a very efficient way get started on implementing new features in particular (even if careful self-review / refinements should be essential).

Going back to the original question of definitions, I would argue that by the time we come up with a good definition for vibe coding, it will already be obsolete. We should also appreciate how quickly this landscape is evolving and treat any policies we come up with as living documents.

Adopting those new toys under the pressure of a feeling of urgency would be a terrible idea. That's exactly the narrative that tech giants want to instigate in our minds. My personal opinion regarding e.g. adopting a new programming language has been "let's way 15 years and see if it is still there" (Rust is almost at that point :-))

GDAL has always been a very conservative project in terms of tech adoption (I have to fight each time I want to bump the C++ version!). I guess if it is still there after 28 years, this must be part of the reason of its success.

I see. In that case I suggest dropping the term "vibe coding" altogether and focus directly on LLM assist. The wording used by Oracle is a good starting point, making it clear which activities are allowed and those which are not.

has been a terrible experience and showed me that it would ultimately lead to burn out if becoming the norm.

I really believe the solution for this should not be banning LLM assistance.

A possible solution is to have parallel tracks of pull requests for different level of LLM assistance.

Perhaps indicating the amount of human time invested by the contributor(s) in preparing a PR.

Each maintainer could decide which of these tracks they invest how much efforts in.

Each maintainer could decide which of these tracks they invest how much efforts in.

I haven't heard about any existing GDAL maintainer who was keen in reviewing LLM generated PRs. As a proof of that, notice the 3 ones flagged as such at the bottom of https://github.com/OSGeo/gdal/pulls that have been sitting there for many weeks. It is disingenuous to say to potential contributors that they may use LLM assisted coding if there are no maintainers willing to review such PR.

GDAL is already a much too big beast compared to the size of its maintainer community. We don't need more code coming from people interested in drive-by contributions.

There was an initial version of this policy, at it was confirmed that is was not enough. If I remember correctly it was "softened" after some discussions. Now we have to harden it.

It has been explained many times: the reviewing and maintenance resources are very, very limited. The experience is that throwing LLM generated code saturates those resource. So we have to cut this. Immediately. Otherwise the project CANNOT CONTINUE.

GDAL is not in a hurry to implement anything. It is mature, stable and well known (and good quality). And these qualities are valued out there, by open and proprietary code.

For sure in some time we will review this policy. Maybe to make it even harder, or softer. Let's see. But now we have to act to protect the project and its maintainers.

https://dl.acm.org/doi/full/10.1145/3807518 might be interesting to this discussion. They offer their own definition, and explain why, based on current literature, vibe coding in large, long-lived projects can be problematic.

Is "latently" the right word here? Possibly should be "largely"?