Scarab Field Lab has dropped the velvet rope. The diagnostic suite's public evidence library is now accepting open submissions from developers, maintainers, and teams who want their messy real-world codebases reviewed—not fixed, not vibe-coded, but diagnosed. The stated goal is simple but ambitious: can Scarab surface repo truth clearly enough that a tangled codebase becomes diagnosable? Not magically repaired. Just brought into focus where the actual fault lines live.

What Scarab Actually Is

This matters because there's been confusion in the space. Scarab is not an AI coding agent. It doesn't replace maintainers or claim to auto-repair projects. Instead, it identifies evidence-backed diagnostic findings: boundary failures, repo-truth drift, verification gaps, and repair lanes. Repairs, when they happen, still fall to human developers or authorized agents working outside the public Field Lab.

The Track Record So Far

Field Lab already has real receipts. Scarab's work has been merged across three major open-source platforms: pnpm, Docker Compose, and OpenAPI Generator. Those aren't toy demos—they're patches in production codebases that passed upstream review. There's also a React stepwise quieting experiment on record. That test didn't claim 'Scarab fixed React.' Instead it validated a process methodology: identify hotspot, find boundary, apply bounded repair, rerun validation, step down complexity, repeat until quiet. The point was testing whether noisy diagnostic surfaces could be worked down through evidence, one hotspot at a time.

What Scarab Wants Next

But the maintainer behind Field Lab says that experiment, while valuable, isn't enough anymore. The next phase targets full-stack mess—real repos with enough complexity to actually stress-test the theory: unclear ownership, cross-layer drift between frontend and backend, stale docs contradicting actual behavior, weak verification surfaces, build or dependency confusion, API or schema mismatches, configuration drift across environments, security boundary confusion in auth flows, async or event queue behavior that doesn't match expectations, observability gaps in production, and yes—AI-assisted code that's drifted from the original architecture. The ideal Field Lab candidate isn't necessarily the biggest repo. It's one where failures cross a boundary, where issues are hard to reason about, where obvious patches might be too narrow, too wide, or aimed at the wrong layer entirely. Where the system is telling conflicting stories across stacks.

How to Submit

Submissions go through GitHub Discussions in the Scarab Field Lab repo. Candidates should include: public repo link, associated issue/PR/failing workflow/bug report, description of what's messy or confusing, suspected boundary surface if identifiable, and reproduction notes with logs, versions, and environment details where shareable. Public repos are easiest to evaluate. Company repos can start as conversations—just don't post secrets, credentials, customer data, proprietary source, or internal logs. Important caveat: submitting doesn't guarantee Scarab will run diagnostics, publish a report, open a PR, or attempt any repair. This is an intake path for review against the tool's current capabilities.

The Theory Underneath

The core hypothesis being tested: repositories have their own 'operating truth.' That truth might be clean and explicit in well-maintained code—or it might be buried across tests, configs, schemas, build scripts, runtime behavior, documentation history, and old conventions. Scarab's job isn't to invent repo truth or own it. The repo owns its truth. The agent codes against that surfaced truth instead.

Why This Matters for AI Coding Agents

Here's where the real stakes emerge. Current AI coding work assumes more context solves problems—more files, memory, tools, retrieval, orchestration. But related context isn't the same as authoritative context. A giant pile of repo material doesn't automatically tell an agent what owns a change, what boundary applies, what evidence matters, what validator proves safety, what shouldn't be touched, or where the actual fault line is. Scarab's question isn't whether AI can generate code—it obviously can. The question is whether it can work inside real codebases without drifting, if the repo continuously surfaces what's true, what owns what, what boundaries apply, and what proves the next step is safe.

Key Takeaways

  • Scarab Field Lab is accepting public submissions for diagnostic review via GitHub Discussions
  • Already merged patches in pnpm, Docker Compose, and OpenAPI Generator under real upstream review
  • Looking specifically for full-stack complexity: cross-boundary failures, drift surfaces, conflicting system stories
  • Not an AI coding agent—diagnostic findings only; repairs still come from maintainers or authorized agents

The Bottom Line

This is the kind of grounded, evidence-first thinking the AI coding space desperately needs right now. Too many tools promise magic fixes while ignoring that real codebases have truth surfaces that must be respected, not overridden. If Scarab can prove the diagnostic-first approach scales to genuine full-stack mess, it might just show the industry what working *with* repo reality actually looks like.