Forem

# GreenRoute — Google Maps for Sustainable Commuting 🌍

Sushmita Dubey — Sun, 19 Apr 2026 13:27:37 +0000

What I Built

GreenRoute is a climate-tech web application that helps users compare travel routes based on time, cost, and carbon emissions, making it easier to choose eco-friendly commuting options.

Instead of optimizing only for speed, GreenRoute also helps optimize for sustainability.

Live Demo

https://sushmita25dubey.github.io/DEV-Earth-Day-2026-Weekend-Challenge/

Users can:

Compare Car, Public Transport, and Bike/Walking routes
Identify the Greenest Route
See estimated carbon savings
Use a What-If Impact Simulator to project monthly and annual impact
Interact with a Gemini Climate Coach for AI-powered sustainability guidance
Take an Earth Day Pledge for greener commuting habits

Inspiration

Daily transportation choices create environmental impact, but most commuters rarely see that impact while making decisions.

How It Works

A user enters a start point and a destination.

GreenRoute compares route options using:

Travel time
Cost
Estimated CO₂ emissions

It highlights the greenest option and shows environmental impact metrics.

Example:

Choosing Bike/Walking instead of a car can help reduce emissions and improve annual carbon savings.

Google Gemini Integration

GreenRoute includes a Gemini Climate Coach that provides:

Personalized commuting sustainability suggestions
Climate guidance through quick prompts
AI-powered answers to questions like:
- How can I reduce commute emissions?
- Is cycling always greener?
- Best route for students?

Gemini is used as an interactive sustainability assistant, not just a static feature.

Features

✅ Route comparison
✅ Carbon savings calculator
✅ What-If impact simulator
✅ Mock route visualization
✅ Gemini Climate Coach
✅ Earth Day Pledge
✅ localStorage support
✅ Dark climate-tech UI

Built With

HTML
CSS
JavaScript
localStorage
Google Gemini (AI feature integration)

What’s Next

Future improvements could include:

Real maps integration
Live route APIs
Real-time traffic + emissions data
Deeper Gemini-powered commuting recommendations

Building "Guide": An iOS App for Crisis Response

Ketaki Kulkarni — Sun, 19 Apr 2026 13:24:52 +0000

The Mission
When an emergency hits a hotel, the biggest enemy is fragmented information. My goal with Guide was to create a reliable, minimalist tool that keeps guests and staff in sync.

The Real-World Logic
Instead of over-promising on "AI magic," I built the logic to be practical. The Gemini-powered Assistant works based on available data:

Reference Mode: If a manager (using the staff code STAFF123) uploads a blueprint to the Supabase bucket, Gemini uses that specific document to help guide users.

Standard Mode: Without a blueprint, the assistant falls back to general safety protocols to ensure the user is never left without guidance.

Help Buttons: The app is equipped with quick action buttons to place calls to emergency services during critical situations.

Technical Architecture

Swift Fallbacks: In life-safety scenarios, you can't always wait for an API. I built hardcoded "Quick Response Factors" (QRFs) into the Swift code for Fire, Earthquakes, and Medical emergencies.

Minimalist Footprint: I relied entirely on native MapKit and SF Symbols rather than heavy external assets to reduce the overall size of the app.

Secure Coordination: Staff can trigger building-wide broadcasts, while guests can share their live location with authorities via a single tap.

Final Thoughts
Building this proved that AI-native tools like Google Antigravity don’t just write code—they allow us to focus on the human logic of the problem. I’m still refining the UI/UX, so if you have thoughts on the earthy-green palette, I’m all ears!

Appetize link: https://appetize.io/app/b_g2yygyljyegaqlr6lvyrit7334

Demo Link:
https://drive.google.com/file/d/1PIuIq0BZ_DNYPhcpuFYULZA25yNCwIXI/view?usp=drive_link

GitHub Repo link:
https://github.com/Kool-K/Guide-Emergency-Response-Hospitality-iOS-App.git

Self-Governing Cloud Performance: MCP-Orchestrated Multi-Agent Blueprint for Autonomous SLA Assurance

Manvitha Potluri — Sun, 19 Apr 2026 13:21:29 +0000

Self-Governing Cloud Performance: MCP-Orchestrated Multi-Agent Blueprint for Autonomous SLA Assurance

Managing performance in multi-tenant cloud systems has reached an inflection point. Organizations deploying hundreds of microservices across elastic infrastructure face a fundamental problem: the volume of performance signals, metrics, logs, traces, and events has exceeded human cognitive capacity for real-time synthesis.

DevOps teams routinely manage environments producing over 10 million metric data points per minute, yet the median time to detect and resolve a performance degradation event remains measured in hours, not minutes.

This post presents a complete implementation blueprint for a multi-agent performance management system orchestrated through the Model Context Protocol (MCP), designed for DevOps Cloud Solutions Architects operating multi-tenant Kubernetes infrastructure.

The Gap in Current AIOps Tools

Current AIOps platforms like Dynatrace Davis, Datadog Watchdog, and New Relic AI, provide anomaly detection and correlation but stop short of autonomous remediation. They surface insights, but a human must evaluate and execute every action.

Existing research on autonomous performance engineering demonstrates algorithmic feasibility but omits critical production concerns:

How does the agent authenticate to the Kubernetes API?
What happens when two agents simultaneously attempt conflicting scaling actions?
How are agent actions audited for SOC 2 compliance?
How does the system degrade gracefully when the LLM provider experiences an outage?

This blueprint answers all of those.

Why MCP as the Integration Backbone

The Model Context Protocol was selected for three practical reasons:

1. Tool discovery without hard-coded API clients.
MCP's tool-description schema allows agents to discover and invoke operational tools without hard-coded API clients, critical when toolchains evolve independently of the agent system.

2. Built-in authentication delegation.
MCP's session management and authentication delegation simplify credential lifecycle management across all agents.

3. Streaming support.
MCP's streaming support enables agents to consume real-time telemetry feeds without polling, reducing latency between signal detection and agent reasoning from minutes to seconds.

The 4-Layer Architecture

Layer	Function	Recommended Stack
Telemetry Bus	Ingest, normalize, tag with tenant context	OpenTelemetry Collector, Kafka, Vector.dev
Intelligence Engine	Anomaly detection, correlation, baselining	Prometheus + Recording Rules, Grafana ML, ClickHouse
Agent Orchestrator	Multi-agent coordination, reasoning, planning	5 MCP agents, Redis Streams, LangGraph
Governance Gateway	Policy enforcement, blast radius, audit	OPA, Argo Rollouts, PostgreSQL

The 5 Agents — Roles and Responsibilities

Each agent runs as an independent process with its own MCP client session, enabling independent scaling, fault isolation, and credential scoping.

Watchtower

Role: Real-time anomaly detection and triage
MCP Servers: Prometheus MCP, PagerDuty MCP
Max Autonomy: Level 2 (supervised)
Scope: Read-only + alert escalation

Watchtower observes. It never executes. When it detects an anomaly it publishes a structured observation event to the Redis Streams event bus for other agents to act on.

Elastik

Role: Horizontal and vertical scaling decisions
MCP Servers: Kubernetes MCP, Cloud Provider MCP
Max Autonomy: Level 3 (autonomous)
Scope: Pod/node scaling within guardrails

Three safety constraints are hardcoded at the MCP server level — not in agent prompts, which can be manipulated:

Maximum 3x scale-up factor per invocation
Minimum 2 replicas for any production deployment
300 second cooldown between consecutive scaling actions on the same deployment

Configurer

Role: Runtime config and tuning optimization
MCP Servers: ConfigMap MCP, Feature Flag MCP
Max Autonomy: Level 2 (supervised)
Scope: Non-destructive config changes only

Arbitrator

Role: Tenant fairness and SLA enforcement
MCP Servers: Billing MCP, OPA MCP
Max Autonomy: Level 2 (supervised)
Scope: Quota adjustment, throttling

The Arbitrator maintains a real-time SLA burn rate metric for each tenant. When a tenant's burn rate exceeds 1.5x the sustainable rate, the Arbitrator automatically elevates the priority of pending optimization proposals for that tenant and can preempt lower-priority optimizations for others.

Strategist

Role: Capacity planning and cost forecasting
MCP Servers: FinOps MCP, all read servers
Max Autonomy: Level 1 (advisory only)
Scope: Recommendations only, never executes

The Proposal-Approval Pattern

Every agent action follows this flow:

Agent detects issue
→ publishes proposal event to Redis Streams
→ Governance Gateway evaluates against OPA policies
→ Arbitrator checks for cross-tenant conflicts
→ execution_authorized event issued
→ Agent executes
→ Outcome verified within rollback time budget
→ Full audit record written to PostgreSQL

