DEV Community: Shubham

What's All Am I Hosting? Full Infrastructure Breakdown

Shubham — Sat, 04 Jul 2026 18:52:41 +0000

Every few months, someone asks me how I run my entire online presence for basically nothing. The short answer is: I don't pay for what I can get for free.

The long answer is this post.

My entire infrastructure this site, APIs, email, monitoring, URL shortener, dev tools runs on free-tier cloud services. Total cost: $0/month. That's less than a single AWS load balancer costs for an hour.

Here's exactly how it works, why I chose each piece, and what I'd do differently.

The Philosophy: Free Tier First

I have a simple rule: if a service has a generous free tier that covers my use case, I use it. If I outgrow it, I'll pay but most of us never outgrow free tiers for personal projects.

The second rule: own the critical paths. DNS is the backbone, so it's on Cloudflare (free, but best-in-class). The main site is on Vercel (free, seamless Next.js deployment). Everything else databases, email, APIs, monitoring is a managed service that solves exactly one problem well.

DNS: Cloudflare (The Glue That Holds It All Together)

Everything starts with DNS. Cloudflare runs chan.ns.cloudflare.com and dave.ns.cloudflare.com as my authoritative nameservers. Every subdomain in this post is a DNS record that Cloudflare serves for free.

I use Cloudflare as a pure DNS provider no CDN proxying on most records except a few redirects (cal, link, mail). The proxied records hide my origin IP and give me free SSL termination, but I keep most records direct because I want full control over the traffic path.

Why Cloudflare over Route53 or self-hosted? Cloudflare's free plan includes unlimited DNS queries, DNSSEC, easy API access, and their dashboard is fast. Route53 charges per query. Self-hosting DNS is unnecessary complexity. Free + best-in-class = no contest.

The Main Site: Vercel

shubhkumar.in is hosted on Vercel's free tier. The apex domain uses an A record to 216.198.79.1 (Vercel's anycast IP for apex domains you can't use a CNAME at the root).

Vercel's free tier includes 100GB bandwidth, 6000 build minutes, automatic SSL, and edge network distribution. For a Next.js site with ISR, this is more than enough. The site loads fast everywhere because Vercel serves it from their edge network.

The www subdomain CNAMEs to the root standard practice.

Other Vercel-Hosted Sites

cv.shubhkumar.in Resume site. Next.js, deploys from GitHub.
news.shubhkumar.in Another Next.js site.

Hosted Applications: The Free Tier Dream Team

Render API Server

api.shubhkumar.in runs on Render's free tier. It handles contact forms, webhooks, and server-side endpoints the static site can't handle. Render gives 750 hours/month plenty for a low-traffic personal API.

Why Render over Railway or Fly.io? Render has the most generous free tier for this use case. The deploy experience is smooth (Git push → deploy), and SSL is automatic.

GitHub Pages Lightweight Pages

connect.shubhkumar.in is a simple social link aggregator Linktree-style but self-hosted. Single HTML page, zero cost, instant deploy from a GitHub repo.

Infrastructure: The Stuff That Runs in the Background

Tailscale Private Network Bridge

tail.shubhkumar.in points to my Tailscale node at 100.115.133.19. Tailscale creates a WireGuard mesh across all my devices laptop, home server, cloud VMs. The DNS record lets me reach my home lab from anywhere using a proper subdomain.

The real magic: Tailscale handles NAT traversal automatically. My home server is behind CGNAT (common with Indian ISPs), and Tailscale punches through without any port forwarding. Free tier: up to 100 devices.

Databases Managed, Never Self-Hosted

I use managed databases exclusively. Supabase (Postgres) for anything that needs relational queries and real-time subscriptions. MongoDB Atlas for document storage when the schema is fluid. Both on free tiers or their cheapest paid plans whichever covers the workload.

Self-hosting a database is the fastest way to turn a weekend into an ops nightmare. Backups, replication, patches, disk space all someone else's problem. The managed premium is worth every rupee.

Fly.io Lightweight Apps

track.shubhkumar.in hosts WakaAPI (self-hosted WakaTime stats) on Fly.io. Free allowance covers the tiny resource usage 3 shared-CPU VMs with 256MB RAM, 3GB storage, 160GB outbound.

Cal.com Scheduling

cal.shubhkumar.in Cloudflare-proxied redirect to Cal.com. Self-hosting a calendar scheduler isn't worth my weekend.

Better Uptime Monitoring

status.shubhkumar.in Free tier. Monitors all endpoints, notifies on Slack. 10 monitors with 3-minute checks and a public status page.

Tools and Redirects

Dub.co URL Shortener

go.shubhkumar.in runs on Dub.co's free tier. Short, memorable links go.shubhkumar.in/github, etc. Open-source, great API, free tier includes custom domains and basic analytics.

Used to run YOURLS on a VPS. Moving to Dub.co saved maintenance and gave better analytics.

Simple Redirects

