Ardour development and AI

Blog
#1

So, Robin and I (Paul) have begun some discussion about the possible role of LLM-based “AI” in the development of Ardour. Before going any further, let’s clarify what remains unchanged in our assessment:

  1. machine generated code cannot be copyrighted; it therefore cannot be licensed, which means that if it is not public domain (a concept that doesn't really exist within the EU), it cannot be compatible with existing FLOSS licenses, including the GPL2+ that Ardour uses.
  2. US courts (and others) have indicated that some amount of human intervention in the generation of code by a machine makes it copyrightable, but they have not indicated precisely what level of intervention/involvement/modification is required.
  3. currently, the most capable LLM's remain under the tight control of high-value corporations, who can price access to it as they see fit, as well as withdraw or curtail access for any (or no) reason at all.
  4. using LLM's requires large amounts of energy and highly specialized and very expensive hardware. This is typically not local to the user, but "in the cloud".
  5. the construction of the "data centers" where this hardware is located is a focus of worldwide opposition, partly but not wholly attributable to the energy and water consumption that these centers require.
  6. LLMs have been trained unscrupulously on the vast mass of open source projects, along with an unknown amount of non-open source code. When they are asked to generate code, the extent to which they are violating the terms of the licenses of the code they were trained on is subject to significant debate; it is sufficient to note that there are questions to be raised here about both the morality and the legal provenance of the generated code.
  7. LLMs can generate new code (and thus new "pull requests") that arrive at open source projects like Ardour) at a rate that almost always outstrips the capacity of human programmers to review it effectively. This either means massive overload for code reviewers, or the adoption of large amounts of unreviewed code, or both.
  8. Overall, widespread adoption of LLM-based technology appears likely to have profound economic, political, social and environmental impacts, with many/most of them negative for the foreseeable future. For this reason, we are extremely reluctant to adopt it within the Ardour project.

In the interests of "knowing the enemy", we have experimented a little with Claude ourselves, and watched several LLM-generated PRs sent to the Ardour project. More recently, we've seen the emergence of at least four "vibe coded" complete DAWs, written in a tiny percentage of the time Ardour took and at least superficially very feature complete. This has caused us to consider whether our absolute position on "no LLM code" in Ardour is correct, and we've decided to open this discussion up to our community. But before that, please read more to see the sorts of things we're thinking about.

Bad LLM code/design

It is clear from some of the PRs we've seen that LLMs are entirely capable of generating problem-riddled code designs. We think that this may be partly a function of the fact that person prompting the LLM doesn't know much about Ardour's internal architecture or about what we consider "good design". We do not want to spend any time reviewing such PRs and we don't want their code inside the program. Even on one small project that Paul attempted, the initial LLM-generated solution was completely wrong and deeply flawed from a design perspective (it did provide a few clues on how to move forward with human-based development, though).

Amazing LLM code generation

Paul recently tried Claude's capability to implement a large body of code (16k lines of C++) that could address a fairly significant issue for Ardour's future prospects. This was mostly grunt work, implementing several hundred functions required by an API, but using a technology that has so far played no part in our codebase. Claude was apparently able to complete this task in a single digit number of hours, after 14 iterations with feedback and insights from Paul. We do not believe there is any human being alive on the planet who would have voluntarily completed this task, let alone in the time frame that Claude appears to have taken. In this case, the resulting work could benefit many other projects who are currently grappling with potential irrelevancy on future Linux systems.

Developer-constrained Development

Over the years, Ardour has benefitted from the amazing contributions of developers and others. However, it remains true that for most of its life, the project has been severely constrained by available developer-hours. Some of the tasks we have on our roadmap are deep, intense, far-ranging projects. It is (to be frank) quite intimidating to think about starting these when the scope of the changes and the likely time to get them release-ready are so large.

Although the new "vibe-coded" DAWs are lacking in innumerable details that Ardour (and other traditionally developed DAWs) have gained over the decades, there is every sign that their codebase can evolve at astonishingly fast rates. They may not be contenders for serious use today, but in 3 months or a year, that could be a very different situation.

Based on what we have seen of Claude (and others) so far, there is no way that any human development team can effectively keep up with what a good LLM coding harness is capable of.

Who's going to do it? Who's going to care?

Continuing on from the previous point: there is no queue of programmers lined up waiting to work on Ardour. If we use an LLM to accomplish a task, we have not taken that task away from a human developer, we've simply made it more likely that the task gets done.