Every audit record includes the full agent reasoning chain, every MCP tool call with parameters and responses, the OPA policy evaluation result, and the execution outcome with before/after metrics. This satisfies SOC 2 Type II and ISO 27001 requirements for automated change management.

Blast Radius Controls

Dimension	Level 2 Supervised	Level 3 Autonomous
Max tenants affected	3 per action	1 per action
Max capacity change	±50%	±30%
Max services affected	5	2
Change freeze respect	Hard block	Hard block
Rollback time budget	15 minutes	5 minutes

OPA Policy Stack — 4 Layers

Safety policies — hard limits that cannot be overridden
SLA policies — tenant-specific contractual constraints
Operational policies — change freeze periods, concurrent action limits
Cost policies — budget ceilings, reserved instance utilization targets

Kubernetes MCP Server — Reference Implementation

The Kubernetes MCP server exposes 7 tools:

get_pod_metrics
get_hpa_status
scale_deployment
patch_resource_limits
get_node_allocatable
cordon_node
get_events

Each tool enforces tenant-scoping through Kubernetes namespace isolation. The agent's MCP session is bound to specific namespaces — cross-tenant access is prevented at the protocol level, not just the reasoning level.

This distinction is critical. Research on LLM prompt injection vulnerabilities shows agents can be induced to cross tenant boundaries under adversarial conditions if isolation only exists in the prompt. Protocol-level enforcement is the only safe approach.

Real Incident Walkthrough

Watchtower detects p99 latency spike: 180ms → 1,240ms on an enterprise-tier tenant.

It correlates three concurrent signals:

340% increase in GC pause time on 3 of 8 pods
Memory utilization 71% → 94% on those same pods
A deployment event 47 minutes prior that modified JVM heap settings

What happens automatically:

Watchtower publishes structured observation event
Elastik proposes: scale from 8 → 12 replicas immediately
Elastik proposes: rollback the recent deployment
Arbitrator verifies scaling won't breach tenant entitlement or impact co-located tenants
Governance Gateway approves scale-out (Level 3 — within guardrails)
Rollback requires Level 2 — on-call engineer notified via PagerDuty and approves
SLA restored

Time from detection to SLA restoration: under 5 minutes.
Equivalent manual workflow average: over 2 hours.

Phased Deployment

Phase	Weeks	Deliverables	Exit Validation
1: Observe	1–4	Telemetry bus, read-only agents	95% metric coverage, <5s ingestion latency
2: Advise	5–10	Agents recommend, humans execute	80% recommendation accuracy vs. human decisions
3: Assist	11–18	Level 2 autonomy, human notified	Zero SLA violations from agent actions
4: Govern	19–26	Level 3 for Elastik, full autonomy	MTTR < 8 min, cost reduction > 25%

Phase transitions are Helm values overrides — no redeployment needed.

Three Rollback Mechanisms

Action rollback: Every executed action records a compensating action. If outcome verification fails within the rollback time budget, the compensating action fires automatically.

Agent rollback: If an agent's error rate exceeds 10% within a 1-hour sliding window, it is automatically demoted to Level 1.

System rollback: Any operator can run /agents-pause in Slack to instantly demote all agents to Level 1.

Projected Performance

Metric	Industry Baseline	Projected
MTTD	15–30 min	1–3 min
MTTR	1–4 hours	5–15 min
SLA Compliance	99.5–99.9%	>99.95%
False Positive Alerts	70–80% false positive	70–85% reduction
Infrastructure Costs	25–40% overprovisioned	30–40% savings

Key Implementation Lessons

The hard engineering is not the AI. The agent reasoning layer is the simplest component to implement. The difficulty lies in governance policies, MCP server specifications, tenant isolation enforcement, rollback choreography, and human-agent trust calibration.

MCP schema quality determines agent quality. Treat MCP tool descriptions with the same rigor as public API documentation. Ambiguous schemas produce ambiguous agent behavior.

Tenant isolation must be at the protocol level. Prompt-level isolation is not sufficient against adversarial conditions.

Plan for LLM provider outages from day one. The system must degrade gracefully to rule-based automation during LLM unavailability.

The observation phase is not optional. The 4–6 week read-only phase generates baseline data, surfaces integration issues, and builds operator trust.

Cloudflare and GitHub are building identity systems for AI agents. We're not ready for this.

Aditya Agarwal — Sun, 19 Apr 2026 13:19:44 +0000

AI agents are getting their own credentials and nobody is asking who's accountable when they leak. That sentence should terrify you more than it does.

I've been managing secrets at a 15-person startup for a few years now. We can barely keep human API keys out of Git history. The idea of every AI agent running around with its own identity makes me want to close my laptop and go farm goats.

But here we are.

What Actually Happened

Cloudflare just launched a new scannable API token format with prefixes like cfat_. This is smart — it means tokens are instantly recognizable by pattern-matching tools. GitHub Secret Scanning can detect leaked Cloudflare tokens when they show up in a commit, though the revocation process may require manual remediation rather than being fully automatic.

That's genuinely good engineering. Two major platforms cooperating to shrink the window between "oops" and "revoked." I respect it.

But zoom out for a second. Why does this need to exist at all?

The Real Problem Nobody Wants to Say Out Loud

Non-human identities already outnumber human ones in most organizations. Read that again. Service accounts, CI/CD tokens, bot credentials, API keys — they've been quietly multiplying for years. Now add AI agents to the pile.

Each agent requires credentials to do anything useful. Call an API. Read a database. Deploy a service. Each one becomes a new secret to rotate, scope, monitor, and eventually lose track of.

Here's what I've seen firsthand:

→ Secrets get copy-pasted into .env files that end up in repos
→ Service accounts get created for a "quick test" and never get deleted
→ Nobody owns the rotation schedule because nobody owns the bot
→ When something leaks, the first question is always "wait, what even uses this?"

That's the state of things today. With humans mostly in the loop. 🫠

AI Agents Make This Exponentially Worse

When a human leaks a key, you yell at the human. You do a postmortem. You add a pre-commit hook. There's a feedback loop.

When an AI agent leaks a key — or gets prompt-injected into exposing one — who's accountable? The developer who deployed it? The platform that hosted it? The agent framework that didn't sandbox credentials properly?

Nobody has a good answer yet. And startups are already shipping agents with broad API access because speed wins over security every single time at that stage. I know because I've been that person choosing speed.

The Cloudflare + GitHub integration is a safety net. But safety nets work best when you're not actively trying to juggle chainsaws on a tightrope. At startup scale, with a two-person platform team, you're absolutely juggling chainsaws.

What I Think We Should Be Doing

I don't have a complete answer. But I have opinions:

→ Agents should get short-lived credentials by default. Not long-lived API keys. Tokens that expire in minutes, not months.
→ Every non-human identity needs an owner. A real human on the hook. No orphan service accounts.
→ Scope should be laughably narrow. If an agent only needs to read from one endpoint, it gets access to one endpoint. Period.
→ Audit logs for agent actions should be first-class. Not an afterthought bolted on after the first incident.

The cfat_ prefix and auto-revocation are steps in the right direction. But they're band-aids on a wound we haven't even fully discovered yet. 🩹

Here's the Thing

We built identity management for humans over decades and we're still bad at it. Now we're handing credentials to autonomous software that can act at machine speed, make unpredictable decisions, and get tricked by a well-crafted prompt.

The infrastructure isn't ready. The policies aren't ready. The org charts definitely aren't ready. And yet the agents are already shipping.

I'm not saying stop building agents. I'm saying treat agent identity as a first-class security problem right now, not after the first big breach makes it obvious.

So here's my question: who owns non-human identity at your company? Is it security? Platform? DevOps? Or is it the terrifying answer — nobody? 🔐

Building a Smarter Hiring Engine: AI Recruiter with RAG, Memory & Web Search

Ranjan Dailata — Sun, 19 Apr 2026 13:12:54 +0000

This is a submission for Weekend Challenge: Earth Day Edition

Background

What I Built

Recruit Intelligence Agent is an AI-powered recruitment assistant that streamlines hiring through:

Automated candidate screening
Resume parsing
Job description matching
Candidate validation via live web search

It goes beyond traditional ATS systems by combining RAG, memory, web search, and reasoning into a single intelligent workflow powered by BackBoard

Overview

Recruit Intelligence Agent is a production-ready AI-powered recruitment API built with FastAPI and Backboard. It streamlines the hiring process through automated candidate screening, resume parsing into standardized JSON Resume format, intelligent job matching with gap analysis, job description generation with market research, and candidate validation via live web searches.

