Someone left a comment on my LinkedIn post: “These agents are good for small projects, not big complex ones.”

Fair. I’d just shown them building a cookie clicker. So I decided to prove them wrong in the most direct way I could think of. I’d build something genuinely complex. Something I had zero experience with. Something that would fail loudly if the agents couldn’t handle it.

I’d never built a game. Not a simple one. Not ever.

I picked a cybersecurity tower defense game with a server-authoritative WebSocket engine, a Factorio-inspired production chain mechanic, real-time attack waves, and a multi-service deployment across Vercel and Fly.io. Then I typed one command, went to make dinner, and came back to a deployed, playable game PipeWar.

This is how the agents actually work — the architecture, the prompt structure, the safety mechanisms, the memory system — and how you can build the same thing yourself.

The real problem with single-AI coding

When you ask one AI to architect, build, test, and deploy in a single conversation, it context-switches constantly. It forgets the auth model it defined 20 minutes ago. It skips tests because you didn’t explicitly ask. It makes UX decisions a designer would reject.

The problem isn’t intelligence. The problem is scope.

Real engineering teams don’t work this way. An architect designs the system. A designer specs the screens. A developer builds from those specs. QA tries to break it. Security audits before launch. Every person has a defined role, defined inputs, and a clean handoff to the next.

I built that structure as AI agents — Navox Agents. 8 specialists for Claude Code, each scoped to one job, each running on its own context window, orchestrated to work together the way a real team does.

The architecture: orchestration, handshakes, and three types of human control

Most multi-agent write-ups show you a diagram. What they skip are the mechanisms that make it actually work. There are three: orchestration, handshakes, and human-in-the-loop controls. Each is a different thing.

Orchestration is how the team is managed. The Architect is not just a design agent — it’s the active project manager for the entire build. When you run /agency-run, the Architect reads your prompt, decides which agents are needed, determines the sequence, identifies what runs in parallel, and produces a RECOMMENDED TEAM block before a single line of code is written:

RECOMMENDED TEAM:
1. Architect — DESIGN — system design before anyone builds
2. UX — FLOW → SPEC — map every screen and state
3. Security — DESIGN-REVIEW — auth model audit before build starts

PARALLEL AGENTS (can run simultaneously):
• UX + Security - both depend only on the Architect's output

BLOCKERS TO RESOLVE FIRST:
• Auth strategy undefined - need to know: JWT or session-based?

No agent decides on its own when to start. No agent picks up your raw prompt and starts guessing. The Architect maps the team, flags blockers, and briefs each agent specifically.

Handshakes are how knowledge moves between agents. When the Architect finishes, it doesn’t pass a doc and move on. It produces structured handoff notes — a prepared brief for each downstream agent containing exactly what that agent needs to start its specific job:

HANDOFF NOTES:
→ UI/UX Agent: Design login, signup, password reset flows.
   Auth is JWT. No OAuth in v1. Show token expiry state.
→ Full Stack Agent: Implement JWT auth per the security model.
   Access token: 15 min. Refresh: stored in Redis, rotated on use.
→ Security Agent: Auth model uses short-lived JWTs + Redis refresh.
   Threat surface: login endpoint, token refresh, session fixation.
→ DevOps Agent: Deploy to Vercel (frontend) + Cloudflare Workers (backend).

The UX agent doesn’t read the full system design doc. It receives the UX brief extracted from it. Security receives a different brief from the same source. Same document, different handshakes. This is what keeps agents from contradicting each other — they don’t share a context window and they don’t read each other’s work directly.

Human-in-the-loop controls come in three distinct types, and understanding the difference matters:

GATE — a hard stop before downstream agents can proceed. The Architect produces its design. Nothing moves until you type APPROVED. Agents that hit a gate output:

⚠️ HITL REQUIRED — GATE
Please review and respond: APPROVED | REVISION NEEDED: [notes]

CHECKPOINT — a review point between stages. Lower stakes. You scan the output and respond CONTINUE or FEEDBACK: [notes]. The Local Review agent runs here — it starts your app locally, opens the browser, takes a screenshot, and waits for you to type LGTM, FEEDBACK: [what to change], or STOP. If you say FEEDBACK, it loops back to Full Stack with your notes. If you say STOP, it kills the server and exits immediately.

ESCALATION — the agent self-pauses when it hits something it cannot or should not decide alone. Two valid approaches with a business-level tradeoff. A destructive action like dropping a table. Anything that contradicts the Architect's design. The agent stops and outputs exactly what decision you need to make before it continues.

On top of all three, there’s a dangerous command interception layer. Commands matching rm -rf, drop, truncate, --force, production, or deploy surface for human approval before execution — every time, without exception.

How to build an agent: the actual prompt structure

Each agent is a single markdown file. No code. No dependencies. No platform. Just a system prompt that Claude Code loads from .claude/agents/.

Here’s the skeleton every agent in the team is built on:

---
name: _agentname
description: One sentence. What this agent does and when Claude
             should load it. Include trigger keywords.
tools: Read, Write, Edit, Bash, Glob, Grep
model: claude-sonnet-4-6
---

## Identity
You are a [role] specialist with [X] years shipping [domain].
You think in [framing]. You are [position in team].

## Role in the Team
You own [specific slice]. You never [what this agent must not do].
You receive from: [upstream agent] — [what you get].
You hand off to: [downstream agent] — [what you produce].

## Modes

### [MODE: PLAN]
Entry point when the user isn't sure what they need.
Deliver: situation assessment + recommended next mode.

### [MODE: PRIMARY]
Full execution. Deliver: [specific artifacts].
Never omit: [non-negotiables].

### [MODE: VERIFY]
Check the work. Deliver: [pass/fail findings + fixes].

## Hard constraints
- Never [action that belongs to another agent]
- Always [non-negotiable behavior]
- Never proceed past a GATE without explicit human approval —
  output ⚠️ HITL REQUIRED and state exactly what's needed

## Project memory
At the start of every run:
  cat .claude/memory/agentname.md 2>/dev/null || echo "No memory yet"

After completing your task, update your memory with decisions made,
patterns observed, and what to remember for next time.

Two things worth pointing out. First: model routing. The Architect and Security agents run on claude-opus-4-6 — the hardest thinking jobs get the most capable model. Every other agent runs on claude-sonnet-4-6. This is intentional and it matters for cost at scale.

Second: the memory system. Every agent reads and writes its own memory file at .claude/memory/agentname.md. There's also a shared .claude/project-memory.md that the orchestrator updates after every run. The agents remember stack decisions, auth patterns, what failed last time, and why certain choices were made — across sessions. For a solo builder this is significant. The team never starts from zero.

The modes: how you actually talk to the agents

Every agent supports PLAN as a safe entry point. From there, each has specific modes for specific workflows. You can run the full chain or reach into any single agent directly.

The pattern is consistent across all agents: a PLAN mode that scopes the work, execution modes that do it, and verification modes that check the result. Security's LAUNCH-AUDIT is a hard gate — nothing deploys without a pass/fail verdict from it.

# Run the whole team end to end
/navox-agents:agency-run Build a task manager with user auth and Supabase

# Reach into one agent for a specific job
/navox-agents:architect DIAGNOSE
/navox-agents:security LAUNCH-AUDIT
/navox-agents:fullstack DEBUG — here's the error: [paste]
/navox-agents:qa REGRESSION

The stress test: PipeWar

A cookie clicker is a proof of concept. I needed something that would genuinely break an under-engineered system — multiple services, a real-time game engine, WebSocket communication, production deployment across two platforms, and enough complexity that any gap in the agent coordination would show up immediately.

PipeWar is a cybersecurity tower defense game. You build a factory on a 20×20 grid — miners extract ore, smelters produce plates, assemblers combine inputs into circuits. Connect everything with directional conveyor belts. Win condition: produce 20 Advanced Circuits while keeping uptime above 95%.

Iron Ore ──→ Smelter ──→ Iron Plate ──────────────────────┐
                                                           ├──→ Assembler ──→ Advanced Circuit
Copper Ore ──→ Smelter ──→ Copper Plate ──→ Copper Wire ───┘

The twist: once your factory generates enough traffic, attack waves spawn from the east edge. The attackers are real threat types — DDoS bots swarm in numbers, SQL injection probes seek undefended paths, Zero-Day Exploits arrive every fifth wave as 300 HP bosses. Your defenses are real security tools — Rate Limiters, WAFs, Auth Middleware, Circuit Breakers — each with distinct mechanics.

The Architect chose the stack: Next.js 15 with TypeScript and HTML Canvas on the frontend, FastAPI running a 20 tick/second server-authoritative game engine on the backend, SQLite via aiosqlite, WebSocket for real-time state sync, deployed across Vercel and Fly.io. I didn’t pick any of it. I approved it.

Then I ran one command:

/navox-agents:agency-run Build PipeWar — a Factorio-inspired tower defense game
themed around cybersecurity. 20x20 grid, production chains, attack waves,
WebSocket real-time engine. Deploy to Vercel + Fly.io.

What the build actually looked like

The orchestrator paused twice while I was cooking. Once to confirm login to Fly.io — the DevOps agent intercepted the deploy command and surfaced it before executing. Once at the Local Review checkpoint — the agent started the app, opened the browser, took a screenshot, and waited. I walked over, typed LGTM, went back to the kitchen.

Three hours later: deployed, playable, tests passing.

After launch I found 8 production bugs. The production chain wasn’t producing circuits. The circuit breaker defense wasn’t activating. Belt direction glyphs showed question marks. I ran:

