DEV Community: zaxion

The 47-File PR "Improvement" That Broke Me

zaxion — Thu, 09 Apr 2026 06:22:57 +0000

The PR that changes core authentication
logic with zero tests and a description
that says "added login stuff."

The contributor who responds to every review
comment with a new commit instead of amending.
By the time it's ready to merge the history
looks like a wall of "address feedback"
commits that tell you nothing.

I tried handling this with PR templates.
Wrote detailed contributing guides.
Added a checklist to every PR.

Contributors ignored them.

Not maliciously. They're excited to contribute
and moving fast. I get it. But I was spending
more time leaving the same comments over and
over than actually reviewing the code.

"Please add tests for this."
"Can you split this into smaller PRs?"
"This commit message doesn't tell me anything."

Copy paste. Every week. For 14 PRs in a row.

So I built Zaxion.

It's a GitHub App that sits in your repo
and enforces whatever rules you define —
in plain English or Json/YAML.

Not generic rules. YOUR rules.

Things like:

Flag any PR touching more than 20 files without a linked issue
Block merges on /auth changes with no test files included
Reject PRs where CI is failing
Warn on commit messages under 10 characters

You write the rule once. Zaxion enforces
it on every PR forever.

When a contributor opens a PR that breaks
your rules, Zaxion leaves a comment explaining
exactly what's wrong. The contributor fixes
it before it ever reaches your review queue.

The part that surprised me most —

contributors actually appreciate it.

Getting a clear automated comment saying
"this PR is missing test coverage for
the files you changed in /auth" is less
embarrassing than a maintainer leaving
the same comment manually.

It feels like a system, not a judgment.

It's free for open source projects.
Takes about 30 seconds to install.

If you maintain a repo and you're tired
of leaving the same review comments every
single week — try it.

👉 zaxion.dev

I'm still building it and taking feedback
actively.
I need brutal honest feedback.

What's the most annoying PR pattern
you keep seeing in your repo?

I built a GitHub App that enforces your code standards on every PR — here's why

zaxion — Sun, 05 Apr 2026 05:59:22 +0000

I got tired of the same conversation happening
every single week.

"Why is there a hardcoded API key in this PR?"
"We talked about this."
"I know, I forgot."

Every team I've been around has standards
written somewhere — a Notion doc, a README,
a Confluence page nobody opens. And every
team watches those standards get ignored the
moment someone is under deadline pressure.

Human reviewers miss things. Not because
they're bad engineers. Because they're tired,
they're focused on business logic, and
they've already had the same conversation
ten times this month.

So I built Zaxion.

It's a GitHub App that enforces your custom
policies on every PR automatically. You write
the rule once — "no hardcoded secrets",
"all changes to /auth need tests", "no raw
SQL with user input" — and Zaxion checks
every PR against it. If a PR violates a rule,
it gets blocked and the developer gets a
clear explanation of exactly what to fix.

Not a linter. Not regex matching.

It uses Babel AST to actually understand
your code — variable scope, taint tracking,
data flow. Combined with an LLM evaluator
for higher level architectural rules that
are hard to express as code.

I'm a CS student and this is the first real
thing I've shipped publicly. It's free for
open source projects. Took about 30 seconds
to install on my own repos.

If you've ever felt the pain of the same
issue slipping through review for the
fifth time — this is what I built to stop
that.

Brutal feedback welcome.

zaxion.dev

Share Your Repo and I'll Show You What Would Break If You Enforced Code Standards

zaxion — Fri, 13 Mar 2026 00:43:13 +0000

You want to enforce rules like "Detects hardcoded secrets (API keys, tokens, credentials) in code." or "Ensures APIs are protected by rate limiting." but scared it'll slow down your team?

I'll test the rule on your PR and show you exactly what would happen.

No surprises. No guessing. Just data.

As the title suggest, simply responde with:

Your GitHub repo:

Name: github.com/your-company/your-repo
Your role: Maintainer / Contributor / Engineering Manager