Key capabilities:

Parse resumes (Backboard supported files) into structured JSON Resume format
Evaluate candidates against job descriptions with scoring and analysis
Perform deep agentic reasoning with multi-step analysis pipelines
Validate candidate work history and credentials via web search
Research skill market trends and salary ranges
Generate optimized, inclusive job descriptions
Analyze team composition for skill gaps
General document Q&A and summarization

Core Features

Resume Parsing

Extracts structured JSON Resume data from the supported file types:

Basics (name, email, summary)
Work history
Education
Skills
Projects
Certifications

Supported File Types

Category	Extensions
Documents	`.pdf`, `.doc`, `.docx`, `.ppt`, `.pptx`, `.xls`, `.xlsx`
Text / Data	`.txt`, `.csv`, `.md`, `.markdown`, `.json`, `.jsonl`, `.xml`
Images	`.png`, `.jpg`, `.jpeg`, `.webp`, `.gif`, `.bmp`, `.tiff`, `.tif`

Candidate Evaluation

Scores candidates against job descriptions
Identifies:
- Skill gaps
- Transferable skills
- Risk factors

Agentic Reasoning

Multi-step pipeline:

Parse resume
Extract skills
Research market demand
Analyze job fit
Validate claims

Web Search Validation

Verifies candidate profiles
Validates company work history
Research skill trends

Memory-Enabled Reasoning

Stores candidate details automatically
Improves future evaluations
Enables contextual decision-making

Document Q&A

Ask questions about resumes and get contextual answers.

Job Description Generator

Generates optimized and inclusive JDs
Includes:
- Responsibilities
- Skills
- Market insights
- Inclusivity checks

Demo

Run locally with FastAPI and accessing the API documentation:

Swagger UI: http://localhost:8000/docs
ReDoc: http://localhost:8000/redoc
Health check: http://localhost:8000/health
Cost metrics: http://localhost:8000/metrics/costs

Generate Job Description

Summarization

Parse Resume Document

Quick Start

The application supports two modes of operation:

Mode 1: Stateful (Recommended for multiple operations on same document)

# Step 1: Upload a document
curl -X POST http://localhost:8000/upload -F file=@resume.pdf

# Response: {"thread_id": "thread_xxx", "status": "indexed"}

# Step 2: Use thread_id for all subsequent calls
curl -X POST http://localhost:8000/parse -F thread_id=thread_xxx
curl -X POST http://localhost:8000/evaluate -F thread_id=thread_xxx -F job_description="Senior Python Developer with Django, PostgreSQL experience..."
curl -X POST http://localhost:8000/comprehensive_evaluate -F thread_id=thread_xxx -F job_description="Senior Python Developer..."

Mode 2: Fallback (Single operation, creates new session each time)

# Direct file upload - no need to manage document_id/thread_id
curl -X POST http://localhost:8000/parse -F file=@resume.pdf
curl -X POST http://localhost:8000/evaluate -F file=@resume.pdf -F job_description="Senior Python Developer..."

Code

GitHub Repository:
https://github.com/ranjancse26/recruit_intelligence_agent

Installation

Clone the repository and navigate to the project directory
Create and activate a virtual environment:
- Windows: venv\Scripts\activate
- Linux/Mac: source venv/bin/activate
Install dependencies:
pip install -r requirements.txt
Configure environment variables in .env file:
BACKBOARD_API_KEY=your_api_key_here
BACKBOARD_LLM_PROVIDER=openai
BACKBOARD_MODEL_NAME=gpt-5-mini
BACKBOARD_TIMEOUT=1800

Running the Application

uvicorn app.main:app --reload

Endpoint Examples

Parse Resume (JSON Resume format)

curl -X POST http://localhost:8000/parse -F thread_id=thread_xxx

Returns structured resume data with basics, work, education, skills, projects, etc.

Evaluate Candidate

curl -X POST http://localhost:8000/evaluate \
  -F thread_id=thread_xxx \
  -F job_description="Senior Python Developer with 5+ years experience in Django, FastAPI, PostgreSQL, AWS"

Returns score, strengths, gaps, risk flags, and recommendation.

Comprehensive Agentic Evaluation

curl -X POST http://localhost:8000/comprehensive_evaluate \
  -F thread_id=thread_xxx \
  -F job_description="Senior Python Developer..."

Performs full pipeline: resume parsing → skill extraction → market research → job fit analysis → validation.

Summarize Document

curl -X POST http://localhost:8000/summarize -F thread_id=thread_xxx

Reason on Document

curl -X POST http://localhost:8000/reasoning \
  -F thread_id=thread_xxx \
  -F question="What are the candidate's leadership experiences?"

Q&A

curl -X POST http://localhost:8000/qa \
  -F thread_id=thread_xxx \
  -F question="What Python frameworks has the candidate used?"

Web Search for Candidate

# General search
curl -X POST http://localhost:8000/websearch \
  -F thread_id=thread_xxx \
  -F query="John Doe Python developer GitHub"

# Search with known details
curl -X POST http://localhost:8000/websearch \
  -F name="John Doe" \
  -F email="john@example.com" \
  -F company="Google"

Validate Candidate Profile

curl -X POST http://localhost:8000/validate \
  -F name="John Doe" \
  -F email="john@example.com" \
  -F company="Google"

Validate All Companies from Resume

curl -X POST http://localhost:8000/validate-companies \
  -F thread_id=thread_xxx

Generate Job Description

curl -X POST http://localhost:8000/jd/generate \
  -F role_requirements="Senior Python Developer with Django, FastAPI, PostgreSQL experience. 5+ years of backend development."

Research Role Market Trends

curl -X POST http://localhost:8000/jd/research-trends \
  -F role="Software Engineer" \
  -F industry="Technology"

Analyze Existing Team

curl -X POST http://localhost:8000/jd/analyze-team \
  -F team_composition_json='[{"role": "Frontend Developer", "skills": ["React", "TypeScript"], "experience": 3}, {"role": "Backend Developer", "skills": ["Python", "Django"], "experience": 5}]'

How I Built It

Tech Stack

Python 3.8+
FastAPI
Backboard SDK
Pydantic
python-multipart

Architecture

recruit_intelligence_agent/
├── app/
│   ├── main.py
│   ├── routes.py
│   ├── core/
│   │   └── monitoring.py
│   ├── services/
│   │   └── backboard_client.py
│   └── tools/
│       ├── reasoning_tools.py
│       ├── resume_tools.py
│       ├── candidate_websearch.py
│       ├── jd_generator.py
│       └── resume_schema.json
├── requirements.txt
├── .env
└── README.md

Key Technical Decisions

1. Backboard Integration

Document upload with indexing
Thread-based conversations
Memory-enabled reasoning
Web search integration

2. JSON Resume Schema

{
  "basics": {
    "name": "",
    "label": "",
    "email": "",
    "phone": "",
    "url": "",
    "summary": "",
    "location": {
      "address": "",
      "city": "",
      "region": "",
      "postalCode": "",
      "countryCode": ""
    },
    "profiles": []
  },
  "work": [
    {
      "name": "",
      "position": "",
      "url": "",
      "startDate": "",
      "endDate": "",
      "summary": "",
      "highlights": []
    }
  ],
  "education": [
    {
      "institution": "",
      "area": "",
      "studyType": "",
      "startDate": "",
      "endDate": "",
      "score": "",
      "courses": []
    }
  ],
  "skills": [
    {
      "name": "",
      "level": "",
      "keywords": []
    }
  ],
  "projects": [
    {
      "name": "",
      "description": "",
      "highlights": [],
      "keywords": []
    }
  ],
  "awards": [],
  "certificates": [],
  "publications": [],
  "languages": [],
  "interests": [],
  "references": [],
  "meta": {}
}

3. Agentic Reasoning Pipeline

Step 1: Resume parsing
Step 2: Skill extraction
Step 3: Market research
Step 4: Job fit scoring
Step 5: Validation

4. Memory Layer

Stores candidate summaries
Enables better future decisions

5. Dual Mode Operation

Stateful mode with thread + document IDs
Stateless fallback mode

API Endpoints

Endpoint	Description
POST /upload	Upload document
POST /parse	Parse resume
POST /evaluate	Evaluate candidate
POST /comprehensive_evaluate	Full reasoning pipeline
POST /summarize	Summarize document
POST /reasoning	Run reasoning
POST /qa	Ask questions
POST /websearch	Web search
POST /validate	Validate profile
POST /validate-companies	Validate companies
POST /jd/generate	Generate JD
POST /jd/research-trends	Market trends
POST /jd/analyze-team	Team analysis

