Managing a popular open source project is a lot of work and can be very rewarding. This is especially so for a security-critical application such as KeePassXC that enables people around the world to protect their most sensitive information. As such, we have implemented a robust quality control process that ensures all code merged into production is thoroughly reviewed, tested, and signed off on.

Recently, we changed our contribution policy and readme to address code created by Generative AI by adding the following paragraph:

“Generative AI is fast becoming a first-party feature in most development environments, including GitHub itself. If the majority of a code submission is made using Generative AI (e.g., agent-based or vibe coding), then we will document that in the pull request. All code submissions go through a rigorous review process regardless of the development workflow or submitter.”

This statement has sparked a variety of reactions from innocent questions to serious concerns. We want to address them head-on and explain how we use AI and how we keep the project safe and secure.

However, before we can explain our process for AI contributions, we should explain our general code contribution workflow first. The KeePassXC Team has five maintainers with the ability to merge code into the develop branch, including two core maintainers with admin access to the organisation. Code contributions are generally posted to GitHub as a pull request. Code submitted this way runs through our CI pipeline for basic quality assurance and is then tested and reviewed line by line by one of the maintainers. Merging is blocked until at least one maintainer signs off on the changes. If the changes were proposed by a maintainer, another maintainer will do the review. This policy is strictly followed, even for small changes. After the review, the submitted commits are squashed into a single commit to ensure only the tested top state makes it into the main branch, and the CI will run again after the commit is merged.

This process is fully transparent and open for anyone to see, and it does not change with AI. We take no shortcuts. At KeePassXC, we use AI for two main purposes:

As an additional pair of “eyes” in code reviews. In this function, AI summarises the changes (the least helpful part) and points out implementation errors a human reviewer may have missed. AI reviews don’t replace maintainer code review, nor do they relieve maintainers from their due diligence. AI code reviews complement our existing CI pipelines that perform unit tests, memory checks, and static code analysis (CodeQL). As such, they are a net benefit and make KeePassXC strictly safer. Some examples of AI reviews in action: example 1, example 2. 1.

For creating pull requests that solve simple and focused issues, add boilerplate code and test cases. Unfortunately, some people got the impression that KeePassXC was now being vibe coded. This is wrong. We do not vibe code, and no unreviewed AI code makes it into the code base. Full stop. We have used Copilot agent to draft pull requests, which are then subsequently tweaked in follow-up commits, and reviewed by a maintainer, openly for anyone to see, with the same scrutiny as any other submission. Good pull requests are merged (example), bad pull requests are rejected (example).

All this is only part of the development process. There are no AI features inside KeePassXC and there never will be!

The use of Copilot for drafting pull requests is reserved for very simple and focused tasks with a small handful of changes, such as simple bugfixes or UI changes. We use it sparingly (mostly because it’s not very good at complex tasks) and only where we think it offers a benefit. Copilot is good at helping developers plan complex changes by reviewing the code base and writing suggestions in markdown, as well as boilerplate tasks such as test development. Copilot can mess up, and we catch that in our standard review process (e.g., by committing a full directory of rubbish, which we identified and fixed). You can review our copilot instructions. Would we ever let AI rewrite our crypto stack? No. Would we let it refactor and rewrite large parts of the application? No. Would we ask it to fix a regression or add more test cases? Yes, sometimes.

Since we are using AI responsibly this way, it made little sense to ban AI submissions by third-party contributors. Such a policy would be near-impossible to enforce anyway. In fact, we’d rather have them transparently disclose the use of AI than hide it and submit the code against our terms. According to our policy, any significant use of AI in a pull request must be disclosed and labelled. As of writing, we have 7 open and 11 closed AI-assisted pull requests. Feel free to check and review them yourself; it’s all open and transparent. If you spot any actual issues with the code that we missed, please tell us.

At the moment, this is all an experiment for us, and we will adjust our policies and methods as the need arises. There was a possibility that we’d be swamped with low-quality AI pull requests, but that has so far not manifested.

A fear often expressed was that we’d become lazy and lose our skills to review (AI) code properly. Let me tell you: all members of the KeePassXC team have many years of experience in software engineering and project management, we have maintained KeePassXC for almost a decade, and we still code ourselves for work and for fun. This will not suddenly go away because we have another tool in our belts.

Certain more esoteric concerns about AI code being somehow inherently inferior to “real code” are not based in reality. Code is deterministic, and the same instruction will always do the same thing regardless of who or what wrote it. There is no invisible ink. An incorrect snippet copied from an online forum is equally wrong and dangerous to one generated by AI or one invented by organic brain cells. What we must ensure is correctness and we do that with code review and tests.

And lastly, an interesting complaint we saw was that because AI code was optimised to look appealing to humans, LLMs could supposedly slip innocent-looking but malicious code past our code review. Personally, I would be much more concerned about a skilled human saboteur doing that than a general-purpose code LLM—look no further than famous recent supply-chain attacks. Beyond their technical limitations, commercial LLMs are not designed to purposefully generate nice but incorrect code (certainly not the ones we use), and it is hard to imagine how this would be a good marketing strategy. Malicious and deceptive LLMs are absolutely conceivable, but that would bring us back to the saboteur.

To add a little more context to the deceptive LLM argument: LLMs are indeed optimised by alignment methods to develop a desired style. This is not a magic superhuman trait. In fact, were you ever annoyed by the bubbly, wordy, seemingly eloquent, yet deeply obtuse language of LLM text? You’re not alone. LLM language is not magical, it is optimised to cater to the preferences of a broad cross-section of certain (mostly North-American) demographics. But all this is beside the point, because code is not a persuasive essay. There are many ways to write bad code (we have seen a lot of bad code submitted before LLMs), but in the end, it must produce a measurable result that needs to pass a test in order to be accepted.

So please, be skeptical of AI. But also be skeptical of human strangers as we are to you. If our AI policy toppled your trust in us, ask yourself why you trusted us (or anyone) in the first place. You don’t know us, you trust our reputation, and we earned that by building a stable product, which we will continue to do. You have our full commitment that we will not integrate any AI features into KeePassXC, and we will not merge any code (human or AI) without tests and thorough review. We have high standards; please continue holding us to them, but let’s have a rational and informed conversation.

Feedback

Please report any bugs you encounter at our GitHub issue tracker. We are also available on Matrix for real-time feedback and discussions. See our contact page for further options.