/navox-agents:architect DIAGNOSE

The Architect scanned every file in the codebase and returned all 8 bugs with exact files, exact lines, and exact fixes. I confirmed. Full Stack fixed all 8 and wrote 9 new unit tests. 65 tests passing. DevOps redeployed.

Something unexpected happened during that parallel run. Claude Code pulled in an agent from a completely different plugin I had installed — without me asking. It saw that all my agents were busy working in parallel and nobody was reviewing the code being written, so it brought in an outside agent to fill the gap. Like a project manager who notices the team is at capacity and calls in a freelance reviewer. I didn’t orchestrate that. Claude Code did. That moment told me something fundamental about how multi-agent systems actually work at scale — the orchestration layer isn’t just following your instructions. It’s evaluating the situation.

The context isolation insight: after 8 hours of continuous agent work, my main Claude Code session had used 26% of its context window. Each agent runs in its own isolated context — its own token budget, its own reasoning space. They can’t contaminate each other’s state. This is the architecture decision most people miss when building multi-agent systems. Isolation isn’t a limitation. It’s what makes long-running, parallel work possible without the whole system degrading.

Install and run it yourself

/plugin marketplace add https://github.com/navox-labs/agents
/plugin install navox-agents
/reload-plugins

If you hit an SSH error first time:

git config --global url."https://github.com/".insteadOf "git@github.com:"

For a new project, copy a stack template first — the agents read it automatically and never ask you to re-explain your setup:

cp ~/.claude/templates/nextjs.CLAUDE.md ./CLAUDE.md          # Next.js + Vercel
cp ~/.claude/templates/python-fastapi.CLAUDE.md ./CLAUDE.md  # FastAPI + Fly.io
cp ~/.claude/templates/node-api.CLAUDE.md ./CLAUDE.md        # Express + Railway

Then start with the Architect:

/navox-agents:architect DIAGNOSE

It reads your request, maps the team, flags blockers, and tells you exactly which agents to run and in what order. From there, either follow its recommendations manually or hand everything to the orchestrator:

/navox-agents:agency-run Build a [describe what you want]

The agents are free, MIT licensed, and your code never leaves your machine. Everything is markdown — fork it, modify the prompts, build your own specialist. The source is at github.com/navox-labs/agents. PipeWar — built, debugged, and deployed entirely by the agent team — is playable here. The code is public if you want to see exactly what 8 agents produce in three hours.

If 2026 is the year of the AI team, the interesting question isn’t whether agents can build complex software. PipeWar already answers that. The question is how you design the team.

The agents are free, MIT licensed, open source: github.com/navox-labs/agents. Your code never leaves your machine.

Built by Navox Labs

There’s a conversation I keep having with people in the middle of a job search. They’ve been applying for weeks — sometimes months. They have a solid resume. They’re not being unreasonable about salary. They’re just… not getting anywhere. And when I ask them about their network, they say some version of the same thing:

“I don’t really have one.”

What they mean, usually, is that they don’t have a close friend at a big company who can hand their resume directly to a hiring manager. They mean their inner circle isn’t powerful enough, well-placed enough, or well-connected enough to crack open a door.

They’re right about that. But they’re wrong about what it means.

Because the research is clear — and it’s genuinely counterintuitive — that the people most likely to get you your next job aren’t your closest contacts. They’re the ones you barely know.

Why Your Best Friend Can’t Help You as Much as You Think

In 1973, Stanford sociologist Mark Granovetter published a paper that has since become one of the most cited studies in social science. He’d been interviewing professionals about how they found their jobs, expecting to find that close relationships — friends, family, tight colleagues — were the primary pipeline.

What he found instead was the opposite. Most people got their jobs through contacts they saw only occasionally, or rarely at all. Acquaintances. Former colleagues they hadn’t spoken to in years. Conference contacts. People hovering at the outer edges of their social world.

He called this the strength of weak ties. And the logic, once you hear it, makes complete sense.

Your close friends live inside the same social bubble you do. They know the same people, move in the same circles, hear about the same opportunities. They want to help you — but they mostly have access to the same information you already have.

Your weak ties, by contrast, live in different bubbles. A former coworker who moved to a different industry. A college acquaintance who relocated to another city and built a new career. A professor you emailed once for a recommendation. These people exist at the edges of different worlds — and those worlds contain opportunities that your immediate network has never heard of.

“Your weak ties connect you to networks that are outside of your own circle. They give you information and ideas that you otherwise would not have gotten.” — Mark Granovetter

The Experiment That Proved It

For decades, Granovetter’s theory was influential but technically unproven at scale. Correlation isn’t causation. Maybe people with better careers just happened to maintain wider networks. Maybe it was the other way around.

Then, in 2022, a team of researchers from Stanford, MIT, and Harvard published a study in Science that changed that. They had access to something extraordinary: LinkedIn’s “People You May Know” algorithm, and five years of randomized experiments affecting over 20 million users.

LinkedIn had been quietly varying its recommendation algorithm — some users got more suggestions for people they were already close to, others got more suggestions for distant acquaintances. The researchers then tracked what happened to those users’ job outcomes across a period in which 600,000 new positions were created.

The results confirmed that weaker ties raised the possibility of job mobility the most. But the study also added a crucial refinement: it’s not that the weakest possible ties are best. Mid-tier friends are more helpful than either one’s closest friends or near-strangers — those with whom you share roughly 10 connections and seldom interact.

Not strangers. Not best friends. The people somewhere in the middle — the ones you know just enough to reach out to.

The Numbers Most Job Seekers Don’t Know

Here’s what makes this more than an interesting academic concept. The referral economy — the informal network through which jobs are actually filled — operates at a completely different scale than the job board economy most people are competing in.

Referrals are four times more likely to be offered a job than candidates who apply through traditional job boards. Employee referrals account for 30 to 50 percent of all new hires. Yet referred candidates make up only about 7 percent of applicants.

One referral is worth approximately 40 cold applications.

Read that again. One warm introduction — from someone who barely knows you well enough to mention your name to a colleague — carries the same weight as forty resumes fired into the void.

Most people spend their job search almost entirely in that void. They optimize their resume, set up job alerts, apply to dozens of listings per week, and wonder why nothing is happening. The problem isn’t their resume. It’s that they’re playing a game where the odds are structurally terrible, when there’s a different game — with dramatically better odds — happening just adjacent to it.

The reason they’re not playing that game isn’t lack of networking ability. It’s that they’ve been told their network isn’t good enough to matter.

You Already Have the Network. You Just Haven’t Mapped It.

This is the part that surprises most people.

You don’t need a powerful inner circle to access the referral economy. You need to understand the geometry of the network you already have.

Consider what it means to have 150 first-degree connections on LinkedIn — a fairly modest number for most working professionals. Each of those 150 people has their own network. At an average of a few hundred connections each, your second-degree network — people you’re one introduction away from — likely numbers in the tens of thousands. Your third-degree network reaches into the hundreds of thousands.

Somewhere in that graph: people who work at every company you’re interested in. People who’ve made the exact career transition you’re trying to make. People who hire for the exact role you want.

The network isn’t missing. The map is.

I know this because I ran my own data. When I mapped my LinkedIn connections through this framework, my network had two structural bridges — connections whose removal would disconnect my professional graph from entire industry clusters I had almost no other presence in. When I saw who they were, I almost laughed. Neither was a senior executive or anyone I’d have thought to contact if I were job searching. One was a former classmate I’d spoken to twice since graduation. The other was someone from a conference three years ago — we’d shared a table at lunch, connected on LinkedIn that afternoon, and never exchanged another word. They were the last two people on my mental list. They were also, structurally, the most important people in my network.

The practical implication is that the job search strategy most likely to work isn’t volume — it’s excavation. Mapping what’s already there. Here’s what that looks like concretely:

Start with your alumni network. LinkedIn’s Alumni tool (free to all users) lets you filter every graduate of your institution by company, role, location, and graduation year. A shared university is a genuine connection — it gives you something real to reference when you reach out, and acceptance rates for outreach with genuine shared context are meaningfully higher than cold messages.

Contact people in your field at target companies, but not to ask for jobs. Ask for fifteen minutes to hear about their career path or get a perspective on the industry. This sounds small, but it’s how the actual labor market works. Most people are more willing to share their experience than to hand you a job, and informational conversations have a habit of turning into introductions.

At the end of every conversation, ask one specific question: Is there anyone else in this space you think I’d benefit from talking to? Each time you ask and receive a name, your network expands by at least one node. Over six to eight weeks of consistent outreach, that compounding effect reaches people you never could have found through a job board.

Watch for hiring signals. Funding announcements, executive appointments, and product launches are public signals that hiring is being actively planned — often weeks or months before a formal job posting appears. A warm second-degree contact at a company that just announced a Series B is extraordinarily valuable. Reach out within 48 hours of any such announcement, when the organization is actively thinking outward.

The Hardest Part Isn’t What You Think

When I’ve walked people through this framework, the most common objection isn’t “I don’t have the connections.” It’s “I feel weird reaching out to people I haven’t spoken to in years.”

That feeling is real, and it deserves to be acknowledged. Cold-to-warm outreach — contacting someone you only loosely know — feels presumptuous in a way that sending an application never does. Applications feel like playing by the rules. Reaching out to a former colleague from three jobs ago feels like asking for something.

But the research suggests that perception is inverted. Reaching out to a near-stranger on LinkedIn to ask for a referral has roughly the same success rate as being one of five hundred resumes in an ATS queue. Reaching out to someone with a genuine shared context — a former employer, a mutual colleague, an alumni network — is a fundamentally different interaction, and people respond to it differently than you’d expect.