Job Description Generator

Inclusive language checks
Clarity scoring
Market trend integration
Skill gap analysis

Interesting Implementation Details

Document polling until indexed
Schema-driven parsing
Graceful error handling
Company validation via web search
Skill demand analysis

Prize Category

Best Use of Backboard

Document processing
Memory-enabled reasoning
Web search integration
Agentic workflows

Summary

Recruit Intelligence Agent is an AI-powered hiring assistant built on Backboard that transforms traditional recruitment into an intelligent, data-driven process.

It combines document understanding (RAG), persistent memory, real-time web search, and multi-step reasoning to go beyond keyword-based screening and enable true candidate evaluation.

The agent can:

Parse resumes into structured intelligence
Match candidates to job descriptions with context awareness
Validate candidate profiles using live web data
Perform reasoning-based scoring with explainable insights

Unlike conventional ATS systems, it doesn't just filter resumes — it understands experience, identifies transferable skills, and makes informed hiring recommendations.

The result is:

Faster screening
Better candidate fit
Smarter, explainable hiring decisions

Built with ❤️ for the Earth Day Hackathon 2026

How I Structure Every .NET Project (Clean Architecture Breakdown)

Ayman Atif — Sun, 19 Apr 2026 13:09:20 +0000

Most .NET projects don’t fail because of bad code.
They fail because of unclear structure.

When everything is dumped into a single project or loosely organized folders, things feel fine at first — until the project grows. Then small changes start breaking unrelated parts, testing becomes painful, and onboarding new devs turns into a mess.

Over time, I’ve converged on a simple structure that avoids most of these problems without overengineering.

Here’s how I structure almost every .NET project.

The core idea: separation of responsibility

The goal isn’t “complex architecture.”
It’s predictable boundaries.

Each part of the system should have one reason to change.

So I split my projects into 4 layers:

API
Application
Domain
Infrastructure

1. Domain layer (the center of everything)

This is the core of the system.

It contains:

Entities
Value objects
Domain rules
Core business logic

No dependencies on anything external.

Example:

User
Order
Invoice

The rule here is simple:
If you remove everything else, this should still make sense.

2. Application layer (use cases)

This is where the business workflows live.

It contains:

Use cases (CreateOrder, RegisterUser, etc.)
Interfaces (contracts)
DTOs
Validation logic

This layer defines what the system does, not how it does it.

It depends on the Domain layer, but nothing else.

3. Infrastructure layer (implementation details)

This is where external systems live:

Database (EF Core, Dapper)
Email services
File storage
External APIs

This layer implements interfaces defined in Application.

Example:

IEmailService → implemented here
IUserRepository → EF Core implementation here

This keeps your core logic independent from frameworks.

4. API layer (entry point)

This is the thin outer layer.

It contains:

Controllers / endpoints
Dependency injection setup
Request/response handling

Its job is simple:

Receive input → call Application → return output

No business logic should live here.

Why this structure works

This setup gives you:

Clear boundaries between concerns
Easier testing (especially Application layer)
Swap database or services without touching business logic
Scalable structure for real projects

But more importantly:

You stop thinking about “where should this go?” every time you write code.

The mistake most devs make

They either:

Overcomplicate architecture early
or
Put everything in one project until it breaks

This sits in the middle:

Simple enough to start fast, structured enough to scale.

I packaged this into a starter setup

After rebuilding this structure across multiple projects, I turned it into a ready-to-use starter kit so I don’t repeat the setup every time.

If you want a clean .NET foundation you can just clone and build on:

https://yaman95.gumroad.com/l/clean-core-dot-net-starter-kit

AI Masters vs Everyone Else

Jono Herrington — Sun, 19 Apr 2026 13:06:20 +0000

I closed Cursor after ten minutes.

It was September. Everyone was talking about AI agents and context windows and something called "agent mode" that supposedly changed everything. I downloaded Cursor, opened it, watched it index my codebase ... and felt my chest tighten. The interface was wrong. The shortcuts were wrong. Everything I'd spent fifteen years optimizing was suddenly foreign.

I went back to VS Code that afternoon. Told myself I'd try again later. Kept maxing out my GitHub Copilot credits instead.

Three weeks later, I tried again. This time I stayed long enough to build something real. Now I have ChatGPT, Claude, Cursor with multiple models, and OpenClaw + Ollama running in a virtual environment. I use different tools for different problems. I've become the person I couldn't imagine being in that first ten minutes.

The divide I almost fell into isn't about willingness to try new things. It's deeper than that. The split won't be good developers versus bad developers. It'll be AI masters versus everyone else. And the gap is already widening faster than most people realize.

The split won't be good developers versus bad developers. It'll be AI masters versus everyone else.

The $2,000 Engineer

I've been talking to principal engineers across the industry. Large enterprise companies. Household names. People whose scope spans systems most developers never touch. And I'm seeing a pattern that contradicts the mainstream narrative entirely.

The analysts say AI is a 2-5x multiplier. The principal engineers I'm talking to say that's wrong. They argue AI isn't multiplication ... it's exponentiation.

One of them spends over $2,000 a month on tokens. Not because he's wasteful. Because he's built systems that compound. He's orchestrating agent loops, chaining workflows, training algorithms on his codebase until they anticipate his architectural decisions. The output isn't faster code. It's different code. Solutions he wouldn't have reached through traditional means.

These aren't junior engineers copy-pasting Claude outputs. These are masters of their craft who recognized that systematic thinking ... the skill that got them to principal ... is the exact skill that unlocks AI's real potential.

They're not prompting. They're building operating systems.

They're not prompting. They're building operating systems.

The License Turned In

I have another story. An old colleague. Tech lead at a well-known lifestyle brand. Solid engineer. Smart person. Someone who could solve problems other people got stuck on.

His company doesn't mandate AI usage. Some teams use it, some don't. Leadership treats it like a preference ... Vim versus Emacs, tabs versus spaces. Personal choice.

He turned in his AI license.

Said he wanted to stay "pure." Keep his skills sharp the traditional way. Prove he could still code without assistance. And I get the instinct ... I had it in those first ten minutes with Cursor. The discomfort of a new tool feels like a threat to your identity.

But here's what I can't reconcile. No one can deny the speed. No one can deny the output. The engineers spending $2,000 a month aren't producing marginally better work. They're producing categorically different work. Solutions at different altitudes. Architectures that wouldn't emerge from traditional workflows.

My old colleague thinks he can catch up when he's ready. That the gap is just familiarity with a new interface. Ten minutes of discomfort, stretched across a few weeks.

He's wrong.

What Masters Actually Do

The narrative that AI is "just prompting" is dangerously incomplete. Yes, you can get value from good prompts. But the engineers who are pulling ahead aren't writing better prompts. They're thinking in systems.

A regular AI user goes to their codebase and says: "I need a function that does X." They write a prompt. They get frustrated when the output is non-deterministic. They try again. They settle for something close enough.

The master builds differently. They start with guardrails. Error handling patterns. Architectural constraints encoded into the environment. They train their AI on their standards until it knows ... before they ask ... what "good" looks like in their system.

Principal engineers have an unfair advantage here. They're already thinking in systems. They've spent years building mental models of how components interact, where complexity hides, which abstractions hold and which collapse. AI doesn't replace that thinking. It amplifies it.

Principal engineers have an unfair advantage. They're already thinking in systems.

The master engineer doesn't fight the non-determinism. They harness it. They know that asking the same question three times yields three valid approaches, and their job is selecting the right one for the context. They're curators, not just consumers.

This is why "I use ChatGPT sometimes" doesn't mean what people think it means. The tool is available to everyone. The operating system around the tool is what separates the masters from everyone else.

The Non-Determinism Problem

People complain that AI is unreliable. Same prompt, different outputs. Unpredictable behavior. Hard to trust.

But humans are equally non-deterministic. Ask an engineer the same architecture question three times ... morning, afternoon, after a bad deploy ... and you'll get three different answers based on sleep, stress, blood sugar, whether their standup ran long. We've always managed this variability with standards and accountability. Code review. Design patterns. Architectural decision records.

The same solution applies to AI. The problem isn't tool reliability. It's absence of standards.

The engineers who are thriving aren't luckier or working with better models. They've built constraint systems. Their AI operates inside encoded rules ... lint configs, architectural tests, workflow definitions that keep the creativity pointed in productive directions.

This is what I missed in my first ten minutes with Cursor. I thought the tool was the unlock. It's not. The unlock is the system you build around the tool.

The Two Camps

