[OSGeo-Discuss] Using AI in OSGeo projects - Notes from the Timisoara BoF

Seven (Aka Arnulf) seven at arnulf.us
Wed Jul 8 07:55:53 PDT 2026


Hello,
(it's been a while since I was active here) but theses are so 
interesting and challenging times that I also want to chime in from the 
side lines. I regret not having been at this Timisoara BoF!

As a project lead and senior (non-developing) software "manager" I have 
to cope with AI in diverse contexts.

I support Jeroen in saying that AI has come to stay. But also want to 
add "for good and bad!" We have to address the bad side, otherwise it 
will kill some of the most important aspects of open source - and the 
community around it. Immediately to my mind come the following issues:

* readability and understandability of code is suffering
* bloat
* growing danger of malicious code injection (also due to bloat)
* sheer increase of code base - and resulting increase for (non-AI) 
review, maintenance, packaging, debugging, etc.
* test bloat (may eventually shrink - but we have to actively address this)

Copyright? Anyone? Licenses? Hahaha.


On a community level we have all heard of the sharp decline of deep and 
thorough tech talk that can be searched in archived discussions. 
Stackoverflow, OSGeo mailing lists (is that even a thing anymore?), 
discord, all in decline. At the same time there is a bloat of 
superfluous documentation and innovation stagnates (LLMs are by their 
very definition not "creative".

On yet another level (from my business experience) I can see senior 
developers burn out by the dozens because they get choked with (often 
well meant) submissions, timelines become shorter while projects 
accelerate and delivery times shrink. The whole dev-to-prod cycle has 
accelerated so much (deliberately and purposefully to maximize output 
and efficiency) that it becomes hard to track and stay on top. 
Especially for core libraries this is an issue. Really old code base is 
fairly safe so far, but the new stuff, oh my!

AI increases efficiency but not necessarily effectiveness.

The worst are textual and presentation bloat (and is already creeping 
into regular dialogs and conversation). We ask AI to document the 
required functions in a statement of requirements and then let them 
transfer it to a requirements specification which then gets copied into 
prompts by (human) "engineers" tasking AI agents - which then do - 
"something".

Presentations are bloat so much that the receiving end immediately asks 
an AI to summarize it to then decide on - what exactly?

OK. This will not be the end of times - yet again. But we are certainly 
at a pivotal point in time and must therefore very carefully listen to 
those who have built the open source environment so far.


Thank you,
Seven



Am 08.07.26 um 14:27 schrieb Iván Sánchez Ortega via Discuss:
> Hey Jeroen,
> 
> I disagree with your point of view, because (from where I'm sitting) it seems
> biased. You say:
> 
>> If you code with AI or review PRs, we want you involved and I invite you to
>> start the conversation [...]
> 
> Reading between the lines, it'd seem that people who do **not** use LLMs for
> coding or reviews are not equally invited. The anti-LLM and LLM-skeptical
> folks deserve the same voice as encouragement than the pro-LLM folks. I don't
> think that's currently the case.
> 
> 
>> If we lose respect and stop being a welcoming community, the harm
>> lasts longer than any single PR. *We are in this together.* AI-assisted
>> coding is here to stay, and it also opens doors, [...]
> 
> You seem to be asking that the anti-LLM camp should show more respect towards
> the pro-LLM camp, and I have to ask for the opposite. When a maintainer says
> "no LLM PRs", the submitter should respect and welcome that. If we don't aim
> for that, I bet that people are going to feel disrespected and burn out.
> 
> 
> 

-- 
https://arnulf.us



More information about the Discuss mailing list