Further, Ardour is a tool, not a final product for the overwhelming majority of our users. Extending and improving the capabilities of that tool takes nothing away from the audio productions that our users undertake with Ardour.

So ...

... the question becomes: how to proceed here? Here is an outline of an approach that Robin and I discussed:

  • We do not accept LLM-generated code (*) generated for/by people without write-access to our repository. Possibly the limitation would be both more specific and more arbitrary than that: we need to feel confident that the code has been generated at the direction of someone who understands Ardour's internal architecture and design. This would likely lead to some dissatisfaction since the criteria will likely appear arbitrary to some. (*) This would be waived for 1-5 line bug fixes whose purpose and intent is clear.
  • We should preferentially use LLM's to generate code for features/projects that are developer-time limited, rather than inspiration limited. To give an example from our current context (fall of 2026): this principle would support using LLMs to work on a feature like folder tracks, but not helping Ardour to be more friendly to non-western musical culture.
  • When using an LLM we should strive to play a significant role in the design and evolution of the code, to the extent that we can confidently claim copyright (in the face of the legal situation mentioned above).
  • When reviewing LLM-generated code, we may reject it en masse for any reason, without explanation. This is critical for limiting the chance that we are just overwhelmed by LLM-generated PR's. We cannot stop those from being queued, but we need to remain free to take a very quick look and just reject it without explanation. We know this may be hard on some possible contributors, but the project cannot become dominated by PR reviews. The first point above notwithstanding, it would be ideal to first discuss features with developers before asking an LLM to generate code that has a strong chance of being summarily rejected.
  • We continue to have zero to very limited interest in AI-assisted workflows within Ardour. The only possible exception at this time might be stem separation. We do not work on automated mixing, automated composition, automated accompaniment etc. etc.

In as tiny a nutshell as it can be put: what do you think about using LLM coding tools to speed up the development of Ardour (under something like the guidelines described above), versus remaining free of such tools' output but also moving at a notably slow pace compared to other DAWs (notably the new "vibe coded" ones)? Again, this is not a question about AI tools within Ardour, but the use of AI tools to work on development.