The other thing worth knowing: most people like being helpful. They like being asked for their perspective. They like making introductions that work out. The ask that feels awkward to you rarely feels that way to the person receiving it, as long as it’s specific, personal, and not leading with “can you get me a job.”

Lead with curiosity. Lead with shared context. The referral, if it comes, follows from a relationship — not a request.

The job market is genuinely hard right now. The math on cold applications is brutal, and that’s not a reflection of anyone’s talent or effort. But the network most people believe they don’t have is, in almost every case, there — partially mapped on publicly accessible platforms, reachable through two or three degrees of connection, full of people who took the same paths you’re trying to take.

The question is whether you’re willing to stop thinking of networking as something powerful people do, and start thinking of it as something the data shows actually works — for anyone willing to read the map.

Your next job is probably sitting in your second-degree network right now. Someone who knows someone you know, working somewhere you’d want to be. They don’t know you’re looking.

Tell them.

If you’d rather skip the manual mapping, I built a tool called Navox Network that takes your LinkedIn data export and does the graph analysis for you — surfacing which of your existing connections are most worth reaching out to based on exactly the research described here. No signup, and your data never leaves your browser. Mapping your network and seeing who to reach out to is free; an optional tier ($149 once) drafts the messages and tracks your outreach. The original open-source version that kicked this off — the network-science engine — is on GitHub if you want to see how the scoring works; a star ⭐️ means a lot.

New research reveals how AI screening, ghost jobs, and algorithmic bias created a “doom loop” that makes job searching statistically futile — and what you can do about it.

🔬 Data-driven investigation based on 48 academic sources

If you’ve applied to hundreds of jobs and heard nothing back, you’re not alone — and it’s not your fault.

Something fundamental broke in 2024, and the numbers tell a shocking story:

• Up to 83% of employers are projected to use AI to screen resumes (often rejecting you in under 10 seconds)¹
• 27.4% of online job postings are completely fake — “ghost jobs” with no intention to hire²
• Job seekers now need 400–750 applications to land a single offer³
• Success rates collapsed from 5% a decade ago to just 0.1–2% today⁴

This isn’t a hiring slowdown caused by the economy.

It’s a systemic collapse caused by artificial intelligence, algorithmic bias, and corporate deception — creating what industry leaders now call the “doom loop” that’s making everyone miserable.⁵

If you’re a job seeker, recruiter, or policymaker trying to understand why the job market feels impossible right now, this investigation will give you the data-driven answers you need.

1. Why This Matters (Even If You’re “Highly Qualified”)

The old hiring equation is dead.

For decades, we were told success followed a simple formula:

Skills + Experience + Effort = Opportunity

But today, that equation is obsolete.

Here’s what actually happens now:

Today, your resume is often rejected in under 10 seconds — not by a human, but by an opaque AI system trained on historically biased data.⁶

According to recent research from the University of Washington, AI hiring tools favor white-associated names 85.1% of the time in direct comparisons with Black candidates.⁷ In their comprehensive study analyzing 550 real-world resumes across three state-of-the-art language models, Black male candidates never ranked higher than white male candidates — not once, in any trial.

Even worse?

Many of the jobs you’re applying to were never real to begin with.

📊 The Key Statistics You Need to Know

DATA SOURCES:

• Society for Human Resource Management (SHRM) 2025 Survey
• Greenhouse Hiring Platform Internal Data (70,000+ companies)
• University of Washington Algorithmic Bias Study
• ResumeUp.AI LinkedIn Analysis (7.18 million postings)
• Bureau of Labor Statistics JOLTS Data

2. The Shocking Numbers Behind the Breakdown

Let’s talk facts — not vibes.

📊 83%

of employers use AI for screening

AI usage in hiring skyrocketed from just 12% of employers in 2020 to 48% in early 2025, with projections reaching 83% by year-end.¹ The adoption happened faster than regulators could respond.

👻 27.4%

of job listings are ghost jobs

Analysis of 7.18 million LinkedIn postings reveals more than 1 in 4 jobs advertised online don’t actually exist.² Greenhouse, a major hiring platform serving 70,000+ companies, reports that in any given quarter, **70% of their clients post at least one ghost job.**⁵

📄 400–750

applications per offer

With an average 8.3% chance of landing an interview from one application, and typical interview-to-offer ratios, candidates now need hundreds of applications to secure a single job.³

🎯 0.1–2%

online success rate

Cold online applications have a success rate that has collapsed by up to 95% in the past decade — from approximately 5% to as low as 0.1% today.⁴

Then vs. Now: A Decade of Decline

This isn’t inefficiency.

It’s structural failure.

3. The “Doom Loop” Nobody Warned You About

In 2024, Greenhouse CEO Jon Stross coined a term that perfectly captures what’s happening: the “doom loop.”

It works like this:

1. Job seekers use AI to apply to hundreds of jobs faster
2. Employers receive 2–6x more applications than they can process
3. Companies deploy harsher AI filters to manage the volume
4. Algorithms mass-reject candidates within seconds
5. Desperate applicants apply to even more jobs — including ghost postings
6. The cycle intensifies

The result?

A self-reinforcing AI-powered rejection machine that benefits no one — not candidates, not recruiters, not companies.

“AI has infiltrated hiring — from applicants using the tool to apply to hundreds of jobs and employees automating the process in response — creating a doom loop making everyone miserable.” — Jon Stross, CEO of Greenhouse (hiring platform serving 70,000+ companies)⁵

Internal Greenhouse data shows recruiter workload increased 26% in a single quarter due to AI-enabled mass applications.⁵ Meanwhile, 20% of companies now receive thousands of applications for individual roles — making human review impossible.¹

The promise was efficiency.

The reality is chaos.

4. Why AI Didn’t Make Hiring Better (It Made It Worse)

AI was sold as a solution to bias, cost, and inefficiency.

It delivered the opposite.

4.1 The Bias Problem: AI Inherited Our Worst Habits

When Amazon built an internal AI recruiting tool in 2014, they discovered it was penalizing resumes that contained the word “women” (as in “women’s chess club”) and systematically downgrading graduates of all-women’s colleges.⁸

They scrapped it. But thousands of other companies deployed similar systems without such scrutiny.

The bias isn’t limited to gender:

Racial Bias:

• Wilson et al.’s University of Washington study found AI systems favor white-associated names 85.1% of the time⁷
• Black male candidates never ranked higher than white candidates in direct comparisons (0% preference rate)
• The bias persisted across different job types and qualification levels

Age Discrimination:

• The first EEOC settlement involving AI hiring resulted in a $365,000 penalty⁹
• The company’s AI automatically rejected female applicants over 55 and male applicants over 60
• Over 200 qualified applicants were screened out based solely on age

Gender Bias:

• Female-associated names were favored only 11% of the time compared to male names⁷
• Research shows that even awareness of algorithmic gender bias significantly deters women from applying, including the most qualified candidates¹⁰

In Mobley v. Workday (2023), a class action lawsuit alleges Workday’s AI screening tools systematically discriminated based on race, age, and disability.¹¹ A Black man over 40 applied to over 100 positions through companies using Workday’s system — every single application was rejected, often within hours.

The case could potentially cover millions of job seekers affected by the same system.¹²

4.2 The Efficiency Myth: Costs Are Up, Not Down

The 2025 SHRM Benchmarking Survey found something shocking:

**Average cost-per-hire and time-to-hire have both increased during the period of generative AI adoption.**¹

Before Mass AI Adoption → After AI Adoption
    Time-to-hire: increasing → Average: 42 days (2024)
    Cost-per-hire: increasing throughout AI adoption period
    
Source: SHRM 2025 Benchmarking Survey

Why?

1. Application Volume Overload: AI-enabled mass applications increase volume 2–6x, overwhelming even AI systems
2. False Negative Rates: Biased algorithms reject qualified candidates, forcing longer searches
3. Candidate Withdrawal: 38% of job seekers would reject offers from AI-heavy recruiting processes⁵
4. Quality Issues: Screening for keyword matches rather than actual qualifications reduces hire quality

AI didn’t solve the problem.

It became the problem.

4.3 The Trust Collapse

72% of job seekers report negative mental health impacts from long hiring processes and poor employer communication.¹³

79% of actively searching U.S. workers experience heightened anxiety during their job hunt.⁵

Only 26% of applicants trust AI to evaluate them fairly.⁵

38% would reject job offers from companies with AI-heavy recruiting processes — higher among those most familiar with how AI works.⁵

This is no longer just a career issue.

It’s a public health issue.

Research on AI-induced technostress shows prolonged exposure to AI-driven work environments correlates with:

• Feelings of uncertainty and lack of control
• Cognitive overload from continuous AI interaction
• Anxiety and depression symptoms
• Emotional exhaustion from repeated rejection¹⁴

When tens of millions engage in job searches annually, and most experience these stressors intensely, the aggregate mental health impact is substantial.

5. Ghost Jobs: The Quiet Scam Distorting the Economy

While AI bias gets headlines, there’s a quieter scandal destroying trust in the job market:

Ghost jobs.

These are job postings for positions that don’t exist — and they’re everywhere.

The Scale of the Problem

Multiple independent sources confirm alarming numbers:

• LinkedIn Analysis: 27.4% of all U.S. job listings are likely ghost jobs²
• Greenhouse Data: 18–22% of job postings qualify as ghost jobs⁵
• Employer Surveys:
• 40% of companies posted fake jobs in the past year¹⁵
• 30% currently have active ghost job listings¹⁵
• Nearly 1 in 3 employers admit posting with no hiring intention¹⁶
• 81% of recruiters have posted ghost jobs¹⁷

