Finding problems is the easy part
Every security scanner is good at one thing: making a list. Run one on any real codebase and you'll get hundreds of findings — most of them legitimate, almost none of them actually fixed. The list gets exported to a spreadsheet, someone glances at it in a meeting, and it quietly rots. The hard part was never finding the problem. It's that fixing even one finding properly takes an engineer's afternoon, and there are four hundred of them.
Patchward is my attempt at the actual hard part: it scans, decides what's worth fixing, writes the fix, checks its own work, and opens a pull request you can review — running on your own machine, not uploaded to someone's cloud.
(A naming note: this shipped first as RepoMend, until I found out repomend.com belongs to an unrelated company in the exact same space. Renamed in July 2026. Same tool, same results below, just not sharing a name with a stranger's product anymore.)
The pipeline
Five scanners run at once — Semgrep, Bandit, pip-audit, Trivy, and ESLint — and their output gets combined and handed to a model that sorts findings by how bad and how exploitable they actually are. Then comes the part I care most about: the fix generator has a deliberately narrow job. One finding, one small fix, nothing else touched. It doesn't refactor the surrounding code. It doesn't "improve" anything nearby just because it's already in there. It changes exactly the lines the finding is about.
Before a fix goes anywhere, it has to survive three checks, in order:
- —Does the original problem actually go away? Re-run the scanner. If the same rule still fires, the fix didn't work.
- —Did it stay in its lane? The edit has to sit entirely within the lines it was authorized to touch — a "fix" that wanders outside that boundary gets thrown out even if the change itself looks fine.
- —Do your tests still pass? Run against your own test suite, on your own machine. If there's no test runner to check against, Patchward says so directly in the pull request instead of quietly skipping the step and pretending everything's fine.
Fail any of those three and the fix is gone. Not queued for a second attempt with a more convincing prompt. Not flagged for someone to look at later. Gone. That's the guarantee I actually want to make: if you see a Patchward pull request, the problem is gone, the edit stayed where it was supposed to, and the tests still pass.
Runs on your machine, not somewhere else
Security tooling that quietly uploads your source code to someone else's servers is asking for a level of trust it hasn't earned yet. Patchward runs inside your own environment, in a sandboxed container. The scanner results never leave your machine. I'll say plainly what does leave it, rather than let it stay implied: the triage and fix-writing steps send file contents to Anthropic's API to do their work — that's stated directly on the product's own limits page, not buried in a terms document nobody reads.
It installs as a normal command-line tool (uv tool install patchward, then patchward fix --repo .) and currently passes 565 automated tests at 91.20% coverage — a number I check by hand right now, since the automated version of that check isn't built yet.
The checkdmarc story
This is the proof I like telling, mostly because the honest version is more interesting than the tidy one would have been.
Patchward scanned checkdmarc, a DNS-security library used in mail infrastructure, and flagged a real problem: a bare except: pass block quietly swallowing every error, including the ones someone actually needed to see. I opened a pull request with a fix.
The maintainer didn't merge it. He closed it, in favor of his own version — narrower, backed by an actual analysis of what that code path can raise, with a test proving it. His exact words closing mine: "Closing as superseded by #262 — much appreciated for flagging it." His fix is what shipped, in version 5.17.3.
So here's the honest accounting: the problem was real, and it got fixed. The fix that shipped wasn't mine. I'd rather report that straight than dress it up, because it's actually the point — the tool found something real and got a domain expert to engage with it seriously, and the expert wrote something better than the first draft. That's the system working as intended, not a near-miss.
Want to try it
Pilots are by request right now: point Patchward at a repository and see real, verified pull requests before committing to anything. Ask for one →