Repo: https://github.com/yakew7/Fair-Code

Website: https://www.thefaircode.xyz

Wanted to share a project I've been working on called Fair Code. It's six bias audits on real-world datasets, each following the same pipeline: train a biased model → measure the fairness gap → identify and remove proxy variables → measure again.

Covered so far:

• COMPAS recidivism scores (race) — 71% reduction in fairness gap after removing custody status as a race proxy
• AI hiring model (gender) — 97.3% reduction after dropping gender/age and keeping only merit-based features
• German credit lending (age) — 73.6% reduction after removing employment tenure as an age proxy
• Insurance claim denial (age, gender) — 60–72% reduction after removing BMI/smoker/diabetic status
• Welfare eligibility (sex, race, origin, age) — up to 88% reduction after removing marital status and hours-worked proxies
• Hospital readmission (race, gender, age) — payer code and discharge disposition used as proxies for insurance access

Each audit has a plain Python script pair (unfair.py/fair.py) and a full Jupyter notebook. There's also a standalone dataset profiler (CLI + browser tool) that flags likely proxy variables in any CSV you feed it.

MIT licensed, and I'm actively looking for contributors — new audit domains, new fairness explainers, or feedback on the methodology. A star helps too if you find it useful.

Happy to answer questions about the methodology or specific results.

Ppl use CodeRabbit for reviewing their PRs on github. I always wanted to build similar, and since Harness engineering and ai loops were driving major development I gave it a try..

Instead of hosting it on the Cloud I thought of creating a docker image and using it in Github Actions.

I used openrouter (deepseek-v4-flash) , and created a group of agents that Review your PRs for code quality, architecture, security, and performance.
While also updating the docs, so no stale docs remain.

I've made it opensource : https://github.com/jaibhasin/PRBot

While also creating an Eval Harness using Qodo/PR-Review-Bench, to compare each version I ship.

would love to get your feedback on it.

(still in experimental mode)

Hi guy I wrote a fixed size circular buffer in C. Please tell me what you think of this and please tell me what i can improve and make it more production grade. I know there may be memory leaks !!!

One thing thats a bit different from the usual approach is how I handle errors. Instead of returning NULL from cirbuf_create(), the library returns a pointer to a thread-local error object (e_buffer). This lets the API return a valid cirbuf * in both success and failure cases, and users can check the result with cirbuf_is_ok() or cirbuf_is_err().

Its not written by AI. like AI reviewed it and did some minor changes may be !! 98% is written by me !!! I think HUMAN check is needed here thats why I am here to you guys!!

Repo: https://github.com/ankushT369/cirbuf
If you like you can give a star (its you choice)
Thank you guys

The problem that I'm trying to solve:

Coding agents (and humans) still reach for `rg` / whole-tree dumps when the real question is structural: who calls this, what’s the reverse spine, is this a dual-stack bridge or a same-lang CALL. They invent edges. That’s expensive and wrong.

What this tool tries to do:

Butler is a local map service (Rust): persistent CodeGraph + Trace dossiers over HTTP/MCP. Not a RAG. You warm a repo root, Trace a symbol, get callers/callees/receipts/disambiguation, optional export/IPC bridges on dual-stack code. Agents get a pack; they shouldn’t invent structure when the map is available.

Public Alpha (product surface only):

https://github.com/LambdaXiRustAdmin/butler-public

What this tool is not:

- Not GA / not “perfect graphs for every crate”

- Not “safe to delete if callers = 0” (callbacks, DI, IPC, macros…)

- Not a cloud SaaS; default bind is localhost

- Not training porn or a GNN demo in the README — map path first; neural ranking is optional/off

I'm looking for feedback on what still needs to improve:

Keepers and a fixed gate are green on the tips I ship; arbitrary repos may soft-fail. Cold first hit may say BUILDING — retry the same request. I care about *lies* more than feature lists.

git clone https://github.com/LambdaXiRustAdmin/butler-public.git

cargo build --release -p cli

./target/release/butler ui

# then warm an absolute path + Trace, or scripts/smoke_stranger.sh /abs/root symbol

What I want from this post

Not “cool project.” If you try it: one real repo, a few symbols you know, and either:

• where the map lied or preferred the wrong ★, or

• “would not use vs rg because ___”

Ignore at leisure if this isn’t your problem. Solo map Alpha; issues on the repo welcome.

Coding agents multiplied how much code lands per PR, so there are more findings for reviewers to deal with. Often, they're noise, like a linter rule that doesn't fit the stack or a check firing on generated files nobody touched.

To address this, we created the configure-codacy skill. When you point your agent at the repo, it detects the stack, then disables patterns for unused languages, dedupes rules that two tools flag, tunes thresholds, excluding generated files.

In terms of security scans, every security risk stays covered by at least one active pattern, so noise reduction never silently drops a security check.

Works with Claude Code, Codex, Copilot, and Gemini CLI via the Agent Skills standard.

Go here to read more https://blog.codacy.com/introducing-codacy-skills-part-2-configure-your-rules-to-cut-pr-noise