Industry rates vary:

• Corporate services: 31% ghost job rate
• Tech, publishing, software: 40% of companies posted fake positions¹⁸
• 79% of these listings remained active months later¹⁸

Why Companies Post Ghost Jobs

Research identifies several motivations:¹⁹

1. Investor Signaling (Growth Optics) Companies post jobs to project growth to investors, especially during earnings seasons. Appcast found 24% of recruiters were explicitly asked to keep postings live “for visibility” rather than actual hiring.²⁰

2. Talent Pipeline Building 50% of hiring managers post roles to maintain a warm talent pool “at the ready” for future hiring.¹⁶ They collect and store resume data for potential future use.

3. Employee Retention Tool 67% of companies use ghost jobs to make current employees feel replaceable, suppressing requests for raises or improved conditions.¹⁵

4. Market Research Firms analyze submitted resumes and salary expectations to benchmark their workforce and understand competitive positioning.

5. Internal Political Requirements HR departments maintain postings to meet internal metrics or appear busy, even when positions aren’t approved.

🚨 Why This Matters to You

If 27.4% of postings are fake, and you apply to 400 jobs:

• ~110 applications go to NON-EXISTENT positions
• At 45 min per application = 82.5 HOURS WASTED
• That’s TWO FULL WORK WEEKS applying to fake jobs

Total job seeker time wasted on ghost jobs annually:

27 Billion Hours

That’s more time than it took to build the Great Pyramid — wasted on applications that were never meant to be filled.

The Economic Damage

Ghost jobs don’t just waste individual time — they distort the entire labor market:

Labor Market Data Corruption: Ghost jobs inflate the Bureau of Labor Statistics’ Job Openings and Labor Turnover Survey (JOLTS) figures, which policymakers use to assess labor market health.²¹ In July 2025, reported openings of 7.18 million include an estimated 1.3–1.6 million ghost jobs (18–22% rate).²²

This affects:

• Federal Reserve interest rate decisions (based on perceived labor market tightness)
• Unemployment insurance policy
• Workforce development funding allocations
• Economic forecasting models

Hiring Inefficiency: Companies with poor candidate experience (including ghost jobs) pay 10% more per hire on average.²² For a company making 30 hires at $100,000 per role, that’s $300,000 in excess costs.

Market Function Collapse: The hires-per-posting ratio has halved from 8:10 in 2019 to 4:10 in 2024,²³ indicating declining market efficiency. This mirrors classic economic failures where buyers can’t distinguish real value from fake supply.²⁴

6. Who Is Hurt the Most

AI recruitment doesn’t fail evenly.

It amplifies inequality.

AI Discrimination by the Numbers

Race:

• White-associated names: Favored 85.1% of the time⁷
• Black male candidates: 0% preference rate in direct comparisons⁷
• Result: Black job seekers may need 2–3x more applications to overcome systematic screening penalties

Gender:

• Female-associated names: Favored only 11% of the time⁷
• Amazon’s AI: Penalized the word “women” on resumes⁸
• Result: Women face systematic algorithmic disadvantage before human review

Age:

• First EEOC AI settlement: $365,000 penalty⁹
• Cause: Auto-rejected applicants over 55 (women) and 60 (men)
• Result: Age discrimination automated at scale

Network Access:

• One referral equals approximately 40 cold applications in effectiveness²⁵
• Groups with less professional network access hit hardest
• First-gen college students, immigrants, career switchers disadvantaged

The Compounding Effect

AI didn’t remove bias.

It industrialized it.

Workers at intersections of multiple marginalized identities — Black women over 50, for example — face compounded disadvantages that single-axis analysis fails to capture.²⁶

California became the first state to recognize intersectionality as a protected category in September 2024,²⁶ acknowledging that discrimination based on combinations of characteristics cannot be reduced to evaluating race or gender alone.

Yet most AI systems aren’t designed to detect or prevent intersectional bias.

It amplifies inequality:

• Older workers face automated age discrimination
• Women and minority candidates are disproportionately filtered out
• Career switchers and immigrants lack referral networks
• One referral still equals 40 cold applications — but not everyone has networks

AI didn’t remove bias.

It industrialized it.

7. What You’ll Gain by Reading This Research

This isn’t just about rejecting AI.

It’s about governing it before it governs us.

Whether you’re a job seeker, recruiter, policymaker, or technologist building AI systems, this comprehensive synthesis gives you:

✅ A data-driven explanation of why hiring feels broken (not anecdotes — hard numbers you can cite)

✅ Legal, economic, and technical insights in one place (peer-reviewed research, court cases, industry data)

✅ A framework to understand why effort no longer maps to outcomes in job searching

✅ Clear policy and system-design solutions for what comes next (not just complaints — actionable fixes)

This isn’t about rejecting AI.

It’s about governing it before it governs us.

📚 About the Research

This investigation synthesizes:

• 48 peer-reviewed studies and academic papers
• Legal cases including the first EEOC AI hiring settlement ($365,000) and Mobley v. Workday class action
• Government reports from Congressional Research Service and Bureau of Labor Statistics
• Industry data from SHRM, Greenhouse, LinkedIn Economic Graph
• Labor market statistics published 2019–2025

No original survey data was collected. This is a comprehensive synthesis of existing research across computer science, law, economics, and organizational behavior — identifying systemic patterns not visible within individual disciplines.

What Comes Next?

Researching this crisis convinced me that the problem isn’t candidates — it’s the system. Resumes weren’t built for this era. AI screening tools optimize for filtering, not understanding. So I started building something different.

Navox (navox.tech) is an AI-powered profile card that lets recruiters actually have a conversation with a candidate’s experience — instead of scanning a PDF for 6 seconds. It’s early. But it’s live. And every data point in this article is part of why it exists.

If you want to see what it looks like: navox.tech/card/nahrin — ask it anything.

8. The Bottom Line: What Happens Next

The Question We Must Answer

When 99% of Fortune 500 companies¹² rely on AI to gatekeep economic opportunity, we face a choice:

Who is accountable when algorithms decide who gets to work?

The AI recruitment crisis is not inevitable.

But ignoring it is a choice — with consequences.

What You Can Do Now

📌 If you’re a job seeker:

1. Focus on referrals and networking (still 40x more effective than cold applications)²⁵
2. Use keywords from job descriptions (AI scans for exact matches)
3. Apply to companies with verified postings (LinkedIn “verified” badge, direct company sites)
4. Report suspected ghost jobs to help clean up the market
5. Document your experience (contribute to growing awareness and pressure for change)

📌 If you’re a recruiter or employer:

1. Audit your AI tools for bias (required in NYC, recommended everywhere)²⁷
2. Maintain human oversight of automated rejections (70% currently don’t)¹
3. Remove ghost jobs immediately when positions are filled
4. Disclose AI use to candidates (transparency builds trust)
5. Track demographic outcomes (measure for disparate impact)

📌 If you’re a policymaker:

1. Require bias audits for employment AI systems (follow NYC Local Law 144 model)²⁷
2. Ban or regulate ghost job postings (California, New Jersey, Kentucky initiatives)¹⁶
3. Extend liability to AI vendors, not just employers using them
4. Provide candidates right to explanation and human review
5. Fund enforcement (EEOC needs resources for AI-related cases)

📌 If you’re a technologist:

1. Build fairness testing into AI hiring tools from day one
2. Prioritize transparency and explainability over black-box optimization
3. Recognize technical solutions alone won’t solve social problems
4. Consider ethics before efficiency (speed ≠ progress)
5. Include diverse perspectives in design teams (homogeneous teams build biased systems)

The Path Forward

The evidence presented suggests that the job market in 2025 is experiencing systemic dysfunction.

Yet the crisis also presents an opportunity:

• Legal challenges are succeeding ($365,000 EEOC settlement, Mobley v. Workday class action)⁹¹¹
• Researchers are developing fairness metrics and technical interventions²⁸
• Legislators are proposing comprehensive regulation (federal Truth in Job Advertising Act, state laws)¹⁶
• Workers are organizing and documenting abuses (Change.org petition: 50,000 signatures)

The system’s failures are becoming undeniable.

The question is whether we have the collective will to address them.

📢 Join the Conversation

What’s your experience with AI hiring?

Have you:

• Been rejected in seconds by automated systems?
• Applied to jobs you suspect were fake?
• Noticed bias in the hiring process?
• Successfully navigated AI screening?

Share your story in the comments below. Your experience helps document this crisis and pushes for change.

References

¹ Society for Human Resource Management. (2025). 2025 SHRM Benchmarking Survey. Alexandria, VA: SHRM.

² ResumeUp.AI. (2025). One-Quarter of Jobs Posted Online Are Fake Ghost Jobs: Study. Entrepreneur. https://www.entrepreneur.com/business-news/one-quarter-of-jobs-posted-online-are-fake-ghost-jobs-study/496683

³ LinkedIn Talent Solutions. (2024). Global Talent Trends 2024. LinkedIn Economic Graph Research.

⁴ Greenhouse. (2024). Candidate Experience Research. Internal data cited in State of Job Hunting Report.

⁵ Greenhouse. (2024). 2024 State of Job Hunting Report. https://www.greenhouse.com/blog/greenhouse-2024-state-of-job-hunting-report

