In C# they are pretty bad when it comes to adding unnecessary complexity, same with plain javascript. I mostly use(at work) them to repeat patterns now, all original code and reasoning is done by me.
This also lets me get by with less tokens than my workmates since an LLM just copying or slightly changing things to fit new entities does not need a lot of reasoning, especially since business logic will be explained in the prompt.
But the biggest part is the smallest thing on the UI: the picker, which automatically determines the curve, to which you can then apply the gain (gonna have to rename local contrast)
And I love the results. Yeah, still in progress, but it just looks great already. I would never be able to do this on my own. To me, the maths, concepts and implementation is stratospheric, in a language i dont know. It might be stratospheric for most dt contributors too.
Only way for me to achieve this is a 4 step loop
plan (opus)
implement (sonnet)
review (opus)
fix (sonnet)
Now Iām not sure if darktable should accept these 5000 lines of AI slop, genuinely not sure if it is a good idea. But I can tell you, this is going to serve me well for a long time to come.
You need to iterate on that with several prompts asking the model to implement best practices, focus on code quality, problem decomposition, reusability, readability, maintainability and what not. If possible, you ask one model to do the analysis, a different one to implement and another one to judge the result. I am not talking about different sizes, actually different models (e.g., Claude vs. Gemini). You then do a thorough code inspection. You take note of all the details that you do not like and ask the model to act on them.
You repeat this process a couple of times (more for very large changes) and your code will be much better than virtually anybody could ever write (in a finite and reasonable amount of time, that is).
For all my coding assisted contributions to darktable, I spend way more tokens on these iteration loops than on the actual feature implementation. The proportion is probably 4 or 5 to 1.
EDIT: This was the whole point of the OP. Itās a tech that makes it possible for the developer to focus on the end goal instead of the nitty-gritty details. It creates a huge potential for a level of polish and feature-completeness (especially in FOSS projects) that until recently one could only dream about.
Yes, and this is the real difference that a lot of non-engineers do not understand: these are all tedious and very time consuming activities that no one enjoys doing. As a result, we tend to do it sloppily and superficially, because itās not what we want to be spending our time on. Instead, an LLM will do all of the above with complete dedication, and if properly prompted/harnessed with much better results. Also, the human brain is not very good at static code analysis, in which LLMs - on the contrary - excel.
Another area where LLMs help immensely is prototyping. You can try out 1000 different things, and each of them costs only minutes instead of hours if not days. That means that you can actually afford the luxury of exploring the solution space, as opposed to settling on the first thing that ākind of works and doesnāt breakā.
Writing a hack program to insert metadata in JPEGs of engineering drawings for a museum. Started with the idea of bash scripts and exiftool, but rapidly distilled the solution to a single C++ program, with a bit-hack ImageDescription tag insert routine provided by Copilot. I understand the JPEG structure well-enough to have figured it out over a few days, but Copilot just puked it out in a couple of seconds. A specific task, easy to completely specify, and a solution I can easily pick through to verify.
When you dig through the toolbox for a tool, just have to make sure you donāt grab it by the pointy/sharp endā¦