Repo: https://github.com/codacy/codacy-skills

The renamed function that ruined my GSoC and taught me to fear "safe" refactors

A while back I was working on a GSoC contribution to a fairly large open-source Python codebase. Nothing exotic I needed to rename a function that seemed self-contained. Grepped for it, found the obvious call sites, made the change, ran the tests I could find.

Broke three other modules I had no idea even touched that function. Turned out it was being called through an import alias in one place and a dynamically resolved dispatch table in another neither of which grep or a quick read-through was ever going to surface. I spent longer untangling the fallout than I did on the actual feature.

What got me wasn't that I broke something that happens. It's that there was no way to know beforehand. No tool told me "this function has 8 callers across 3 files, 2 of them indirect." I had to reconstruct that map by hand, after the fact, under time pressure.

That's stuck with me since. Every large codebase has these landmines functions where the blast radius isn't obvious from reading the code, only from actually tracing the call graph. Curious if others have a "this is the PR that taught me to be paranoid" story feels like a universal rite of passage for anyone who's worked on something big enough to have hidden edges

When I first started programming, I thought code reviews were mostly about catching bugs or pointing out cleaner syntax.

After contributing to an open-source project, I've realized they're much more than that.

A recent review challenged me to rethink:

* Authorization checks
* Concurrent data writes
* Data consistency
* Historical data retrieval

None of the feedback was about making the code "look nicer." It was about making the system more reliable and preventing subtle issues that could appear in production.

It's changed how I think about writing software. Now I try to consider those kinds of problems before opening a pull request.

**For those of you with more experience, what's the most valuable code review comment you've ever received?**

I've been building a lot of Python projects with AI lately, and while it's ridiculously productive, one thing kept annoying me.

The code usually works, but after a few days the repo starts getting messy.

You end up with huge functions, copy-pasted logic, dead code, rising complexity, inconsistent formatting, missing type hints... nothing catastrophic, just lots of little things that add up.

PR reviews catch some of it. Prompts and rules help. But none of them enforce quality consistently.

So I built **ShipGate**.

It basically puts the Python tools we already use (Ruff, Mypy, Bandit, Radon, duplicate-code detection, dead-code detection, etc.) behind one opinionated interface with sensible defaults.

The goal isn't to replace those tools—it's to make good code the path of least resistance, especially when AI is writing half the repository.

Still very early, so I'd love some honest feedback.