This story has been told before. New technology arrives. Two camps form. One embraces the change, builds expertise, pulls ahead. The other waits for the dust to settle, for best practices to emerge, for the tool to mature.

Only one camp ever wins.

The divide isn't about talent. Talent is too distributed, too random. The divide is timing. How early someone decided this was worth getting good at.

I see it in my own trajectory. Those first ten minutes of discomfort could have stretched into weeks, months, years. I could have kept maxing out Copilot credits in VS Code, telling myself I was staying current, while the real practitioners were building fundamentally different capabilities.

The engineers spending $2,000 a month on tokens aren't spending money. They're buying optionality. They're compounding advantages that will compound again before the late adopters even recognize the game has changed.

The engineers spending $2,000 a month on tokens aren't spending money. They're buying optionality.

What This Means for Leaders

If you're leading engineering teams, you have a decision to make. You can treat AI like a productivity tool ... optional, preference-based, something engineers pick up if they're interested. Or you can recognize it as a fundamental shift in what engineering excellence looks like.

The "purists" on your team aren't preserving their skills. They're preserving their comfort. And comfort is expensive in a market that's moving this fast.

The question isn't whether your engineers use AI. It's whether they've built systematic approaches to using it well. Whether they can describe their eval harnesses, their agent loops, their constraint systems. Whether they've thought beyond prompting to orchestration.

If they can't ... they're not in the first camp. They're in the second.

The measuring stick has changed. You're not being evaluated against the engineer next to you anymore. You're being evaluated against the one who started practicing eighteen months ago.

The split is here. The camps are formed. Darwin already explained what happens next.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Fusion: Everything Is a Modular Package

Sergej Willmann — Sun, 19 Apr 2026 13:01:44 +0000

What if there were no traditional static root projects and package types, allowing a package manager to build the root project along with its dependencies? To see how this generic approach benefits PHP projects and which problems it solves, let's look at the core implementation of Fusion's modularity:

Projects are modular packages.
Packages can depend on each other and even themselves.
Packages are built the same way and share a unified state with per-package stateful files.

Recursive Dependency Graph

The ability for a package to depend on itself makes standalone packages manageable and removes the need for static initial distributions. Instead, root and nested packages are built within a single dependency graph:

Since Fusion itself is also a package, it works well as a real-world example:

A: Fusion - Package Manager
B: Box - DI Container

In its own metadata, the package manager depends on a dependency injection container for abstraction, and for user-friendly non-breaking updates (2.x.x), it also depends on itself:

{
    "structure": {
        "valvoid.com/valvoid": "fusion/2.0.0",
        "/dependencies": "valvoid.com/valvoid/box/2.0.0"
    }
}

Because these dependencies are defined in the metadata, the maintenance command remains user-friendly without arguments:

fusion build

For major upgrades, for example for future release 3.0.0, an explicit reference argument must be passed to override the fallback reference defined in the metadata:

fusion build build.source=valvoid.com/valvoid/fusion/3.0.0

Regardless of how the reference is passed, Fusion connects different versions of the same root package into a recursive graph. The higher version can either trigger a custom migration script or rely on Fusion's default behavior.

Open Dependency Graph

Without static root projects, graphs can expand upward. The flexible entry point, which shifts with each new reference, lets standalone packages become default dependencies that parent packages can consume and extend:

For example, Fusion itself is such a default package:

Determining which parent packages customize a default package, and in what order they are applied, is not trivial. For this reason, Fusion provides built-in extension logic at the metadata layer, which it also uses itself. The package manager exposes the virtual config path in production metadata via the extendable indicator and expects the generated extender data to be in the stateful directory:

{
    "structure": {
        "/config": "extendable",
        "/state": "stateful"
    }
}

A custom package manager, as an extender package on top, declares Fusion as a dependency in its production metadata and maps its own configuration directory into the exposed virtual path:

{
    "structure": {
        "/config": ":valvoid/fusion/config",
        "/dependencies": "valvoid.com/valvoid/fusion/2.0.0"
    }
}

Since the relation is abstract, the extender does not pass anything directly to Fusion's configuration. Instead, it contributes to the shared state generated during the build process, constrained only by the config schema:

fusion build

Once completed, Fusion, like any other default package, reads the ordered extender directories from the generated extensions.php file in its own stateful directory:

return [

    // exposed virtual path
    "/config" => [

        // mapped extender directories
        2 => "<absolute extender root dir>/config",
       #3 => "<other extender>",
    ]
];

During subsequent executions, the package manager applies all mapped configs in deterministic top-down order without exposing merge logic to extenders, minimizing overhead.

Circular Dependency Graph

Due to unrestricted references, packages can depend on each other, resulting in a graph relative to its entry point. This allows the graph to be reused across different builds by constructing it from different nodes:

Reflex and Box are example packages that share such a graph:

A: Reflex - Testing Framework
B: Box - DI Container

Testing upcoming releases before your own release, such as breaking changes in the 2.0.0 dependency injection container used by Reflex for abstraction, is the most interesting part of such relationships. The default Valvoid registry
is production-only and limited to its own sources (valvoid.com/<path>/<reference>), so the Reflex production metadata fusion.json prepends the 2.0.0 reference pattern for upcoming versions using the logical || operator and applies the changes along with the next bugfix release 1.0.1:

{
    "version": "1.0.1",
    "structure": {
      "/dependencies": "valvoid.com/valvoid/box/2.0.0||1.1.0"
    }
}

Inside the shared development metadata fusion.dev.php, Reflex drops the production source by setting it to null and defines the upcoming version 2.0.0 using the GitLab repository branch 2.0 as the offset:

return [
    "structure" => [
        "/dependencies" => [
            "gitlab.com/valvoid/box/'code/==2.0.0:2.0",
            "valvoid.com/valvoid/box" => null
        ]
    ]
];

Box, in parallel, increases its version in the production metadata fusion.json to 2.0.0, and in the shared development metadata fusion.dev.php it also changes the source to the GitLab repository branch 1.0 as the offset:

{
    "version": "2.0.0"
}

return [
    "structure" => [
        "/dependencies" => [
            "gitlab.com/valvoid/reflex/'code/==1.0.1:1.0"

            // previous production source
            // "valvoid.com/valvoid/reflex/1.0.0"
        ]
    ]
];

Using separated metadata files, both packages build each other for testing inside the pipeline with upcoming versions by running the build command:

fusion build

Wrapping Up

These are the use cases I have found in my projects and implemented in Fusion. There will likely be more as it is used in additional projects and different setups. If you like the approach without traditional static root projects and package types, you can try Fusion in your next project:

Package: Default Valvoid registry
Project: GitLab repo

Tokio Versus Goroutines: Latency Under Adversarial Load

speed engineer — Sun, 19 Apr 2026 13:00:00 +0000

When memory pressure meets tail latency requirements, the conventional wisdom about async runtimes crumbles under real-world data

Tokio Versus Goroutines: Latency Under Adversarial Load

When memory pressure meets tail latency requirements, the conventional wisdom about async runtimes crumbles under real-world data

Under adversarial conditions, different async runtimes show dramatically different latency characteristics that challenge popular assumptions about performance.

The Conventional Wisdom Gets It Wrong

Ask any developer about choosing between Rust’s Tokio and Go’s goroutines, and you’ll hear familiar refrains: “Go is simpler,” “Goroutines just work,” “Rust is faster but harder.” This surface-level analysis misses a critical reality that emerges only under adversarial load conditions.

The breakthrough moment came during a production incident at a financial services company. Their Go-based trading system, handling 50,000 concurrent connections with sub-millisecond latency requirements, began showing tail latencies spiking to 200+ milliseconds during market volatility. The culprit wasn’t network congestion or database bottlenecks — it was memory pressure causing goroutine scheduler degradation.

When Good Runtimes Go Bad: The Memory Wall

Under normal conditions, both Tokio and goroutines perform admirably. But “adversarial load” isn’t just about connection count — it’s about resource exhaustion patterns that reveal fundamental architectural differences.

Recent benchmarking data shows a stark divergence when systems approach memory saturation:

The Goroutine Memory Explosion

Goroutines consumed far more RAM than Rust required when scaling to high task counts. At 100,000 concurrent tasks, goroutines exhibited a 3x memory overhead compared to Tokio tasks. This isn’t just about efficiency — it’s about failure modes.

When a Go application approaches memory limits, the runtime’s garbage collector becomes increasingly aggressive. GC pause times that normally measure in microseconds can spike to tens of milliseconds under pressure. For each goroutine waiting on I/O, the runtime maintains stack space (typically 2KB initially, growing as needed) plus scheduling metadata.