Let us know (we're sure you will). This discussion is not binding on us, but we are seriously and genuinely interested in your opinions.

15 Likes
#2

In the face of current realities and future probabilities I think this is your only option and I think you are taking a very balanced and common-sense approach, thanks for sharing this with the community.

4 Likes
#3

Thanks for being open and transparent with your internal discussions.

I appreciate that it might not be easy to land on a sensible path here. But you list several misgivings to begin with, which I largely agree with, and apart from the legal issue of copyright, you seem to address none of them with your proposed approach. Is the idea to just swallow those in the name of some kind of “inevitability” of LLM tool proliferation? The ethics of these tools don’t change because of the surge of reverse engineered DAW clones.

I think we’re in for a wild west of new offerings because of this trend now. Many of these projects will be abandoned and unmaintained after a short while. Some might end up being good, but they will be fully dependent on LLM token pricing and compute availbility. If you are a music producer hoping to find a new “home” in these LLM-generated clones, I think you need to prepare yourself to move alot in the coming time.

I for one would appreciate the continued stability of a human developed application.

7 Likes
#4

1000% slow team here.

1 Like
#5

I agree with rasmus here, the ethical drawbacks of allowing such contributions, many of which are listed quite cogently in the former half of the post, are too significant to ignore, even in the limited proposed capacity.

As a user I’m more than happy waiting longer for patches if it means the development process does not entertain such tools.

2 Likes
#6

I agree with the sentiment presented by @rasmus. I wouldn’t want to use and donate to a program whose development burns tokens at the expense of the poor, and fills the pockets of venture capitalists. That goes against the very reason FOSS exists.

An extra point not mentioned in your post – it has been studied that heavy LLM use leads to deskilling, making human specialists gradually lose their competence. Whether this happens is largely up to the individual, because no one can police “thinking for yourself” during development. But adopting AI tools definitely paves a clearer way for individuals to fall victim to this effect, potentially leading to future engineers being less capable than today.

That said, the world operates in shades of gray, not black-and-white. I admire those opposed to AI trends and mostly oppose them myself, but there are some areas where I can see the benefits, like the aforementioned 16k+ lines of C++ that no one would have voluntarily written. Some development work is inarguably tedious and does not involve contructive insight or problem solving. This of course does not nullify the ethical concerns.

As for the ethical concerns (enviroment), I think the key lies in moderation. Currently the tools have become too widespread and using them is too easy, which leads to wasting energy and resources. The existence and tone of this post gives me confidence that Ardour could be trusted with not “overusing” the technology, but of course I could be wrong.

Can’t really comment on the legal aspect of training on data without permission. It is undoubtedly evil, but the deed is done – maybe it’s sensible to use some models, as long as it does not produce demand for more stealing? If that is even possible.

To sum up, I believe AI use could be excused in some extreme cases, but I’d be happier knowing that my DAW of choice is human-made. Please don’t follow in Linus Torvalds’s footsteps.

[EDIT] I’m not happy with how these last two paragraphs came out. The reason I was lenient is because the problem does not lie with the LLM technology itself, but rather with the current socio-political landscape surrounding it. It is futile to try to separate this from politics, unfortunately.

I think Ardour should proudly reject LLM code today, due to the many dubious-at-best, ethical compromises that would surround this decision. If a more ethical way to use this technology becomes viable in the future, we should have this discussion again. But right now, it is more important to stick to FOSS principles.

1 Like
#7

As I put it to a coding friend who asked why I don’t use Suno or some other tool to “get more done, quicker”: You know what the best bit about writing lyrics is? Writing lyrics. Singing and realising that it’s horrid to vocalise and getting that last line into place, often at the microphone when laying it down.

Now, if I have recorded and I need to remove some noise or fix a pop or some other minutae, I don’t care if it’s hand-done, analogue, digital or “AI” assisted. Whatever works.

I get the impression that you guys want to approach Ardour the same way. FWIW, I do think that the code situation is the same as the artistic situation. It is a ticking time bomb; legal-wise, quality-wise and most importantly, detrimental to your own mental-health and pride in your work.

I trust you will make the best choices for your baby.

3 Likes
#8

@paul and @x42, that is simply an outstanding essay on an important topic. I expect it to result in valuable discussions and will follow with interest.

I’m not a coder but offer this observation. It appears to me that the Ardour dev team includes more than just the two of you. Somehow you qualified these other contributors. Perhaps a similar approach could be applied to AI-generated submissions. My guess is that the qualification process is informal at this point - someone came up with a feature or idea for Ardour, communicated it to you, and established their expertise over a long enough period of time to give you confidence in their abilities. Could this process be formalized so that you’re confident enough to review and potentially accept contributions that have AI-generated components? And reject out of hand contributions from unqualified individuals and/or sources?

1 Like
#9

(post deleted by author)

#10

I chose and pay for Ardour because it is open-source software. I am aware more comfortable, but proprietary software could be used instead but I refuse to use it. In the same way, I will keep using Ardour because it is AI-free.
Do you consider the vibe-coded competitors to threaten Ardour’s financial balance and existence, if at some point, they become complete enough?

1 Like
#11

This has been debated in scientific circles.

https://www.researchgate.net/publication/393011815_Generative_AI_without_guardrails_can_harm_learning_Evidence_from_high_school_mathematics

https://arxiv.org/html/2609.20143v1

1 Like
#12

Yes, absolutely. However, my initial panic about this has lessened somewhat, and I think this quote from Chris Randall in a recent blog post summarizes it as well as anything:

There are a lot of delay plugins. You buy ours because you believe that we either do understand, or want to understand, what you’re trying to accomplish, and we want to help you realize it. You are paying for a relationship with Adam and I, in essence, and the fact that between the two of us we have nearly a century of experience in electronic music, and also use these tools we make. Our 25 or so years of business have been predicated on that relatively simple relationship, but the times, they are a-changin’.

(AI Slop, Vibe-Coded Clones & Indie Plugins | Audio Damage)

We can only hope that Chris’ point is true for Ardour (*), and remains true for some significant time to come.

(*) the point being that the people behind a project, notably their (our!) committment, attitude and beliefs matter significantly.

7 Likes
#13

Another one from team slow here, for all the obvious reasons, including “to whom do you attribute credit, when the attributions have been stripped out?”

For background, I’ve had an entire career in IT infrastructure, with an increasing focus on automation via programming. The end of the last role in that career actually happened because, between my own work and my coaching of team-mates, we automated three of our own roles (including mine) out from under ourselves.
So I’m very much a fan of tools that accelerate productivity, and I completely understand the appeal of something that can generate new code with that kind of a multiplier.

LLMs, though? I’ve been watching from the sidelines, and I’ve yet to hear of a case where they’ve worked out well in even the medium-term, especially for maintainability. They do seem to be popular in generating security exploits, though :slight_smile:
Also, part of my concern is that they’re often observed to have a corrosive effect on their users’ judgement, and the excellent judgement of the Ardour team is one of the reasons it’s still my primary tool.

In case you’re wondering: yes, I’ve thought about trying to contribute myself. However, I’m primarily a Lisp developer, with added background in Python, no C++, and a nasty case of chronic burnout. I can try…

2 Likes
#14

For me one very important feature is support and long term stability. I easily would prefer this over having every new feature under the sun. (Even today I only use a part of the features Ardour offers.)
I would be very annoyed if I had to learn new tools as they come and go (That’s what’s gonna happen)

2 Likes
#15

I think AI is ok, but the person who delivers the code must understand it all and fully respect the coding standards and policies, so that anyone working on that code in the Ardor project can understand it at a glance and feel comfortable with what they see.

In just a few months, the reality has changed in so many ways; even the Linux kernel gang (mostly) accepts AI code under certain conditions.

2 Likes
#16

I’m happy to see that you guys are seriously considering this. I think the guidelines you have laid out are completely reasonable. As a user, I don’t want slop in Ardour, but I don’t mind using an LLM to speed up development so long as it is being supervised by someone who knows what they’re doing.

The only part I disagree with is this one:

We continue to have zero to very limited interest in AI-assisted workflows within Ardour. The only possible exception at this time might be stem separation. We do not work on automated mixing, automated composition, automated accompaniment etc. etc.

The features you’re describing here would be a massive boon to my workflow. I’ve mentioned in another thread how I’d like to have something similar to Logic’s Session Players, which probably fit under auto-accompaniment. And automated mixing would save me literal hours of headaches, even if it just generated a rough mix and expected me to fill in the details. I don’t care about automated composition though.

#17

Yes, and many of us have responded by migrating partly or entirely to NetBSD.

4 Likes
#18

It’s true that vibe-coded DAWs are pumping out features really fast, but, even ignoring all of the ethical concerns, they’re not time-proven. Ardour has been around forever and has earned trust: users know that maintainers are capable and willing to fix issues that arise with the program. Vibe-coded DAWs, on the other hand, haven’t been around for long enough and haven’t had to actually maintain their work in response to the changing times or even bugs resulting from expanding the scope. It’s not Ardour that has to worry about keeping up with vibe-coded DAWs, it’s the vibe-coded DAWs that have to worry about being able to keep up. I wouldn’t be compelled to learn a tool I can’t hope to rely on in the future.

6 Likes
#19
Tiny Nutshell:

Under the guidelines you describe, yes, do it.

Large Nutshell:

  1. In my opinion, to ultimately resolve the completely-valid moral/non-free/ethical/environmental(/etc.) concerns of using LLM tech. especially as offered by behemoth corporations, you should perhaps set your more long-term sights on buying and building a local, Ardour-trained LLM (or other) system to assist you. I imagine on a time-scale of 2-5yr this will probably be possible (with comparable speed to what Anthropic, "Open"AI, etc., has to offer currently). -Decentralization is the way to go for sure.
  2. Somewhat needless to say, but I think you should at least guarantee that Ardour will forever remain as 100% human-reviewed code at a bare minimum. LLMs can help you do some of the “grunt work”, as you understandably put it. –But ultimately every single line/patch of code is at least read with a cogent, human mind (-like yours or Robin’s) to ensure correct flow, syntax, logic, overall ‘correctness’, as well as your personal preference. (In other words, never, ever succumb to using “AI” as a magic, black box.)
  3. You and Robin (and others) have absolutely proven yourselves as incredibly versatile and knowledgeable developers. That skill set (colloquially speaking) ain’t goin’ nowhere. If there’s anyone to be using LLM for assistance and, again, laborious “grunt work” that literally no one wants to do, it should be expert, knowledgeable devs such as yourself.
  4. Thus, as you suggested, rejecting most or all LLM-generated code from those who are not a part of the core dev team makes 100% sense to me. (-And you should explicitly state that condition basically everywhere so that LLM PR’s are hopefully kept to an absolute minimum.)

Thank you for authoring this blog post!
It’s definitely a pressing topic at the moment… :face_with_spiral_eyes: :woozy_face:

-Joe L.

1 Like
#20

Yes, that’s well known. But the Linux kernel is still there and will continue to be. Personally, I stick to Linux.