DEV Community

Seyed Alireza Alhosseini
Seyed Alireza Alhosseini

Posted on

EvoGuard: Building the Trust Layer for AI-Generated Software

#ai #devops #software #github

What exists today, what we are building next, and why software evolution needs a new layer of intelligence

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

The Core Idea

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
Enter fullscreen mode Exit fullscreen mode

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.

Why Existing Code Review Is Not Enough

Consider an AI-generated change that:

  • compiles,
  • passes type checking,
  • passes unit tests,
  • passes CI,
  • looks reasonable in a Pull Request.

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:

  • previous rollbacks,
  • reverted commits,
  • production incidents,
  • dependency failures,
  • architectural decisions,
  • internal conventions,
  • security findings,
  • ownership structures,
  • flaky tests,
  • deployment history.

For example, imagine a repository has an undocumented rule:

Never call fetch() directly.
Use the internal httpClient abstraction.
Enter fullscreen mode Exit fullscreen mode

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.

The Repository Has a Memory

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

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.

What EvoGuard Has Today

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:

Risk Overview

A nine-dimensional Ecosystem Compatibility Score (ECS) with confidence information and evidence.

Evidence Explorer

A structured view of evidence associated with a change.

Historical Patterns

A representation of repository memory and the separation between observation, inference, and policy.

Provenance

Declared, inferred, and unknown provenance states with confidence.

Review Comments

Evidence-linked review findings with source locations and suggested actions.

Policy & Gates

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
Enter fullscreen mode Exit fullscreen mode

The current demo uses bundled mock data, so this should not be confused with the future production backend.

The Architecture We Are Building Toward

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
Enter fullscreen mode Exit fullscreen mode

The production design includes components for:

  • GitHub integration
  • Pull Request ingestion
  • change normalization
  • Git history mining
  • dependency analysis
  • evidence storage
  • context construction
  • risk scoring
  • LLM explanation
  • policy enforcement
  • review delivery
  • outcome tracking

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.

The Nine-Dimensional ECS

One of the central concepts is the Ecosystem Compatibility Score.

Instead of producing a generic:

AI confidence: 87%
Enter fullscreen mode Exit fullscreen mode

EvoGuard explores a multi-dimensional compatibility model:

Contract
Historical
Dependency
Test
Convention
Architecture
Security
Ownership
Runtime
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

From Static Review to Outcome-Based Intelligence

This is where EvoGuard becomes more interesting.

Suppose:

PR #100
   ↓
Merged
   ↓
No incident
Enter fullscreen mode Exit fullscreen mode

That is useful information.

Now:

PR #101
   ↓
Merged
   ↓
Production regression
   ↓
Rollback
Enter fullscreen mode Exit fullscreen mode

That is even more valuable.

The system should eventually be able to learn:

Change Pattern
      ↓
Observed Outcome
      ↓
Historical Evidence
      ↓
Future Risk
Enter fullscreen mode Exit fullscreen mode

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:

Outcome-Bound Code Intelligence

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 Next 90 Days

The development roadmap is intentionally divided into three phases.

Phase 1 — Evidence MVP

The immediate objective is to move from the interactive concept toward a real evidence pipeline.

Planned components include:

  • GitHub App integration
  • real PR ingestion
  • diff and commit analysis
  • static analysis
  • CI result collection
  • test result collection
  • dependency extraction
  • basic reporting
  • privacy controls
  • audit logging

These components are currently documented as designed rather than all being production-complete.

Phase 2 — Historical Compatibility

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
Enter fullscreen mode Exit fullscreen mode

The roadmap includes:

  • revert detection,
  • rollback detection,
  • historical pattern mining,
  • dependency compatibility,
  • evidence-linked review comments,
  • convention extraction,
  • feedback capture,
  • initial ECS calibration.

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.

Phase 3 — Real-World Production Pilot

The next step is not another UI feature.

It is validation.

The goal is to run EvoGuard against real repositories and answer measurable questions:

Does it reduce false positives?

Does it detect regressions that ordinary CI misses?

Can historical patterns predict future failures?

Does it reduce review time?

Does it reduce rollback frequency?

Can developers understand why a PR was flagged?

Does the system become more accurate as repository history grows?

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.

The Hardest Problem: Causality

There is a difficult research problem hiding inside EvoGuard.

Suppose:

Commit A
Commit B
Infrastructure change
Traffic spike
Database failure
Rollback
Enter fullscreen mode Exit fullscreen mode

Which change actually caused the incident?

It is dangerous to simply say:

Rollback → Commit A was bad
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

and never silently turn an inference into a fact.

This separation is already part of the project's core design principles.

The Future: Counterfactual PR Analysis

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?"
Enter fullscreen mode Exit fullscreen mode

This could eventually become a new category of developer tooling:

Predictive Software Change Intelligence.

The Bigger Opportunity: Autonomous Coding Needs Autonomous Verification

AI coding agents are moving toward increasingly autonomous workflows:

Issue
  ↓
Plan
  ↓
Code
  ↓
Test
  ↓
Pull Request
  ↓
Review
  ↓
Merge
  ↓
Deploy
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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 Vision

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
Enter fullscreen mode Exit fullscreen mode

That creates a continuous learning loop:

More changes
     ↓
More outcomes
     ↓
More evidence
     ↓
Better repository memory
     ↓
Better risk prediction
     ↓
Safer autonomous development
Enter fullscreen mode Exit fullscreen mode

The system gets better because the software system itself generates more evidence.

Beyond GitHub

The current focus is GitHub, but the architecture is not fundamentally tied to one platform.

The longer-term roadmap includes:

  • GitLab support
  • Bitbucket support
  • runtime behavior analysis
  • predictive refactoring
  • opt-in cross-organization learning
  • custom LLM providers
  • incident-management integration
  • broader multi-language support.

This opens another possibility:

The Software Evolution Graph

Imagine representing a company’s software as a continuously evolving graph:

Code
 │
 ├── Dependencies
 │
 ├── Developers
 │
 ├── PRs
 │
 ├── Architecture
 │
 ├── Deployments
 │
 ├── Incidents
 │
 ├── Rollbacks
 │
 └── Runtime behavior
Enter fullscreen mode Exit fullscreen mode

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.

What EvoGuard Is — and Is Not

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.

Why This Matters Now

The software industry is entering a new phase.

We are moving from:

Human writes code
Enter fullscreen mode Exit fullscreen mode

to:

Human + AI writes code
Enter fullscreen mode Exit fullscreen mode

and increasingly toward:

AI agents write and modify code
Enter fullscreen mode Exit fullscreen mode

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 EvoGuard Thesis

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?
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

That is the direction EvoGuard is exploring.

From Code Generation to Software Evolution Intelligence

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
Enter fullscreen mode Exit fullscreen mode

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.

Explore EvoGuard

The project is open source and evolving:

GitHub:
https://github.com/modarresi1913/Evoguard

If you are working on:

  • AI coding agents
  • DevSecOps
  • software reliability
  • autonomous software engineering
  • code provenance
  • repository intelligence
  • software architecture
  • AI safety for developer tooling

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

Top comments (0)