link.shubhkumar.in and mail.shubhkumar.in are Cloudflare-proxied redirects using 192.0.2.1 (Cloudflare's placeholder IP). No server needed Cloudflare page rules handle the redirects.

Email Infrastructure: The Hardest Part

Email is the hardest thing on a personal domain. I run three services for different purposes because each solves a specific problem.

Zoho Mail Primary

Primary email on Zoho's free plan 5 mailboxes with 5GB each, custom domain, IMAP/SMTP, calendar. The last remaining free tier for professional email on a custom domain after Outlook killed their free custom domain offering and Google Workspace charges $6/user/month.

MX: mx.zoho.com (priority 10), mx2/3 as fallbacks. DMARC set to reject with Cloudflare reporting.

Trade-off: Zoho's spam filtering is decent but not Gmail-level. For free, acceptable.

SimpleLogin Email Aliases

simple.shubhkumar.in Creates aliases that forward to my primary inbox. If a service sells my email, I delete the alias. Free tier: 15 aliases, PGP encryption, open-source.

Resend Transactional + Broadcast Emails

I use Resend for all outgoing emails transactional notifications, broadcast newsletters, and contact form submissions. It handles everything through a single clean API with good deliverability out of the box.

Resend's free tier includes 100 emails/day, which covers my low-volume needs. DKIM and SPF configured through forms.shubhkumar.in for proper authentication.

Security and Verification Records

DMARC (reject) Strictest policy. Reports to Cloudflare's DMARC reporting. Caught email spoofing attempts at least twice.
BIMI Shows my logo next to authenticated emails. Mostly vanity but looks professional.
Keybase Domain ownership proof.
Google Search Console Site ownership for search analytics.

What I Don't Use (And Why)

No Kubernetes. Everything fits in docker-compose or managed platforms. K8s is operational overkill for one person.
No AWS. Pricing model punishes hobbyists. One misconfigured resource = surprise bill. I use SES for email only when necessary.
No self-hosted CI. GitHub Actions is free for public repos.
Databases: Managed Supabase (Postgres), MongoDB Atlas, etc. Free tiers + cheapest plans cover everything. Self-hosting a database is unnecessary ops overhead.

Cost Breakdown

Service

Cost

What It Runs

Vercel

Main site (Next.js) + CV + News

Cloudflare DNS

All DNS records, proxied redirects

Render

API server

GitHub Pages

Link aggregator

Fly.io

WakaAPI instance

Better Uptime

10 monitors, status page

Dub.co

URL shortener

Zoho Mail

Primary email, custom domain

SimpleLogin

15 email aliases

Resend

Transactional + broadcast emails

Tailscale

Mesh VPN, 100 devices

Supabase

Managed Postgres (free tier)

MongoDB Atlas

Managed MongoDB (free tier)

Total

$0/mo

~15 services, one domain, full infra

Lessons Learned

You don't need to self-host everything. Used to run my own email server, Git server, CI huge time sink for zero benefit. Managed services let you focus on what matters.
DNS TTL matters. Low TTL (1–300s) on frequently changed records. High TTL (86400) on stable records for faster lookups.
Email deliverability is a second job. DKIM + SPF + DMARC + BIMI + reverse DNS + feedback loops takes a full day to set up. Get it right once, don't touch it.
Free tiers are designed to hook you. That's fine as long as you understand the migration cost before you're locked in.
Monitoring is not optional. Better Uptime caught three outages I wouldn't have noticed until someone emailed me.

The Reality

Running your own infrastructure is a trade-off setup time and occasional debugging for complete control and zero ongoing cost. For me, it's worth it.

But I also know when to stop. I don't self-host email. I don't run a Docker registry. I don't build custom dashboards. The services I chose handle those well enough that my time is better spent building on top of them.

Building My Personal Website From Scratch: Tech Stack, Architecture, and Lessons Learned

Shubham — Sat, 27 Jun 2026 19:12:59 +0000

As a software engineer, a personal website is more than just an online resume it’s an open-ended canvas, a sandbox for testing new tech, and a reflection of how you approach software architecture.

When I set out to build shubhkumar.in, I didn't want to just spin up a template or use a no-code builder. I wanted to build a production-grade, highly optimized, and scalable platform from scratch.

Here is a look under the hood at the stack, the design decisions, the hosting setup, and the inevitable mistakes made along the way.

The Tech Stack: Modular & Decoupled

Instead of building a monolithic application, I opted for a decoupled frontend and backend architecture. This keeps the presentation layer lightweight while allowing the API to scale independently.

Frontend: Next.js & Tailwind CSS. Next.js handles the user interface with excellent performance, while Tailwind CSS keeps the utility-first design clean, responsive, and highly maintainable.
Backend API: Express.js (Node.js). Hosted at api.shubhkumar.in, this unopinionated framework handles dynamic requests and serves content efficiently.
Database & Distributed Caching: MongoDB Atlas & Redis. MongoDB Atlas acts as our fully managed cloud database layer. To slash latency and prevent unnecessary database queries, a cloud-managed Redis instance sits right in front of it.

Design Decisions: Single Source of Truth & Multi-Tier Caching

The core philosophy behind this project was performance, reusability, and absolute separation of concerns.

Instead of letting the Next.js frontend query the database directly, everything routes through the dedicated Express API. The biggest architectural win here is that the API acts as a single source of truth for my entire digital footprint.

Beyond the main portfolio at shubhkumar.in, I also host my dedicated CV at cv.shubhkumar.in. Both frontends consume data from the exact same API endpoints. If I update a project description, add a new tech stack proficiency, or modify my work history, the change reflects universally across all subdomains.

To deliver instantaneous, sub-100ms response times globally, the architecture leverages a two-tier aggressive caching model:

The API Tier (Redis): When a request hits the Express backend, it checks the cloud Redis cache first. If it's a hit, it serves it instantly. If it's a miss, it pulls from MongoDB Atlas and hydrates Redis with an expiration TTL (Time-to-Live).
The Frontend Tier (Next.js Data Cache): Pages aren't just fetching live on every request. Next.js caches data at the framework layer using time-based revalidation (next: { revalidate: ... }). This serves prerendered static pages from Vercel’s edge network while quietly updating the data in the background once the timer lapses.

Hosting & Deployment: The Cloud Setup

For hosting, I wanted a fully managed, modern cloud setup that eliminates infrastructure maintenance overhead while providing global scalability.

Frontend Hosting (Vercel): The Next.js frontend is deployed on Vercel, providing global CDN distribution and world-class optimization for Next.js assets out of the box.
Backend Hosting (Render): The Express.js API runs on Render, managing web environments smoothly with auto-deployments from Git and managed SSL setup.
Health & Diagnostics (Uptime Monitoring): To ensure high availability across this distributed setup, I implemented a robust uptime monitoring layer that pings the frontend endpoints and the underlying API services, alerting me the second a bottleneck occurs.

Mistakes I Made (And How I Fixed Them)

No project is built from scratch without a few roadblocks. Here are the major pitfalls I encountered:

The Double-Caching Sync Dilemma: Layering Next.js revalidation over an aggressive Redis cache meant that content updates were trapped behind two separate timers. Modifying database records sometimes wouldn't show up on the live UI for quite a long time due to cache stacking.

*   _The Fix (and Current Plan):_ Right now, the site relies on short, balanced time-to-live intervals. However, the long-term solution is already in the works: building a unified dynamic webhook pipeline. When data changes, a hook will trigger an automatic `DEL` command to the Redis key and simultaneously ping a Next.js API route handler to call `revalidatePath()` or `revalidateTag()`, flushing both layers instantly.

Over-Engineering the Backend Initially: I started treating my personal API like an enterprise microservices platform, worrying about premature optimization before the core features were even stable.

*   _The Fix:_ I stripped it back to a clean, modular Express architecture. YAGNI (You Aren't Gonna Need It) applies to personal portfolios just as much as production SaaS products.

Handling Cold Starts on Managed Hosting: When the API instances go quiet, spin-up times on managed cloud infrastructure can sometimes introduce latency for the first visitor.

*   The Fix: I streamlined database connection pools, minimized the deployment bundle, and utilized the uptime monitoring pings as a dual-purpose "heartbeat" to ensure the API container stays warm, active, and snappy.

Final Thoughts

Building shubhkumar.in from scratch wasn't the fastest way to put a portfolio online, but it was easily the most rewarding. It forced me to think through the entire lifecycle of an application from building a multi-tier cache architecture to managing production cloud deployments.

The best part? Because it’s driven by a single-source-of-truth API, it can power any future side project or subdomain I decide to build down the road.

Moving from 60s to 6s: Latency Optimization Lessons from Functional Programming

Shubham — Wed, 24 Jun 2026 10:36:02 +0000

The broader tech community often views functional programming (FP) as an elegant academic exercise great for type systems, formal reasoning, and compiler guarantees, but less relevant to the realities of high-throughput production systems.

That assumption is wrong.

While optimizing a large-scale distributed workflow engine, we used PureScript and Haskell to rethink a legacy execution model, reducing end-to-end latency from roughly 60 seconds to under 6 seconds a nearly 90% improvement.

This wasn't achieved through additional hardware, bigger databases, or infrastructure tuning. Instead, the gains came from applying a few core functional programming principles: non-blocking asynchronous effects, explicit modeling of side effects, and treating workflows as composable data structures.

This is the engineering story behind that transformation.

The Bottleneck: Polling-Based Workflow Execution

The original system relied on a pull-based worker architecture.

Each request flowed through multiple sequential stages, including validation, business rule evaluation, external service interactions, state transitions, and final reconciliation.

The execution model was built around a database-backed work queue:

A worker completed a step and persisted the updated state.
The next worker periodically polled the database for pending work.
Once discovered, it executed the next stage and persisted the result.
The process repeated until completion.

While this approach provided durability and operational simplicity, it introduced significant latency.

Every stage depended on a polling interval before the next stage could begin. Even relatively small delays compounded across multiple workflow stages.

As the number of sequential steps increased, the majority of request time was spent waiting for the next polling cycle rather than performing useful work.

The system wasn't compute-bound.

It was wait-bound.

The Strategy: Introducing a Fast Execution Path

To eliminate unnecessary waiting, we split execution into two distinct paths:

A Fast Path optimized for low-latency request processing.
A Durable Path optimized for reliability, retries, and recovery.

Rather than routing every request through the durable workflow engine immediately, the system first attempts direct execution using PureScript's Aff runtime.

Aff provides lightweight, non-blocking asynchronous execution with structured error handling and resource safety.

A typical request now follows a path similar to:

Request

→ Validation

→ Business Rules

→ External Service Call

→ State Update

→ Response

If all operations succeed, the request completes immediately without entering the background workflow system.

By avoiding unnecessary persistence and polling between every stage, latency dropped dramatically.

In the common success case, requests now completed in under six seconds.

The Reliability Challenge

Fast paths are easy to build.

Reliable fast paths are significantly harder.

Any optimization that bypasses durable infrastructure risks losing execution state when failures occur.

To preserve reliability guarantees, we needed a mechanism that could seamlessly transition between immediate execution and durable recovery without introducing duplicate side effects.

Modeling Workflows as Data

The solution was to represent workflow operations as a custom DSL built using algebraic data types and interpreted through a Free Monad.

Instead of executing side effects directly, workflow steps were first modeled as data.

Operations such as:

Reading state
Writing state
Calling external services
Running parallel computations
Updating workflow progress

were represented as declarative instructions.

This separation between workflow definition and execution enabled a powerful capability: deterministic replay.

As execution progressed, the interpreter recorded the result of completed operations.

If an error occurred during fast-path execution, the current workflow state could be persisted and handed off to the durable execution engine.

When processing resumed later:

Previously completed operations were replayed from recorded results.
Successful work was not re-executed.
Execution continued from the exact point of failure.

This allowed the system to combine low-latency execution with strong reliability guarantees while avoiding duplicate side effects.

Results

The biggest lesson wasn't simply that the system became faster.

It was that functional programming provided architectural tools that made an entirely different execution model possible.

Don't Poll When You Can Propagate

Polling introduces latency even when no real work is being done.

For multi-stage workflows, event-driven execution often produces substantial performance improvements.

Separate Workflow Definition from Execution

Representing workflows as data creates opportunities for replay, testing, simulation, recovery, and optimization that are difficult to achieve when side effects are tightly coupled to business logic.

Types Enable Architectural Confidence

Strong type systems make it possible to build complex execution and recovery mechanisms with far greater confidence.

Many categories of invalid state transitions and workflow bugs can be eliminated before code ever reaches production.

Final Thoughts

Reducing latency from 60 seconds to 6 seconds wasn't primarily a performance-tuning exercise.

It was the result of changing how the system modeled work.

Functional programming provided the abstractions needed to separate business logic from execution, build reliable recovery mechanisms, and optimize the common path without sacrificing correctness.

The next time someone describes functional programming as purely academic, consider that some of its most powerful ideas aren't about writing cleaner code.

They're about building systems that are both fast and resilient at scale.

The Disconnected Edge: How We Solved In-Flight Data Sync at 35,000 Feet

Shubham — Sun, 14 Jun 2026 01:55:15 +0000

When most engineers think about deploying a modern application, they imagine a familiar setup: cloud infrastructure, global CDNs, auto-scaling services, and near-constant internet connectivity.

The architecture patterns are well understood. If something goes wrong, the application can usually reach another service, retry a request, or fetch fresh data from the cloud.

But what happens when your application spends most of its life completely disconnected from the internet?

That's the challenge we faced while building a next-generation in-flight entertainment (IFE) platform.

And it forced us to rethink some of our most fundamental assumptions about distributed systems.

The Reality of Running Software on an Aircraft

Our platform ran on embedded edge devices installed onboard commercial aircraft.

These devices powered the entire passenger experience:

Movies and TV shows
Games
Digital publications
E-commerce catalogs
Passenger analytics
Operational data collection

Unlike a typical web application, however, these systems couldn't rely on continuous connectivity.

For most of their operational life, they were completely isolated from the internet.

Yet every day brought new content, software updates, pricing changes, configuration updates, and analytics data that needed to move between a central backend and hundreds of aircraft spread around the world.

Building the application wasn't the hard part.

Keeping everything synchronized was.

When Cloud-Native Assumptions Stop Working

Modern software architecture often assumes the network is always available.

Applications are designed around:

Real-time APIs
Continuous synchronization
Cloud-hosted storage
Immediate access to backend services

Our environment broke every one of those assumptions.

Aircraft devices regularly experienced:

Extended periods with no connectivity
Short and unpredictable synchronization windows
Limited compute resources
Restricted power budgets
High reliability requirements

A failed synchronization couldn't leave a device in a broken state. Passengers still expected the system to work regardless of whether it had connected to the backend recently.

That changed our design philosophy completely.

Designing for Offline First

Instead of treating connectivity loss as an exception, we treated it as the default operating mode.

Every aircraft device maintained its own local copy of everything it needed to operate:

Application assets
Media content
Configuration data
Transaction queues
Analytics events

The backend remained the source of truth, but the aircraft could continue operating independently for days or even weeks if necessary.

Connectivity became a bonus rather than a requirement.

This single mindset shift influenced almost every architectural decision that followed.

Synchronization Became the Product

In many systems, synchronization is a background task.

For us, synchronization became one of the most critical parts of the platform.

The workflow was intentionally simple:

The backend generated update manifests.
Devices checked for available updates whenever connectivity existed.
Only changed assets were downloaded.
Downloaded content was verified.
Updates were applied atomically.
Analytics and operational data were uploaded back to the backend.

The goal wasn't speed.

The goal was reliability.

If a network connection dropped halfway through a transfer, the device needed to recover gracefully and continue from where it left off.

No corruption. No inconsistent state. No manual intervention.

The Challenge of Moving Large Media Libraries

One of the biggest engineering challenges involved content distribution.

A typical update might contain:

Video files
Images
Application bundles
Configuration changes

Re-downloading everything every time simply wasn't realistic.

Bandwidth was limited, synchronization windows were unpredictable, and some assets were extremely large.

To make transfers practical, we relied heavily on:

Manifest-driven synchronization
Content hashing
Incremental downloads
Compression
Delta updates where possible

The principle was straightforward:

Transfer only what changed.

That simple rule dramatically reduced synchronization times and bandwidth usage across the fleet.

Building for Unreliable Networks

Connectivity quality varied enormously.

Sometimes devices synchronized over stable networks.

Other times they relied on slow, intermittent cellular connections.

The synchronization system had to assume failure could happen at any point.

To handle this, we built in:

Retry queues
Checkpointed downloads
Idempotent operations
Integrity verification
Automatic recovery mechanisms

One of the most important requirements was ensuring that a failed synchronization never damaged the existing system.

If an update couldn't be completed successfully, the device simply continued operating from its last known-good state.

Passengers never noticed the difference.

Observability Without Real-Time Access

One of the more interesting challenges wasn't deployment.

It was debugging.

Most modern observability platforms assume engineers can access telemetry in real time.

That wasn't possible for us.

Aircraft devices spent long periods disconnected, making live monitoring ineffective.

Instead, devices accumulated operational information locally:

Structured logs
Health metrics
Synchronization reports
Diagnostic data

Whenever connectivity became available, this information was uploaded and aggregated centrally.

The result wasn't real-time observability.

It was delayed observability.

And that required a different mindset when diagnosing production issues.

What We Learned

Building systems for disconnected environments teaches lessons that are easy to overlook in cloud-first architectures.

Connectivity Is a Feature, Not a Guarantee

Many applications assume the network will always be available.

We learned to assume the opposite.

Systems designed to function without connectivity are often more resilient overall.

Idempotency Is Non-Negotiable

When networks are unreliable, retries become routine.

Every operation must be safe to execute multiple times.

Without idempotency, synchronization quickly becomes a source of inconsistency and failure.

Local-First Architectures Are Surprisingly Powerful

Giving edge devices autonomy reduces dependency on centralized infrastructure.

It improves user experience and limits the blast radius of failures.

In many cases, it produces a more robust system than one that depends heavily on constant connectivity.

Simplicity Wins

The most reliable parts of our platform weren't the most sophisticated.

They were the simplest.

Clear manifests, atomic updates, strong validation, and predictable workflows consistently outperformed more complex approaches.

Reliability often comes from reducing complexity rather than adding it.

Final Thoughts

A lot of modern engineering focuses on scaling cloud infrastructure.

But some of the most interesting distributed systems problems exist far from the cloud at the edge, where connectivity is intermittent, resources are constrained, and reliability matters more than raw throughput.

Building software for aircraft forced us to rethink assumptions about deployment, networking, observability, and synchronization.

The result was a platform capable of operating independently for extended periods while staying synchronized with a centralized backend whenever connectivity became available.

And while the environment was unique, the lessons weren't.

Whether you're building for aircraft, ships, remote industrial sites, IoT devices, or any other disconnected environment, the same principle applies:

Design for a world where the network isn't guaranteed.

Everything else becomes easier after that.

Turning Your AI Into an Adversarial Security Agent: The SKILLS.md Framework

Shubham — Sun, 07 Jun 2026 09:18:06 +0000

A continuation of: Breaking to Build: How CTF and Bug Bounty Hunting Rewires System Design

In my previous article, I explored how offensive security permanently changes the way engineers think about systems. Once you've spent enough time exploiting race conditions, bypassing authorization boundaries, abusing SSRF chains, and breaking assumptions hidden deep inside application logic, you stop viewing software as a collection of features.

You start viewing it as an attack surface.

That shift fundamentally changes how you design production systems. The problem is that modern software development is no longer purely human-driven. Today, a massive percentage of engineering work happens alongside AI coding assistants. Tools now generate thousands of lines of code faster than most engineers can review them.

And that introduces a brand new problem.

AI systems are optimized for one thing: Generate code that works.
Attackers are optimized for something completely different: Find code that breaks.

That difference matters. A generated API endpoint might pass every functional test while still exposing a devastating BOLA (Broken Object Level Authorization) vulnerability. A generated webhook handler might function perfectly while allowing SSRF into your internal infrastructure. A generated payment workflow might appear correct while collapsing into a double-spend condition under concurrent execution.

The code works. The architecture fails. And that is exactly where real-world vulnerabilities are born.

The Missing Layer in AI-Assisted Development

Most teams currently treat AI coding agents like extremely fast junior engineers. They give them instructions like:

"Build this feature"
"Refactor this service"
"Create this migration"

The model responds by optimizing for correctness, readability, and implementation speed. Security is rarely treated as a first-class objective.

Most AI systems are never explicitly taught to think like attackers. They are taught how software should behave; they are not taught how software is abused.

That distinction becomes increasingly dangerous as organizations move toward autonomous code generation, AI-assisted architecture, and agentic development workflows.

The solution turns out to be surprisingly simple: instead of prompting for features alone, we inject a persistent security reasoning framework directly into the agent's operating context.

That framework is SKILLS.md.

What Is SKILLS.md?

SKILLS.md is a structured operational framework that teaches an AI agent how to evaluate software through an adversarial lens. It is not a prompt, a simple checklist, or another copy-paste of the OWASP Top 10. It is a behavioral framework that continuously pushes the model to ask "How would an attacker abuse this?" before it asks "How do I implement this?"

The goal is to transplant the mindset developed through years of CTF competitions, bug bounty hunting, and incident response directly into the AI’s reasoning process.

Why Traditional Security Checklists Fail

Most security documentation focuses on known vulnerability categories (XSS, SQLi, CSRF, SSRF, IDOR). These are important, but attackers rarely think in categories. They think in assumptions.

Every vulnerability exists because somebody assumed something was true:

The frontend won't send invalid values.
Only authenticated users can reach this endpoint.
This request executes once at a time.
Nobody can access that internal network.

Bug bounty hunting teaches you something uncomfortable: assumptions are where systems fail. Security is often less about blocking payloads and more about eliminating dangerous assumptions. SKILLS.md is built entirely around that philosophy.

The Evolution From Builder To Breaker

Plaintext

Traditional Engineering:
Requirement ──> Implementation ──> Testing ──> Deployment

Security-Oriented Engineering:
Requirement ──> Implementation ──> Abuse Analysis ──> Boundary Verification ──> Concurrency Analysis ──> Deployment

The first workflow asks: Does this feature work?

The second asks: What happens when somebody intentionally tries to break it?

SKILLS.md forces AI agents into the second mode.

The Specifications: SKILLS.md

Modern AI tools and tools like Claude Code have evolved past static, single-file home directory configurations. They utilize the Agent Skills Standard, which relies on a nested folder footprint (skills/<skill-name>/SKILL.md) and mandatory YAML frontmatter.

The frontmatter contains semantic metadata. When you start an AI session, the engine scans the description block to automatically determine when to pull this skill into context.

Here is the production-ready implementation file.

Markdown

---
name: secure
description: "Evaluates software architecture and code through an adversarial lens. Automatically invokes when generating APIs, designing features, reviewing code, or managing authentication, state, and data boundaries."
user-invocable: true
---

# Security-First Architecture Skill

**Axiom:** Inputs malicious. Clients untrusted. Networks hostile. Dependencies may be compromised. Never trust; always verify at execution point.

---

## Domain Controls

| # | Domain | Attacks | Key Controls | Core Question |
|---|--------|---------|-------------|---------------|
| 1 | **State / Race** | TOCTOU, double-spend, optimistic-lock loss | `SELECT FOR UPDATE`; distributed lock (Redis `SET NX PX`); validate ETag every write | Can same op succeed twice in parallel, or state change between check and act? |
| 2 | **AuthZ / BOLA** | IDOR, BOLA, mass assignment, GraphQL introspection | Ownership check at data layer, not route; allowlist binding (strong_params/Pydantic DTO); disable introspection in prod; tenant-scope every query | What changes if resource ID or any request field changes? Who verified ownership? |
| 3 | **SSRF** | Metadata endpoint, DNS rebind, redirect chain, `gopher://` | Resolve DNS → re-validate IP vs RFC-1918+169.254+fc00 denylist; allowlist domains; HTTPS-only via egress proxy; proxy follows redirects, not app code | Who controls final destination after DNS resolution and redirects? |
| 4 | **Path Traversal** | `../../`, URL-encode, null byte, Zip Slip, symlink | `realpath()`/`Path.resolve()` → verify under root; never concat user input to paths; use UUIDs as storage keys; validate archive entries before extract | Can user-controlled string, after normalization, escape storage boundary? |
| 5 | **Blast Radius** | Lateral movement, over-permissive IAM, credential reuse | Non-root containers, read-only rootfs, `--cap-drop ALL`; per-service least-privilege IAM; separate creds per env/service; mTLS between services | If this service is fully compromised, what else is reachable without new creds? |
| 6 | **Fail-Closed** | Broad catch-continue, feature-flag default-on, null bypass | Default DENY in every auth check, exception block, conditional; feature flags off for security features; `default: deny` in all security-relevant switches | What does system permit on unexpected error, null, or undefined in auth path? |
| 7 | **Secrets / Crypto** | Log leak, `alg:none` JWT, weak HMAC, IV reuse, timing oracle, weak PRNG | Secrets Manager + rotation; CSPRNG only; pin JWT alg server-side; RS256/ES256 cross-service; `timingSafeEqual`; AES-256-GCM unique nonces; ban MD5/SHA-1/DES/RC4 | Can credential be recovered, forged, or brute-forced from token, log, or build output? |
| 8 | **Supply Chain** | Typosquat, dep-confusion, `postinstall` RCE, unpinned deps | Exact-version pin + lockfile; verify signatures/hashes; audit `postinstall` scripts; private registry namespace; `npm audit`/`pip-audit`/`cargo audit` in CI | What third-party code executes in build/runtime that we don't own and audit? |
| 9 | **Event Integrity** | Replay, out-of-order, schema-invalid crash, webhook spoof | Idempotency keys (Redis TTL); strict schema → DLQ on malformed; HMAC-SHA256 webhook sig + 5-min timestamp window; sequence numbers for ordering | Can replaying/reordering an event corrupt state? Is every inbound event cryptographically authenticated? |
| 10 | **LLM / AI** | Prompt injection (direct/indirect), agentic tool abuse, secondary injection | Treat model output as untrusted input; explicit tool-auth gateway per user permission; strict output schema (JSON Schema/Pydantic); human-in-loop for irreversible actions; no ambient creds in agent env | What auth boundaries exist between model output and execution? Can injected content in retrieved data override system instructions? |
| 11 | **Injection** | SQLi, XSS, CMDi, SSTI, XXE, NoSQLi, ReDoS | Parameterized queries; `execFile([...])` not `exec(string)`; context-aware output encoding; disable XML external entities; reject `$`-prefix JSON keys; audit regexes for backtracking; never eval user input in templates | Does any user-controlled string reach an interpreter without structural separation? |
| 12 | **AuthN / Session / OAuth** | Credential stuffing, session fixation, missing server-side invalidation, redirect-URI wildcard, missing PKCE, token-in-URL | CSPRNG session tokens; rotate on login/priv-escalation; server-side invalidation on logout; `Secure;HttpOnly;SameSite=Strict`; Argon2id (64MB/3-iter) or bcrypt≥12; exact-match `redirect_uri`; PKCE for public clients; bind `state` to session; identical error messages + timing | Can attacker reuse, predict, fix, or intercept session/token/auth-code without knowing original secret? |
| 13 | **Log Exposure** | Credential leak, PII capture, log forgery via `\n\r`, stack-trace disclosure | Scrub tokens/JWTs/keys/PAN/SSN/email before every log write; allowlist loggable fields; sanitize `\n\r\033` in user input; disable verbose stack traces in prod responses | If every log line leaked, what sensitive data would be visible? |
| 14 | **Deserialization** | pickle/ObjectInputStream/`yaml.load`/Marshal RCE, gadget chains, DoS via nested structures | Never deserialize untrusted data with native formats; use JSON/Protobuf + schema validation; if unavoidable: allowlist filter + HMAC-sign payload; always `yaml.safe_load` | Does any code path deserialize attacker-influenced data with a class-instantiating deserializer? |
| 15 | **Rate Limits / DoS** | Credential stuffing, ReDoS, zip bomb, billion-laughs, large upload, unbounded pagination | Rate limits per-IP + per-user at gateway and app; tightest on auth/reset/OTP; cap body/upload size at ingress; GraphQL depth+complexity limits; timeouts on all external calls + queries; queue expensive ops; `limit ≤ 100` on pagination; return 429 + `Retry-After` | Can a single actor trigger resource consumption that degrades availability for others? |
| 16 | **HTTP Controls** | CORS credential theft, XSS via missing CSP, clickjacking, MIME-sniff bypass, SSL-strip | Exact-origin CORS allowlist (never reflect `Origin`, never `*` + credentials); HSTS `max-age=63072000;includeSubDomains;preload`; CSP allowlist `script-src`, no `unsafe-inline/eval`; `X-Content-Type-Options:nosniff`; `X-Frame-Options:DENY`; `Referrer-Policy:strict-origin-when-cross-origin`; `__Host-` cookie prefix | Can cross-origin page, framed page, or MIME-sniffed resource exploit browser trust in this origin? |
| 17 | **File Upload** | Zip Slip, polyglot exec, oversized upload, SVG XSS, archive bomb | UUID storage keys (never user filename); separate origin (S3 bucket/CDN subdomain) + `Content-Disposition:attachment`; validate by magic bytes not MIME; enforce size+count at ingress; reject SVG/HTML or sanitize with DOMPurify; cap archive extraction size + entry count | Can an uploaded file execute code, escape storage, or gain application-origin trust? |
| 18 | **Info Disclosure** | Stack traces, version headers, debug endpoints, username enum, timing leak | Opaque error IDs to clients, full detail server-side only; remove `Server`/`X-Powered-By`/`X-AspNet-Version`; disable debug/admin/introspection in prod (fail startup if debug=prod); identical error messages + response times; scan for exposed debug routes | Does any response, header, error, or timing difference reveal internal structure to unauthorized caller? |
| 19 | **Build Pipeline** | Compromised CI, over-permissive build IAM, unsigned images, secrets in logs, fork PR secret leak | Pin CI actions to commit SHAs; secrets only on protected branches; read-only source + write-only artifact IAM for build; sign images (cosign/Sigstore) + verify at deploy; OIDC ephemeral creds (no long-lived keys); branch protection: review + CI + signed commits required | Can compromised dependency update, CI job, or PR introduce malicious code reaching production without human review? |

---

## Verification Protocol (run sequentially on every review/design)

1. **Trust Boundaries**   map all input sources (HTTP, queues, webhooks, files, env); strip all safety assumptions
2. **Concurrency**   find TOCTOU windows; verify DB-level locking on every state mutation
3. **AuthZ**   confirm ownership check at data-access layer, not route layer, on every request
4. **Privileges**   least-privilege IAM, service accounts, container caps, DB permissions
5. **Blast Radius**   full compromise simulation: map reachable services/creds/data without new credentials
6. **Interpreter Paths**   trace user input to SQL/shell/template/XML/YAML/pickle; confirm structural separation
7. **Auth Surface**   session lifecycle (issue→rotate→invalidate), MFA, OAuth parameter binding, credential storage
8. **Log Audit**   confirm no secrets/PII/payment/raw bodies in any log path including error handlers and APM agents
9. **Rate Controls**   sensitive endpoints have per-user + per-IP limits; expensive ops queued with concurrency caps
10. **HTTP Controls**   CORS allowlist, security headers, CSP, no verbose error leakage on all response paths
11. **Upload & Deserialization**   files stored outside app origin with server-generated keys; no native deserializer on untrusted data
12. **Build Pipeline**   CI secrets scoped, actions SHA-pinned, images signed and verified at deploy

> **Target:** Code that behaves predictably when an adversary is actively attempting to shatter it.

Installation Guide

To ensure your AI assistant picks up this framework without breaking file path scopes, use the explicit terminal setups below depending on your favorite environment.

1. Claude Code

Claude Code evaluates configurations from your global home configuration space (~/.claude) or local workspaces (.claude).

Global Installation (Applies across all code repositories on your machine without altering git states):

Bash

mkdir -p ~/.claude/skills/security-review
# Save the Markdown block above into this file:
nano ~/.claude/skills/security-review/SKILL.md

* **Project-Specific Installation** *(Committed directly into git to enforce security rules across the whole engineering team)*:

bash
mkdir -p .claude/skills/security-review
nano .claude/skills/security-review/SKILL.md


### 2\. Cursor (and custom IDEs)

Cursor indexes markdown definitions gracefully via workspace indexing or dedicated custom instructions.

Bash

shell
mkdir -p .cursor/skills/security-review
nano .cursor/skills/security-review/SKILL.md


_(Alternatively, you can save it as a top-level_ `SKILLS.md` _file in your root workspace)._

### 3\. Orchestrated Agent Frameworks (CrewAI / LangGraph)

For autonomous multi-agent pipelines, pass the file directly as system background data inside your orchestration configuration:

YAML

yaml
agent:
role: Adversarial Security Auditor
backstory: You analyze architectural code changes strictly through the lens of SKILLS.md rules.
instructions:
- Ingest the custom SKILLS.md baseline constraints.
- Check every generated code route against Concurrency and Trust Boundaries.


## How to Use the Framework

Once installed, you don’t need to repeatedly copy-paste security prompts. The framework leverages both passive and active execution behaviors.

### Method A: Automated Semantic Triggering (Passive Mode)

Because the custom frontmatter contains a deep `description` string, the AI continuously evaluates your inputs. If you type a standard prompt that crosses defensive boundaries, the engine auto-activates the skill behind the scenes.

*   **Your Prompt:** _"Write an endpoint that takes a user's uploaded image URL, downloads it, and processes metadata."_

*   **The AI's Internal Action:** The engine intercepts words like _URL_ and _downloads_. It auto-loads `security-review` from disk, catches the **SSRF / Deterministic Routing** rule, and adds domain validation code before outputting the feature.


### Method B: Manual Slash Invocation (Active Mode)

If you want to explicitly mandate an application review, call the skill directly via standard interface paths.

*   **In Claude Code:** Use the custom command shortcut directly inside your terminal session:

    Bash

    ```


    /security-review Review our new database migration file for potential data isolation vulnerabilities.


    ```

plaintext

In Cursor Composer: Force index mapping by targeting the file handle directly inside the chat bar:

  Please build out our stripe payment callback router following the criteria defined in @SKILL.md

Real-World Transformations: Before and After

When SKILLS.md is active, the agent stops acting like a passive code generator and starts acting like an unyielding architecture reviewer.

Example: Payment Balance Deduction

Without SKILLS.md: The user asks for a simple point redemption function. The AI generates a standard SELECT balance followed by an UPDATE balance sequence. It looks clean, passes unit tests, but immediately falls to a race condition exploit when a user executes parallel curl requests.
With SKILLS.md: The agent's internal reasoning detects a state change trigger. It forces the SQL generation to include row-level isolation via SELECT ... FOR UPDATE or requires a strict Idempotency-Key header transaction check.

Example: User-Configured Webhooks

Without SKILLS.md: The user prompts the AI to build an outbound webhook engine so users can get alerts. The AI uses a simple Axios/Fetch call passing the target parameter. An attacker signs up, sets their webhook to [http://169.254.169.254/latest/meta-data/](http://169.254.169.254/latest/meta-data/), and extracts cloud infrastructure IAM keys.
With SKILLS.md: The agent flags the user-controlled URL routing pattern. It refuses to output the code until it builds an accompanying domain allowlist check, wraps the execution in an isolated egress proxy, or isolates the protocol rules.

The Bigger Shift

Today, engineers review AI-generated code. Tomorrow, AI systems will review AI-generated code. Eventually, entire engineering workflows will become completely autonomous.

When that happens, security can no longer exist as an afterthought or a final manual compliance checklist performed at the tail end of a sprint. It has to become a core property of the AI's internal reasoning loop.

AI does not automatically inherit security instincts. It inherits whatever mental models we explicitly give it. If you train an AI to think only like an engineer, it will build systems. If you train it to think like an attacker, it will help you build resilient systems.

The future belongs to the teams that can do both. Secure software is not created by accident; it is forged when someone spends enough time thinking about how it breaks first.

Breaking to Build: How CTF and Bug Bounty Hunting Rewires System Design

Shubham — Sun, 31 May 2026 18:50:37 +0000

As software engineers, we are trained to be creators. We stare at a product requirement document, map out the happy path, write the logic, pass the unit tests, and ship it. Our default mental model is constructive: How do I make this system work?

But if you have ever spent a weekend hunting for bugs on a crowdsourced bounty platform or staying up until 3 AM playing a Capture The Flag (CTF) competition, your brain undergoes a permanent structural shift. You stop looking at code exclusively as an implementation of business requirements. Instead, you start looking at it as an attack surface.

Playing on the offensive side of security completely changes the way I write code and architect distributed systems. The moment my fingers leave the keyboard after implementing a new feature, a second thought instantly kicks in: "If I were targeting this system, how would I break what I just wrote?"

Here are the core system design lessons that offensive security beats into your engineering instincts.

1. Eradicating the Myth of the "Trusted Database"

A classic flaw in traditional software engineering is the reliance on implicit trust boundaries. Developers are naturally paranoid about direct user inputs (like a POST request body), but they tend to drop their guard once data is written to the database. They treat data returned from a SELECT query as inherently "safe."

An attacker who understands vulnerabilities like SSTI (Server-Side Template Injection) or Stored XSS knows exactly how to exploit this complacency. They will inject a payload into a benign-looking field (like a profile username or an address line), let it sit quietly in your database, and wait for your backend to fetch it later and drop it un-sanitized into a high-privilege processing sink or HTML rendering engine.

[Attacker Payload] ──► [Inbound Request] ──► [Database (Stored Plaintext)]
                                                    │
                                        Backend fetches data later
                                                    │
                                                    ▼
[Malicious Execution Sink] ◄── [No Validation] ◄── [App Read Layer]

CTF experience forces you to adopt a strict Zero-Trust Input/Reflection Policy.

Every data point entering a processing context-whether it came from an unauthenticated webhook, a secure API call, or was reflected out of your own PostgreSQL database-is treated as radioactive untrusted data.
Sanitization and structural typing must happen not just at the network perimeter, but at the boundary of every execution sink.

2. Eliminating IDOR by Architecting Hard Boundaries

Insecure Direct Object References (IDOR) routinely sit at the top of real-world bug bounty payouts because they are incredibly easy to exploit but devastating in execution. An IDOR happens when a system exposes a direct reference to an internal database record (like an incremental integer or a plain UUID) via an API endpoint, and fails to validate if the requesting user actually owns that resource.

A typical developer might implement a endpoint like this:

GET /api/v1/organization/getDetails?orgId=5690

To an engineer with a bug bounty mindset, seeing an orgId or userId exposed directly in a query parameter or a mutable request header instantly triggers a red flag. It shouts: “Change this number, read someone else’s data.”

To completely engineer past this vulnerability, you shift the source of truth entirely away from client-controlled variables. Instead of trusting the request parameters to tell you who the organization or user is, you pull those identity markers exclusively from a cryptographically signed session context or an immutable JWT verified at the gateway level.

If the client wants to see their organization details, they call:

GET /api/v1/organization/myDetails

The backend looks up the authentication session token, extracts the immutable, verified orgId bound to that active session token, and queries the database using that token. The user can manipulate the HTTP parameters all they want; they can never force an out-of-bounds state transition because they don't control the variables powering the query.

3. Anticipating SSRF and CSRF in Component Design

When you have spent hours constructing complex payloads to bypass firewalls in an SSRF (Server-Side Request Forgery) challenge, you design internal networking components differently.

If your backend needs to support a webhook notification feature or pull an image from a user-supplied URL, a non-security background might just use a standard HTTP client library to fire off the request. But an offensive mindset immediately foresees the vulnerability: an attacker passing http://127.0.0.1:8500/ or an internal AWS metadata endpoint (http://169.254.169.254/) to scan your internal VPC from the inside out.

Knowing this, you build defensiveness directly into your infrastructure blueprints: isolating egress traffic for user-supplied URLs to sandboxed network zones, enforcing strict DNS resolution checks against private IP ranges, and implementing secure Cross-Site Request Forgery (CSRF) tokens on all state-changing endpoints from day one.

The Verdict: Offensive Experience is a Defensive Superpower

You can read every security checklist, memorize the OWASP Top 10, and mandate static analysis tools across your CI/CD pipeline-but nothing replaces the deep architectural paranoia gained by actively breaking systems.

Playing CTFs and hunting bounties teaches you to read between the lines of your own source code. It transforms security from a tedious, compliance-driven box to check before a release into a continuous, active thread running through your entire system design process.

When you learn how to think like a breaker, you become an infinitely better builder.

Demystifying the Trinity: Functor, Applicative, and Monad in PureScript

Shubham — Sat, 30 May 2026 04:24:48 +0000

When diving into pure functional programming, you are immediately confronted with three abstract terms that sound more like advanced physics concepts than software engineering patterns: Functors, Applicatives, and Monads.

For a long time, the internet has tried to explain them using metaphors like "burrito boxes" or "spaceships." Based on my experience and everyday usage, it is much better to look at them for what they truly are: elegant design patterns for managing data flow, context, and computation with mathematical certainty.

Let’s break down this holy trinity of functional programming using clean, practical PureScript examples.

The Core Concept: Values in a Context

Before writing code, let’s establish a visual mental model. In PureScript, we often deal with values wrapped inside a context (or container).

Maybe a represents a value of type a that might be missing (handling null safely).
Either e a represents a computation that might fail with an error of type e.
Effect a represents a synchronous side-effect (like logging to the console or interacting with the DOM).

The Trinity-Functor, Applicative, and Monad-are simply a progressive set of tools that allow us to manipulate these wrapped values without manually unwrapping and re-wrapping them at every single step.

1. Functor: Mapping over a Context

The simplest abstraction is the Functor. A Functor allows you to apply a normal, pure function to a value that is sitting inside a context.

The Definition

To be a Functor, a type constructor f must implement the map function (often written as the infix operator <$>).

Code snippet

class Functor f where
  map :: forall a b. (a -> b) -> f a -> f b

Usage Example

Imagine you are processing a transaction payload where the payment amount might be missing (Maybe Int). You want to convert this amount into cents (multiply by 100).

Code snippet

module Main where

import Prelude
import Data.Maybe (Maybe(..))
import Effect (Effect)
import Effect.Console (logShow)

-- A pure function that knows nothing about contexts
toCents :: Int -> Int
toCents dollar = dollar * 100

main :: Effect Unit
main = do
  let dynamicAmount = Just 50  -- A value inside a context
  let missingAmount = Nothing  -- An empty context

  -- Using map (<$>) to apply the pure function inside the context
  logShow (toCents <$> dynamicAmount) -- Output: (Just 5000)
  logShow (toCents <$> missingAmount) -- Output: Nothing

Crucial Insight: Notice how toCents takes a raw Int, not a Maybe Int. The Functor instance for Maybe automatically handles the plumbing. If it’s Just, it applies the function. If it’s Nothing, it short-circuits safely.

2. Applicative: Function and Value Both in Contexts

What happens if the function itself is trapped inside a context? Or what if you want to apply a pure function that takes multiple arguments to multiple wrapped values? This is where Functor falls short, and Applicative steps in.

The Definition

An Applicative Functor extends Functor with two main functions: pure (to lift a raw value into a context) and apply (written as <*>).

Code snippet

class Functor f <= Applicative f where
  pure  :: forall a. a -> f a
  apply :: forall a b. f (a -> b) -> f a -> f b

Usage Example

Suppose we are building a user profile record from an API response. We have a pure data constructor createUser that takes a String (Name) and an Int (User ID). However, both pieces of data are fetched independently and arrive wrapped in a Maybe context.

Code snippet

type User = { name :: String, id :: Int }

createUser :: String -> Int -> User
createUser name id = { name: name, id: id }

main :: Effect Unit
main = do
  let maybeName = Just "Alice"
  let maybeId   = Just 1024

  -- Functor + Applicative in harmony:
  -- 1. `createUser <$> maybeName` maps the first argument, returning: Maybe (Int -> User)
  -- 2. We use `<*>` to apply the remaining wrapped Int argument.
  let maybeUser = createUser <$> maybeName <*> maybeId

  logShow maybeUser 
  -- Output: (Just { name: "Alice", id: 1024 })

  -- If any piece is missing, the whole thing safely results in Nothing
  let partialUser = createUser <$> Nothing <*> maybeId
  logShow partialUser 
  -- Output: Nothing

Crucial Insight: Applicatives allow you to run independent computations in isolation. The evaluation of maybeId does not depend on the result of maybeName.

3. Monad: Dependent Chaining (The Heavy Lifter)

Finally, we reach the Monad. While Applicatives handle independent wrapped values, Monads are designed to handle dependent sequential computations.

Use a Monad when the output of one context-wrapped computation determines what the next context-wrapped computation should look like.

The Definition

A Monad extends Applicative by introducing bind (written as >>=).

Code snippet

class Applicative m <= Monad m where
  bind :: forall a m b. m a -> (a -> m b) -> m b

If you tried to use regular map with a function that returns a wrapped value (i.e., a -> m b), you would end up with a messy nested context: m (m b). The Monad’s job is to apply the function and automatically flatten the result.

Usage Example (PureScript `do` notation)

PureScript provides syntactic sugar called do notation, which makes working with Monads look like imperative code while preserving pure functional guarantees under the hood.

Let's look at a typical multi-step verification sequence:

Validate a user ID.
If valid, look up their wallet balance (which could fail).
If they have enough funds, process the transaction.

Code snippet

import Data.Maybe (Maybe(..))

-- Simulating dependent lookups
validateUser :: Int -> Maybe String
validateUser id = if id == 777 then Just "VIP_User" else Nothing

getWalletBalance :: String -> Maybe Int
getWalletBalance username = if username == "VIP_User" then Just 500 else Nothing

-- Monadic Chaining using `do` notation
processPayment :: Int -> Maybe String
processPayment userId = do
  username <- validateUser userId         -- Extracts string out of Maybe
  balance  <- getWalletBalance username   -- Dependent on previous username
  if balance > 100
    then Just "Payment Successful!"
    else Nothing

main :: Effect Unit
main = do
  logShow (processPayment 777) -- Output: (Just "Payment Successful!")
  logShow (processPayment 123) -- Output: Nothing (Fails safely at step 1)

Crucial Insight: If validateUser returns Nothing, the Monad stops evaluating the rest of the block immediately. We get bulletproof error propagation without writing a single nested if-else or try-catch block.

Summary: Choosing Your Tool

In my day-to-day workflow, I pick the right tool for the job by asking a simple question about what I am trying to combine:

Abstraction

What you have

What you want to apply

Code pattern

Functor

Value in a context (f a)

A pure function (a -> b)

f <$> x

Applicative

Values in contexts (f a, f b)

A pure multi-arg function

f <$> x <*> y

Monad

Value in a context (m a)

A function returning a context (a -> m b)

x >>= \v -> ... or do blocks

Final Thoughts

Adopting these typeclasses fundamentally shifts how you reason about software architecture.

Before using this framework, handling multi-step asynchronous or conditional logic meant writing deeply nested error-handling logic. By leveraging Functor, Applicative, and Monad, we compose complex architectures out of small, highly reusable, and predictable building blocks. It makes systems dramatically easier to refactor, impossible to crash with unexpected null pointers, and exceptionally clean to maintain.

AI Is Making Senior Engineers 10x Faster - And 10x More Exhausted

Shubham — Thu, 28 May 2026 10:01:24 +0000

When AI coding tools first appeared, I thought:

“Nice. Less boilerplate.”

Now it feels like I’m managing a team of infinitely fast junior engineers that never sleep, constantly hallucinate, and submit pull requests every 30 seconds.

As a senior engineer, AI has dramatically increased my productivity.

It has also dramatically increased my cognitive load.

Both things are true at the same time.

The Good Part: AI Removes the Annoying Work

There’s no denying it anymore.

LLMs are insanely useful for:

Writing repetitive code
Generating tests
Refactoring old logic
Explaining unfamiliar codebases
Writing SQL
Generating migration scripts
Producing documentation nobody wanted to write

Things that used to take 2 hours now take 15 minutes.

I can scaffold APIs instantly.

I can debug faster.

I can prototype ideas without context-switching for half a day.

AI gives senior engineers leverage.

And leverage compounds fast.

The productivity jump is real.

The Bad Part: Senior Engineers Became Human Validators

Here’s the problem nobody talks about enough:

AI shifted senior engineering from “building systems” to “constantly validating generated output.”

Earlier:

Juniors wrote code
Seniors reviewed architecture and edge cases

Now:

AI writes massive amounts of code instantly
Seniors review ALL of it

Everywhere.

All the time.

And unlike juniors, AI has:

Infinite confidence
No memory
No accountability
No understanding of business context

It can generate code that looks perfect while quietly introducing:

race conditions
security issues
hidden performance problems
broken abstractions
fake APIs
impossible edge-case handling

The scary part is that the code often looks clean.

Very clean.

Sometimes cleaner than human-written code.

Which makes spotting mistakes even harder.

AI Increased Output, But Also Increased Noise

One senior engineer can now produce the output of an entire small team.

Sounds amazing, right?

Except now:

PR sizes explode
Architecture decisions happen too quickly
People ship generated code they barely understand
Teams confuse “velocity” with “quality”

The bottleneck is no longer writing code.

The bottleneck is:

understanding systems
validating correctness
maintaining consistency
keeping complexity under control

AI accelerated code generation much faster than it accelerated engineering judgment.

And that gap is becoming painful.

Context Engineering Is Becoming More Important Than Coding

The best engineers I know today are not the people writing the most code.

They are the people giving AI the best context.

A weak prompt creates chaos.

A strong prompt creates leverage.

Senior engineers are now spending more time:

designing workflows
defining constraints
writing repository instructions
creating architecture guardrails
building agent tooling
managing AI behavior

We are slowly moving from:

“software engineers”

to:

“system directors for machine-generated software.”

That sounds futuristic.

But honestly, it mostly feels like more responsibility.

The Hidden Burnout Nobody Talks About

AI creates a weird kind of exhaustion.

Not physical exhaustion.

Cognitive exhaustion.

You are constantly:

verifying outputs
re-checking assumptions
reviewing generated logic
correcting hallucinations
re-explaining context
fighting subtle inconsistencies

It feels like supervising an incredibly fast intern that learns nothing between conversations.

And because the output is instant, expectations change instantly too.

Management sees:

“Tasks finish faster.”

Senior engineers feel:

“I’m mentally reviewing 5x more moving pieces than before.”

That mismatch is dangerous.

Junior Engineers and the Experience Gap

Another thing that worries me:

Junior engineers can now generate advanced-looking systems without fully understanding them.

That’s powerful.

But also risky.

Earlier, painful debugging built intuition.

Now AI often bypasses the struggle phase completely.

Which means senior engineers increasingly become:

teachers
validators
architecture reviewers
production safety nets

The gap between “can generate code” and “can engineer systems” is becoming massive.

The Reality Nobody Wants to Admit

AI is not replacing senior engineers.

It’s making strong senior engineers more valuable.

Because somebody still needs to:

understand distributed systems
identify bad abstractions
reason about scale
evaluate trade-offs
catch subtle failures
make architectural decisions

AI can generate solutions.

It still cannot reliably judge consequences.

And consequences are where senior engineering lives.

Final Thoughts

I genuinely love using AI.

I use it every day.

I would never go back.

But AI didn’t reduce the importance of senior engineering.

It amplified it.

The industry thinks AI is automating software development.

What it’s actually doing is increasing the demand for engineers who can think critically under complexity.

AI removed a lot of typing.

Unfortunately, it also created an endless stream of things that now require human judgment.

And human judgment remains the most expensive part of software engineering.