Scaling trust when 80,000 commits flood in
OpenClaw began as a weekend experiment by Peter Steinberger in November 2025. Less than a year later, the personal AI assistant project had amassed roughly 388,000 GitHub stars, 81,000 forks, and more than 80,000 commits. That velocity forced the project’s maintainers to rethink how they evaluate contributions, secure dependencies, and define what “trust” even means when much of the incoming code is generated by AI agents.
In a video interview recorded six months into the project’s life, Steinberger and a group of OpenClaw maintainers discussed how they adapted their workflows to survive the surge. Their lessons span contribution review, supply chain security, and the human toll of maintaining a project that grew faster than any in GitHub history.
Contributions look different when agents write the code
The first challenge was triage. OpenClaw’s maintainers were drowning in pull requests and issues, with some contributors opening hundreds at once via automated pipelines. Steinberger stopped calling them pull requests altogether.
I don’t even call them pull requests. I call them prompt requests.
Josh Lehman described contributors running “automated software factories” that mined the repository for anything that looked like a problem. The bottleneck shifted from attracting participation to finding genuinely valuable work amid the noise.
Yet the maintainers refused to close the door on newcomers. Some of the project’s best first-time contributions came from people with no development background who used agents to create a pull request and then collaborated with maintainers to finish it. Vincent Koc noted that a good portion of those merged first-time pull requests came from non-developers — people with a specific problem and a need, rather than a résumé.
The same tools that lowered the barrier for newcomers also complicated the maintainers’ own relationship with work. Val Alexander observed that some contributors became so enamored with what agents could do that they stopped sleeping, trying to compress a week of work into a single night. Others used the technology to reclaim time — Lehman, a parent of small children, said OpenClaw lets him delegate to agents so he can step away. Sally O’Malley noted that maintainers sometimes announce on the project channel that they are “going to touch grass” for a few hours.
Agents amplify both the opportunity to do more and the importance of knowing when to step away.
Proving you understand the work
There was no single path to becoming an OpenClaw maintainer. Koc got Steinberger’s attention through security work after being ignored; Brad Groux built a Microsoft Teams plugin; Alexander started answering questions in voice chat. The common thread was finding a gap and filling it.
As raw contribution counts became a less reliable signal, the team developed new criteria for what made a pull request stand out. Agent transcripts, screenshots of testing, and a clear explanation of the contributor’s reasoning all carried weight. Steinberger was explicit about what mattered most.
Nobody cares if you wrote the code or not, but we care if you actually thought about this feature.
If you provide transcripts of your session with an agent, maintainers can see how you arrived at the pull request and understand your discussion with the tool. Screenshots prove you ran the code. The key question was never whether a human or an agent wrote something — it was whether the contributor comprehended the feature and its interactions with the rest of the project.
Maintainers themselves also leaned on AI to review AI-generated code. Alexander described using GitHub Copilot to review incoming pull requests automatically, generating clarity on what files changed and why. Lehman observed that OpenClaw was the first project where it became normalized for maintainers to simply edit a submitted pull request and “make it right” rather than send it back for revision.
When reputation becomes a liability
The flood of AI-generated contributions created new attack surfaces. Koc described contributors duplicating existing pull requests to farm merge badges — visible markers that acted as trust signals to maintainers. The more merges you had, the more credible you looked. The team had to identify duplicates and determine which submission was the original.
Steinberger described a company using an automated pull request to promote its product. In each case, the code was only part of what needed evaluation. The maintainers also had to scrutinize the social signals they had been using to decide whom to trust in the first place.
Balancing safety with convenience
Security defaults were a constant tension. Tighter workspace restrictions generated complaints from users who found the agent too limited; looser restrictions opened the door to incidents. Steinberger called it a hard game — finding the balance between convenience and safe-by-default behavior.
The equation depends on the agent’s capabilities, the user’s level of understanding, and what the surrounding environment will tolerate. There is no universal answer.
Supply chain attacks pushed the project to scrutinize its own dependencies. The team went through its dependency tree with “a fine-tooth comb,” reducing core dependencies and — just as importantly — building relationships with the maintainers of the packages they kept. Steinberger noted that it is not the norm for companies to contribute back to upstream projects instead of maintaining a private fork and moving on.
Learning security from a community of maintainers
The GitHub Secure Open Source Fund offered both practical security training and something less tangible: a connection to other maintainers dealing with the same strains. Josh Avant recalled a presenter’s first piece of advice: get a cup of coffee, take a breath. The human element of maintaining was part of the curriculum.
For Lehman, the program sharpened his ability to direct agents effectively. Agents can do nearly anything you ask, but you have to know what to ask for — and the security training gave him that vocabulary. Koc emphasized the value of a community where maintainers could compare notes on securing open source projects as those challenges kept evolving.
