The most important rule: be honest and inform about it!
Tools should generally be used for improving the quality of the project, not for rapidly adding new features.
Keep a log of the prompts used - prompts should be included
verbatimely in the git commits as long as it's possible without making
the messages too messy. When relevant, chat-output may also need to
be included. The docs/design-folder can be used for dumping
AI-generated design documents, code reviews, prompts that are too
large for being included in the commit message, etc.
Keep it clear what is human-written vs what is AI-written. In a feature-branch, separate AI-commits and human-commits is preferable. Those should most often be squashed together before including it in the main branch, with a notice in the commit message on what parts of the commit is AI-generated.
If you've spent hours, perhaps a full day of your time writing up a pull request, then I sort of owe you something. I should spend some of my time looking through the submission carefully, and if nothing else, I owe to be polite, respectful and guide you in the right direction or give a good explanation for why I think your pull request is pulling the project in the wrong direction. A human being have feelings, I should be careful not to hurt your feelings.
At the other hand, perhaps you've spent 30 seconds either doing ruff check --fix ; gh pr create or telling Claude "Please fix support for
Microsoft Exchange and create a pull request". Do I still owe you to
spend time looking through the submission carefully and spending time
being polite and caring about your feelings?
Perhaps your pull request is just one out of many such "drive-by pull requests". It doesn't scale for a maintainer to spent lots of time on each such pull request. At least, I should not waste time trying to explain in details why I'm rejecting the pull request.
It's fine to ask the AI for help to analyze a bug and create a fix for it. By discovering the bug, reproducing it and testing it you're adding real value to the project - just remember to be honest, if you have no clue what Claude did and why it solves the bug, then inform! Do not take offence if the code changes are rejected, or completely rewritten.
-
Do respect the maintainers time. If/when the maintainer gets overwhelmed by pull requests of questionable quality or pull requests that do not pull the project in the right direction, then it will be needed to add more requirements to the Contributors Guidelines.
-
YOU should add value to the project. If you prompt the AI to "look through the issues for this project, find some low-hanging-fruit, fix the issue and send a PR", then it's Claude and not you delivering value. I can run the same prompt myself, and it would cost me less effort than to review your contribution.
-
YOU ought to understand the changes. The change goes into the project attributed to your name (or at least github handle), so it would be nice if you understand the change you're proposing.
-
Transparency is important. If a significant part of the value in the pull request was generated by tools, then it's relevant. Do not write "I found this issue and here is a fix", but rather "I ran the ruff tool on the code, it found this issue, and here is the fix". If the AI was fixing a bug for you, then write in the pull request that "this bugfix was vibed up, I have no idea what the AI has done here". End the commit message with "Assisted-By: ..." or "Co-Authored-By: ...".
-
YOU should be ready to follow up and respond to feedback and questions on the contribution. If you're letting the AI do this for you on your behalf, then it's a chance you're neither honest nor adding value to the project. You should at least do a quick QA on the AI-answer and acknowledge that it was generated by the AI.
-
Most AI policies warns about potential copyright infringements. I can hardly think it's any risk wrg of contributions to the Python CalDAV library. In particular, if your changeset consists of lots of minor changes to existing code, then it's nothing to worry about.
-
The Contributors Guidelines aren't strongly enforced on this project as of 2026-02, and I can hardly see cases where the AI would break the Code of Conduct, but at the end of the day, it's YOUR responsibility that the contribution follows those guidelines.
The maintainer started playing with Claude Code in the end of 2025 - and blogged about it
Releases 2.2.6 - 3.2.0 has been heavily assisted by Claude - which is pretty obvious when looking into the commit messages. My experiences has been mixed - sometimes it seems to be doing a better and faster job than me, other times it seems to be making a mess a lot faster than what I can do it. Despiteof (or because of?) using Claude extensively, I spent much more time on the 3.0.0-release than estimated.
Lots of time and efforts have been spent on doing QA on the changes, fixing up things and/or asking Claude to do a better job. The surge of issues reported after the 3.0-release is probably unrelated to the AI usage - it's a result of trying to shoehorn both async and API changes into it without breaking backward compatbility and without duplicating too much code. The CHANGELOG.md entry for 3.0 explicitly declared a caveat: "there are massive code changes in version 3.0, so if you're using the Python CalDAV client library in some sharp production environment, I would recommend to wait for two months before upgrading".
I don't have any good log of prompts given to Claude prior to the 3.2.0-release, but some of the considerations from Claude has been stored under docs/design. A copy of my CLAUDE.md-file can now be found in the same directory.
Generated changes and human-made changes are often mixed up. I prefer "logical" commits containing self-sustained changesets, one of the things I'm often asking Claude to do is to do a rebase of a branch and organize the commits in one or few logical commits with descriptive commit messages.
Post-3.2.0 and until further notice I will try to go back to the old ways for doing the "core development tasks" - new features and complex refactoring. If nothing else, it's important for maintaining my brain cells, coding skills and making sure all the changes sticks to my memory. The new policy is that GenAI-tools should be used mainly for improving quality, not speeding up the development.
I still intend to use GenAI heavily for certain tasks, particularly anything that is either "mundane and tedious" or unrelated to the "the working end" of the library. Examples:
- Code reviews. I think there should be a policy that all changesets and releases should go through AI-driven code review. By itself it sounds like a good idea, though one should be aware of the risk is that this comes instead of human reviews rather than as an addition.
- Writing up test code. I do believe "test driven development" is a good idea (write test code first, then the logic), but writing tests may be both tedious and difficult. Claude can make them really fast, though it still needs some QA, care should be taken to ensure it's testing the right thing.
- Debugging. It's easy to get stuck and spend tons of time on debugging - sometimes (but not always) Claude can find them easily. (Best approach is sometimes to do manual debugging in parallell with AI-driven debugging ... sometimes I "win", othertimes the AI "wins").
- Minor bugfixes ... the bugfix itself may be a one line changeset, but tests and debugging takes time.
- Maintaining the integration test framework. I've consistently failed setting up and maintaining a "battery" of caldav servers from 2013 to 2025, thanks to Claude we now have it in place. It's important, a majority of issues reported are about compatibility problems, the more servers I have for testing every release, the less troubles will be discovered downstream.
- Setting up CI-related automated QA tests, pipelines etc
- The companion caldav-server-checker tool is quite suitable for GenAI-work - it's a bit like test code, writing up the checks to discover various server issues is rather tedious and time-consuming. Without AI-help I would probably have covered less than half of the "features" that are now tested for.
- Investigations of different architectural choices - like with the async work I had claude develop different design approaches and chose the one that I felt most comfortable with (though I'm still not sure that I did the right choice).
- Reading RFCs and quickly give a pointer to the relevant sections, or verifying that the code is according to the standards or not (but care should be taken - I've seen Claude hallucinating completely wrong RFC references).
- Various other mundane and tedious work (i.e. "I left a TODO-note in the code over there, could you have look into it and eliminate it?").