Pick ONE rule you want to test: Common rules:

✅ "All new code needs tests"
✅ "No secrets in code"
✅ "Database changes need rollback plan"
✅ "All functions need documentation"
✅ "No TODO comments in main branch"

Or describe your Own RULE:
Exmaple:

"Enforces separation of concerns (Controller -> Service -> Data)."
"Identifies potential memory leaks in code patterns."
"Prevents installation of vulnerable or malicious packages."

Show me a PR that caused problems (Recommended): Share a PR where:

A bug got merged and had to be fixed later.
Missing tests broke production.
Code review missed something obvious.

Example: github.com/your-company/repo/pull/123

And I'll send you an interactive governance simulation report showing:

📊 Impact Analysis:

False positive rate for your codebase
Time saved vs manual review
Exact PRs that would have been caught

🚀 Risk-Free Deployment Plan:

How to test this policy safely
What to adjust before enforcement
Expected impact on team velocity

📈 ROI Calculation:

Hours saved per week on manual reviews
Bugs prevented from reaching production
Developer time freed up

Policy-as-Code vs. LLM Agents: A Benchmark You Need to See

zaxion — Thu, 12 Mar 2026 01:50:03 +0000

Why We Built Zaxion: Deterministic Governance vs. Probabilistic AI

A technical comparison of Policy-as-Code engines against LLM-based reviewers like Claude Code.

The Engineering Challenge: Consistency at Scale

As senior engineers and founders, we face a recurring dilemma: how to scale code quality without scaling manual review time. The industry's current answer is "AI Agents"—using LLMs like Claude Code to autonomously review pull requests.

While impressive, LLMs introduce a fundamental flaw in governance: Non-Determinism.

If you ask an LLM to review the same PR five times, you might get five different sets of comments. For creative suggestions, this is a feature. For security compliance and architectural governance, it is a bug.

We built Zaxion to solve this. Zaxion is a deterministic, AST-based governance engine designed to enforce policies with 100% consistency, sub-second latency, and immutable audit trails.

Here is how Zaxion compares to state-of-the-art LLM review (benchmarked against Claude Code).

1. The Core Architecture: AST vs. LLM

The fundamental difference lies in how the code is analyzed.

Claude Code (Probabilistic)

