Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback.
Let's get one thing straight before we start: your machine learning model has never met a human being in its life.
It has never shaken a hand, told a bad joke at a party, or been unfairly cut off in traffic.
All it has ever "known" is a spreadsheet. And yet, somehow, these systems keep managing to recreate the exact same prejudices humans have been working on for centuries.
How does a pile of matrix multiplication end up being sexist?
Turns out, it's less "evil robot" and more "extremely diligent intern who was only ever shown one folder of examples and told to copy the pattern exactly."
The Bank That Learned the Wrong Lesson
Picture a bank that builds an AI to score loan applicants.
It trains the model on years of historical data: income, occupation, age, and whether people paid their loans back. Reasonable enough.
Then someone on the compliance team runs a check and finds the model is quietly handing out lower credit scores to women.
Nobody told it to do that. Nobody wrote a line of code that said if gender == "female": score -= 20. So what happened?
A couple of things, usually at the same time:
- Imbalanced data: If the training set has way more male applicants than female ones (because historically fewer women applied, or were approved), the model gets really good at predicting outcomes for men and just sort of shrugs at everyone else. Statistically, the smaller group becomes "less important" to get right.
- Data that remembers old grudges: If women were rejected more often in the past for reasons that had nothing to do with their actual ability to repay a loan, the model trained on that history will cheerfully learn to keep doing it. The model isn't inventing bias. It's just an excellent student of it.
This is the part that trips people up: the AI doesn't need to be told someone's gender to discriminate based on it.
It can pick up plenty of other clues.
"Just Remove the Sensitive Data!" (Narrator: It Was Not That Simple)
The obvious fix seems obvious: don't give the model anyone's gender, race, or age, and problem solved, right?
Nope. This approach even has a name, "fairness through unawareness," and it mostly just means the discrimination goes undercover instead of disappearing.
Here's why: tons of everyday, totally-innocent-looking data points are quietly correlated with protected characteristics. Job title. Working hours. Postcode.
None of these scream "this is a proxy for gender" on their own, but put enough of them together and a clever enough model can reconstruct exactly what you tried to hide.
Classic example: if women in a certain industry are more likely to work part time, a model deciding who gets made redundant based on "working hours" is functionally making a decision based on gender, even though gender was never in the spreadsheet.
The model didn't need the label. It found the shape of the thing anyway.
Here's roughly how that sneaky proxy problem develops:
So deleting the column doesn't delete the pattern.
The pattern was never really about the column.
It was about everything correlated with it.
Okay, So What Actually Helps?
This is where it gets genuinely interesting, because "algorithmic fairness" is now its own little universe of mathematical techniques for measuring and reducing this stuff.
A few of the moves in the toolkit:
- Pre-processing: Rebalance the training data itself. If women are underrepresented in the loan dataset, go find or weight more examples so the model actually has something decent to learn from.
- In-processing: Change how the model learns in the first place, nudging the training process itself to care about fair outcomes, not just raw accuracy.
- Post-processing: Leave the model as-is but adjust its outputs afterward to correct for skew.
None of these are a magic fix-it button, and here's the catch nobody likes to mention: different fairness measures can actually contradict each other.
You genuinely cannot satisfy every mathematical definition of "fair" at the same time.
Choosing which one matters most is a judgment call, not a settled equation, and it depends heavily on context, law, and who might be harmed by getting it wrong.
There's also a wrinkle around accuracy.
Sometimes fixing the bias and improving accuracy point the same direction (more data on an underrepresented group can genuinely make the model both fairer and better).
Other times you're facing a real trade-off between fewer errors overall and a fairer distribution of who bears those errors. Pretending that tension doesn't exist doesn't make it go away.
Wait, Doesn't Testing for Bias Mean Collecting the Very Data You're Trying to Avoid?
Yes, and this is one of the more counterintuitive bits.
To find out whether your model is discriminating by religion, or race, or disability, you often need to actually look at religion, race, or disability data for a sample of people, specifically to check the outcomes.
That means processing what's called "special category data," which comes with its own extra layer of legal conditions attached (think: needing a specific lawful basis beyond the usual one, on top of an actual reason tied to equality monitoring or research).
It's a genuinely strange position to be in.
You can't fix what you refuse to measure, but measuring it means handling sensitive information responsibly, with proper justification, safeguards, and usually a written policy explaining exactly why you're doing it and how you'll protect it.
Here's roughly what that decision path looks like in practice, zoomed out to the essentials:
The short version: testing responsibly is allowed and often necessary, it just has to be done deliberately, not as an afterthought.
The Part Where Nobody Wants to Hear "It Depends"
If there's one theme running through all of this, it's that fairness isn't a checkbox.
It's not something a model achieves and then you're done forever. Removing a column doesn't fix it.
One fairness metric doesn't capture it. A single retraining pass doesn't cement it.
Real mitigation looks more like an ongoing habit: documenting your approach from day one, testing against real-world outcomes (not just accuracy scores), watching for drift once the system is actually deployed, and being honest about the trade-offs instead of pretending there's a clean answer.
It also means asking a genuinely underrated question before any of the technical stuff: is an algorithm even the right tool for this decision, or does this particular problem actually need a human being who can use judgment on a case that doesn't fit the pattern?
Sometimes the most sophisticated fairness intervention available is simply admitting the AI shouldn't be making the call alone.
And if nothing else, next time someone says "we just removed the sensitive columns so the model can't be biased," you now know exactly which follow-up question to ask.
Disclaimer: This article was written by me; AI was used to fix grammar and improve readability.
AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.
git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.
Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.
⭐ Star it on GitHub:
HexmosTech
/
git-lrc
Free, Micro AI Code Reviews That Run on Git Commit
| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |
git-lrc
Free, Micro AI Code Reviews That Run on Commit
GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.
git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.
In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen
At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…
Top comments (0)