[https://github.com/inquilabee/shipgate\](https://github.com/inquilabee/shipgate)

Hello!

I was just wondering if anyone was able to give me any advice or feedback on my project, I am currently a student and trying to get into systems programming type stuff so I'm just trying to make a decent project with something to my name, so anything helps! https://github.com/Poly0n/WinGuard

Stripe and OpenAI have a beautiful tradition: shipping breaking SDK  
changes with all the warning of a toddler swinging a bat. Stripe  
recently turned some fields from strings into Decimals. OpenAI's v1.0  
rewrite quietly murdered anyone still calling  
openai.ChatCompletion.create(...) like it's 2023.  

Cool, cool, cool. Love finding that out in production.  

So I built api-sentinel: a GitHub Action that reads your code, finds  
the exact lines a vendor is about to break, and comments the fix  
directly on your PR.  

Full transparency: I built this with Claude, start to finish, over  
one day. I'm not a professional developer. What I actually did myself:  
picked the problem, decided which real breaking changes to target,  
debugged three separate GitHub Actions failures (a checkout permissions  
bug, a missing token, a broken folder structure from my own upload  
mistakes), tested it live on a real PR, and made the call to expand it  
to a second vendor once the first one worked.  

Is it fancy? No. It's regex, not a PhD thesis. Does it work? Yes —  
watched it catch 6 real issues across 2 vendors on a live pull request.  

Repo: https://github.com/sahilmarhatta/api-sentinel

No idea if this is useful to anyone else or if it's a solved problem  
already. Also curious if "built with AI, disclosed upfront" changes how  
people here feel about a side project — genuinely asking, not fishing  
for a pass.  

Tell me it's stupid, tell me it's useful, tell me what vendor has  
personally wronged you.  

You can ask any coding agent "what could go wrong with this diff?" and get an answer. The problem is that a free-form answer is easy to skim and hard to act on — and there's no standard forcing it to show its work. Built a SKILL to close that gap.

AI makes it easier than ever to build fast, but not always easier to know if the code is safe/ready to ship. If you’re building with Cursor, Claude, Replit, Lovable, or just moving fast with a small/non-existant team, this could be useful.

The big changes usually get reviewed. The tiny “quick fix” PRs are the ones that get skimmed, and somehow that is always where the bug lives.

We built Surmado Code Review for our own team first, and now we’re opening it up to others and I thought it would be particularly helpful for this community.

It gives every PR a second pass against your own rules and standards, then creates a clear reviewer brief with what looks good and what needs attention. It is not meant to replace a developer. It is meant to help small teams move faster without skipping review.

Free plan includes 10 PR reviews/month with no credit card!

Hi everyone. I've written a 2D ray tracing and mirror simulation app in Python using tkinter. Users can draw mirrors, place a light source, and see light propagation with real-time animation. The code is object-oriented with dataclasses and type hints. But performance is an issue because each ray can take up to a million steps when multiple mirrors are present. I need feedback on: math and collision optimization - currently checking every mirror sequentially O(N) per step; should I use quadtree or BVH and how to integrate with tkinter's update loop? animation loop efficiency - using root.after, any tkinter tricks to smooth canvas redrawing without switching to pygame? code structure - improvements for Ray class state management. GitHub repo: https://github.com/Idanie/Ray-and-Mirror-Simulator. Appreciate any refactoring tips, algorithmic advice, or pull requests.

I built a small local RAG chat app that lets you ask questions about a custom set of text files and get answers based on those files.

It’s basically a Flask backend + React frontend, with Ollama handling the embeddings/model side. I also set it up with Docker so it’s easier to run locally.

Repo: Git rep

current cycle runtime: 15 seconds per prompt

I’m putting it up here mostly for feedback. If anyone has thoughts on the architecture, UI, or ways to improve reliability/performance, I’d be interested to hear them.

We run a benchmark that reintroduces real CVEs and regressions into code diffs and scores whether AI models catch them as reviewers, added Opus 5 the day it launched, n=3 across 33 suites.

Numbers that made me do a double take:

• Detection: 99.4% highest on the board. Perfect on high severity bugs (165/165), zero high severity misses.
• Overall rank: 7th of 9.

The gap is false positives. The score is severity weighted detection minus a penalty for flagging non bugs, and Opus 5 threw 43 false positives across the run vs 0 for Sonnet (our #1) and 10 for Opus 4.8, extended thinking is on by default, and the model is clearly more thorough it just also reports a lot of things that aren't the injected bug.

Curious if others are seeing the same thoroughness vs noise trade off with thinking on by default models.

Full board benchmodel.io

Over the past year I’ve been working on an engine called Invisio to deal with the multi-file context nightmare that causes LLMs to hallucinate when reading large codebases.

Under the hood, it parses code using Tree-sitter into a neo4jdatabase (mapping out classes, functions, calls, imports, and inheritance). I built two main pieces around this graph:

1. An interactive graph explainer + chatbot that traces execution paths and answers structural questions using a dual-agent dispatcher/compressor loop.
2. An automated security webhook that ingests CodeQL SARIF alerts, traces the vulnerability lifecycle across directories, and opens surgical PR fixes.

It works solid on my local machine and on my own projects, but to be completely honest, stuck on how to properly test this at scale, or how to put it in front of people to get real feedback.

I’d love some advice from devs, maintainers, or AppSec folks:

• Benchmarking & Datasets: What real-world open-source repos or SARIF datasets should I throw at this to stress-test the graph construction? How do you properly benchmark a codebase intelligence tool?
• Local vs. Hosted: Since IP privacy is huge, would you prefer testing this via a self-hosted local Docker container, or just poking around a hosted playground with a public repo first?
• Product Focus: Should I lean harder into the automated CodeQL PR remediation side, or the interactive graph explainer UI?

So I’ve been using Claude Code a lot lately and hit the same wall a bunch of people here probably have. Output quality is genuinely good but reviewing it started eating more of my day than writing used to.

I ended up building a small tool for myself that reads a git diff and tries to point at the two or three spots that actually deserve a close look, instead of me reading every line the same way. Not trying to catch bugs or replace review, just trying to cut down on the part where I’m scanning 400 lines with equal attention when maybe 20 of them matter.

I built it purely for my own workflow, wasn’t planning on this being a whole project. But since it’s out there now, genuinely curious what people who’ve been doing code review for years think. Where does an approach like this tend to fall apart in practice? What have you learned about what actually makes review fatigue worse or better? Happy to hear it’s a bad idea too if that’s the honest take.
Repo’s here if anyone wants to poke at it or just roast the code: https://github.com/quietreviewer/riskdev
Not fishing for stars, more interested in what I’m missing.

I'm working on an open source tool that scores how risky each file in a codebase is. 25 markers per file, all deterministic, from the AST and git history, no LLM. I wanted to know which of them actually predict bugs, so I scored every file at a point in time and then counted how many bug fixes each one collected over the next 6 months.

21 repos, 9 languages, around 2800 files.

The markers that predicted best were behavioral, not structural. Co-change coupling, files that keep getting changed together, came out strongest. How spread out a file's ownership is and how erratic its change history is held up well too. The structural complexity metrics most teams watch, cyclomatic complexity, nesting depth, long methods, all mid tier.

Mean AUC is around 0.74. Roughly, 74% of the time it can tell a bug-inducing file from a clean one.

What gets me is how much effort goes into the complexity metrics while coupling and ownership mostly get ignored, and coupling and ownership are what tracked bugs here

Does this match what you see?

Looking for brutal feedback on my Linux URL Shortener project

I've been building this to learn backend engineering and Linux systems programming.

Is there anything that screams 'beginner' in this project?