why we built schema.
for staff engineers, tech leads, and architects who review prs they can't structurally verify.
we built schema because ai tools change code you cannot see. you approve prs, mass refactors, and dependency upgrades without knowing what the architecture looks like before or after.
the model writes confident, well-tested code. the unit tests pass. but the change quietly moves a function across a boundary, introduces a cycle, or breaks an implicit contract between services. you don't catch it in review because the diff is line-level. the architecture is graph-level.
schema extracts the live architectural graph from your codebase, then shows you the structural diff before every change ships. nodes added, edges rerouted, clusters split. rules checked. contracts verified.
the engine is mit-licensed and runs locally with zero telemetry. the hosted hub adds cross-repo review, shared rules, and agents.md publishing for teams that want the same picture across many services.
if you've approved a pr in the last month that you couldn't fully verify, this is for you.
join the waitlist.
no spam. one email when your slot opens.
faq.
- who is this for, specifically?
- staff engineers, tech leads, architects, and the occasional founder doing all three. anyone who approves prs that touch multiple services or owns cross-team architectural decisions. junior devs ship code; you ship structure, and that's a different problem.
- how is this different from sourcegraph, glean, or codecov?
- sourcegraph indexes symbols; glean does code search; codecov tracks line coverage. none of them surface the architectural graph as a live, queryable object you can diff between two refs. schema does that, and only that.
- how is this different from a static analyzer like sonarqube?
- static analyzers run checks on the file. schema extracts the structural shape of your codebase (services, contracts, data flow, runtime topology) and lets you write rules against the shape itself. it's a different layer of abstraction.
- does it support my language?
- day one: typescript, python, go, java/kotlin, ruby, rust, and generic config (yaml/json/toml/hcl). cross language bridges: rest routes to handlers, grpc proto to implementations, sql ddl to orm models. more on pricing.
- does it work on monorepos?
- yes. that's the primary case. polyglot monorepos with crossed services are exactly where line-level review fails the hardest.
- will it slow down my agent?
- no. the engine extracts the graph at ide latency using tree sitter. mcp calls answer in milliseconds. the agent gets the architectural context before it writes a single line.
- how does it integrate with my coding agent?
- schema ships an mcp server. cursor, claude code, cline, windsurf, zed, and any mcp client can talk to it. one config block, 47 actions exposed.
- what do you collect about my code?
- the oss core sends zero telemetry. the hub layer processes pr metadata and the source files needed to extract the architectural graph for the changed scope. source code is deleted after extraction and never used to train a model. see privacy.
- who built this?
- a small team in helsinki who previously shipped infrastructure at scale and watched ai-generated prs turn solid codebases into archaeology in 18 months. we built the tool we wished existed during code review.
- is it open source?
- yes. the engine, cli, studio app, and vs code extension are mit licensed and live at github.com/schema-ai/mcp. only the cross-repo hub layer is closed-source and paid.