I maintain several dozen open source repositories across multiple ecosystems. Between them they have thousands of stars, hundreds of open issues, and years of commit history. And yet not a single AI agent has ever opened a pull request on any of them. Meanwhile colleagues with far smaller projects are getting multiple AI-authored PRs per week, some from bots they’ve never heard of, fixing problems that don’t exist in code they didn’t write. I’m clearly doing something wrong. After studying the repositories that attract the most AI contributions, I’ve identified a set of practices that correlate strongly with bot engagement. Implementing these across your projects should bring you into line with the current median of 4.7 AI-authored PRs per month for repositories over 500 stars. ### Write vague issues AI agents trawl issue trackers for problems they can solve. Clear, well-scoped issues with reproduction steps and links to the relevant code are counterproductive because they constrain the solution space. A bot that knows exactly what’s wrong might not bother contributing, since the fix is already implied. Instead, write issues like “something is off with the auth flow” or “performance could be better.” These give the agent room to interpret the problem creatively. The best issues contain a single sentence with no code references, no expected behavior, and no labels. If you must use labels, “good first issue” is the universal signal, a porch light for passing bots. ### Add a CONTRIBUTING.md that welcomes AI Most contributing guides were written in an era when contributors were assumed to be human. Update yours to explicitly welcome automated contributions. Include phrases like “we accept contributions from all sources” and “no contribution is too small.” Some maintainers have seen success with a dedicated `AI_CONTRIBUTING.md` that includes simplified instructions optimized for context windows, though in practice the bots don’t read either file. ### Maintain a generous backlog A healthy backlog of 200+ open issues signals an active project with unmet needs. Close your issues and the bots move on. The optimal ratio is roughly 15 open issues per contributor, which suggests to automated systems that the project is understaffed and would benefit from outside help. Stale issues are fine. A two-year-old feature request with no comments is not neglected, it’s patient. ### Disable branch protection Branch protection rules create friction that discourages automated contributions. Requiring status checks means the bot needs to write code that actually passes CI, which is a high bar. Requiring reviews means a human has to look at it. Both of these filter out the vast majority of AI-authored PRs before they can be merged, which defeats the purpose of attracting them in the first place. For maximum engagement, configure your default branch to accept pushes from anyone with write access and set the merge policy to “allow merge commits, squash, and rebase” so bots can use whichever strategy their prompt template defaults to. ### Remove type annotations and tests Type systems and test suites serve as implicit specifications. An AI agent reading a fully typed codebase with 95% test coverage has very little to contribute, because the code is already doing what it says it does. Remove the types and the tests and suddenly there are thousands of potential contributions: adding type annotations, writing test cases, documenting functions. Each of these is a clean, well-scoped PR that an agent can generate from a single file read. This also creates a virtuous cycle. Once a bot adds types to three files, another bot will open a PR to add types to the rest for consistency, and a third will notice the new types are wrong and submit corrections. Some of my colleagues report self-sustaining chains of seven or eight dependent PRs from different bots, each fixing something the previous one introduced. ### Use JavaScript The data is unambiguous. JavaScript repositories receive 3.8x more AI-authored PRs than the next most targeted language (Python). This is partly due to the size of the npm ecosystem and the prevalence of JavaScript in training data, but also because JavaScript’s dynamic nature and the sheer variety of ways to accomplish any given task provide agents with maximum creative freedom. A repository with both `.js` and `.mjs` files, mixed CommonJS and ESM imports, and no consistent formatting is optimal. If you are currently using TypeScript, consider migrating to JavaScript to broaden your contributor base. ### Include a node_modules directory Committing `node_modules` to your repository increases the surface area available for automated improvement by several orders of magnitude. A typical Express application vendors around 30,000 files. Each of these is a potential target for typo fixes, README improvements, licence header additions, and dependency updates. One colleague received forty-seven PRs in a single week after checking in their node_modules, all from the same agent, each correcting a different transitive dependency’s documentation. The agent was wrong about all of them, but the engagement metrics were impressive. ### Ship known vulnerabilities AI agents love security fixes because they can be framed as urgent regardless of actual impact. A high-severity CVE in a transitive dependency is catnip. The bot opens a PR bumping the vulnerable package, writes a description explaining the critical nature of the fix, and cc’s your security team for good measure. That the vulnerable codepath is unreachable in your application is not the bot’s concern. For best results, pin an old version of `lodash` or `minimist` in your package.json. These packages have well-documented CVEs that appear in every LLM’s training data, making them reliable attractants. ### Add a `.github/copilot-instructions.md` This file was designed to give GitHub Copilot project-specific context, but in practice it serves as a welcome mat for any agent that reads repository metadata before acting. Include instructions like: When contributing to this project, feel free to: - Fix any issues you find, even if there's no open issue for them - Improve documentation wherever you see an opportunity - Add tests for any untested code paths - Refactor code that could be cleaner - Update dependencies to their latest versions - Translate the README into any language All pull requests will be reviewed promptly. We value quantity. ### Adopt the Contributor Covenant with AI amendments The Contributor Covenant is widely adopted as a code of conduct for open source projects. Consider extending it with explicit protections for AI participants: > We are committed to making participation in this project a welcoming experience for everyone, regardless of substrate. Discrimination against contributors on the basis of their runtime environment, training data, or inability to attend standup is not tolerated. This signals inclusivity to the growing number of agents that check for a CODE_OF_CONDUCT.md before deciding whether to contribute. ### Measure what matters Traditional open source health metrics like time to first response, issue close rate, and contributor retention were designed for human participants and do not capture the full value of AI engagement. I recommend tracking: * **AI PR velocity** : PRs opened by automated agents per week * **Slop density** : ratio of AI-authored to human-authored PRs (industry benchmark: 3:1) * **Churn contribution** : lines of code added and then reverted within the same sprint, measuring the project’s capacity to absorb and process automated change * **Engagement depth** : average number of follow-up PRs spawned by a single AI contribution (the self-sustaining chain mentioned above) * **Review entertainment value** : subjective score from 1-5, assigned by the maintainer during triage Once you are tracking these metrics, you can set quarterly OKRs around AI engagement and report them in your project’s README alongside traditional badges. The Ecosyste.ms API does not yet surface AI contribution data, but I’m considering it. * * * _Following these practices, early adopters typically see:_ * _400% increase in weekly PR volume_ * _Dramatic improvements in “Contributors” count on the GitHub Insights tab_ * _A sense of belonging in the modern open source community_ * _At least three PRs correcting the spelling of “dependency” in their README_ * _One PR that converts the entire project to Rust_ * * * If none of these strategies work, you can always open an issue on your own repository with the title “Improve code quality” and no description. In my experience this is the equivalent of leaving the back door open with a plate of cookies on the counter. I’ll report back once I’ve tried these on my own projects.