⁶ Soleimani, M., Intezari, A., Arrowsmith, J., Pauleen, D. J., & Taskin, N. (2025). Reducing AI bias in recruitment and selection: An integrative grounded approach. The International Journal of Human Resource Management, 36(14), 2480–2515.

⁷ Wilson, K., Rodolfa, K. T., & Caliskan, A. (2024). Gender, race, and intersectional bias in resume screening via language model retrieval. University of Washington. https://www.washington.edu/news/2024/10/31/ai-bias-resume-screening-race-gender/

⁸ Brookings Institution. (2025). Gender, race, and intersectional bias in AI resume screening via language model retrieval. https://www.brookings.edu/articles/gender-race-and-intersectional-bias-in-ai-resume-screening-via-language-model-retrieval/

⁹ EEOC Settlement Report. (2023). First AI Hiring Discrimination Settlement. U.S. Equal Employment Opportunity Commission.

¹⁰ Ip, E. (2025). Fair AI in hiring: Experimental evidence on how biased hiring algorithms and different debiasing methods affect the quality and diversity of applicants. Organizational Behavior and Human Decision Processes, 180, 105385.

¹¹ Mobley v. Workday, Inc., Case №3:23-cv-00770 (N.D. Cal. 2023).

¹² The Interview Guys. (2025). 85% of AI Resume Screeners Prefer White Names: Why 2025 Is The Year Hiring Discrimination Lawsuits Exploded. https://blog.theinterviewguys.com/85-of-ai-resume-screeners-prefer-white-names/

¹³ Greenhouse. (2024). Candidate Experience Research. Internal data cited in State of Job Hunting Report.

¹⁴ Lee, J., Kim, S., & Park, Y. (2024). AI-induced technostress and mental health in the workplace: A systematic review. Computers in Human Behavior, 158, 108234.

¹⁵ Resume Builder. (2024). Ghost Jobs Survey Results. https://www.resumebuilder.com/3-in-10-companies-currently-have-fake-job-posting-listed

¹⁶ DAVRON. (2025). Ghost Jobs & Misleading Job Ads Are Still Rising. https://www.davron.net/ghost-jobs-misleading-job-ads-are-still-rising

¹⁷ Fast Company. (2024). 3 Ways to Spot a Ghost Job Listing. https://www.fastcompany.com/91183465/3-ways-to-spot-a-ghost-job-listing

¹⁸ The Interview Guys. (2025). Ghost Jobs Exposed: The Companies Posting Fake Job Listings. https://blog.theinterviewguys.com/ghost-jobs-exposed/

¹⁹ Handwerker, E. W., & Pepper, A. H. (2025). “Ghost” Job Postings. Congressional Research Service Report No. IF12977. https://www.congress.gov/crs-product/IF12977

²⁰ Appcast. (2024). Recruiter Survey on Ghost Job Postings. Internal research report.

²¹ Congressional Research Service. (2024). Ghost Job Postings Fact Sheet. https://www.congress.gov/crs-products/IF12977

²² Lindsley, P. (2025). From 1 in 8 to 1 in 5: Ghost Jobs Are Distorting the U.S. Labor Market in 2025. Medium. https://medium.com/@patricklindsley1/from-1-in-8-to-1-in-5-ghost-jobs-are-exploding-in-2025-a7a1fbdad011

²³ Revelio Labs. (2024). Hires Per Job Posting Analysis. Retrieved from CNBC reporting on ghost jobs.

²⁴ Akerlof, G. A. (1970). The market for “lemons”: Quality uncertainty and the market mechanism. The Quarterly Journal of Economics, 84(3), 488–500.

²⁵ Burks, S. V., Cowgill, B., Hoffman, M., & Housman, M. (2015). The value of hiring through employee referrals. The Quarterly Journal of Economics, 130(2), 805–839.

²⁶ Brookings Institution. (2025). Gender, race, and intersectional bias in AI resume screening via language model retrieval. https://www.brookings.edu/articles/gender-race-and-intersectional-bias-in-ai-resume-screening-via-language-model-retrieval/

²⁷ Sheard, L. (2025). Algorithm-facilitated discrimination: A socio-legal study of the use by employers of artificial intelligence hiring systems. Journal of Law and Society, 52(2), 234–267.

²⁸ Albaroudi, E., Mansouri, M., & Alamri, S. (2024). A comprehensive review of AI techniques for addressing algorithmic bias in job hiring. AI, 5(2), 383–407.

If this article helped you understand what’s happening in the job market, please share it with others who need to know. The more people understand the systemic nature of this crisis, the faster we can push for meaningful reform.

👏 Clap if this resonated | 💬 Comment with your experience | 🔄 Share to spread awareness

“Do not love half lovers
Do not entertain half friends
Do not indulge in works of the half talented
Do not live half a life
and do not die a half death.
If you choose silence, then be silent
When you speak, do so until you are finished
Do not silence yourself to say something
And do not speak to be silent.
If you accept, then express it bluntly
Do not mask it
If you refuse then be clear about it
for an ambiguous refusal is but a weak acceptance.
Do not accept half a solution
Do not believe half truths
Do not dream half a dream
Do not fantasize about half hopes.
Half a drink will not quench your thirst
Half a meal will not satiate your hunger
Half the way will get you nowhere
Half an idea will bear you no results.
Your other half is not the one you love
It is you in another time yet in the same space
It is you when you are not.
Half a life is a life you didn’t live,
A word you have not said
A smile you postponed
A love you have not had
A friendship you did not know
To reach and not arrive
Work and not work
Attend only to be absent
What makes you a stranger to those closest to you
and they strangers to you.
The half is a mere moment of inability
but you are able, for you are not half a being
You are a whole that exists to live a life
not half a life.”
― Gibran Khalil Gibran

For those who dream of building technologies that can change lives, the journey can feel isolating. Doubts creep in, amplified by fear of judgment and rejection. You may feel as if your ideas are fragile, as if the world is quick to dismiss what you hold dear. But remember, you are not alone in this journey.

Inspired by Khalil Gibran’s timeless words, this guide is here to remind you that to succeed, you must show up fully — for yourself and for your dreams. Don’t settle for half-steps or half-beliefs, for they will only weaken your path. Instead, be whole, be bold, and live unapologetically, embracing the fullness of who you are.

Here are six half-measures to avoid if you want to rise above fear, loneliness, and doubt.

1. Don’t Build Halfway Relationships: Surround Yourself with Genuine Allies

“Do not love half lovers.” Many relationships in tech and innovation feel superficial, leaving you feeling unrecognized or misunderstood. But you don’t need people who don’t see your vision. Build authentic connections with those who believe in you fully. Seek those who offer their support, honesty, and respect.

The right allies remind you of your worth, especially when doubt arises. Let your relationships reflect the strength of your purpose, for they will fuel you when your journey feels most difficult.

2. Refuse Half-Dreams: Hold onto Your Vision Despite Doubts

“Do not dream half a dream,” reminds us that shrinking your vision won’t make it safer; it will make it powerless. The fear of judgment can tempt you to scale down, to make your ideas fit into what others might find “acceptable.” But a half-dream will only lead to a half-hearted life.

Let your dream be bold, even if it feels lonely or misunderstood at times. Fear of success is a trick of the mind. Embrace your dream in full, without apology. The strength of your vision is what will guide you through the difficult moments.

3. Avoid Partial Transparency: Embrace Radical Honesty

“Do not believe half-truths.” In a world where it’s tempting to mask who we are or soften our beliefs to fit in, know that transparency is your power. Fear of judgment can make us hold back our true thoughts, but when you’re open and real, you find your true supporters.

Speak your ideas with courage. Let people see your vision as it is, without hiding or adjusting to please others. Radical honesty frees you from the weight of fear and allows you to connect with those who understand your value. You’re not here to be liked by everyone — you’re here to bring your unique vision to life.

4. Reject Half-Solutions: Commit to Full Integrity

“Do not accept half a solution.” When doubt and fear are high, shortcuts seem tempting. Half-measures can feel like protection against failure, but they only limit your potential. Instead, trust yourself enough to commit to solutions that fully align with your vision.

You’re here to create something lasting, not something that merely “works for now.” Let every step you take reflect the fullness of your potential, and don’t compromise. When you commit to integrity, you build something real, and that builds your confidence in the face of judgment.

5. Embrace Full Resilience: Use Fear as Fuel for Growth

“Half a life is a life you did not live.” The fear of success and the fear of failure are often two sides of the same coin, but neither should hold you back. Each time you encounter resistance or feel judgment from others, remember that resilience is a choice. Let every doubt, every rejection be fuel that drives you further.

True resilience isn’t about avoiding failure or minimizing success — it’s about allowing both to strengthen you. Face each fear fully, not to be defeated by it, but to learn from it and grow stronger.

6. Avoid Halfway Innovation: Never Stop Pushing Your Vision Forward

“You are a whole that exists to live a life, not half a life.” Halfway innovation is the result of shrinking from success, of keeping your ideas small to avoid rejection. But your calling demands that you push forward, that you explore what’s possible without apology.

Each step forward is a step into the unknown, but this is where true creativity lies. Keep questioning, keep challenging, and let your vision expand. Innovation isn’t a single success; it’s a commitment to always evolve, always reach further.

And Don’t Forget: Live Whole, Lead Boldly, and Create Without Fear

In a world that may not always understand you, remember: “You are not half a being.” You are here to live fully, to create without apology, to rise above the judgments of others. Embrace the people, the dreams, and the truths that align with your highest purpose.

