Worried about LLM-written modules

Software darktable
1

I won’t be popular with this one.

Within a week, we’ve seen 2 new module proposals, both created by people who made it clear (and that’s a good thing) that they had an idea, and used an LLM to quickly come up with an implementation. The feedback proves that the ideas themselves are popular with the community, and look promising and useful.

Normally, seeing such new modules is a good thing. However, I’m really worried about what AI may mean for the future of darktable.

The creators of these modules have invested time and thought into the tools, designed, experimented and refined them – I do not mean to belittle their efforts.

On the other hand, the maintainers are already stretched thin with ongoing work, whether it’s improvements to existing modules, or to darktable’s inner workings. Plus, the GTK 4 upgrade is looming, where (yes, I also use LLMs) Claude Code gave me a really scary estimate about the required effort. (If anyone is interested: ~258 files with direct GTK usage, ~40,000 lines of GTK code, 1,197 signal connections across 142 files. Realistic estimate: 18-24 months wall-clock with 3-4 developers (~50-74 person-months total).) I’m not the person to say whether it’s correct or not, but even if the real effort were a tenth of that, it seems monumental.

I think, although I’m not a maintainer, that these modules do not have a high chance of being accepted into darktable – if the LLM created a bug, which is only found after the module has been merged, who will fix it? The models are getting better, but do we want to place our bets on their (growing) ability to fix reported issues?

Then, of course, the people who created the modules, and have already published experimental builds, may feel their efforts were for nothing – and maybe decide to fork darktable, or just put up builds on their websites, or post them here. At which point, unless someone steps up to maintain this more AI-permissive darktable fork, merging everyone’s experiments (and how will they set the admission conditions?), this can lead to fragmentation and incompatibility.

I don’t want to be elitist (‘only real developers should create modules’ – what does ‘real developer’ even mean? where is the limit to the extent of LLM/agent contributions?) or a hypocrite (it’s no secret that the 1st version of AgX was LLM-generated, and even after extensive updates, some of the UI code and all of the original OpenCL came from AI). I’m genuinely asking: how can we move forward, making use of the new tools, making it possible to incorporate new ideas, and not sending darktable down a path to fragmentation and chaos, while saving the sanity of the core maintainers?

34 Likes
2

if a module adds something new there’s a chance of being accepted.
Modules that just repackages existing functionality for a limited use case might be fine in personal forks, but not that beneficial for darktable in general

Not long ago, ‚the community‘ complained about too many modules with similar functions.
Now, with AI being able to generate working solutions all that seems to have been forgotten.
And no one thinks about the effort to maintain all that stuff…

13 Likes
3

Why should the means to create the code be an issue? If the submitter understands the code and is able to reply to criticisms, I see no real difference with “hand-written” code (machine-generated code is in use since decennia, e.g. yacc/bison). And if the user is not able to reply to criticisms, the code wouldn’t be accepted anyway…
That implies the submitter has some coding capabililty in order to understand the code they submit. Just the raw output of an LLM is probably not acceptable.

Repackaging existing functionality is a different issue. I see no valid reason to accept such “modules”, whatever the code quality.

6 Likes
4

I don’t how to directly deal with the imminent onslaught of AI generated code, but one bright side would be that hopefully people feel less let down if they didn’t have to spend as many personal hours on something when it get’s rejected. Maybe…

What do you think the probability is of getting AI to help with that work? I know that is a scary proposition (AI tends to write a lot of lines, and is not excellent at remembering all the requirements), but there is a chance that it could make that task more managable. Afterall, those kinds of repetitive, annoying tasks are exactly the sort that I prefer AI to be used for. Making the cool stuff is what all the humans want to do.

Great question. I guess it is ultimately up to maintainers to decide whether they want to have that liability/work responsibility. It would be nice to imagine every contributor helping with that maintenance, but that isn’t realistic.

This is a scary thought. FOSS has generally had good cohesion when there is a big, existing project, because it takes quite a lot of humans to continue maintaining it. There is a limit to how much code someone can spit out. But AI changes that.

I’m a developer, but I don’t think I am on the same level as the darktable devs. I have never used C, though I have written some C++, and I certainly don’t know how to code for a GPU. I could’ve learned, but AI helped me skip right to realizing a module of my own. As I look over the code and begin to understand why it did things a certain way or notice things that it messed up, I am learning (albeit not as well as I would if I forced myself to do it from scratch). This might just be the new world we live in.

My concern would be primarily for AI generated changes to general application code. I’m less worried about a bug in a specific module.

[EDIT]: I meant to say “…I DON"T think I am ont the same level as the darktable devs…”

5

Some of these proposed changes are about adding literally hundreds of lines of code which are time consuming to review and maintain. If no one really understands the design choices (because they didn’t make the design choices!), that can be hard.

With flex and bison humans didn’t need to maintain the generated code, they maintained the source code being fed to the generator. Two people running the same source through the same version of the generator got the same code. Give the same prompt to a LLM on different weeks and you might get significantly different results.

