Dev.to has been one of the places where I have had the most honest and useful conversations about AI-assisted software development, repository truth, verification, and what actually makes a change trustworthy.
So I wanted to share this here directly:
Scarab Systems is now accepting requests for diagnostic and repair work.
Scarab helps teams establish what should change before implementation begins: where a failure belongs, what evidence supports that diagnosis, which boundaries and ownership obligations matter, and what the repository itself requires to prove the repair.
Current services include:
- diagnostic boundary reviews;
- bounded repair and patch work;
- independent review of AI-assisted changes;
- broader support for complex, drifted, or multi-repository systems.
But I also want to make something else very clear.
Community projects may receive volunteer Scarab support
Not every important software project has enterprise funding.
Grassroots organizations, nonprofits, mutual-aid groups, community technology projects, and teams led by or serving marginalized communities often operate with limited engineering capacity and extremely limited budgets.
Their software still matters.
In many cases, those systems support people who cannot afford for them to fail.
So where capacity allows, Scarab Systems may volunteer diagnostic and repair work for community-serving projects.
This is not about asking grassroots teams to adopt Scarab as a tool.
It is about helping them get real software problems repaired.
That might mean diagnosing a bug nobody can place, reviewing an AI-assisted patch before it ships, identifying a broken boundary in a drifting codebase, or preparing a narrow fix for a workflow people depend on.
This is not a lesser version of the work.
The same diagnostic standards apply. The same attention to repository evidence, change boundaries, ownership, and validation applies.
The difference is that some useful software serves people and communities who should not be priced out of a serious technical second opinion.
Confidential by default
All engagements are confidential.
Private repositories, internal documents, project details, technical findings, and conversations remain private unless the organization explicitly chooses to make something public.
No project will be turned into a case study, promotional post, Field Lab record, or public proof point without clear permission.
Teams may begin with a high-level description before sharing any private technical details.
What to send
A request can begin with:
- a repository or issue link;
- a failure that nobody has been able to place correctly;
- an AI-assisted patch that needs independent review;
- a maintenance problem in a complex or undocumented system;
- a community-serving software project that needs help with a bounded bug, repair, or patch review.
We will first determine whether the problem fits a diagnostic review, a bounded repair, broader engagement, or volunteer community support where capacity allows.
The goal is not to sell the largest possible project.
The goal is to establish the real problem, define the smallest responsible change, and let the system prove the result.
Commercial work supports the continued development of Scarab.
Public open-source work proves the system.
Community work keeps the system honest.
The repository owns the truth.
The agent writes the code.
The repository validates the result.
The developer develops.
Requests can now be submitted through the Scarab Systems website:
or email directly:
Top comments (0)