This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

FairLens AI is a premium, high-end SaaS platform designed for AI-powered bias auditing. I built this tool to help data scientists and researchers easily identify, quantify, and mitigate hidden biases within their datasets before those datasets are used to train machine learning models.

My vision as a developer has always been to create meaningful impact in society through technology. Monitoring and detection systems are crucial for accountability in tech, and I realized that while many people talk about AI fairness, there are very few accessible, beautifully designed tools to actually measure it. FairLens AI bridges that gap. By simply uploading a CSV dataset, users receive instant insights into fairness metrics across protected attributes, visualized through an interactive, glassmorphism-styled dashboard. It calculates complex metrics like Demographic Parity Ratio and Disparate Impact, assigns an overall fairness score, and provides actionable mitigation recommendations.

Demo

Live Project Link: FairLens AI Platform
GitHub Repository: bibhupradhanofficial/fairlens-ai

Video Demo:

Screenshots:
Fairness score:

AI-generated executive summary and intersectional analysis:

The Comeback Story

This project originally started as an ambitious idea for a data visualization dashboard, but I hit a massive roadblock when it came to the actual data science and backend engineering. The Finish-Up-A-Thon gave me the exact push I needed to rethink my architecture and finally complete it.

Where the project was before:
Previously, FairLens AI was essentially a beautiful, static mockup. I had built out the frontend architecture using React 18, Vite, and Tailwind CSS, and perfected the UI using Framer Motion and Recharts to give it a premium feel. However, the project stalled completely at the backend. Writing a manual, hardcoded statistical engine capable of parsing diverse datasets, calculating edge cases for Disparate Impact, and figuring out “feature importance” was overwhelming. The dashboard was full of dummy data, and the repository sat untouched.

What I added and fixed to finish it up (The “After”):
To bring the project across the finish line, I completely abandoned the idea of hardcoding the statistical logic and pivoted to an AI-agentic architecture. I added the following major features:

• Supabase Edge Functions: I implemented a robust, serverless backend using Deno (audit-bias/index.ts) to securely handle the dataset statistics over an API without bogging down the client.
• Google Gemini 3 Integration: I connected the Edge Function to the Google Gemini 3 Flash Preview model via an AI gateway. I engineered a highly specific system prompt that feeds the CSV cross-tabulations to the LLM and forces it to act as a “Fairness Expert.”
• Structured JSON Insights: Instead of returning plain text, I configured the AI to return strictly typed JSON tool calls containing the exact fairness metrics, an overall 0-100 fairness score, and concrete mitigation steps.
• Dynamic Frontend Wiring: I updated the AuditDashboard to dynamically map this live AI data into my Recharts visualizations and metric gauges, turning the UI into a fully functional, intelligent auditing tool.

My Experience with GitHub Copilot

GitHub Copilot was an absolute game-changer for pushing this project to completion, particularly when navigating the complex typing requirements between the frontend and the Supabase Edge Functions.

• Type Safety & Boilerplate: Copilot anticipated the Zod schemas and TypeScript interfaces required for my AuditResult objects, saving me hours of manual typing.
• Component Generation: When building the AuditDashboard.tsx and the MetricGauge components, Copilot suggested the repetitive Tailwind classes needed for the glassmorphism effects and conditional rendering (e.g., automatically suggesting the success/warning/destructive color mappings based on the metric status).
• Data Parsing: Copilot was incredibly helpful in suggesting the logic for processing the CSV outputs and formatting the cross-tabulations accurately before sending them off to the Edge Function payload.

It acted as a constant pair programmer, allowing me to focus on the high-level architecture and the user experience rather than getting bogged down in syntax.

Based on your Merge Magic draft , here’s a cleaner CEO-style Markdown version:

# Merge Magic: Resolving the Merge Conflicts That Shouldn’t Need a Human

I built **Merge Magic** because I got tired of resolving the same merge-conflict pattern over and over again.

Same conflict shape.  
Same “keep both” outcome.  
Same wasted time every time I rebased onto `main`.

At first, it was a small utility to remove that friction. Over a few weeks, it became something I now use daily.

Merge Magic automatically resolves merge conflicts that are clearly additive, while surfacing the ones that actually require human judgment.

It is free, bring-your-own-AI, and it never auto-commits.

You stay in control.

---

## What Merge Magic Does

Merge Magic is designed around a simple idea:

> Most merge conflicts are not real disagreements.  
> They are just two useful changes landing in the same place.

