PatchGarden：我打造了一名不信任自身修補方案的 AI 維護工程師

This is my submission for the Hacktoberfest Open-Source AI Challenge: Week 3 — Slow and Steady.

PatchGarden 🌱: I Built an AI Maintenance Engineer That Doesn't Trust Its Own Patches

AI can write code in seconds. But when it breaks your repository, who makes sure the fix actually works?

We've reached a point where generating code is becoming easier than ever. AI coding tools can suggest implementations, explain errors, and produce patches almost instantly.

But there's a problem I kept coming back to:

Generating a fix is easy. Knowing whether it's safe to trust that fix is a different problem.

A patch can look convincing, modify the right-looking file, and still introduce a regression. A green-looking AI response doesn't mean the bug is gone.

Meanwhile, open-source maintainers are left dealing with failing tests, neglected issues, dependency problems, and maintenance work that never seems to end.

For Hacktoberfest's Slow and Steady challenge, I wanted to explore a different approach.

Instead of building another AI tool that generates more code, I wanted to build something that helps developers spend less time babysitting maintenance work.

Meet PatchGarden — an AI-powered repository maintenance project built around one principle:

Don't trust a patch because AI generated it. Collect evidence, verify the result, and let the developer decide.

🌿 What is PatchGarden?

PatchGarden is designed to help developers investigate repository failures, generate minimal repair proposals, verify changes, and preserve an auditable history of the process.

Think of a developer who returns to a project after months away. There are failing tests, an issue backlog, and a bug report that nobody has had time to investigate.

Instead of manually navigating every step, the developer can delegate a focused maintenance task to PatchGarden.

The intended workflow is:

Investigate → Plan → Patch → Verify → Review

Here's what each stage means:

Investigate: Inspect relevant code and diagnostic evidence to understand the reported failure.
Plan: Produce a structured repair plan with a clear hypothesis and defined verification criteria.
Patch: Generate a minimal, reviewable candidate change in an isolated workspace.
Verify: Run the relevant tests and compare the results against the baseline.
Review: Present the diff and evidence so a human can approve or reject the proposed repair.

If the evidence is insufficient or the tests fail, the system should report that honestly instead of pretending the task succeeded.

The goal isn't autonomous code modification at any cost. It's making repository maintenance less tedious without sacrificing developer control.

🦥 Why does this fit Slow and Steady?

Software maintenance is rarely one dramatic task. It's hundreds of small jobs that developers keep postponing.

Investigate that failing test. Reproduce that bug. Check that dependency. Review that patch. Rerun the suite. Figure out what happened when the process failed halfway through.

Individually, these tasks seem manageable. Collectively, they become maintenance debt.

PatchGarden explores how open-source AI can help with that repetitive work while keeping the developer responsible for the final decision.

The Lazy Payoff

Delegate the investigation. Review the evidence. Spend your attention where it actually matters.

Rather than trying to replace the developer, PatchGarden aims to remove the repetitive work surrounding a repair.

🧠 The important engineering decision: AI proposes, tools verify

I didn't want the entire application to depend on a model saying, "I've fixed it."

An AI model can produce malformed output, misunderstand a code path, or confidently suggest an incorrect repair. That means the model cannot be the authority on whether a patch is correct.

The architecture separates reasoning from execution:

1. Open-weight AI for investigation

The project is designed around Google's open-weight Gemma 3 (4B) running locally on Ollama. A smaller local model creates a healthy engineering constraint: instead of assuming a massive cloud model can magically fix everything, the system limits the context, validates structured JSON outputs, and relies on deterministic tooling for execution. Local inference keeps repository code private and eliminates external API token fees.

2. A controlled execution layer

Repository inspection, Git operations, test execution, and workflow state are handled by explicit application logic rather than arbitrary model-generated shell commands. Model output is treated as untrusted input. Paths are validated, operations are restricted to isolated Git worktrees, and candidate changes are kept strictly quarantined from the main branch.

3. Independent verification

The system distinguishes between generating a patch and demonstrating that the patch passes configured checks. A complete repair record contains:

The original failure and diagnostic evidence.
The proposed change and Git diff.
The verification commands and their exit codes.
Any errors or regressions encountered.
The final maintainer review decision.

Passing tests don't prove that every bug is fixed. They provide evidence that the candidate passes the checks we actually ran. That distinction matters.

♻️ What happens when the process stops halfway through?