When you show up fully, you find the strength to overcome the loneliness, fear, and doubt that come with your journey. You are a Purpose-Driven Pioneer, and the world awaits the greatness only you can bring. So live whole, be bold, and step into your future with courage. The world needs your brilliance — now more than ever.

A special thank you to ChatGPT for lending a hand in editing my blog. 🤖❤️

As developers, we often face the challenge of handling incoming traffic to our applications in a controlled and predictable manner. Whether it’s to prevent abuse, ensure fair usage, or simply to maintain performance and reliability, managing the rate of incoming requests is crucial. This is where the Rate Limiter API comes into play — a powerful tool that provides various rate limiting algorithms to help you manage and control the flow of traffic to your application.

What is the Rate Limiter API?

The Rate Limiter API is designed to give developers a robust set of tools to control the rate of incoming requests to their applications. It includes a range of algorithms such as Token Bucket, Leaking Bucket, Fixed Window Counter, Sliding Window Log, and Sliding Window Counter. Each algorithm serves a specific purpose, allowing you to choose the best fit for your application’s needs.

Why is Rate Limiting Important?

Rate limiting is a critical component in application security and performance. It helps prevent abuse by limiting the number of requests that a single user or IP address can make within a certain timeframe. This not only protects your application from potential denial-of-service (DoS) attacks but also ensures that resources are used fairly among all users.

Engineers should consider integrating a rate limiter into their applications for several reasons:

• Security: Protects against brute force attacks and reduces the risk of system overload.
• Fair Usage: Ensures that all users have equal access to the application’s resources.
• Performance: Helps maintain optimal performance by preventing resource hogging.

Applications That Benefit the Most

The Rate Limiter API is particularly beneficial in scenarios where your application receives a high volume of requests or where the potential for abuse is high. Examples include:

• APIs and Microservices: Protect your services from being overwhelmed by too many requests in a short period.
• E-commerce Platforms: Ensure that your online store remains responsive during peak shopping times.
• Authentication Systems: Prevent brute force attacks by limiting the number of login attempts.
• Content Delivery Networks (CDNs): Regulate the flow of requests to ensure consistent content delivery performance.

Choosing the Right Algorithm For Your Application:

• For Simple Use Cases: If your application needs straightforward rate limiting, such as limiting purchase attempts per minute as in the example, the Fixed Window Counter is often sufficient.
• For Smoothing Traffic: If you want to avoid sudden spikes or need to distribute requests more evenly, the Sliding Window algorithms (Log or Counter) might be better suited.
• For Allowing Bursts: If you need to handle occasional bursts of traffic but still enforce a rate limit, the Token Bucket algorithm is a strong choice.
• For Consistent Processing: If your priority is to handle requests at a steady pace without sudden spikes, the Leaking Bucket algorithm could be ideal.

Where Should You Place the Rate Limiter API in Your Codebase?

To effectively integrate the Rate Limiter API, it’s crucial to place it in the right part of your codebase. Typically, the rate-limiting logic should be implemented at the entry point of your application, such as in the middleware layer or API gateway. This placement ensures that all incoming requests are checked and regulated before they reach your core application logic, providing a robust first line of defense against excessive or malicious traffic.

Here’s an example of how you can set up rate limiting in a Node.js application using Express:

const express = require('express');
const rateLimiter = require('./path-to-rate-limiter'); // Import your Rate Limiter API logic here

const app = express();

app.use(rateLimiter); // Apply rate limiting middleware

app.get('/api/resource', (req, res) => {
  res.send('This is a rate-limited resource');
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

By placing the Rate Limiter API middleware at the top level of your request-handling stack, you ensure that all routes and endpoints benefit from its protection.

How to Integrate the Rate Limiter API into Your Codebase

Integrating the Rate Limiter API is straightforward. Here’s a step-by-step guide using JavaScript:

1. Install the necessary dependencies: Ensure that your project is set up with the necessary tools to handle HTTP requests and responses.
2. Set up the Rate Limiter API: Import the Rate Limiter API and configure it according to your application’s requirements.
3. Apply the Rate Limiter API as middleware: As shown in the example above, place the rate-limiting logic at the entry point of your application to ensure that all incoming requests are managed effectively.
4. Test the integration: Make sure to test the rate-limiting functionality under different scenarios to verify that it behaves as expected.

Example: Rate Limiting Purchase Requests in an E-Commerce Store

In this scenario, we’ll implement rate limiting in a Next.js API route that handles purchase requests. We’ll then create a test page to simulate multiple purchase attempts and see how the rate limiter prevents abuse by limiting the number of requests.

Step 1: Setting Up the Rate Limiter in the Purchase API Route

First, create a new API route to handle purchase requests. We’ll implement the Fixed Window Counter algorithm to limit the number of purchase attempts a user can make within a minute. This algorithm tracks the number of requests within a set 1-minute window and allows up to 3 requests during that period. If the request count exceeds this limit, any additional requests are blocked until the window resets.

// pages/api/purchase.js

import rateLimiter from 'express-rate-limit';

// Initialize the rate limiter middleware
const purchaseLimiter = rateLimiter({
  windowMs: 60 * 1000, // 1 minute window
  max: 3, // limit each IP to 3 purchase requests per windowMs
  message: 'Too many purchase attempts from this IP, please try again after a minute',
});

export default async function handler(req, res) {
  // Apply the rate limiter
  await new Promise((resolve, reject) => {
    purchaseLimiter(req, res, (result) => {
      if (result instanceof Error) return reject(result);
      resolve(result);
    });
  });

  // Handle the purchase request
  if (req.method === 'POST') {
    // Logic for processing the purchase would go here
    res.status(200).json({ message: 'Purchase successful' });
  } else {
    res.status(405).json({ message: 'Method Not Allowed' });
  }
}

Step 2: Creating a Test Page to Simulate Purchase Attempts

Now, let’s create a test page where we simulate multiple purchase attempts by a user. We’ll attempt to make more than 3 purchase requests in quick succession to see how the rate limiter responds.

// pages/test-purchase-limiter.js

import { useState } from 'react';

export default function TestPurchaseLimiter() {
  const [response, setResponse] = useState(null);

  const testPurchaseLimiter = async () => {
    const responses = [];
    for (let i = 0; i < 5; i++) {
      const res = await fetch('/api/purchase', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          productId: '12345', // Example product ID
          quantity: 1,        // Example quantity
        }),
      });
      const data = await res.json();
      responses.push(data);
    }
    setResponse(responses);
  };

  return (
    <div>
      <h1>Purchase Rate Limiter Test</h1>
      <button onClick={testPurchaseLimiter}>Test Purchase Rate Limiter</button>
      <pre>{JSON.stringify(response, null, 2)}</pre>
    </div>
  );
}

Explanation:

• API Route (purchase.js): This route is responsible for handling purchase requests. We've set up a rate limiter that allows a maximum of 3 purchase requests per minute from a single IP address. Any additional requests within that time frame will receive a message indicating that the rate limit has been exceeded.
• Test Page (test-purchase-limiter.js): This page simulates a user trying to make 5 purchase requests in quick succession. The first 3 requests should succeed, and the last 2 should be blocked by the rate limiter.

Does the Choice of Algorithm Matter?

Absolutely, the choice of rate limiting algorithm matters depending on your specific use case and the behavior you want to enforce. Each algorithm offers distinct advantages and trade-offs, and understanding these can help you choose the right one for your application. Here’s a comparison of the most commonly used rate limiting algorithms:

Fixed Window Counter

• How it works: This algorithm counts requests in fixed, non-overlapping time windows (e.g., every minute, hour, etc.).
• Best for: Simpler use cases where it’s sufficient to limit requests within a defined time period, such as limiting purchase attempts.
• Pros: Easy to implement and understand.
• Cons: Can be vulnerable to burst traffic at the edge of a window (e.g., a user could make several requests at the end of one window and more at the beginning of the next).

Sliding Window Log

• How it works: Tracks each request with a timestamp and checks the number of requests within a sliding window of time.
• Best for: Scenarios where you want a more evenly distributed rate limit that avoids the “edge case” burst issue seen with Fixed Window.
• Pros: Provides a smoother rate limiting experience by considering requests over a rolling period.
• Cons: More complex to implement and can be heavier in terms of storage if not managed carefully.

Sliding Window Counter

• How it works: Similar to Fixed Window, but it splits the window into smaller intervals (buckets) and counts requests across overlapping windows.
• Best for: Cases where you want to smooth out the effect of rate limiting without needing precise request logging.
• Pros: Smoother than Fixed Window, with less overhead than Sliding Window Log.
• Cons: Can be more complex to understand and configure.

Token Bucket

• How it works: Tokens are added to a bucket at a fixed rate, and each request consumes a token. When the bucket is empty, requests are blocked.
• Best for: Use cases where you need to allow bursts of traffic but still want to limit the overall rate (e.g., allowing short bursts of purchases while controlling the long-term rate).
• Pros: Allows controlled bursts of traffic while limiting the overall rate.
• Cons: More complex to implement.

Leaking Bucket

• How it works: Similar to Token Bucket, but the bucket leaks tokens at a steady rate, and requests are processed only when tokens are available.
• Best for: Scenarios where you want a steady rate of processing, with controlled delays if the rate is exceeded.
• Pros: Smooths out bursts by handling requests at a consistent rate.
• Cons: Can introduce latency in processing.

Conclusion

The Rate Limiter API is an indispensable tool for any engineer looking to maintain control over application traffic. Whether you’re building an API, managing a login system, or running an e-commerce platform, integrating a rate limiter can significantly enhance the security, performance, and fairness of your application.