// Tokio task: Zero-cost futures


async fn handle_connection(stream: TcpStream) {


    // Future state machine: ~200 bytes


    process_data(stream).await;


}

// Goroutine: Preemptive scheduling overhead


go func() {


    // Stack space: 2KB minimum + scheduling overhead


    handleConnection(conn)


}()

The Tokio Advantage: Deterministic Memory Patterns

Rust tokio remained unbeatable in memory consumption tests. Tokio’s futures are zero-cost abstractions that compile down to state machines. Each async task consumes only the memory needed for its actual state, typically 200–400 bytes for I/O-bound operations.

More critically, Tokio’s memory usage patterns are predictable. No garbage collection means no surprise pause times. No stack-per-task means memory usage scales linearly with actual work, not potential work.

The Tail Latency Trap: When P99 Becomes P50

The real performance divergence appears in tail latency measurements — the metrics that matter most for user experience and SLA compliance.

Goroutine Scheduler Breakdown

Under memory pressure, Go’s scheduler exhibits work-stealing inefficiencies. When goroutines exceed available processors (common in I/O-heavy workloads), the scheduler must constantly migrate work between threads. Each migration involves:

Context switching overhead (1–2 microseconds)
Cache line invalidation
Memory barrier synchronization

These costs compound exponentially under adversarial load. A P99 latency of 2ms can degrade to 50ms when the scheduler becomes saturated.

Tokio’s Cooperative Scheduling Wins

Tokio introduced automatic cooperative task yielding to address tail latency issues. The key insight: cooperative scheduling with preemption guards provides better latency guarantees than preemptive scheduling under load.

Tokio’s approach:

Tasks yield voluntarily at await points
Runtime tracks execution time per task
Automatic yielding prevents monopolization
No context switching overhead between tasks on the same thread

Goroutine context switches create latency spikes that compound under load, while Tokio’s cooperative model maintains predictable execution patterns.

The Production Reality Check: Real Numbers

Let’s examine concrete data from high-load scenarios:

Memory Efficiency Under Pressure

100K concurrent connections :
Tokio: ~800MB RAM usage
Goroutines: ~2.4GB RAM usage
1M concurrent connections :
Tokio: ~8GB RAM usage
Goroutines: ~24GB+ RAM usage (often triggers OOM)

Latency Distribution Analysis

Under 10,000 req/sec with memory pressure:

Goroutines:

P50: 1.2ms
P95: 15ms
P99: 45ms
P99.9: 200ms+

Tokio:

P50: 0.8ms
P95: 2.1ms
P99: 4.5ms
P99.9: 12ms

The difference isn’t just magnitude — it’s predictability. Tokio’s latency distribution remains tight even under adversarial conditions.

The Architecture Behind the Numbers

Why Goroutines Struggle

Goroutines are OS threads in disguise when it comes to memory overhead. The M:N threading model (M goroutines on N OS threads) introduces several bottlenecks:

Stack management complexity : Growing and shrinking stacks requires memory copies
Scheduler lock contention : Global run queue becomes a bottleneck
GC coordination overhead : All goroutines must coordinate during collection cycles

Why Tokio Scales

Tokio implements single-threaded event loops with work stealing. This architecture provides:

Zero-allocation futures : State machines generated at compile time
Lock-free scheduling : Per-thread queues minimize contention
Predictable memory patterns : No GC, deterministic cleanup

// Tokio runtime configuration for adversarial load

[tokio::main]

async fn main() {

let rt = tokio::runtime::Builder::new_multi_thread()

.worker_threads(num_cpus::get())

.thread_keep_alive(Duration::from_millis(100))

.enable_all()

.build()

.unwrap();
```
// Handles 100K+ connections efficiently  
```
}

The Decision Framework: When Data Demands What

Based on production data and architectural analysis, here’s your decision matrix:

Choose Goroutines When:

Team velocity matters more than tail latency (P99 > 10ms acceptable)
Memory is abundant (>4GB per 10K connections available)
Development speed trumps runtime efficiency
Moderate load (<1000 concurrent connections)

Choose Tokio When:

Tail latency requirements are strict (P99 < 5ms required)
Memory efficiency is critical (embedded systems, containers)
High concurrency (10K+ concurrent connections)
Predictable performance under stress is non-negotiable

The Hybrid Approach

For some teams, the answer is both :

Go for rapid prototyping and business logic
Rust/Tokio for performance-critical components
Service mesh architecture allows language-per-service optimization

A systematic approach to choosing between Tokio and Goroutines based on measurable constraints rather than preferences.

Implementation Strategy: Making the Switch

If your analysis points toward Tokio, the migration strategy matters:

Phase 1: Baseline Measurement

# Establish current Go performance baseline


go test -bench=. -benchmem -count=5

Phase 2: Critical Path Migration

Start with your highest-load, latency-sensitive endpoints. These show the clearest benefits and provide immediate ROI measurement.

Phase 3: Gradual Expansion

Expand Tokio usage based on measured improvements , not assumptions.

The Bottom Line: Data Drives Decisions

The choice between Tokio and goroutines isn’t about language preference — it’s about system requirements under adversarial conditions. When memory pressure meets strict latency requirements, Tokio’s architectural advantages become decisive.

The data is clear: tokio performs just as fast as the may under optimal conditions, but significantly outperforms goroutines when systems approach their limits. In production environments where resources are constrained and latency matters, Tokio’s predictable performance characteristics provide a crucial advantage.

Your choice should be driven by measurable requirements:

Can you tolerate 50ms+ P99 latencies under load? Goroutines might suffice.
Do you need <5ms P99 with predictable memory usage? Tokio is your answer.
Is development velocity your primary constraint? Consider the hybrid approach.

The conventional wisdom falls short because it doesn’t account for adversarial conditions. Real production systems don’t run in optimal environments — they run under pressure, with constrained resources and demanding SLAs. That’s where architectural choices matter most, and where Tokio’s design philosophy shines.

Enjoyed the read? Let’s stay connected!

🚀 Follow The Speed Engineer for more Rust, Go and high-performance engineering stories.
💡 Like this article? Follow for daily speed-engineering benchmarks and tactics.
⚡ Stay ahead in Rust and Go — follow for a fresh article every morning & night.

Your support means the world and helps me create more content you’ll love. ❤️

🌍 I Built an Interactive Climate Simulator Where You Control Earth's Fate

Rohan Mirjankar — Sun, 19 Apr 2026 12:59:34 +0000

This is a submission for Weekend Challenge: Earth Day Edition 🌍

What I Built

I built the Earth Condition Simulator — an interactive, browser-based climate model that puts the fate of our planet directly in your hands.

You control six critical environmental parameters — Temperature, Sea Level, Forest Cover, Pollution, Ice Caps, and Clean Energy — and watch Earth respond in real time. The globe visually reacts to every change: ice caps melt, toxic smog rolls in, forests burn, and oceans turn murky. Make things good enough and the planet thrives; push things too far and you're staring at near-extinction.

The core idea was to make climate data feel visceral rather than abstract. Instead of graphs and tables, you get a living, breathing globe that screams back at you when things go wrong.

Demo

🔗 Live Demo → rohan-shridhar.github.io/earth

Rohan-Shridhar / earth

Earth Condition Simulator

🌍 Earth Condition Simulator

An interactive, high-fidelity browser-based simulator that puts the fate of our planet in your hands. Adjust environmental factors in real-time and witness the immediate visual and biological consequences on a global scale.

🚀 What I Built

I built an interactive climate model and survival simulator. Users control six critical environmental sliders—Temperature, Sea Level, Forest Cover, Pollution, Ice Caps, and Clean Energy—to observe their real-time impact on Earth's vitality.

The project features a custom-rendered SVG globe that reacts visually to your settings (melting ice caps, toxic oceans, spreading smog) and includes a professional-grade simulation engine that projects human population changes over a 10-year period based on your ecological choices.

🔗 Demo

Live Demo →

✨ Features

Animated SVG Earth: A custom-built globe with organic bezier-path continents and real-time visual updates.
6-Axis Environmental Control: Fine-tuned sliders for a wide range of climate scenarios.
Live…

View on GitHub

Features at a Glance

