DEAD REPO RESURRECTOR

Inspiration

Open source is built on an amazing idea: anyone can build something useful, and anyone can help improve it. But there is a problem hiding in that model. A repository can be valuable, actively used, and full of unresolved issues while its maintainer simply no longer has enough time to keep up. A bug might be small. An issue might be clearly defined. The fix might only require a few files. Yet it can remain open for months because nobody has the time to investigate it properly. That made us ask: When a repository needs help, who steps up? We were inspired by the idea of a good neighbour. A good neighbour notices when something needs attention, helps where they can, respects the homeowner's boundaries, and doesn't take over. We wanted to bring that idea to open-source software. That became Dead Repo Resurrector — an autonomous maintenance system designed to find neglected repositories, identify small and tractable issues, investigate them, engineer real fixes, and submit those fixes as real GitHub pull requests. Our goal was never to build an AI that blindly changes code. It was to build an AI that knows when it can help, how it can help, and when it should leave the problem alone.

What it does

Dead Repo Resurrector is an autonomous, multi-agent maintenance loop. The system continuously scans GitHub for repositories showing reduced maintenance activity. When it finds a promising candidate, it investigates open issues and determines whether an issue is sufficiently bounded and understandable to handle autonomously. The workflow is: Discover → Identify → Analyze → Decide → Engineer → Contribute → Follow Up Different agents have different responsibilities: Analyst — investigates the repository and issue, evaluates complexity and confidence, and determines whether the task is suitable. Engineer — develops the solution on an isolated branch and commits the changes. Communicator — creates the pull request and communicates the contribution to the maintainer. Orchestrator — coordinates the workflow and manages system state. The most important part is the decision gate. If an issue is too complex, ambiguous, or low-confidence, the system does not attempt to fix it. If it is tractable and confidence is high, the system proceeds. And the output isn't a simulated response or a generated patch sitting inside a dashboard. It produces a real branch, real commits, and a real pull request on GitHub.

How we built it

We built Dead Repo Resurrector around the AWS Strands Agents SDK and a serverless AWS architecture. The system uses: AWS Strands Agents for multi-agent orchestration Amazon Bedrock / Gemini for model flexibility AWS Lambda for serverless processing Amazon SQS FIFO for reliable task processing DynamoDB for state SNS and CloudWatch for event-driven operation and scheduling API Gateway for the live system interface AWS Secrets Manager for credentials GitHub APIs and webhooks for repository interaction React, Vite, Tailwind and TanStack Query for the dashboard S3 + CloudFront for deployment The architecture is event-driven rather than dependent on a single long-running process. A scheduled scanner discovers candidates, queues them, and workers process them through the agent pipeline. Once a contribution is made, the system can follow up with the maintainer after defined intervals. We also built a deterministic, model-free seam alongside the agents so that the core pipeline can be tested offline without depending on live model calls. Most importantly, we made permissions part of the architecture. The Analyst can investigate but cannot modify code. The Engineer can create branches and commits but cannot open PRs or communicate with maintainers. The Communicator can create PRs and comments but cannot modify the code. The orchestrator controls state. This means the agents don't simply promise to behave responsibly — their capabilities are constrained by the infrastructure around them.

Challenges we ran into

Building an autonomous system that interacts with real repositories introduced several challenges.

Giving AI enough power without giving it too much The system needs access to repositories, branches, commits, issues, and pull requests. But unrestricted access would make an autonomous failure potentially destructive. We addressed this through strict agent boundaries and least-privilege infrastructure. Each agent receives only the tools required for its role.
Determining which issues are actually safe to automate An AI agent can generate a plausible solution for almost anything. That doesn't mean it should. We therefore built an Analyst stage and decision gate before engineering begins. The system evaluates the issue's complexity and confidence and only proceeds when the task falls within a tractable scope.
Testing against arbitrary third-party code Running tests from an unknown public repository introduces an obvious security problem: arbitrary code execution. For that reason, third-party test execution is disabled by default in the current system. Our next step is to introduce sandboxed execution environments so generated fixes can be validated safely.
Making the system genuinely autonomous It was easy to build individual AI functions. The harder problem was connecting them into a reliable loop that could operate without someone manually moving information from one stage to another. We had to design state management, event processing, retries, queues, permissions, follow-up mechanisms, and failure boundaries around the agents.
Building something that is useful rather than impressive One of our biggest design decisions was to avoid building a system that merely looks autonomous. We wanted every stage to produce something verifiable. Repository discovered. Issue investigated. Decision made. Code committed. Pull request opened. Maintainer notified. That kept the project grounded in real-world contribution rather than an AI demonstration.

Accomplishments that we're proud of

We built a genuinely autonomous maintenance loop. Instead of stopping at an AI-generated suggestion, our system can discover a repository, investigate an issue, engineer a fix, and produce a real GitHub pull request. We deployed the system to AWS. The entire pipeline runs through a serverless, event-driven architecture using Strands Agents, Lambda, SQS, DynamoDB, API Gateway, and other AWS services. We made autonomy enforceable. Each agent has deliberately restricted permissions. The Analyst cannot modify code, the Engineer cannot communicate with maintainers, and the Communicator cannot change the implementation. We proved the system with real output. Our live dashboard displays real repository, issue, and agent state rather than mocked demonstration data, and the system has successfully opened a real PR. We built for failure and uncertainty. The system can deliberately decline issues that are too complex or ambiguous instead of forcing an AI-generated solution. We created a testable architecture. Alongside the live AI agents, we built a deterministic seam that allows the core pipeline to run and be tested offline without requiring live model calls. The accomplishment we're most proud of We didn't just build an AI that talks about contributing to open source — we built one that actually contributes.

What we learned

The biggest thing we learned was that autonomous AI is less about giving an agent more power and more about giving it the right boundaries. At first, it is tempting to think that the most capable agent should be able to read the repository, modify code, run tests, create a PR, and communicate with the maintainer. But that creates a huge blast radius. Instead, we found that specialized agents with narrow responsibilities create a much safer and more understandable system. We also learned that: Bounded work is a powerful target for autonomy Not every software engineering task needs a human expert from beginning to end. Issue investigation, identifying affected files, implementing small changes, preparing PR context, and following up are often structured enough to be partially automated. Saying "no" is part of being autonomous A system that attempts every issue isn't necessarily more intelligent. A system that can recognize uncertainty and decline an unsafe task can be much more useful. Real-world output matters We deliberately followed a principle throughout the project: Real output or nothing. Never a simulation. A dashboard saying that an AI "would create a PR" isn't enough. Our system actually interacts with GitHub and has opened real pull requests. That distinction changed how we designed and tested the entire project.

What's next for DEAD REPO RESURRECTOR

Dead Repo Resurrector is intentionally not presented as a finished solution to open-source maintenance. There is much more to build. Our roadmap includes: Sandboxed Testing — safely execute third-party tests to validate generated fixes. Smarter Language Support — expand engineering strategies across more languages and repository patterns. Deeper Maintainer Feedback — learn from merged, rejected, and requested-change pull requests. Authenticated Operations — add secure controls for monitoring and managing autonomous contributions. Richer Live Monitoring — provide deeper visibility into system health and contribution outcomes. Scale the Neighbourhood — expand from individual interventions toward continuous maintenance across a much larger open-source ecosystem.