By placing the Rate Limiter API at the entry point of your API routes, you can effectively manage the flow of traffic and ensure that your application remains stable and secure, even under heavy load. And with the testing approach outlined above, you can confidently deploy your rate limiting strategy, knowing that it will perform as expected in production.

So, why wait? Start integrating the Rate Limiter API into your Next.js application today, and take control of your application’s traffic like never before!

A special thank you to ChatGPT for lending a hand in editing my blog. 🤖❤️

In the quest for a more efficient development workflow, managing pull requests (PRs) stands out as a crucial aspect. The goal is simple: avoid the rush of last-minute merges, prevent rebase conflicts, and eliminate the all-too-common “weekend nightmares.” In my search for solutions to streamline this process for my team, I stumbled upon a strategy that not only enhances efficiency but also fosters better communication. I’m excited to share this approach with fellow developers who might find it equally beneficial.

The Need for Efficiency and Clarity 🎯

Why focus on automating PR merges and Slack notifications? The answer lies in the desire to make our development process as smooth and conflict-free as possible. Late-day or end-of-the-week merges often lead to rushed decisions, overlooked errors, and the dreaded task of resolving conflicts that could have been avoided. By scheduling merges during optimal times and instantly notifying the team, we create a workflow that is both efficient and transparent.

And here’s the kicker: there’s no longer any need to manually click on the “Merge pull request” button. When a PR is ready for merging, simply tagging it with the specified label does the trick. For a visual walkthrough on how this is achieved, check out the clip below:

This clip provides a step-by-step guide on setting up your GitHub Actions to automatically merge PRs once they’re labeled accordingly. It’s a game-changer, transforming the merge process from a manual checkpoint to an automated, smooth transition that keeps the development train moving without unnecessary stops.

Implementing the Solution with GitHub Actions

GitHub Actions is the cornerstone of our strategy, enabling us to automate workflows directly within our repository based on specific triggers. Here, we focus on two key actions: merging PRs on a defined schedule and sending notifications to Slack.

Step 1: Scheduling PR Merges

To get started, we create a GitHub Action that triggers on a cron schedule. This ensures PRs labeled as ready-to-merge are automatically merged at the most opportune times, sidestepping potential conflicts and hasty decisions.

• Setting Up the Workflow: In your repository, navigate to .github/workflows and create a new file named merge-on-schedule.yml.
• Defining the Cron Schedule: Choose when you want the merges to occur, avoiding late hours and weekends. For example, mid-week mornings can be an ideal window:

name: Auto Merge on Label

on:
  schedule:
    - cron: '0 17 * * 1-4'  # Triggers at 9 AM PT, Monday to Thursday

permissions:
  contents: write
  pull-requests: write

• Configuring the Merge Action: Utilize the GitHub CLI in the action to merge PRs tagged with ready-to-merge. The action looks something like this:

jobs:
  auto_merge:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v4

      # Setup Node.js 20
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "20"

      # Conditionally run the next steps only if the "ready-to-merge" label was added
      - name: Check if "ready-to-merge" label was added
        if: ${{ github.event.label.name == 'ready-to-merge' }}
        run: echo "ready-to-merge label was added to PR."

      # Setup GitHub CLI
      - name: Setup GitHub CLI
        run: |
          if ! gh --version; then
            sudo apt-get install gh
          fi

      # Authenticate GitHub CLI using GITHUB_TOKEN
      - name: Authenticate GitHub CLI
        run: echo "${{ secrets.GITHUB_TOKEN }}" | gh auth login --with-token

      # Merge PRs labeled as "ready-to-merge"
      - name: Merge PR labeled as "ready-to-merge"
        if: ${{ github.event.label.name == 'ready-to-merge' }}
        run: |
          PR_NUMBER=${{ github.event.pull_request.number }}
          PR_URL=${{ github.event.pull_request.html_url }}
          gh pr merge "$PR_NUMBER" --merge --admin
          echo "Merged PR $PR_NUMBER: $PR_URL"

📘 Note: This script authenticates the GitHub CLI, finds open PRs with the ready-to-merge label, and merges them by scheduled time.

Step 2: Sending Slack Notifications

To keep the entire team informed about merged PRs, integrating Slack notifications into the workflow provides instant updates, enhancing team communication.

• Configure a Slack Webhook: First, create an Incoming Webhook in your Slack workspace and store the URL as a GitHub secret named SLACK_WEBHOOK_URL.
• Add the Notification Step: Modify your merge-on-schedule.yml to include a step that sends a message to Slack once a PR is merged:

  - name: Notify Slack
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
    run: |
      curl -X POST -H 'Content-type: application/json' --data '{"text":"🚀 A PR was just merged!"}' $SLACK_WEBHOOK_URL

This sends a cheerful message to your designated Slack channel whenever a PR merge is successfully completed.

Best Practices and Insights 🌟

• Test Your Workflow: Ensure everything works as expected by testing your workflow in a controlled environment before full implementation.
• Maintain Security: Keep your secrets secure and limit access to necessary personnel only.
• Iterate and Improve: Be open to feedback and ready to adjust your process as needed.

Wrapping Up

As we wrap up this guide, I want to leave you with the complete merge-on-schedule.ymlfile that brings everything we’ve discussed to life. This file encapsulates the automation of PR merges and Slack notifications, acting as a blueprint for you to customize and implement within your own projects. With this setup, once a PR is ready and labeled, the rest unfolds automatically, saving time and streamlining your team’s workflow.

Here is the merge-on-schedule.ymlfile in full:

name: Automated PR Merges & Slack Notifications

on:
  schedule:
    - cron: '0 17 * * 1-4'  # Triggers at 9 AM PT, Monday to Thursday

permissions:
  contents: write
  pull-requests: write

jobs:
  auto_merge:
    runs-on: ubuntu-latest
    steps:
      # Checkout the repository
      - name: Checkout repository
        uses: actions/checkout@v4

      # Setup Node.js 20
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "20"

      # Conditionally run the next steps only if the "ready-to-merge" label was added
      - name: Check if "ready-to-merge" label was added
        if: ${{ github.event.label.name == 'ready-to-merge' }}
        run: echo "ready-to-merge label was added to PR."

      # Setup GitHub CLI
      - name: Setup GitHub CLI
        run: |
          if ! gh --version; then
            sudo apt-get install gh
          fi

      # Authenticate GitHub CLI using GITHUB_TOKEN
      - name: Authenticate GitHub CLI
        run: echo "${{ secrets.GITHUB_TOKEN }}" | gh auth login --with-token

      # Merge PRs labeled as "ready-to-merge"
      - name: Merge PR labeled as "ready-to-merge"
        if: ${{ github.event.label.name == 'ready-to-merge' }}
        run: |
          PR_NUMBER=${{ github.event.pull_request.number }}
          PR_URL=${{ github.event.pull_request.html_url }}
          gh pr merge "$PR_NUMBER" --merge --admin
          echo "Merged PR $PR_NUMBER: $PR_URL"

      # Notify Slack
      - name: Notify Slack
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
        run: |
          curl -X POST -H 'Content-type: application/json' --data '{"text":"🚀 A PR has just been merged automatically!"}' $SLACK_WEBHOOK_URL

I hope this tutorial helps you as much as it has helped me. If you have questions, insights, or want to share your experience, feel free to reach out. Let’s make development a smoother, more enjoyable journey for everyone involved.

Happy coding!

A special thank you to ChatGPT for lending a hand in editing and beautifying my blog. 🤖❤️

A Relatable Start

If you had met me four years ago and asked me to pen down a line of code from scratch, I’d probably be sneaking a peek at MDN or nervously typing away on Stack Overflow. The greenness was evident, the confidence wobbly. Every time I tried to fit into the existing codebase, it felt like trying on shoes several sizes too big.

During a peer review, when a more seasoned engineer pointed out my mistakes, it felt like a splash of cold water. “This is not how we code” they’d say. That night, nestled in the comfort of my home, a question haunted me — why did I transition from architecture to software engineering? Did I want to be an engineer who just coded, or did I want to be a coder who engineered? I chose the latter, not out of defiance, but out of purpose. I wanted to be the one solving problems, not just typing them out.

Embracing Creativity

For those who know the whimsical twists and turns of my personality, they’ll affirm that anything devoid of creativity feels mundane to me. Borrowing code from Stack Overflow might save the day with its quick fixes, but let’s face it, it’s not the panacea for all coding ailments. Sure, I could grab a snippet from the web, slap it onto my editor, and make it run. It might save a moment, but at what cost? Efficiency? Scalability? That’s the daily puzzle that sparks my passion and keeps me on my toes each sunrise.

From Student to Teacher

Fast forward a few years, and I’m the one behind the reviewing screen. And boy, do I feel the weight of those four words now more than ever! As I scan through merge requests, I often catch myself thinking, “Is this how we want to code?” While I might be more diplomatic in my feedback now, the sentiment remains.

So, here’s the engineering conundrum: How do I forge a consistent code ethos across a team? We’ve got linters in place, making our code look pretty and standardized. We’ve integrated unit tests, ensuring our functions do what they’re supposed to. TypeScript’s static typing has been a godsend, catching errors way before runtime. But what about the logic? The architecture? How do I enforce DRY principles or nudge developers away from nesting ternaries like there’s no tomorrow? 🤖

Let’s Dive Deeper!

Let’s get curious, do you remember the game “Tic Tac Toe”? Yeah, that classic 3x3 grid game. While this might seem like a simple code challenge for many, the elegance is in the implementation. Let me take you through a code review session:

The Controller Grid

