I'm a CS student. I built a GitHub App and audited 5 popular repos with it. here's what I found.

#opensource #webdev #github #codenewbie

I started building Zaxion in August 2025.

No co-founder. No team. No funding. Just me, a CS
student, annoyed at watching the same
security mistakes show up in every codebase I
touched — including my own.

The idea was simple: what if your team's standards
actually got enforced on every PR, automatically,
before a human ever had to say anything?

8 months later I shipped it.

Zaxion is a GitHub App that enforces custom code
policies on every PR. You write the rule once in
plain English or in Jason format. It enforces it forever. Hardcoded
secrets, unhandled async calls, raw SQL with user
input, missing tests on critical paths — whatever
your team actually cares about.

The engine uses Babel AST to understand code
semantically. Not just text matching. Actual data
flow, variable scope, taint tracking. For higher
level architectural rules that are hard to express
as code, it uses an LLM evaluator. Both run on
every PR in under a second.

After I shipped it,** I wanted to prove it worked on
real codebases**. Not toy examples. Not repos I
controlled. Real production code from teams that
actually know what they're doing.

**So I ran it on 5 of them.

**

cal.com

cal.com is one of the most well-known open source
scheduling platforms. 32k stars. Active team.
Professional codebase.

Zaxion found console.log statements shipping to
production in markdownToSafeHTMLClient.ts at line 15.

2 occurrences. Production code. Not a test file.

Console logs in production mean internal application
data is printing to every user's browser console.
Not a catastrophic breach. But the kind of thing
that shouldn't make it through review.

It did. Zaxion caught it.

trpc/trpc

tRPC is the TypeScript RPC framework that half the
modern web is built on. Serious engineers. Fast
moving repo.

Zaxion found 5 unhandled async calls in
packages/react-query/src/utils/createUtilityFunctions.ts

Production utility code. If any of those promises
reject — and eventually they will — the app fails
silently. No error message. No stack trace. Just
broken behavior that takes hours to trace back to
a missing try/catch.

5 occurrences. Passed human review.

withastro/astro

Astro is the web framework everyone switched to
when they got tired of shipping too much JavaScript.
The team ships fast and ships well.

Zaxion found 5 unhandled async calls in
packages/astro/src/runtime/server/jsx.ts

That file runs on every server render. If those
async calls fail without error handling, the server
throws an unhandled exception in production. For
every user hitting that route.

Same pattern as trpc. Different repo. Different team.
Same result.

the pattern

I want to be clear about something.

I'm not posting these findings to make these teams
look bad. cal.com, trpc, and astro are maintained
by some of the best engineers in open source. These
are not rookie mistakes.

These are what happens when good engineers review
a lot of PRs very fast. Volume beats attention
every time. The issue isn't skill. It's that humans
can't maintain the same level of focus on PR number
47 as they had on PR number 1.

That's the gap Zaxion sits in.

It doesn't get tired. It doesn't have a bad day.
It doesn't approve something because it's Friday
and the PR looks fine at a glance.

It runs the same check on every PR the same way
on day 300 as it did on day 1.

how it works in 30 seconds

You install Zaxion on your GitHub repo as a GitHub
App. It takes about 30 seconds.

You either use the 31 built-in policies that ship
with it — covering security, reliability,
architecture, code quality, testing, and performance
— or you write your own policy in plain English or in jason format in the dashboard.

When a PR opens, Zaxion analyzes it and either
passes it or blocks it with a comment explaining
exactly what failed, which file, which line, and
what the policy says.

That's it.

I need your help

I'm going to be straight with you.

Zaxion is real and it works. t*he findings above
are genuine.* but it's also something **I built alone
as a 20 year old CS student **over 8 months — which
means it's not perfect.

some policies might be too aggressive for certain
codebases. some advanced rules that you create might not work
correctly on every repo. some edge cases I haven't
seen yet are probably going to break something.

I'm not asking you to use a broken tool.
I'm asking you to use an early one.

if you install it and something doesn't work the
way you'd expect — I genuinely want to know. not
to defend it. to fix it.

if a policy fires when it shouldn't — tell me.
if a policy misses something obvious — tell me.
if the dashboard is confusing — tell me.

this is the stage where real feedback from real
developers matters more than anything else.
and I'd rather hear "this is broken" from someone
who tried it than build in a vacuum for another
8 months.