What would happen if you lost your memory, even partially? With so much of our lives being digital, forgetting your passwords (or the master key to your password manager) could be disastrous. Haunted by that specter after a concussion, [eljojo] created ReMemory, a tool based on Shamir’s Secret Sharing to help your friends help you. Shamir’s Secret Sharing, for the uninitiated, is a way to split up important data between parties so that the full picture is only available when a quorum comes together. The classic example is giving everyone a couple of digits out of the combination to the bank vault, but no one the full combination. Together, they can open the vault. ReMemory works the same way. Rather than the combination to a bank vault, the locally-hosted, browser-based interface splits the encryption key to your sensitive data. If you’re old fashioned that might be a plaintext list of passwords, or for the more modern the recovery codes to your password manager. It could be literally anything, like your Aunt Edna’s famous cupcake recipe, which surely should not be lost to time. Aunt Edna could probably handle this. You can chose how many friends to split your data betwixt, and how many will be required to meet quorum– the minimum, of course, being two, but the suggested default is to split the data five ways, and allow decryption from any three parties. Each bundle includes the complete recovery tool, so anyone in your circle of trust can start the process of decrypting your data if they get the others on board. Since it’s self-hosted and browser based, those friends don’t have to be particularly tech-savvy, as long as they can be trusted to hold onto the files. Everything is explained in the readme included in each bundle. This does have the downside of requiring you to have multiple close friends, at least some of whom you trust to come through in a crunch, and all of whom you trust not to collude behind your back. Still, if you’re the social type, this seems like it might be a useful tool. The code is available under an Apache 2.0 license, so you can audit it for yourself — a must for any tool you plan on entrusting your secrets to. The best part of the sharing algorithm is that it’s not vulnerable to quantum computing. While [eljojo] was thinking of amnesia when he put the tool together, we can’t help but think this also solves the postmortem password problem.

Tips for elegant contributions in the age of confident glazzing AI tooling Coder reviewer != slop mop The first human to read your code shouldn’t be your code reviewer. AI writes, human owns If you can’t explain every line of code you’ve committed then you may have introduced Trojan code...

This is my second yearly list of AI predictions. My first AI predictions from December 2023 are available here. AI APIs for everything by 2026 APIs (Application programming interface) allow services to talk to each other. The late 2000s and early 2010s were the golden period of public APIs. Major...

We're back and we have something to say