The Controller Grid is responsible for the direction buttons: up, down, left, and right. This component is mainly responsible for allowing the user to select a direction and then update the active cell accordingly.

The Main Grid

The Main Grid. This is where the active cell gets highlighted based on the user’s actions. Each cell in this grid checks if it’s the currently active cell and changes its background color accordingly.

The Game Container

The Game Container acts as the orchestrator of our game. It manages the state of our game, particularly the current active cell, and also handles the arrow button clicks. Notice the use of the useState hook for state management. It keeps track of the current active cell.

'use client';

import { useState } from 'react';
import MainGrid from '../MainGrid';
import ControllerGrid from '../ControllerGrid';

const GameContainer = () => {
  const [activeRow, setActiveRow] = useState(0);
  const [activeCol, setActiveCol] = useState(0);

  const moveActiveCell = (direction: 'up' | 'down' | 'left' | 'right') => {
    switch (direction) {
      case 'up':
        setActiveRow(Math.max(0, activeRow - 1));
        break;
      case 'down':
        setActiveRow(Math.min(2, activeRow + 1));
        break;
      case 'left':
        setActiveCol(Math.max(0, activeCol - 1));
        break;
      case 'right':
        setActiveCol(Math.min(2, activeCol + 1));
        break;
    }
  };

  const isActive1 = activeRow === 0 && activeCol === 0;
  const isActive2 = activeRow === 0 && activeCol === 1;
  const isActive3 = activeRow === 0 && activeCol === 2;
  const isActive4 = activeRow === 1 && activeCol === 0;
  const isActive5 = activeRow === 1 && activeCol === 1;
  const isActive6 = activeRow === 1 && activeCol === 2;
  const isActive7 = activeRow === 2 && activeCol === 0;
  const isActive8 = activeRow === 2 && activeCol === 1;
  const isActive9 = activeRow === 2 && activeCol === 2;

  return (
    <div className="min-h-screen flex flex-row items-center justify-center">
      {/* MainGrid Start */}
      <div className="bg-yellow-300 w-96 h-96 flex flex-wrap mr-10">
        <div id='1' data-testid="cell-1" className={`w-1/3 h-1/3 border border-slate-700 ${isActive1 ? 'bg-pink-300' : ''}`} />
        <div id='2' data-testid="cell-2" className={`w-1/3 h-1/3 border border-slate-700 ${isActive2 ? 'bg-pink-300' : ''}`} />
        <div id='3' data-testid="cell-3" className={`w-1/3 h-1/3 border border-slate-700 ${isActive3 ? 'bg-pink-300' : ''}`} />
        <div id='4' data-testid="cell-4" className={`w-1/3 h-1/3 border border-slate-700 ${isActive4 ? 'bg-pink-300' : ''}`} />
        <div id='5' data-testid="cell-5" className={`w-1/3 h-1/3 border border-slate-700 ${isActive5 ? 'bg-pink-300' : ''}`} />
        <div id='6' data-testid="cell-6" className={`w-1/3 h-1/3 border border-slate-700 ${isActive6 ? 'bg-pink-300' : ''}`} />
        <div id='7' data-testid="cell-7" className={`w-1/3 h-1/3 border border-slate-700 ${isActive7 ? 'bg-pink-300' : ''}`} />
        <div id='8' data-testid="cell-8" className={`w-1/3 h-1/3 border border-slate-700 ${isActive8 ? 'bg-pink-300' : ''}`} />
        <div id='9' data-testid="cell-9" className={`w-1/3 h-1/3 border border-slate-700 ${isActive9 ? 'bg-pink-300' : ''}`} />
      </div>
      {/* MainGrid End */}

      {/* ControllerGrid Start */}
      <div className="bg-gray-300 w-48 h-48 flex flex-wrap">
        <div className="w-1/3 h-1/3"></div>
        <div className="w-1/3 h-1/3 flex justify-center items-center">
          <button data-testid="up-button" onClick={() => moveActiveCell('up')}>⬆</button>
        </div>
        <div className="w-1/3 h-1/3"></div>

        <div className="w-1/3 h-1/3 flex justify-center items-center">
          <button data-testid="left-button" onClick={() => moveActiveCell('left')}>⬅ </button>
        </div>
        <div className="w-1/3 h-1/3"></div>
        <div className="w-1/3 h-1/3 flex justify-center items-center">
          <button data-testid="right-button" onClick={() => moveActiveCell('right')} className='rotate-180'>⬅</button>
        </div>

        <div className="w-1/3 h-1/3"></div>
        <div className="w-1/3 h-1/3 flex justify-center items-center">
          <button data-testid="down-button" onClick={() => moveActiveCell('down')}>⬇</button>
        </div>
        <div className="w-1/3 h-1/3"></div>
      </div>
      {/* ControllerGrid End */}
    </div>
  );
};

export default GameContainer;

One might ask, why use such a brute-force method? Why not make it more efficient or robust? And those are valid questions. But remember, every engineer starts somewhere. Over time, as we encounter more challenges, learn from our mistakes, and absorb knowledge from others, our solutions become more refined.

The Quest Continues

However, there’s always room for improvement. What if there’s a tool out there that could scan through this code and suggest optimizations, logic refinements, and best practices? A tool that acts like that seasoned developer, who once told me, “this is not how we code.”

Curious about the complete picture? Dive into the entire codebase on my GitHub repository.

The Next Step: A Challenge for Us All

In this digital age, when machine learning and automation are redefining the way we operate, why not envision a solution for code reviews too? What if we could bridge the gap between a newbie’s enthusiasm and a maestro’s wisdom? We’ve automated CI/CD pipelines, we’ve automated testing — so why not automated mentoring?

But here’s the open-ended challenge to my fellow engineers: If such a tool were to be created, what features would make it both educational and efficient? How do we ensure that while automating the review process, we’re not just enforcing rules, but fostering understanding? How do we differentiate between the strict syntax of a linter and the nuanced mentorship of a seasoned engineer? 🤔

I’m on a quest to answer these questions and to possibly build a solution. But, I need diverse insights. So, I’m tossing this challenge back to the community. Share your thoughts, your ideas, and your criticisms. Let’s engineer a tool that not only corrects but educates. After all, as we’ve seen with my journey, it’s not just about writing code — it’s about writing the future.

Your insights could be the catalyst for the next big leap in code excellence. So, are you up for the challenge? 🔍🚀

A special thank you to ChatGPT for lending a hand in editing and beautifying my blog. 🤖❤️

In this ever-evolving world, being unique is not about fitting in. This is the story of my voyage from the concrete world of architectural design to the limitless expanse of software engineering, driven by curiosity and a conviction that being unique is about standing out. With Albert Einstein’s words, ‘I have no special talent. I am only passionately curious,’ I set off on a path less traveled, teeming with unknowns, but with a steadfast determination to change the world.

Chapter 1: The Start of Something New

As a child, I was fascinated by the transformative power of architecture. The idea of converting an abstract thought into a tangible reality, brick by brick, was captivating. But as I grew older, the dynamic world of technology started to enthrall me. My curiosity first sparked when I wondered, “how do credit cards work?” Soon, I found myself flooded with queries about building applications and was irresistibly drawn to the limitless potential and intriguing challenges of software engineering.

Transitioning from blueprints to lines of code was akin to learning a new language — intimidating, challenging, yet incredibly fulfilling. I had to decode complex algorithms, traverse through an unfamiliar industry, and embrace the constant feeling of being on the edge. Yet, as I dug deeper, I discovered parallels between my old and new worlds. Both were about design, problem-solving, and turning concepts into reality. In architecture, you use lines and angles, while in software, you use code — like solving a complex mathematical equation.

Chapter 2: Reengineering My Skills

As I dove deeper into the world of software engineering, Kahlil Gibran’s words, ‘…Do not accept half a solution. Do not believe half truths. Do not dream half a dream…’ became my mantra. I began by dissecting my CV, trying to find skills from my architectural background that could transfer over to my new domain.

Math, project management, spatial reasoning, meticulous attention to detail, negotiation, and problem-solving were skills I honed as an architect and were incredibly relevant in my new field. This newfound understanding bolstered my confidence and highlighted the interconnectedness of these two seemingly disparate domains. I felt like an explorer charting a new course, ready to prove my mettle in software engineering, without the conventional experience that comes with it.

Chapter 3: Joining a Startup and the Lessons I Learned

Joining a startup was like stepping into a high-speed roller coaster ride. Our small team of twenty blossomed into a bustling company of a hundred. Here, I learned that growth often means stepping out of your comfort zone, embracing change, and making decisions even with incomplete information.

The tech industry, where innovations evolve every 18 months, doesn’t permit a slow-down. It’s about keeping up with trends, constantly learning, and expanding your skillset.

Chapter 4: The last chapter of my beginning

As I look back, I realize my journey from crafting architectural designs to coding software applications was more than a mere career switch. It was a transformative expedition that expanded my understanding of ‘architecture’ — from the physical to the virtual, from the seen to the unseen.

If you’re contemplating a similar shift or finding your way in the fast-paced world of a startup, remember Gibran’s words. It’s not about switching worlds; it’s about weaving together lessons from both domains to create a unique tapestry that sets you apart. Yes, this journey is a roller-coaster ride filled with anxiety and high-pressure moments, but just as pressure creates diamonds, these challenges have shaped me into the multifaceted professional I am today.

Today, I wear many hats. I can design a house, set up your navigation system, and connect it all with your mobile application — a one-stop solution. This journey has made me unstoppable, and now, the world is truly my oyster.”