🌍 Animated SVG Globe — Custom-built with organic Bezier-path continents, real-time ocean color shifting, smog overlays, fire particles, cloud layers, and polar ice caps — all reacting live to your slider input
6 Environmental Sliders — Temperature (−2°C to +10°C), Sea Level, Forest Cover, Pollution, Ice Caps, and Clean Energy
Earth Health Score — A unified 0–1000 vitality meter with reactive color-coded status labels (from Thriving Paradise to Near Extinction)
Real-time Population Ticker — A frame-by-frame world population counter (8.2B baseline) that ticks up or down based on current planetary health
Event Feed — Contextual alerts that surface climate events based on your settings ("Coral reefs fully bleached worldwide", "Low-lying island nations submerged", etc.)
10-Year Simulation Engine — A projection model that calculates year-by-year population impact based on all six variables combined, with animated reveal and a color-coded survival verdict
Zero Dependencies — Pure Vanilla HTML5, CSS3, and JS. No frameworks, no libraries, no build step.

How I Built It

This was built using Antigravity — a vibe coding tool powered by Google Gemini 2.0 Pro — with a deliberate "Single File → Split Architecture" workflow. I started with a single monolithic prototype to get the logic right, then refactored into index.html / style.css / script.js for maintainability.

The Globe Rendering Pipeline

The globe is a pure SVG with layered groups for ocean, land, clouds, ice caps, smog, and fire. Each frame (via requestAnimationFrame), the renderer:

Recomputes ocean color based on temperature + pollution (deep blue → murky brown)
Shifts the atmosphere stroke hue reactively
Translates continent and cloud positions to simulate rotation
Calculates biome visibility (forest → desert → jungle) based on sliders
Renders fire particle ellipses when temp > 5 and forest < 55%

The Simulation Math

The 10-year engine runs a loop calculating annual population growth starting from 8.2B, applying weighted penalties per variable:

let growth = 80; // Base +80M/yr
growth -= (temp / 10) * 200;
growth -= (poll / 100) * 150;
growth -= (1 - forest / 100) * 100;
growth -= (sea / 10) * 80;
growth -= (1 - energy / 100) * 60;
growth -= (1 - ice / 100) * 40;

Getting the weights to feel scientifically plausible and emotionally impactful — without being either too forgiving or instantly catastrophic — took the most tuning.

The UI

Orbitron + Space Mono for that command-center sci-fi feel. Glassmorphism-lite with a deep space background, CSS starfield, and reactive glow shadows on the globe (drop-shadow that intensifies as Earth Health drops). All slider tracks fill with the current condition color dynamically via inline background updates.

Challenges

SVG Realism — Making the globe look like an actual planet using only paths, gradients, and ellipses was harder than expected. Organic-looking continents required a lot of manual Bezier tuning. The rotation effect is a fake — two copies of the continent group translate infinitely and wrap around — but it sells the illusion.

Balancing the Math — The simulation needed to feel consequential. Too lenient and players don't feel the stakes; too brutal and it's demoralizing. The current formula was iterated ~8 times.

Single-File Performance — Keeping everything smooth at 60fps without any external state management or virtual DOM meant being careful about what gets recomputed each frame vs. what's event-driven.

Prize Categories

🏆 Best Use of Google Gemini — Built using Antigravity, which is powered by Google Gemini 2.0 Pro as its underlying model for code generation and iteration.

Understanding Subqueries and CTEs in SQL

Tom Chege — Sun, 19 Apr 2026 12:58:22 +0000

After getting comfortable with joins and window functions, I’m now diving into more advanced query structuring techniques.

Subqueries felt like a natural extension of filtering and aggregation. CTEs, on the other hand, introduced a cleaner way of breaking down complex logic into readable, step-by-step components.

This guide provides a practical comparison of both concepts using a simple student exam results dataset, highlighting when and why to choose one over the other.

What is a Subquery?

A subquery is a query nested inside another query. It runs first, and its result is used by the outer (main) query.

Subqueries can be placed in:

SELECT clause
FROM clause
WHERE or HAVING clause

Why Use Subqueries?

Subqueries are useful when you need to:

Perform intermediate calculations
Apply dynamic filtering
Break down complex logic without creating temporary tables
Keep queries self-contained

1. Subqueries in the WHERE Clause

This is the most common use case.

Example: Students scoring above the overall average

SELECT 
    student_id,
    marks
FROM exam_results
WHERE marks > (
    SELECT AVG(marks)
    FROM exam_results
);

What’s happening:

The inner query calculates the average marks across all students.
The outer query filters for students who scored above that average.

Subqueries in the WHERE clause with IN and EXISTS

Using IN (for value comparison)

SELECT student_id
FROM exam_results
WHERE student_id IN (
    SELECT student_id
    FROM exam_results
    WHERE marks > 80
);

Using EXISTS (for row existence check)

SELECT DISTINCT e1.student_id
FROM exam_results e1
WHERE EXISTS (
    SELECT 1
    FROM exam_results e2
    WHERE e2.student_id = e1.student_id
    AND e2.marks > 80
);

Key Difference:

IN → Compares values against a list
EXISTS → Checks whether at least one matching row exists (usually more efficient with large datasets)

2. Subqueries in the SELECT Clause

Used to compute additional values for each row.

Example: Show each student’s marks alongside their personal average

SELECT 
    e1.student_id,
    e1.marks,
    (
        SELECT AVG(e2.marks)
        FROM exam_results e2
        WHERE e2.student_id = e1.student_id
    ) AS student_avg
FROM exam_results e1;

Note: This is a correlated subquery — it runs once for every row in the outer query, which can impact performance on large tables.

3. Subqueries in the FROM Clause (Derived Tables)

Creates a temporary result set that can be treated like a table.

Example: Average marks per student

SELECT *
FROM (
    SELECT 
        student_id,
        AVG(marks) AS avg_marks
    FROM exam_results
    GROUP BY student_id
) AS student_avg;

Important: Derived tables must have an alias.

Types of Subqueries

Scalar Subquery: Returns a single value
Column Subquery: Returns multiple rows (usually one column)
Correlated Subquery: References columns from the outer query and runs for each row

What is a CTE (Common Table Expression)?

A Common Table Expression (CTE) is a temporary named result set defined using the WITH clause. It makes queries more readable by breaking them into logical steps.

Think of it as creating a named mini-table that you can reference later in the same query.

Why Use CTEs?

Improved Readability — Break complex logic into named, logical steps instead of deeply nested subqueries
Reusability — Define a result set once and reference it multiple times in the same query
Easier Debugging — You can SELECT * from any CTE individually to test and verify intermediate results
Better Organization — Complex queries become a series of clear building blocks rather than one giant nested statement
Logical Flow — You can build your query step by step, making it easier to understand the thought process
Reduced Repetition — Avoid repeating the same subquery logic multiple times

CTEs are especially powerful when you need to perform multiple transformations or aggregations on the same dataset before joining everything together.

Basic CTE Example: Student averages

WITH student_avg AS (
    SELECT 
        student_id,
        AVG(marks) AS avg_marks
    FROM exam_results
    GROUP BY student_id
)
SELECT *
FROM student_avg;

Types and Use Cases of CTEs

1. Simple CTE

WITH high_scores AS (
    SELECT *
    FROM exam_results
    WHERE marks > 80
)
SELECT * FROM high_scores;

2. Multiple CTEs

WITH student_avg AS (
    SELECT 
        student_id,
        AVG(marks) AS avg_marks
    FROM exam_results
    GROUP BY student_id
),
top_students AS (
    SELECT *
    FROM student_avg
    WHERE avg_marks > 85
)
SELECT * FROM top_students;

3. Recursive CTE

Used for hierarchical or recursive data (e.g., organizational charts, bill of materials). Advanced topic — not ccovered in this article.

Subqueries vs CTEs

Aspect	Subqueries	CTEs (Common Table Expressions)
Readability	Can become hard to read when deeply nested	Much cleaner and more structured
Reusability	Logic must be repeated if used multiple times	Defined once and can be reused multiple times
Performance	Simple subqueries are fast; correlated ones can be slow	Often better with modern optimizers; depends on usage
Debugging	More difficult	Easier (you can `SELECT` from each CTE separately)
Scope	Limited to the immediate query part	Available throughout the entire query

When to Use Each

Use Case	Recommended Choice	Reason
Simple filtering or single value	Subquery	Quick and concise
Complex, multi-step logic	CTE	Better organization and readability
Reusable intermediate results	CTE	Defined once, used multiple times
Row-by-row comparisons	Correlated Subquery	Runs for each row and can reference outer query values
Readability & maintainability	CTE	Easier to read, debug, and maintain

Conclusion

Both subqueries and CTEs help break down complex SQL problems, but they do so in different ways:

Subqueries are great for quick, inline logic that fits naturally inside another clause.
CTEs shine when your query becomes more complex and you want maximum readability and maintainability.

As you progress, the goal shifts from “writing queries that work” to “writing queries that are clear, efficient, and easy to maintain.”

