Updated 30 September 2026
LinuxLinks reviews and recommends free and open source software. Inclusion on the site is an editorial decision, not an entitlement. An entry in one of our roundups represents a recommendation, so we consider more than a project’s stated features. We also examine its reliability, maturity, maintainability and development practices.
What We Mean by “AI-Heavy”
We use the term “AI-heavy” when generative AI has played a substantial role in producing or modifying a project’s code, tests, documentation, artwork or other important materials.
The term describes how a project was developed, not what the software does. A program that offers AI-related features is not necessarily AI-heavy.
Occasional use of AI for explanations, debugging assistance, code review or routine development tasks does not automatically make a project AI-heavy. There is no dependable way to calculate the precise proportion of a codebase produced by AI, so we do not apply a fixed percentage threshold. Each project is assessed individually.
Our General Position
We do not impose a blanket ban on software developed with the assistance of generative AI. These tools can be useful when employed by developers who understand, verify and take responsibility for the resulting work.
However, substantial reliance on generated material can introduce additional concerns. These include:
- Features that are incomplete or do not work as described.
- Repetitive, unnecessarily complex or poorly structured code.
- Weak error handling and inadequate testing.
- Unsafe, outdated or unnecessary dependencies.
- Unexpected network activity or other security concerns.
- Documentation that does not accurately reflect the software.
- Uncertainty about the origin or licensing of generated material.
- Maintainers being unable to explain, debug or repair their own code.
- Projects being abandoned shortly after their initial release.
For these reasons, AI-heavy projects are generally less likely to receive coverage, particularly when they are new, immature, derivative, poorly tested or presented with exaggerated claims.
Disclosure Requirements
Anyone submitting a project to LinuxLinks must disclose material use of generative AI accurately.
The disclosure should explain, in reasonable terms:
- Which generative AI tools were used.
- Whether they were used for code, tests, documentation, artwork or other project materials.
- The approximate extent of their use.
- How generated material was reviewed, tested and verified by a human maintainer.
For an AI-heavy project to be considered for coverage, we strongly prefer this information to be disclosed prominently in the project’s README, website or development documentation. It should not be hidden in an obscure issue, discussion or commit message.
Failure to disclose substantial AI use, or providing misleading information about it, will normally result in the project being declined.
How Projects Are Assessed
When considering an AI-heavy project, we may examine:
- Whether the software works reliably on Linux.
- Whether its advertised features are actually implemented.
- The quality, clarity and maintainability of the code.
- The project’s testing and release practices.
- The accuracy of its documentation.
- The maintainer’s understanding of the codebase.
- The maintainer’s ability to investigate and correct faults.
- The project’s development history and prospects for continued maintenance.
- Dependency, privacy and security risks.
- The provenance and licensing of project materials.
- Whether the software offers genuine usefulness beyond existing projects.
A repository’s size, commit count or apparent level of activity is not treated as proof of quality or maturity.
Editorial Decisions
We may decline coverage when there is insufficient evidence that a project is reliable, properly maintained or understood by its maintainer. We may also postpone consideration until a project has established a credible development and maintenance record.
Established projects may be treated differently from newer AI-heavy projects. Where a project has a long development history and substantial adoption, we may continue to recommend it even if recent development has become heavily AI-assisted. We distinguish between mature projects that later adopted extensive use of generative AI and newer projects whose codebase has been substantially built through AI-assisted development from an early stage.
An AI-heavy project may still be covered when it is useful, transparent, properly tested and maintained by people who clearly understand and take responsibility for it.
We may revisit existing coverage if a project is abandoned, if serious faults come to light, or if previously undisclosed AI use is discovered. An entry may be amended or removed when the project no longer meets our editorial standards.
We do not maintain a separate category for AI-heavy software. AI use is a development consideration, not a software category, and a separate listing could be interpreted as an endorsement.
Final Decision
All coverage decisions remain at the discretion of LinuxLinks. This policy is intended to protect the quality and usefulness of our recommendations while allowing responsible and transparent use of generative AI in software development.