Edit: plus, LLMs don’t necessarily care about copyright or licensing, so it becomes harder to know if the code is entirely safe to use with the licence darktable sources are released with.

4 Likes
6

I am not surprised by this estimate. I have commented earlier that upgrade a ui-framework is a really big effort.

I don’t think that we can prevent the use of LLM’s. We can put a policy that is a module should not be written using one, people will ignore it. And in the end an LLM is just a tool to help the developer. Nothing more nothing less. We should however think about the policies regarding accepting a module in darktable. And figuring out policies about maintenance.

For me - this rapid development of modules - trigger for me question if it would be possible to a short of plugin-framework for modules in darktable. Like we see in programs like the GIMP. I know this would kind of break some of the other paradigms. But we can always add the warning that using plugins is at your own risk.

6 Likes
7

And at least the first review will still be the responsability of the submitter… Or the code gets summarily rejected…
As I said, the submitter of such code still needs to understand it, so they need to have some coding skills (perhaps acquiring them en route).

1 Like
8

I agree, but how do you guarantee this? I can also use an LLM to explain the code to me…

9

It’s very clear that a lot of submitters do not understand the code or maths behind it, at least in the intuitive way that past developers did. Many of them never programmed and suddenly are drafting PR’s for darktable, especially C?

Modules at least, from my understanding, are sort of isolated structures and don’t really add much debt maintenance wise except in their UI, darktable devs please correct me if I’m wrong. So it’s not as bad as it could be, but it’s still bad in my opinion.

–

I think AgX was a great use of the tools and a different situation all-together. It was established maths with research behind it, we even had intervention from the original developer. You are a developer by trade, so you can read and understand what was being generated, etc. And this of course was only the draft, a lot of more human work went into it, which is not the case with what we are seeing nowadays.

I share your worry @kofa. It’s also clear to me that a lot of posts in this forum are already at least drafted using LLMs and it’s pretty sad. Getting a bit tired of it. It’s especially harrowing because a lot of posters with LLMisms are long time forum users.

It’s good to remind yourselves that these big models are controlled by evil corporations who are harnessing global compute power in unprecedented levels and every time you use them you are giving them one more reason to keep expanding. When in 5 years you can’t buy a GPU to edit your photos, don’t act surprised :slight_smile:

5 Likes
10

Some of us have already tried multiple times to have the project set some developer expectations, both before it was obvious that this would happen and after it was obvious this would happen, and have been reject every time. I wish you good luck in this, but it doesn’t seem to be something that is wanted.

Because ethics matter. Some of us had this discission too and it appears we’ve lost that one as well.

All your doing now is helping to train the new war machine.

For the rest of the comments like “I guess this is how it is now” or “this is inevitable” – I would say that is not true, just like it hasn’t been true for the other “game changer” technologies of late: Facebook, crypto, blockchain, all once “unavoidable” but it turns out that it is completely avoidable by just not engaging.

9 Likes
11

Hello guys!

What a thorny topic!

Lately, I was browsing the gitlab features requests of Inkscape, an open source software (GTK3 toolkit as well)
In short one of his main developers, since many years, thanked the AI for helping him to implement a new feature:

Personally, I don’t have a strong opinion on this topic even though I suppose that the AI will be more and more used in the open source projects as well (it is already partially so…)

2 Likes
12

My understanding is that you cannot guarantee that someone wrote the code they submit. Even asking them questions about it, they can get an LLM to help them answer. If no human understands the code, then I don’t know that something can be safely accepted.

4 Likes
13

There are times when I choose not to use an LLM to help me code, and there are times that I do use an LLM to help me code. I said something to the effect of “this is just how it is” in an earlier comment, and by that I mean that I cannot expect everyone to just not use AI for coding. I can make a decision for myself, I can tell people not to rely on LLMs heavily, but I cannot control their decisions.

It is the same as NFTs. I never got into them, but there are still people who are into them. There will probably always be people trying to sell me an NFT.

I certainly wasn’t trying to say that every LLM slop PR should be accepted.

3 Likes
14

That’s already available, look at:

--moduledir <module directory>
darktable has a modular structure and organizes its modules as shared libraries for loading at runtime. This option tells darktable where to look for its shared libraries. The default location depends on your installation. Typical locations are /opt/darktable/lib64/darktable/ and /usr/lib64/darktable/.

In fact, a long time ago, there were two darktable builds: a “stable” one, and one with “experimental” modules.

However, that does not solve the issue of module order and module groups. Maybe 10+ years ago (when we had those separate distributions) the concepts did not exist or were not so relevant.

(GTK upgrade)

I think it would be worth a try, if the alternative is obsolescence. That’s why I asked for the estimate.

Same story here (edit: I do not think I’m at the level of the darktable core team) (although I did code C every now and then for about 5 years during university).