Mechanism: Tokenizes code, sends it to an inference API, and predicts the next most likely token (comment).
Pros: Can understand "intent" and natural language context.
Cons: Hallucinations, varying output based on temperature settings, and high latency (seconds to minutes).
Failure Mode: False positives due to probabilistic generation (e.g., flagging a valid pattern as an error because it's uncommon).

Zaxion (Deterministic)

Mechanism: Parses code into an Abstract Syntax Tree (AST), extracts structural facts, and evaluates them against declarative JSON/YAML rules.
Pros: Zero hallucinations, mathematical certainty, and sub-second execution.
Cons: Requires explicit rule definitions (Policy-as-Code).
Success Mode: If a rule says "Block imports from fs in frontend files," Zaxion blocks it every single time, instantly.To make it Pass the PR either you have to solve that BLOCK issue First or you can request you Admin to Override it, the Overridden Fuction also Audit of who, when and why. So everyone know this Overriden is Approved by WHO.

2. Technical Benchmark: Zaxion vs. Claude Code

We ran a comparison on a standard repository enforcing strict security guidelines (e.g., no hardcoded secrets, mandatory tests for API endpoints).

Feature	Zaxion (Policy-as-Code)	Claude Code (LLM Agent)
Consistency	100% (Same input = Same output)	~85% (Varies by run)
False Positive Rate	< 0.1% (Logic-based)	~15-40% (Context-dependent)
Latency (100 files)	~400ms	~45s - 2m
Enforcement	Hard Block (CI Failure)	Suggestion (Comment)
Audit Trail	Immutable JSON Log	Chat History
Cost	Fixed / Low / Free for Open Source Project	Variable (Token-based)

The Verdict

For suggestions (e.g., "This function could be more readable"), Claude Code excels.
For governance (e.g., "This migration lacks a rollback script"), Zaxion is the only viable engineering solution. You cannot build compliance on a probabilistic foundation.

3. Zaxion’s First-Class Capabilities

Zaxion is built for teams that need to prove their compliance posture, not just improve their code style.

Declarative Single-Source-of-Truth

Policies are defined in zaxion.json or YAML. This configuration file is version-controlled, reviewed, and serves as the absolute law for the repository.

{
  "policy": "require_tests_for_api",
  "scope": "backend/src/controllers",
  "rule": {
    "type": "file_existence",
    "pattern": "*.test.ts"
  },
  "enforcement": "blocking"
}

Automated Audit Trails (SOC2 / ISO 27001 Ready)

Every decision Zaxion makes is recorded.

Input: The PR diff and the active policy version.
Output: The PASS/BLOCK verdict and the specific AST nodes that triggered it.
Result: An immutable artifact that auditors can verify instantly. No more screenshots of PR comments.

Simulation Engine

Before enforcing a rule, Zaxion allows you to backtest it against your git history.

"If I enable this rule today, how many of last week's PRs would have failed?"
Zaxion provides a detailed impact analysis report, allowing you to tune policies without disrupting developer velocity.

4. Conclusion: The Right Tool for the Job

We are not replacing AI; we are validating it.

Use Claude Code to help your developers write better code and generate documentation.
Use Zaxion to ensure that what they ship meets your non-negotiable standards for security, architecture, and compliance.

Architecture is not a suggestion. It is a constraint.

Validate Our Claims

Don't take our word for it. Run the benchmark yourself.

Install the Zaxion GitHub App on a non-critical repo. If you don't want to install it on your repo, you can still run the simulation.
Run a Simulation to see what Zaxion catches that your current process misses.(https://zaxion.dev/governance)
Compare the results against your manual reviews or AI suggestions. Then, you can decide whether to use Zaxion or not.

Start a Risk-Free Simulation at zaxion.dev

I Broke 50 PRs With One Config Change. Here's How I Built a Time Machine to Prevent It.

zaxion — Mon, 09 Mar 2026 03:10:05 +0000

We've all been there. You decide it's time to improve code quality. "No more console.log in production code," you declare. You add a simple ESLint rule, push the config, and merge.

Ten minutes later, your Slack blows up.

"Why is the build failing on my PR?"
"I can't deploy the hotfix!"
"Who turned on the fun police?"

You just broke 50 open pull requests because you didn't know how widespread the "violation" was. You revert the change, apologize, and the codebase remains messy.

This fear of "Policy Shock"—the disruption caused by enforcing new rules—is why many teams are afraid to tighten their governance.

But what if you could time-travel? What if you could test your new rule against the last 100 PRs in your repo before you merged it?

That's exactly what we built. Here is the technical deep dive into how we created a Policy Impact Simulator for GitHub.

The Problem: Governance is a Guessing Game

Most CI/CD pipelines are binary: pass or fail. When you introduce a new check, it applies to everything immediately. There is no "try before you buy."

We needed a system that could:

Draft a policy (e.g., "Max PR size: 20 files").
Fetch historical data (snapshots of past PRs).
Replay the draft policy against that history.
Visualize the "Blast Radius"—how many legit PRs would have been blocked?

The Architecture

We built this using a Node.js backend (Express) and a React frontend. The core logic resides in a PolicySimulationService that acts as our time machine.

1. The Snapshot Engine

The first challenge is getting data. We don't want to clone repos and run npm install 100 times—that's too slow. Instead, we fetch metadata snapshots via the GitHub API.

We treat a PR as a collection of facts:

File count
Extensions used (.ts, .js, .py)
Test coverage ratios
Diff stats (additions/deletions)

Here is a simplified view of our snapshot collector:

// backend/src/services/policySimulation.service.js

async function collectSnapshots(repo, daysBack) {
  // 1. Fetch merged PRs from the last N days
  const prs = await github.fetchHistoricalPRs(repo, daysBack);

  // 2. Extract lightweight "Fact Snapshots"
  return prs.map(pr => ({
    id: pr.number,
    files_count: pr.changed_files,
    has_tests: pr.files.some(f => f.filename.includes('.test.')),
    extensions: [...new Set(pr.files.map(f => path.extname(f.filename)))],
    // ... other metadata
  }));
}

By abstracting the code into metadata "facts," we can run thousands of simulations in seconds without touching the filesystem.

2. The Simulation Loop (The "Judge")

Once we have the snapshots, we feed them into our evaluation engine. This is where the magic happens. We call this "The Judge."

The Judge takes a Draft Policy (JSON logic) and a Snapshot, and returns a verdict: PASS or BLOCK.

// The core simulation loop
async function executeSimulation(draftRules, snapshots) {
  const results = {
    blocked: 0,
    passed: 0,
    impacted_prs: []
  };

  for (const snapshot of snapshots) {
    // The Judge evaluates the rule
    const verdict = evaluate(draftRules, snapshot);

    if (verdict === 'BLOCK') {
      results.blocked++;
      results.impacted_prs.push({
        pr: snapshot.id,
        reason: `Violated rule: ${draftRules.type} (Limit: ${draftRules.value})`
      });
    } else {
      results.passed++;
    }
  }

  return results;
}

This deterministic loop allows us to tweak a threshold—say, changing max file count from 20 to 50—and see the impact graph update instantly.

3. Frontend Visualization

On the frontend, we use React to make this data actionable. We built a PolicySimulation component that lets users:

Select a target repo.
Configure a draft policy (e.g., "Require 2 reviewers").
Hit "Simulate".

The results are rendered using Recharts to show the "Blast Radius."

// frontend/src/components/governance/PolicySimulation.tsx

export const PolicySimulation = () => {
  const [result, setResult] = useState<SimulationResult | null>(null);

  // ... setup logic ...

  return (
    <div className="grid grid-cols-3 gap-6">
      <Card>
        <CardTitle>Simulation Configuration</CardTitle>
        <Select onValueChange={setPolicy}>
          <SelectItem value="pr_size">Max PR Size</SelectItem>
          <SelectItem value="coverage">Test Coverage</SelectItem>
        </Select>
        <Button onClick={runSimulation}>
          <Play className="mr-2" /> Simulate Impact
        </Button>
      </Card>

      <div className="col-span-2">
        {result && (
           <Alert variant={result.blast_radius > 50 ? "destructive" : "default"}>
             <AlertTitle>Blast Radius Alert</AlertTitle>
             <AlertDescription>
               This policy would have blocked {result.total_blocked} out of {result.total_scanned} PRs.
               {result.blast_radius > 50 ? " This is too disruptive!" : " Safe to merge."}
             </AlertDescription>
           </Alert>
        )}
        {/* Charts go here */}
      </div>
    </div>
  );
};

We intentionally calculate a "Friction Index". If a policy blocks >20% of historical PRs, we flag it as "High Friction." This simple heuristic has saved us from merging overly aggressive rules countless times.

Lessons Learned

Building this tool taught us three key lessons about developer experience (DX):

Metadata > Source Code: You rarely need the full AST to make high-level governance decisions. Metadata (file types, sizes, authors) covers 80% of use cases and is 100x faster to process.
Feedback Loops Matter: When you can see the impact of a rule immediately, you write better rules. It turns governance from a bureaucratic "gate" into a design problem.
JSON Schema is Powerful: Defining policies as JSON (rather than hardcoded functions) allows us to version them, diff them, and—crucially—simulate them without deploying code.

Future Work: AI Analysis

Our next step is integrating LLMs to explain why a policy failed. Instead of just saying "Blocked," we want the system to look at the PR description and say, "Blocked because this PR touches the payment gateway but lacks a 'Security' label."

We have a prototype running using a translate-natural-language endpoint that converts plain English ("Block PRs with no tests") into our JSON schema.

// Transforming English to Policy Config
const result = await api.post('/v1/policies/translate-natural-language', {
  description: "Block huge PRs"
});
// Output: { type: "pr_size", max_files: 50 }

Try It Yourself

This simulator is part of our broader initiative to make governance invisible and helpful, rather than painful.

If you're tired of guessing whether your new lint rule will cause a revolt, I highly recommend building a simple "dry run" script for your CI. Even a basic script that greps through your last 50 PRs can save you a headache.

What tools do you use to test your dev processes? Let me know in the comments—I'd love to see how others are solving the "Policy Shock" problem.

Thanks for reading! If you found this technical breakdown useful, drop a star or comment below.

Zaxion: Empowering the Open Source Community with Autonomous PR Governance 🛡️

zaxion — Sun, 01 Mar 2026 19:17:24 +0000

Zaxion: The Autonomous Guardian for Open Source Maintainers 🛡️

The Community

The Open Source (OSS) community is the backbone of modern software. However, it faces a silent crisis: Maintainer Burnout.

Maintainers spend countless hours manually reviewing Pull Requests (PRs), only to find that basic project standards—like adding tests for critical logic or following architectural patterns—have been ignored. On the other side, new contributors often face "rejection anxiety," waiting days for feedback only to be told they missed a rule buried deep in a CONTRIBUTING.md file.

I built Zaxion to turn those "passive" rules into "active" guardrails, protecting the time of maintainers and giving instant, educational feedback to contributors.

What I Built

Zaxion is an autonomous governance platform designed to act as an AI-native PR guardian. It doesn't just "lint" for typos; it understands the intent and context of code changes.

When a developer opens a PR, Zaxion:

Analyzes: Fetches the code diff and understands which parts of the system are being touched.
Evaluates: Runs the project’s specific policies (e.g., "If auth/ is touched, 100% test coverage is mandatory").
Enforces: If a policy is violated, Zaxion blocks the merge and leaves a helpful comment explaining why and how to fix it.

It’s like having a Senior Engineer who never sleeps, ensuring that the standards you define in your head are the standards that actually ship.

Demo

Live Demo: [https://zaxion.dev]

The Decision Console in Action

Autonomous PR Verdicts: Instant policy enforcement with educational feedback to resolve violations before merge. 🛡️

Institutional Proof & Audit Trails

Verifiable Rationale: Every decision is anchored to your constitution with an immutable audit trail and integrity hash. 🏛️

Self-Service Resolution Flow

Automated Guidance: Zaxion provides clear, actionable steps for developers to resolve policy violations and achieve auto-clearance. ⚡

Code

GitHub Repository: [https://github.com/zaxionhq/Zaxion]

How I Built It

Building a tool that handles sensitive code requires a high-performance and secure stack:

Frontend: Built with React + Vite for a lightning-fast, modern UI that lets maintainers track PR status in real-time.
Backend: A robust Node.js (Express) server that handles high-concurrency PR events.
GitHub Integration: Built as a formal GitHub App, using Webhooks to listen for PR activity and the GitHub API to enforce merge blocks.
Security First (Stateless): I implemented JWT-based authentication for users, meaning we don't need to constantly query a database for identity—improving speed and security.
Zero-Retention Model: To respect privacy, Zaxion uses a "Fetch-Analyze-Discard" pattern. Code is analyzed in-memory and wiped immediately after the decision is made.
Smart Logic: Unlike regex-based tools, Zaxion is designed to understand code structure, allowing for complex rules like "Prevent importing heavy libraries in frontend components."

Zaxion turns documentation into action. By automating the governance of our codebase, we can spend less time policing rules and more time building the future of the community.

devchallenge #weekendchallenge #webdev #ai #opensource #github