A maintenance workflow can take multiple steps. A process can crash, a model can time out, or a machine can restart before the job finishes. Simply storing the active task in application memory is not enough.

PatchGarden relies on Temporal durable workflow orchestration paired with persistent SQLite domain state (patchgarden.db) and immutable JSONL audit logs. Workflow state transitions are recorded before and after each phase. If the worker process restarts mid-repair, Temporal rehydrates the execution history, validates saved checkpoints, and resumes execution without re-running completed work or dirtying the repository.

🔓 Why open innovation matters

Open-source AI is not just a label in PatchGarden's technology stack. It creates an opportunity to design the system around model choice, inspectable behavior, and developer-controlled infrastructure:

Model flexibility: Maintainers can swap models or run different quantization levels locally.
Local inference & privacy: Source code, proprietary internal libraries, and sensitive test logs never leave the developer's workstation.
Cost control: Local open-weight models have zero token fees, allowing extensive multi-stage investigation and repair loops.
Transparency: The entire toolchain—from prompt schemas to worktree managers—is open-source and inspectable.

🛠️ How I built it

PatchGarden brings together a broadsheet-inspired web interface, a typed backend API, a durable worker engine, and local open-weight AI:

Project repository: GitHub — Neet2516/PatchGarden
Live application: https://patchgarden-web.onrender.com
Technologies:
- Frontend: Next.js 14 (App Router, React, CSS)
- API: Fastify (Node.js & TypeScript)
- Durable Orchestration: Temporal Cloud / Temporal local server
- Persistence: SQLite (better-sqlite3) & structured JSONL audit logs
- Inference Runtime: Gemma 3 (4B) via local Ollama
- Isolation: Git worktrees for clean verification environments
- Deployment: Render (Hosting the web dashboard and API)

📸 Application Interface & Candidate Patch Review

Here is the live interface running in production on Render:

🎥 See PatchGarden in action

Watch the demo: PatchGarden — YouTube
Try the application: https://patchgarden-web.onrender.com
Explore the source code: https://github.com/Neet2516/PatchGarden

The most important part of a demonstration is not how confidently the AI explains its answer. It's whether the workflow produces inspectable evidence of what happened.

🧪 What I would measure next

A trustworthy maintenance tool needs more than a polished interface. I would evaluate PatchGarden against a reproducible benchmark of deliberately seeded bugs and measure:

Root-cause identification accuracy.
Clean patch application rates across diverse codebases.
Test suite pass rates and regression detection sensitivity.
Workflow recovery fidelity across simulated power and worker outages.
In-flight token latency and memory footprint of local 4B models.
The accuracy of the system's "refusal to patch" when diagnostic evidence is ambiguous.

🌱 What comes next?

The long-term direction is a maintenance assistant that developers can trust with repetitive investigations without surrendering control of their repositories. That means deeper AST-aware repair suggestions, tighter containerized sandboxing, reproducible evaluations, and clearer explanations of uncertainty.

The goal isn't to build an AI that never makes mistakes. It's to build a system that makes mistakes visible, limits their impact, and refuses to confuse a plausible answer with a verified result.

🏆 Prize Categories

Best Use of Render:

PatchGarden's production web dashboard and API service are deployed on Render at https://patchgarden-web.onrender.com using a multi-service render.yaml blueprint with monorepo build orchestration.

Best Use of Temporal:

PatchGarden uses Temporal for durable workflow orchestration, enabling maintenance jobs to progress through defined stages with workflow state, retries, and recovery. This integration supports the project's central goal: making repository maintenance reliable even when individual steps fail.

Local AI with Ollama :

PatchGarden uses Ollama as its local model inference runtime, allowing the application to run a supported model locally for repository analysis and repair proposals. This supports experimentation with open-weight AI while keeping model execution separate from deterministic patch verification.

🤖 My Agent Session

Here is the genuine DevRelay agent session documenting the end-to-end development, debugging, and deployment of PatchGarden:

Direct Session Link: https://dev.to/agent_sessions/patchgarden-building-an-ai-maintenance-engineer-lszqv4

💬 I'd love your feedback

If you maintain open-source projects, what's the maintenance task you keep putting off? Is it reproducing bugs, triaging issues, fixing flaky tests, or reviewing changes generated by AI?

I'd love to learn which part of this workflow would save maintainers the most time—and what evidence you'd need before trusting an AI-proposed patch.

Slow and steady. Evidence before assumptions. Verification before approval.