For example:

```js
<<<<<<< HEAD
export function getUser(id) {
  console.log('[users] fetch', id);
  return db.users.findById(id);
}
=======
export function getUser(id) {
  if (!id) throw new Error('id required');
  return db.users.findById(id);
}
>>>>>>> feature/validation

One branch added logging.
Another added validation.

The correct resolution is obvious: keep both.

A developer can resolve this in 30 seconds. But multiplied across every rebase, every PR, and every team member, those 30 seconds become a tax.

Merge Magic removes that tax where it can — and refuses to guess where it should not.

How It Works

Merge Magic resolves conflicts in three layers.

1. Mechanical Pre-Pass

Some conflicts can be resolved safely from text alone.

Examples include:

• Identical edits on both sides
• One-sided edits where the other side matches the base
• Clearly additive changes in different parts of the same region

These require no AI call.

They are resolved instantly because the answer is structurally obvious.

2. AI-Assisted Resolution

For conflicts that need more context, Merge Magic dispatches the conflict to whichever AI tool you already use.

Supported backends include:

• VS Code language model API
• Copilot
• Claude Code CLI
• Ollama
• Anthropic
• OpenAI
• Gemini

There is no forced subscription layer.

You bring the model. Merge Magic brings the workflow.

3. Verification Floor

Every auto-resolved file is checked against build diagnostics.

Merge Magic captures the baseline error set first, then checks the merged result.

If the resolution introduces new errors, it reverts the file back to conflict markers and shows the actual diagnostic.

Pre-existing errors do not cause false failures.

This is the safety floor.

The Line I Refused to Cross

The most important design decision was not what Merge Magic resolves.

It was what it refuses to resolve.

When two branches genuinely disagree, Merge Magic does not guess.

For example:

• Both branches rename a function differently
• One branch deletes code while another modifies it
• Both branches change the same constant to different values
• Two changes appear semantically incompatible

In those cases, Merge Magic opens a decision card with context:

This conflict is between two commits:

🔴 HEAD        a1b2c3d   perf: bigger page size, shorter session timeout
                          Alice Chen · 2 days ago

🟢 MERGE_HEAD  9b79e0a   scale: max page size, longer session for enterprise
                          Bob Kumar · 1 day ago

The goal is not to hide hard decisions.

The goal is to make the easy ones disappear and make the hard ones clearer.

Three Surfaces, One Engine

Merge Magic runs in three places.

VS Code

A VS Code extension with an auto-mode dashboard.

When git merge produces conflicts, files resolve in parallel with a live progress view.

Terminal

A CLI that can register as a global Git merge driver:

npm install -g merge-magic
mergemagic setup
echo "* merge=mergemagic" >> .gitattributes

After that, git merge and git rebase can invoke the resolver inline.

This is especially useful for recurring conflicts during rebase replay.

CI

A GitHub Action can resolve PR conflicts server-side before a human review:

- run: npm install -g merge-magic

- env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
  run: mergemagic ci --base "${{ github.base_ref }}"

The CI check posts a Markdown report to the Actions summary.

If a conflict requires a real human decision, the check fails loudly.

It does not silently pick a side.

What I Deliberately Do Not Claim

A lot of AI developer tools overclaim.

I tried hard not to.

It is not an AST merge

The mechanical pre-pass is a careful three-way line merge.

It is not tree-sitter.
It is not structural merging.
It is not a true AST-aware resolver.

That is a harder problem, and it is still on the roadmap.

Semantic warnings are heuristics

When the model says two changes may interact, that is not static analysis.

It is a heuristic.

Useful, but not authoritative.

The benchmark is not “better than Copilot”

Copilot’s smart-action resolver is not scriptable, so a clean automated head-to-head benchmark is not really possible.

Merge Magic’s benchmark reports match rate against known human resolutions on a corpus you provide.

That is useful.

It is also honest.

Why This Matters

The promise of AI in developer workflows should not be “trust the model blindly.”

It should be:

Remove the repetitive work.
Preserve human judgment where it matters.
Make the review surface clearer.

That is the philosophy behind Merge Magic.

It is not trying to replace code review.

It is trying to remove the part of conflict resolution that developers already know is mechanical.

Try It

VS Code

Search for Merge Magic in the Extensions Marketplace.

Or install it here:

Merge Magic on VS Code Marketplace

Terminal

npm install -g merge-magic
mergemagic demo

The demo runs in a temporary repository and will not touch your code.

Feedback I’m Looking For

I would especially value feedback on three things:

1. Does the verification floor catch enough?
   It catches type and lint failures, but not behavioral regressions.

2. Is the mechanical pre-pass too conservative?
   It currently defers anything ambiguous, even when an LLM might handle it well.

3. Is the CI mode too aggressive or too cautious?
   Auto-commit is opt-in, and Merge Magic refuses to push directly to main.

The most useful feedback is where it gets the resolution wrong.

Those cases are what improve the resolver, the prompt, and the pre-pass.

Merge conflicts are not going away.

But the boring ones should.

AI Metrics Decoded: The Numbers That Actually Matter in Production

Why You Need to Know This (Before Your First Production Incident)

Picture this: your team picks a 70B parameter model for a new feature. It runs great on your MacBook. You push to production. The GPU bill arrives. Your manager is not happy.

Or this: your AI API costs explode halfway through the month and nobody knows why.

These are not horror stories. They happen to real engineers — usually the ones who skipped learning the core units of measurement behind AI systems.

As a junior engineer, you’re going to face questions like:

• “Can our GPU handle this model?”
• “Why is the response so slow?”
• “How many tokens are we burning per user per day?”
• “Should we use a 7B or 70B model for this use case?”

Understanding the seven core metrics below gives you the language — and the instincts — to answer confidently.

Let’s break them down.

🧠 Category 1: Model Size — Parameters & Tokens

Parameters

What it is: The learned weights inside a neural network. Think of them as the “memory” of the model — numbers that get adjusted during training to capture patterns in data.

The unit: Just a raw count. We usually express it in:

• M = millions (e.g., BERT = 110M)
• B = billions (e.g., LLaMA 3 8B, GPT-4 ~1.8T estimated)

Why it matters to you:

Rule of thumb: 1 billion parameters ≈ 2 GB of VRAM in half-precision (fp16). Double it for full precision (fp32).

More parameters = more capable model and more expensive to run. Always.

Tokens

What it is: The unit of text that a model reads and generates. Not words — fragments.

Quick visual:

Input text:  "Learning AI is fun!"
             ↓ Tokenizer
Tokens:      ["Learn"] ["ing"] [" AI"] [" is"] [" fun"] ["!"]
Token count: 6 tokens

Why it matters to you:

• API cost is billed per token (input + output separately).
• Context window is measured in tokens — the model can only “see” so much at once.
• Speed (TPS, covered below) is measured in tokens per second.

# Quick check: how many tokens is your prompt?
# Using tiktoken (OpenAI's tokenizer, also used by many OSS models)
import tiktoken

enc = tiktoken.get_encoding("cl100k_base")
text = "Learning AI is fun!"
tokens = enc.encode(text)

print(f"Token count: {len(tokens)}")   # → 6
print(f"Tokens: {tokens}")             # → [71668, 287, 15592, 374, 2523, 0]

Quick cheat sheet:

• 1 token ≈ 0.75 English words
• 1,000 tokens ≈ 750 words ≈ ~1.5 pages
• Non-English text (Hindi, Mandarin, Arabic) uses 30–70% more tokens for the same content

⚡ Category 2: Hardware Power — FLOPS vs. TOPS

This is where a lot of junior engineers get confused. FLOPS and TOPS sound similar. They are not the same thing.

FLOPS (Floating Point Operations Per Second)

What it is: A measure of raw compute power for floating point arithmetic — the kind of math needed for training and running neural networks.

The scale:

Used for: Server-scale training and inference. When someone says “the H100 delivers 989 TFLOPS of FP16 performance”, this is what they mean.

Common GPUs you’ll actually use:

TOPS (Tera Operations Per Second)

What it is: Similar idea, but used for integer or mixed-precision operations on edge hardware and NPUs (Neural Processing Units).

The key difference:

FLOPS  →  Floating point math  →  GPUs / server chips  →  Training & inference at scale
TOPS   →  Integer / INT8 math  →  NPUs / edge chips    →  On-device inference

Real-world examples:

When do you care about TOPS? When you’re deploying a model to a phone, a laptop, or an embedded device — not a data centre. If you’re picking a chip for on-device inference, TOPS is your number.

🏋️ Category 3: Training Cost — FLOPs (Cumulative)

Yes, confusingly, FLOPs (with a capital F, no “per second”) is a different metric from FLOPS.

What it is: The total number of floating point operations performed during an entire training run. It’s a measure of compute budget, not hardware speed.

The unit: Usually expressed as:

• PetaFLOPs (10¹⁵ operations)
• Or PetaFLOP/s-days — how many days at a given FLOPS rate the training took

Real-world examples:

Why it matters to you: Directly as a junior engineer, probably not yet. But understanding it helps you reason about:

• Why training a model from scratch is prohibitively expensive
• Why fine-tuning (starting from a pre-trained model) is so much cheaper
• Why companies like Anthropic and OpenAI have massive infrastructure teams

Quick analogy: FLOPS (the hardware rate) is your car’s horsepower. FLOPs (training cost) is the total miles driven on a road trip. One is speed, one is distance.

🚀 Category 4: Speed & Latency — TTFT, TPS, TPM

These three are the metrics you’ll track the most in production. They live in your dashboards, your SLAs, and your post-mortems.

TTFT — Time To First Token

What it is: How long (in milliseconds) from sending your request to receiving the first token of the response.

Why it matters: This is what determines if your app feels fast. Even if the full response takes 10 seconds, a 200ms TTFT makes the experience feel responsive. It’s the AI equivalent of “First Contentful Paint” in web dev.

User sends prompt
        ↓
  [ ... processing ... ]   ← this duration is TTFT
        ↓
First token arrives → streaming begins → user sees output

Good TTFT benchmarks:

TPS — Tokens Per Second

What it is: How many tokens the model generates per second during the response. Also called generation speed or throughput.

Why it matters: TPS determines whether your streaming response feels smooth or painfully slow.

• A human reads at roughly 3–5 tokens per second comfortably.
• Models generating at < 10 TPS feel sluggish.
• Modern API servers target 50–150+ TPS for good UX.

What affects TPS:

• Model size (bigger = slower per request)
• Hardware (H100 >> A100 >> consumer GPU)
• Batch size (serving multiple requests simultaneously reduces per-request TPS)
• Quantization (INT4/INT8 models run faster, with a small accuracy tradeoff)

TPM — Tokens Per Minute

What it is: Your rate limit from the API provider. The maximum number of tokens your account can process per minute.

Why it matters: Hit your TPM limit and your requests start getting throttled or rejected with 429 Too Many Requests. This is a very common production issue for junior engineers on their first real deployment.

# A common mistake: not accounting for TPM in batch jobs

prompts = load_10000_prompts()   # Each ~500 tokens

for prompt in prompts:
    response = call_llm_api(prompt)   # 🚨 You'll hit TPM limit fast
    process(response)

# Better approach: add rate limiting
import time

TPM_LIMIT = 40000   # tokens per minute (check your plan)
tokens_this_minute = 0
minute_start = time.time()

for prompt in prompts:
    estimated_tokens = len(prompt.split()) * 1.3   # rough estimate

    if tokens_this_minute + estimated_tokens > TPM_LIMIT:
        sleep_time = 60 - (time.time() - minute_start)
        if sleep_time > 0:
            time.sleep(sleep_time)
        tokens_this_minute = 0
        minute_start = time.time()

    response = call_llm_api(prompt)
    tokens_this_minute += estimated_tokens
    process(response)

🔧 Senior Engineer’s Note: How It All Connects

Let me show you a real decision you’ll face: “Should we use an 8B or 70B model?”

Here’s how the metrics interact:

                    8B Model          70B Model
─────────────────────────────────────────────────
Parameters          8 billion         70 billion
VRAM Required       ~16 GB            ~140 GB
GPU Setup           1× A100 40GB      4× A100 40GB
Est. TPS            ~80–120 TPS       ~15–30 TPS
TTFT (A100)         ~150ms            ~400ms
API Cost (est.)     ~$0.15/M tokens   ~$0.90/M tokens
Quality             Good              Excellent
─────────────────────────────────────────────────

The real-world math: Say your app handles 1,000 users/day, each generating ~2,000 tokens per session.

Daily tokens = 1,000 users × 2,000 tokens = 2,000,000 tokens

8B model cost:  2M × $0.00015 = $0.30/day  → $9/month
70B model cost: 2M × $0.00090 = $1.80/day  → $54/month

That’s a 6× cost difference. For a startup, that matters.

The senior engineer’s question isn’t “which model is better?” It’s *”which model is good enough for this use case at this scale?”*

Start with the smaller model. Benchmark it against your quality requirements. Scale up only if you have to.

Quick Reference Cheat Sheet

Where to Go Next

You now have the vocabulary. Here’s how to build on it:

• Experiment with tokenizers → platform.openai.com/tokenizer
• Benchmark models on your hardware → try llama.cpp or Ollama locally
• Track TTFT and TPS in your own apps → add timing logs around your API calls from day one
• Read model cards → every major model release includes parameter count, training FLOPs, and benchmark scores. They’re not marketing fluff — they’re specs.

The engineers who understand these numbers don’t just write code. They make better architectural decisions, avoid expensive surprises, and earn trust faster.

That’s the real reason to care.

Got questions? Drop them in the comments.

Redis is often a misunderstood tool in the backend developer’s arsenal. While many view it simply as a “topic” to be covered in an hour, its role in modern system design is pivotal for building high-performance, scalable applications. This article explores what Redis is, why it is used, and how to set it up locally for development.

Understanding Redis: The In-Memory Powerhouse

At its core, Redis is an in-memory data store, often referred to as a “lightning-fast” hash map or key-value store. Unlike traditional databases like MongoDB or PostgreSQL that primarily store data on a hard disk (SSD or HDD), Redis keeps its state in the RAM (Random Access Memory).

Core Concept: The In-Memory Advantage

The fundamental difference between Redis and traditional databases (like MongoDB or PostgreSQL) is where they store data. While standard databases primarily use disk storage (SSDs/HDDs), Redis keeps its state in RAM (Random Access Memory).

Because RAM access is significantly faster than mechanical or electronic disk reads, Redis is often described as “lightning fast”.

Architecture: The Caching Layer

In a typical application, Redis acts as an intermediary between the backend application and the primary database. This setup creates two primary scenarios:

1. Cache Hit: The backend finds the required data in Redis and returns it immediately to the user, bypassing the slower database.
2. Cache Miss: If the data isn’t in Redis, the backend queries the primary database. It then stores a copy of this “hot record” in Redis for future requests before responding to the user.

This architecture dramatically reduces “read pressure” on the primary database, which should remain the “Source of Truth” for permanent records.

Key Features and Data Management

• Persistence: Contrary to the myth that in-memory data is always lost on restart, Redis offers persistence features. It can load data from saved files back into memory upon a server reboot.
• Key-Value Pairs: Redis stores data in simple pairs. Developers are encouraged to use human-readable, colon-separated keys (for example, user:session:123 or product:all) to avoid collisions and simplify debugging.
• TTL (Time to Live): This is one of Redis’s most powerful features. You can set an expiration time on a key (for example, 90 seconds). Once the time expires, Redis automatically deletes the record, ensuring the memory remains uncluttered.

Advanced Use Cases

Beyond simple data caching, Redis is used for:

• Session Management: Storing user login states (Active/Inactive) across multiple distributed servers.
• OTP Management: Holding temporary One-Time Passwords for a few minutes, they are valid.
• Rate Limiting: Tracking IP addresses or user IDs to prevent abuse (for example, blocking a user for 10 minutes after too many failed login attempts).
• Job Queues: Maintaining lists of background tasks. “Workers” (secondary backend applications) pull jobs from Redis to process time-consuming tasks like sending emails in batches.
• Shared Counters: Tracking live metrics like page views or “likes” across various application instances.

Strategic Local Setup

For development, the sources recommend using Docker and Docker Compose to spin up a local environment. A standard configuration involves:

• Redis Image: Using redis:7-alpine for a lightweight footprint.
• Port Mapping: Binding the default Redis port 6379 to the host machine.
• Persistence Command: Running the server with --appendonly yes to ensure data is written to a log.

In a Node.js environment, the ioredis library is the industry-standard package for communication. A basic connection is established by creating a new Redis client using the local URL: redis://localhost:6379. Developers can test the connection using the PING command, which should return a PONG response from the server.

When to Use Redis

Redis is not a solution for every problem. Use it if your application needs to:

• Remove read pressure from the primary DB.
• Manage rapidly expiring temporary data.
• Handle background job queues or shared counters.

However, it is not a replacement for a primary database.

When NOT to use Redis

Redis is not a “magic bullet”. It should not be used if you don’t have a clear bottleneck or if your data doesn’t fit the patterns described above. If you have a write-heavy application where data doesn’t need to be read frequently, or if you are trying to use it as a primary database for complex relational data, Redis may not be the right solution.