EvoGuard: Building the Trust Layer for AI-Generated Software

EvoGuard, an open-source platform by developer Modarresi, aims to add a trust layer for AI-generated code by evaluating pull requests against repository history, contracts, dependencies, and architectural conventions. The tool, available on GitHub, seeks to make AI-assisted changes more explainable and evidence-backed, addressing the gap where AI-generated code may pass tests but violate undocumented system rules.

AI has made writing software dramatically cheaper. But it has not made changing software safely cheap. That distinction is becoming increasingly important. Tools such as Copilot, Cursor, Codeium, and autonomous coding agents can generate code, implement features, refactor modules, write tests, and open Pull Requests at a speed that traditional engineering workflows were never designed for. The bottleneck is moving. It is no longer: "Can we write the code?" The harder question is becoming: "Should this change be allowed into this particular software system?" That is the problem behind EvoGuard . GitHub: https://github.com/modarresi1913/Evoguard https://github.com/modarresi1913/Evoguard EvoGuard is an evolving context-aware AI code integration and provenance platform designed to sit between AI-assisted development and the production branch. Its thesis is simple: Context before merge. A Pull Request should not be evaluated only against the code inside its diff. It should be evaluated against the living ecosystem around that code: AI Coding Agent │ ▼ Pull Request │ ▼ ┌──────────────────┐ │ EvoGuard │ │ │ │ Repository │ │ History │ │ Contracts │ │ Dependencies │ │ Tests │ │ Security │ │ Architecture │ │ Provenance │ └────────┬─────────┘ │ ▼ Evidence + Risk │ ┌───────┴───────┐ ▼ ▼ TRUST BLOCK │ │ ▼ ▼ Merge Rework The goal isn't to replace developers. The goal is to make AI-generated changes more explainable, evidence-backed, and compatible with the system they are entering . Consider an AI-generated change that: It can still break production. Why? Because the most important information about a mature codebase is often not contained in the diff . It may exist in: For example, imagine a repository has an undocumented rule: Never call fetch directly. Use the internal httpClient abstraction. An AI coding agent may not know this. The code may be perfectly valid JavaScript. The tests may pass. But the change violates a critical architectural convention. The problem isn't that the AI cannot write code. The problem is that it doesn't know what this codebase has learned . EvoGuard is designed around that gap. A mature software repository is not merely a collection of source files. It is a history of decisions and consequences. Imagine: Code Change │ ▼ Deployment │ ▼ Failure │ ▼ Rollback │ ▼ Hotfix │ ▼ Lesson Today, much of that knowledge remains fragmented across Git history, GitHub issues, CI systems, incident reports, documentation, and human memory. EvoGuard's long-term objective is to turn these outcomes into repository memory . For example: Historical Pattern Change: Authentication middleware modified Outcome: Production rollback Evidence: PR 1842 Commit abc123 CI run 921 Incident INC-47 Learned constraint: Authentication middleware changes require security regression testing. Now consider a future Pull Request that makes a structurally similar change. Instead of asking only: "Does this code look correct?" EvoGuard can ask: "Has this repository seen a similar change before, and what happened?" That is a fundamentally different type of code intelligence. It is important to distinguish the current implementation from the larger production vision. Today, the public repository is primarily a working interactive demo and product/architecture foundation , rather than a claim that the complete production engine is already implemented. The current project is built with Next.js, TypeScript, Tailwind, and related frontend tooling, and includes an interactive EvoGuard dashboard. The repository itself explicitly identifies the current codebase as a demo + marketing site. The current dashboard demonstrates concepts including: A nine-dimensional Ecosystem Compatibility Score ECS with confidence information and evidence. A structured view of evidence associated with a change. A representation of repository memory and the separation between observation, inference, and policy. Declared, inferred, and unknown provenance states with confidence. Evidence-linked review findings with source locations and suggested actions. The conceptual merge-policy layer that translates risk into repository-specific decisions. The demo can currently be run locally with: git clone https://github.com/modarresi1913/Evoguard.git cd Evoguard bun install bun run dev The current demo uses bundled mock data, so this should not be confused with the future production backend. The next stage is much more ambitious. The intended architecture is a five-layer pipeline: 01. INGEST │ ▼ 02. ANALYZE │ ▼ 03. CONTEXT │ ▼ 04. DECISION │ ▼ 05. DELIVERY The production design includes components for: The key architectural principle is extremely important: The LLM explains evidence. It does not become the source of truth. Tests, dependency versions, policy violations, security findings, ownership information, and other deterministic signals should come from verifiable sources. One of the central concepts is the Ecosystem Compatibility Score . Instead of producing a generic: AI confidence: 87% EvoGuard explores a multi-dimensional compatibility model: Contract Historical Dependency Test Convention Architecture Security Ownership Runtime These dimensions are intended to be calibrated against the specific repository rather than treated as universal constants. Conceptually: ECS = Contract Compatibility + Historical Compatibility + Dependency Compatibility + Test Compatibility + Convention Compatibility + Architecture Compatibility + Security Risk + Ownership Risk + Runtime Risk The interesting part isn't the formula itself. The interesting part is the feedback loop. A repository should gradually teach the system which signals actually matter. This is where EvoGuard becomes more interesting. Suppose: PR 100 ↓ Merged ↓ No incident That is useful information. Now: PR 101 ↓ Merged ↓ Production regression ↓ Rollback That is even more valuable. The system should eventually be able to learn: Change Pattern ↓ Observed Outcome ↓ Historical Evidence ↓ Future Risk The current roadmap explicitly targets revert detection, rollback detection, historical pattern mining, dependency compatibility, evidence-linked review comments, convention extraction, feedback capture, and initial score calibration. This is the foundation of an important idea: The question is no longer only: "What does the code look like?" It becomes: "What happened the last time this kind of change entered this system?" The development roadmap is intentionally divided into three phases. The immediate objective is to move from the interactive concept toward a real evidence pipeline. Planned components include: These components are currently documented as designed rather than all being production-complete. The second stage is where EvoGuard begins developing its real differentiation. The focus is: Git History + Rollback History + Revert History + Hotfixes + Dependencies + Conventions │ ▼ Historical Compatibility Engine The roadmap includes: This is arguably the most important technical phase. Because this is where the repository starts becoming a source of intelligence rather than merely a source of code. The next step is not another UI feature. It is validation. The goal is to run EvoGuard against real repositories and answer measurable questions: The roadmap includes a policy engine, outcome tracking, real repository pilots, usability testing, reliability improvements, cost optimization, security hardening, and an initial case study. This phase is critical. A beautiful architecture is not enough. The system has to earn trust on real code. There is a difficult research problem hiding inside EvoGuard. Suppose: Commit A Commit B Infrastructure change Traffic spike Database failure Rollback Which change actually caused the incident? It is dangerous to simply say: Rollback → Commit A was bad Real software systems are not that simple. Therefore, future versions of EvoGuard need a stronger outcome attribution engine . The system should distinguish between: Observation Inference Policy and never silently turn an inference into a fact. This separation is already part of the project's core design principles. One of the most exciting directions is to move beyond retrospective analysis. Imagine EvoGuard eventually saying: This Pull Request resembles three historical changes. Two resulted in rollbacks. The highest-risk modification is the authentication middleware. Adding the missing integration test reduces the estimated risk. Now the system is no longer just reviewing the past. It is reasoning about possible futures. Conceptually: Current PR │ ├── Historical similarity │ ├── Dependency impact │ ├── Architecture impact │ ├── Runtime impact │ └── Security impact │ ▼ Counterfactual Analysis │ ▼ "What could happen?" This could eventually become a new category of developer tooling: Predictive Software Change Intelligence. AI coding agents are moving toward increasingly autonomous workflows: Issue ↓ Plan ↓ Code ↓ Test ↓ Pull Request ↓ Review ↓ Merge ↓ Deploy As autonomy increases, human reviewers become a bottleneck. But removing humans entirely is not the answer. We need a trustworthy verification layer. That layer should provide: Evidence + Context + History + Policy + Human Oversight This is where EvoGuard could eventually become more than an AI code reviewer. It could become infrastructure for governing autonomous software development . The long-term architecture looks something like this: Autonomous Coding Agents │ ▼ Pull Requests │ ▼ ┌──────────────────────┐ │ EvoGuard │ │ │ │ Repository Memory │ │ Evidence Graph │ │ Risk Intelligence │ │ Provenance │ │ Policy │ │ Runtime Feedback │ └───────────┬──────────┘ │ ▼ Trusted Change │ ▼ Production │ ▼ Outcomes │ └──────────────┐ │ ▼ Repository Memory That creates a continuous learning loop: More changes ↓ More outcomes ↓ More evidence ↓ Better repository memory ↓ Better risk prediction ↓ Safer autonomous development The system gets better because the software system itself generates more evidence. The current focus is GitHub, but the architecture is not fundamentally tied to one platform. The longer-term roadmap includes: This opens another possibility: Imagine representing a company’s software as a continuously evolving graph: Code │ ├── Dependencies │ ├── Developers │ ├── PRs │ ├── Architecture │ ├── Deployments │ ├── Incidents │ ├── Rollbacks │ └── Runtime behavior Every change becomes an event. Every outcome becomes feedback. Every lesson becomes reusable context. At that point, the system isn't merely reviewing code. It is modeling software evolution itself . It is important to be precise. EvoGuard today is not claiming to be a finished production-grade autonomous gatekeeper. The public repository is currently an evolving product prototype, interactive demo, and architecture foundation. The production architecture — including PostgreSQL, vector storage, Redis/BullMQ, GitHub App integration, Tree-sitter/Semgrep analysis, secret scanning, pluggable LLM providers, and enterprise deployment options — is documented as the target architecture rather than implying every component is already implemented in the public repository. That is intentional. The project is being built around a difficult question: Can we create a trustworthy intelligence layer that learns from the actual evolution of a software system? The answer has to be demonstrated empirically. The software industry is entering a new phase. We are moving from: Human writes code to: Human + AI writes code and increasingly toward: AI agents write and modify code The more code generation becomes autonomous, the more valuable verification, provenance, context, and outcome intelligence become. The future bottleneck may not be code generation. It may be trustworthy integration . The entire project can be reduced to one idea: AI can generate software faster than humans can understand its consequences. Therefore, we need systems that understand the software's history. Not just: What changed? But: Why does this change matter? Has this happened before? What happened then? What contracts could it violate? What dependencies are affected? What security constraints apply? Who needs to review it? What evidence supports the conclusion? And, ultimately: What happened after similar changes reached production? That is the direction EvoGuard is exploring. The first generation of AI developer tools made code generation dramatically faster. The next generation will make software engineering increasingly autonomous. The missing layer is trust . EvoGuard is an attempt to build that layer. Not another generic AI reviewer. Not another static analyzer. Not another code generator. But a system that connects: AI-generated change ↓ Repository context ↓ Evidence ↓ Historical outcomes ↓ Risk ↓ Policy ↓ Human decision ↓ Production outcome ↓ Learning The ultimate goal is simple: Make autonomous software development safer without making it slower. And perhaps the most important shift is this: The future of code review may not be about reviewing code. It may be about understanding how software evolves. The project is open source and evolving: GitHub: https://github.com/modarresi1913/Evoguard https://github.com/modarresi1913/Evoguard If you are working on: I would love to hear your perspective. The question I'm most interested in is: What if every AI-generated Pull Request had to prove that it belongs in the software system before it could reach production? That may be the next frontier of AI-native software engineering. created by Seyed Alireza Alhosseini Almodarresieh