Please read our Comment Policy before commenting.
Good to read.
On 23 July 2026, Codeberg changed its Terms of Use to prohibit projects that mostly consist of code written by generative AI tools, explicitly naming Claude and OpenAI Codex.
It is a shame GitHub is unlikely ever to introduce a similar rule. That would hardly fit Microslop’s determination to force AI into every part of software development.
Are you seeing a lot of vibe-coded on github?
There is shed loads of the slop.
I actually do some vibe coding. I’ve taken a useful CLI tool and removed some of the functionality I’ve not needed and added a few things that really help me. I’m not going to submit the code to the project nor make my repositirory available.. It’s just for my personal use.
fooyin has just published their AI policy:
We do not accept contributions for which generative AI was used at any stage of the development process. Please do not contribute code, documentation, tests, images, or other project material created or modified with large language models, image diffusion models, or similar tools.
Once a contribution is merged, its long-term maintenance becomes the responsibility of the maintainer and other core contributors, which is why contributors must understand and take ownership of every part of their submission.
This policy operates on trust. We may ask whether generative AI tools were used when reviewing a contribution, and pull requests that involve their use will not be accepted.
fooyin is not alone in being super strict when it comes to AI. Zig bans even talking about use of chatbot/LLM services.
Prise, a multiplexor you reviewed recently fits this, the GitHub page mentions AI assisted “collaboration” and the project is now archived.
Marco, thanks for letting me know that Prise has already been abandoned. Just to clarify, my piece was a brief overview of the software, not a review; reviews on LinuxLinks carry the Review tag.
Prise will not be included in our terminal multiplexer roundup, and has been updated to reflect its archived status.
Thanks for this! And for a really useful page!
Why not just have a separate category for AI written software?
That’s an idea for sure. But I’m still concerned about the sheer number of these projects coming out and how long they will last before the ‘developer’ gives up.
The issue is that as a project gets more complicated, LLMs can get send the individual round and round in circles without providing say a critical bug fix. The ‘developer’ themselves has no coding skills to fix it. So the likely outcome is the project gets abandoned.
Do you know that LLMs are being used for Linux kernel development?
Indeed. The kernel now has formal AI-assistance rules.
Honestly, they seem to not entirely deny AI assisted tools but rather appear to be more cautious than usual entirely human-written code. Their reasoning backing their policy is pretty sound IMO. I am myself working on tools that use AI assistance (I use it to see alternative implementations, personal preference) but I probably won’t be submitting for now, till they mature a bit more at least.
The policy gives some confidence on the listings, if anything IMO.
You’re correct. We don’t automatically veto software that makes use of AI.
I’m currently writing a review of a program (not a roundup entry) that makes heavy use of AI in its development process. One reason that convinced me to review is that the maintainer has a prominent disclosure about AI usage.
I thought about this for a while.
We don’t plan on implementing a separate category.
AI-heavy describes how software was developed, not what it does, so it is not a useful software category. There is also no reliable way to determine how much AI was used, making classification inconsistent and potentially unfair.
A separate section could give immature or quickly abandoned projects publicity and appear to endorse them.
But thanks for your suggestion, Leo.
I think using gen AI to create your own projects is perfectly fine. I’ve vibe-coded a couple of apps for my own use. Without any real programming knowledge, I’ve created something that’s really useful for me. I’m not going to share the code though.
I’ve also taken a few existing projects and added a couple of extra enhancements. They make the software so much more useful for me. Even if others might be interested, I’m not going to submit the code to either project, they are just for my use only.
I think that’s a perfectly reasonable use of generative AI.
If you can create something genuinely useful for yourself, or modify an existing program so it better suits your needs, that’s one of the more compelling uses of these tools. You know who the user is, what you need from the software, and you’re not asking anyone else to depend on it.
My concerns are much more about AI-heavy projects that are publicly released, heavily promoted and presented as mature software when the developer may not understand much of the code or be able to maintain it when something goes wrong. That’s a very different proposition from vibe-coding something for your own use.
I really admire projects that completely ban AI.
This article has been adapted into a formal policy.
I don’t give a monkey’s whether software is written with AI.
I agree. In the same way I don’t really care about the language used to write the software, what IDE the developer uses, and so on.