Upgrade StoragePlease reconsider the use of generative AI in Zotero's development
For anyone unaware, Zotero has implicitly adopted an AI-inclusive policy for code submissions and has embraced generative AI contributions via Claude. This has led to an apparent acceleration of Zotero's development, albeit at the cost of stability. For me, Zotero has become noticeably slower and buggier since its older versions.
I have recently encountered several concerning bugs: (1) Upon selecting a folder, a PDF appeared in the contents which was not supposed to be there and which persisted upon selecting a different folder. (2) When highlighting a folder in the sidebar, the highlight will persist even upon deselection.
While these issues are arguably minor, it will only get worse as more "agentic" slopcode is introduced into the codebase. Moreover, I note that the number of bug reports on this forum appear to have increased dramatically since earlier versions, which makes me very concerned about the future of this project.
As a user, I strongly object to the current state of things. I do not want to be saddled with these performance problems or user interface bugs. I want a stable codebase, written and understood by humans, with a more sustainable development cycle.
I call on the Zotero maintainers to reconsider the use of generative AI. I request they adopt a new policy prohibiting the use of LLM/generative AI contributions. I further request that the maintainers prioritise refactoring and cleaning up the codebase.
I have recently encountered several concerning bugs: (1) Upon selecting a folder, a PDF appeared in the contents which was not supposed to be there and which persisted upon selecting a different folder. (2) When highlighting a folder in the sidebar, the highlight will persist even upon deselection.
While these issues are arguably minor, it will only get worse as more "agentic" slopcode is introduced into the codebase. Moreover, I note that the number of bug reports on this forum appear to have increased dramatically since earlier versions, which makes me very concerned about the future of this project.
As a user, I strongly object to the current state of things. I do not want to be saddled with these performance problems or user interface bugs. I want a stable codebase, written and understood by humans, with a more sustainable development cycle.
I call on the Zotero maintainers to reconsider the use of generative AI. I request they adopt a new policy prohibiting the use of LLM/generative AI contributions. I further request that the maintainers prioritise refactoring and cleaning up the codebase.
Thanks for your reply, although I feel my concerns have been too quickly dismissed or even outright ignored. I've been using Zotero for over six years, and it is indeed my impression that there are a greater number of bugs, certainly based on what I've encountered. Take that or leave it for what it's worth, but it's a concern I'm raising here.
More substantively, my points regarding the use of generative AI still stand. My concerns are not specific to Zotero; others have similarly objected to the use of generative AI for coding. I believe the use of LLMs/agents will be actively harmful in the long-term. I feel that the best I can do is push back here. Please do not use generative AI in the development of Zotero. Please reconsider this policy.
Moreover, I believe these concerns are not unrelated from the accelerated release cycle, since one of the major arguments in favour of generative AI is faster production cycles. I personally value stability and maintainability of the codebase far more than additional features or an accelerated release cycle, so I would also support reconsideration of this policy.
If there's one thing I did not say in the original post, it's that I'm frustrated by Zotero's governance structure. I do not have any say in what policies are adopted and which features are prioritised, aside from raising issue or requesting features on this forum. That Zotero is open source is little reassurance to me, lest I become a contributor or act as quality assurance.
Zotero is not "vibe-coded", as your post originally put it. It is developed by a team of a dozen professional software developers, most of whom have been building Zotero for many years. These are developers who know the codebase deeply and review every line of code being committed, no matter how it's generated.
I'm not sure what "adopted an AI-inclusive policy for code submissions" is even supposed to mean. By and large, we don't accept third-party AI-generated code contributions, because there's usually minimal value in those from people who aren't familiar with the Zotero codebase.
But like nearly every other major software project now, Zotero developers use AI during development, to varying degrees, and that generally results in better engineering, better testing, and faster bug fixes.
Current versions of Zotero are much faster than older versions and are likely less buggy than ever before. We have more test coverage than ever, with over 3,000 tests run on every code push, and have needed fewer immediate hotfix releases in 2026 than any year in the last decade. Zotero 9 reduced startup memory usage by 20%, among other performance improvements, and Zotero 10 dramatically lowered memory usage in reader tabs.
What has changed is that there are a vast number of third-party plugins — many genuinely vibe-coded — with unrestricted access to Zotero's internals, and a huge number of the reports that we get here are from people seeing some problem caused by a plugin. That's why our standard response is to ask people to restart in Troubleshooting Mode to confirm any bug. We're working on adding additional sandboxed plugin APIs that will allow plugins to extend Zotero without compromising stability.
If you can reproduce a problem in Troubleshooting Mode, you should follow our standard bug-reporting guidelines so we can fix it. (You've posted to these forums three times, including this thread, and have never reported a bug.) Again, you are mistaken. AI wasn't a factor in the new policy. The faster release cycle is modeled after the release strategies that have been used successfully by major software projects like Chrome and Firefox for over 15 years, and it's primarily about merge policy, not development speed. As explained in the announcement, the goal is to get both stable features and bug fixes to users more quickly, instead of their languishing in year(s)-long betas that only a small minority of people use. You have as much say as any other user participating in these forums, which have been the bedrock of Zotero's community-centric development for 20 years. If you'd like more say in Zotero's development, posting here would be the place to start. But if you're coming here just to say that we shouldn't adopt industry-standard tools that lead to better engineering, there's not going to be much to discuss.