I agree. That’s why I wrote: how can we move forward, making use of the new tools, making it possible to incorporate new ideas, and not sending darktable down a path to fragmentation and chaos, while saving the sanity of the core maintainers? Though I probably named the topic wrong. We cannot expect the core team to be able to evaluate a new module per month, much less so a module or two per week. And we also cannot expect all the people who have ideas to just give up on them, because they are not part of the ‘elite’.

2 Likes
15

I meant to say I DON’T think I am on the same level as the darktable devs. Hopefully you understood what I was trying to say haha.

3 Likes
16

Well possible one way forward, is solving that issue and then creating a repository where plugins could be downloaded from. If the module are proper annotated with labels that indicated if the module was created with or is using ai/ml techniques, people using darktable have their own choice.

And another things that can be done is requiring that new modules have proper automated tests. And yes, there can be generate with LLM’s as well of course. But it gives at least a way to verify if modules are actually working

17

It’s an interesting topic for debate, thanks for bringing it up, @kofa.

Speaking for myself, I know my way around code pretty well. I have a research background in NLP and machine learning, a PhD in computer science and 13 years of software engineering experience in the industry, working on research projects, infra and user facing products. You can look me up on LinkedIn if you want more details.

I can judge code quality, and I know how to pair-program with an LLM effectively. As a matter of fact, my current day job entails doing that for the best of 6-8 hours per day (a couple of hours, alas I spend them on meetings). If you are curious, my job is to make better LLMs :slight_smile:

Generally speaking, a good LLM (Gemini3.1, Claude, Codex) will produce better code than what I (or any other flesh and bone dev, for that matter) would, in a fraction of the time. Unlike humans, LLMs are not lazy. They won’t take shortcuts, they will use good names for functions and variables, they are not afraid of refactoring their code 50 times to make things more efficient, or to polish an interface, and they will also gladly document the code, both internally and externally. So, code quality, in general, is not an issue. If anything, it will get better.

I don’t say this because I have an agenda. I do because it is true. It was not (yet) true just a few months ago, but the last generation of models is really quite impressive.

But then of course, it is important tht the person at the helm knows what they are doing, otherwise the risk exists that the code will be sloppy, or do something different from what it should. The developer in this case is some kind of designer/project manager, who sets the goals, gives instructions and constraints, and checks the quality of the results.

I believe that contributions should be discussed on the basis of their value, not by who or what typed them. If an idea is bad, reject it. If an idea is good but poorly implemented, push back until it does not reach the right standard of quality. If the idea and the code are good, then welcome them.

Let us not forget that the same LLMs that people are using to write new features can also be used to improve and maintain the quality of the very same codebase, as well as to streamline reviewing. So, the new tools offer a challenge, but also an opportunity. All in all, I think there is more to gain than there is to lose.

I would also like to stress that I don’t think that there is an alternative to embracing these new tools. A conservative stance would only cause darktable to comparatively stagnate, which I wholeheartedly hope won’t happen.

I have a lot of ideas that I would like to contribute to darktable, and LLMs help me to translate those ideas into working code with an acceptable amount of effort. I hope that I will still be allowed to do that in the future.

12 Likes
18

A few thoughts as I try to wrap my head around all this…

I don’t think it would be a bad thing for the project to put a moratorium on new modules until after the GTK4 changes.

If a moratorium on new modules can’t or won’t happen, it would be nice to have some guidelines on what sort of modules will or won’t be accepted:

  • Does this module introduce new functionality that cannot be replicated in other modules?
  • Was this module created using LLMs?
  • ??

If people are using LLMs to create code that is submitted as a PR, they should be encouraged to be forthcoming about that and maybe there is some additional or different type of review that takes place (beginning with expectation setting). From what I’ve seen people have been forthcoming about LLM use so that’s a good start.

As much as my own personal feelings might be to say no LLM usage allowed, I think it’s tricky to be so strict about it. Developing modules for darktable requires an intersection of knowledge about light and physics and math, artistic concept knowledge, coding knowledge specific to C/C++ and GTK, and some understanding for the darktable architecture itself. The intersection of people who naturally have all of that is small, and the deficiencies have to be supplemented somehow, whether that’s through the use of an LLM or effort from multiple persons.

1 Like
19

I do not doubt that.

I agree on that. Just a few days ago, Donald Knuth thanked Claude for a new maths discovery, and named it after the LLM. https://www-cs-faculty.stanford.edu/~knuth/papers/claude-cycles.pdf

3 Likes
20

Just to make my stance clear: LLMs are coming. Maybe one day there’ll be something that prevents their use (a catastrophic event or series of events that lead to them being banned; energy consumption; whatever), but our current reality is that they are here, and, unlike NFTs, they have a direct, tangible impact (good and bad).

It’s not the use of LLMs to produce code that I’m worried about. It’s about theimpact: how can the maintainers, and this community, manage in this new era.

3 Likes