Happy querying!

Paperclip AI Review: I Tried to Build a Zero-Human Company in a Weekend [2026]

Kunal — Sun, 19 Apr 2026 12:51:32 +0000

Paperclip AI Review: I Tried to Build a Zero-Human Company in a Weekend [2026]

Last Friday at 9 PM, I gave an AI a company name, a business goal, and zero employees. By Sunday night, I had an AI-generated brand, a marketing strategy full of hallucinated statistics, and a website that looked like someone fed a blender a stack of Bootstrap templates. Welcome to Paperclip AI, the platform that promises to let anyone build an autonomous company staffed entirely by AI agents. I spent a weekend testing that claim so you don't have to.

Paperclip AI is a platform where you describe a business idea and an AI CEO named "Zeus" recruits AI employees — a CTO, CMO, Sales Rep, and more — to autonomously build and run your company. The premise is wild. The execution taught me a lot about where agent systems actually stand today.

What Is Paperclip AI and How Does It Work?

Paperclip AI was built and launched in roughly one month by founder Ayush Pathak. The pitch, as Pathak described on X, is straightforward: "The goal is to let anyone build an autonomous company by hiring AI employees."

Here's how it works in practice. You visit paperclip.ai, give your company a name and a goal, and Zeus — the platform's AI CEO agent — takes over. Zeus analyzes your goal, determines what roles the company needs, and "hires" specialized AI agents to fill them. It's a multi-agent orchestration system with a business-friendly skin.

The AI agents can theoretically write code, create websites, draft cold emails, manage social media, and build marketing strategies. Under the hood, it's coordinated LLM agents, each assigned a persona and task domain, wrapped in a no-code interface.

If you've been following multi-agent AI systems moving from demos to production, the architecture will feel familiar. Paperclip AI is what happens when someone packages that concept for non-technical users and says "here, run a business with this."

My Weekend With Paperclip AI: What Actually Happened

I tested Paperclip AI by building a consulting micro-company. A niche I actually know after 14+ years in software engineering. I called it "ShipRight Consulting" with the goal: "Help early-stage startups ship their MVP in 8 weeks through fractional CTO services."

Zeus got to work immediately. Within minutes, I had an AI CTO, an AI CMO, and an AI Sales Rep "hired" and working on tasks. The speed was impressive. The AI CMO produced a marketing brief within an hour. The AI CTO started outlining a tech stack and a website.

Then things got weird.

The marketing strategy was plausible but unverifiable. The AI CMO generated a positioning document that included claims like "fractional CTOs save startups 4-6 billable hours per week compared to full-time hires." Sounds reasonable, right? Except that statistic was AI-generated and I couldn't find any source to back it up. This is a real problem: if you're a non-technical founder using this platform, you'd take that number at face value and slap it on your landing page. Now you're publishing misinformation with total confidence.

The website was, to put it charitably, rough. One early adopter on X described their Paperclip-generated website as "just spaghetti," and yeah, that tracks. My AI CTO produced a landing page with broken layout, inconsistent styling, and copy that read like a fever dream of startup buzzwords. I've reviewed enough production code to know the difference between a prototype and a mess. This was the latter.

The cold email drafts were the highlight. The AI Sales Rep produced outreach templates that were... actually decent? The subject lines were specific, the value propositions were clear, and the tone was appropriate. If I were coaching a junior sales hire, these emails would be a solid first draft. Not production-ready, but a real starting point.

Here's a walkthrough from Metics Media that captures the general experience:

[YOUTUBE:XXplTbQR9to|Paperclip AI Tutorial: How to Build a Zero-Human Company]

Where Paperclip AI Falls Apart

The problem with Paperclip AI isn't that it's bad at individual tasks. It's that there's no quality filter. Nobody is in the loop to say "that statistic is made up" or "that website doesn't render on mobile." The agents execute with confidence regardless of whether the output is good.

I've shipped enough features at scale to know that the hard part of building a company isn't generating ideas or drafting documents. It's judgment. Knowing which of ten possible directions is the right one. Catching the subtle error that looks correct to everyone except someone with domain expertise.

Paperclip AI has none of that. Its agents will hallucinate market data, produce broken code, and draft legal copy with the same cheerful certainty. And because the platform is designed for people who don't have the expertise to catch these errors, the failure mode is particularly dangerous.

Compare this to frameworks like CrewAI or Microsoft's AutoGen, which are multi-agent orchestration tools built for developers. Those tools give you control over agent behavior, output validation, and human-in-the-loop checkpoints. They're harder to use, but that difficulty is the point. It forces the operator to understand what the agents are doing. Paperclip AI abstracts all of that away, and the abstraction costs you accuracy.

If you've been exploring the agent ecosystem, my comparison of OpenClaw vs CrewAI digs deeper into what separates a toy demo from a production-grade agent framework. The gap is enormous.

Can Paperclip AI Actually Build a Working Business?

Short answer: no. Not without significant human oversight at every step.

Longer answer: it's a solid brainstorming and scaffolding tool, if you know what you're looking at. After my weekend experiment, I had a pile of raw material — positioning ideas, email templates, a rough brand direction, a list of potential customer segments. None of it was production-ready, but all of it saved me time on first-draft thinking.

That distinction matters. The platform's value isn't in replacing humans. It's in compressing the "blank page to rough draft" phase of starting a business. If you treat Paperclip AI as an idea accelerator with a fun UI, it delivers something. If you treat it as an autonomous company builder — which is explicitly how it's marketed — you're going to have a bad time.

The danger isn't that AI agents can't do work. It's that they can't tell you when the work they've done is wrong.

This is the core tension in every autonomous agent system right now. Having worked with LLM-based tools in production for the past two years, I can tell you the "last mile" problem — getting from 80% correct to actually reliable — is where all the real engineering lives. Paperclip AI skips that mile entirely.

The Bigger Question: Are We Ready for Zero-Human Operations?

Paperclip AI is a provocative experiment. Building and launching it in a single month, as Pathak did, is impressive execution. But the platform inadvertently demonstrates exactly why "zero-human" companies aren't viable yet.

The risks aren't theoretical. They showed up in my weekend test:

Hallucinated data presented as fact in marketing materials and business plans. My "4-6 hours" stat had zero source.
Unreviewed code pushed to production with broken layouts. Security vulnerabilities and logic errors are basically guaranteed.
Autonomous outreach. Cold emails sent on your behalf that you never saw. One bad email to the wrong person and your brand takes a hit, or you're violating CAN-SPAM.
No escalation path. When an AI agent makes a bad call, there's nobody to catch it. The system just keeps going.

I've written before about how AI coding agents won't replace engineers but will change how we think about code. The same principle applies here, amplified. AI business agents won't replace founders. But they will change how we think about the early stages of company building. If we're honest about their limitations.

The multi-agent AI space is moving fast. Tools like CrewAI and AutoGen are getting more sophisticated every month. The underlying models are getting better at reasoning and self-correction. In two years, a platform like Paperclip AI might actually work. But today, in 2026, it's a proof of concept wearing a product's clothing.

What Paperclip AI Gets Right (Despite Everything)

I don't want to be entirely dismissive. Three things stood out:

The onboarding is frictionless. Name, goal, go. There's something powerful about reducing the barrier to "starting a company" to a single sentence. For someone who's been paralyzed by the complexity of launching a side project, that alone has value.
The agent coordination is visible. You can watch Zeus delegate tasks to different AI employees and see their outputs in real time. It's the most intuitive visualization of multi-agent orchestration I've seen outside of developer tools. If you're trying to explain to a non-technical stakeholder what multi-agent systems even look like, point them here.
The direction is right, even if the vehicle isn't. The future of business tooling probably does involve AI agents handling routine tasks autonomously. Paperclip AI is pointing at the right destination. The vehicle just isn't road-ready.

It occupies a strange space: too ambitious to be a toy, too unreliable to be a tool.

The Verdict

Paperclip AI is not going to build your company for you. Full stop. But it might change how you think about what's possible.

If you're a developer or technical founder, spend an hour with it. Not because the output is useful (most of it isn't), but because watching AI agents attempt to coordinate a business will teach you more about the current state of autonomous systems than any whitepaper. You'll see exactly where multi-agent AI works, where it breaks, and how far we still have to go.

My prediction: within 18 months, one of the serious agent frameworks — CrewAI, AutoGen, or something we haven't seen yet — will ship a business-builder that actually works for narrow, well-defined company types. Paperclip AI won't be the winner. But it might be the thing that convinced the winner to try.

Originally published on kunalganglani.com