DEV Community: Shubham

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 rolling out a modern streaming or web application, they visualize a standard cloud-native environment: a global CDN, elastic load balancers, and a continuous pipeline pushing updates to infinite resources.

But what happens when your deployment target is an isolated, battery-powered hardware device flying inside a metal tube at 35,000 feet?

At AirFi, operating a next-generation In-Flight Entertainment (IFE) platform forced us to completely rethink modern web architecture. When you lack a persistent, high-bandwidth connection to AWS, the cloud can no longer be your source of immediate truth. Instead, you are forced to conquer the ultimate disconnected edge problem.

Here is how we designed a hybrid, localized infrastructure to keep our systems updated without consuming precious in-flight bandwidth.

The Architecture: Hanger-Based Edge Proxies

Instead of trying to fight the high cost and extreme latency of satellite internet mid-flight to update heavy media content (like Hollywood movies, music, or web apps), we shifted our synchronization strategy entirely to the ground.

However, passenger gates are chaotic, and standard airport tarmac Wi-Fi is notoriously unreliable. To guarantee data integrity, we integrated our sync cycles into the aircraft's routine service windows, targeting two specific ground locations: airline plane hangers and catering/food hangers.


[ AWS Cloud Backend ]
        │
        ▼ (Over the Internet)
[ Hanger Content Proxy (Local Cache) ]
        │
        ▼ (High-Speed Local Wi-Fi)
[ Onboard Portable IFE Box ]

We deployed localized Content Proxies directly inside these hangers. These proxies acted as high-speed regional caches that pulled down global updates directly from AWS ahead of time. When an aircraft docked in or near the hanger for cleaning, catering, or maintenance, the portable IFE hardware automatically associated with the hanger’s dedicated high-speed Wi-Fi network to ingest the updates locally.

Atomic, Split-Manifest Synchronization

Even on a high-speed hanger network, turnaround windows can be unpredictably cut short. If a plane is pushed out early, a naive file-transfer system would result in corrupted movie files or broken application states.

To solve this, we decoupled our data ingestion pipeline into two distinct layers:

The Content Manifest as the Ultimate Source of Truth: Rather than downloading a giant, opaque payload, the onboard device initially prioritized pulling down a highly compressed, lightweight Content Manifest. This file detailed the precise global state, directory layout, dependency tree, and cryptographic hashes of every single asset the device was required to hold for its next flight lifecycle.
Sequential Atomic Downloads: Armed with the manifest, our synchronization engine didn't try to download everything at once. It processed assets sequentially and atomically—downloading and verifying exactly one manifest item at a time (e.g., syncing a single movie completely, writing it to disk, verifying its hash, and then moving onto the web application assets).

If the device lost connection mid-sync because the plane was moving, previously completed assets remained 100% intact, validated, and ready for use.

The Hybrid Layer: GSM Failover for Critical Telemetry

While transferring gigabytes of media assets was strictly gated to high-speed hanger Wi-Fi networks, certain data points couldn't wait for a hanger turnaround. Passenger usage analytics, digital menu transaction logs, and urgent system configuration overrides needed a faster loop back to our core backend.

For this mission-critical data, we built a hybrid networking layer that utilized GSM (cellular) networks. The moment the aircraft touched down on the tarmac anywhere in the world and a cellular signal became available, the device spun up its GSM module to securely offload encrypted telemetry and pull down vital system updates.

By separating heavy media from critical operational telemetry, we ensured that our data loops remained low-latency and cost-effective, proving that navigating the edge isn't about having a constant connection—it's about making the absolute most of the connections you have.

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: security-review
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
---

# Agent Skill: Security-First System Architecture (Breaking to Build)

## Purpose
This skill transforms the agent from a feature implementation assistant into a security-focused architectural reviewer. The objective is to continuously evaluate whether a design remains resilient under adversarial conditions.

Every system is evaluated from two perspectives:
1. Functional correctness — Does it work?
2. Adversarial resilience — How can it be abused, bypassed, or broken?

---

## Core Philosophical Directive
Assume: Inputs are malicious, clients are untrusted, networks are hostile, dependencies may be compromised, and internal services are untrusted. Never trust; always verify at the point of execution.

---

# Exploitation Mindset → Resilient Architecture Matrix

### 1. State Isolation vs Race Conditions
* **Exploitation:** Attackers exploit concurrent execution paths to double-spend balances, redeem coupons multiple times, or bypass inventory thresholds.
* **Requirements:** Enforce ACID transactions, row-level locking (`SELECT ... FOR UPDATE`), or distributed locks where required. Never rely on request timing assumptions.
* **Core Question:** *Can the same operation succeed twice if executed simultaneously?*

### 2. Explicit Authorization vs BOLA / IDOR
* **Exploitation:** Modifying resource identifiers (e.g., `/api/users/1002`) to access unauthorized tenant data.
* **Requirements:** Decouple Authentication from Authorization. Force ownership validation directly at the data access layer. Never assume an authenticated user has access to all identifiers.
* **Core Question:** *What changes if the resource identifier changes?*

### 3. Deterministic Routing vs SSRF
* **Exploitation:** User-controlled URLs triggering backend requests toward cloud metadata (`169.254.169.254`), internal container networks, or private admin panels.
* **Requirements:** Strict domain allowlists, network segmentation, outbound network proxies, and strict protocol restrictions. Never trust regex alone.
* **Core Question:** *Who ultimately controls destination routing?*

### 4. Canonical Resource Access vs Path Traversal
* **Exploitation:** Path manipulation (`../../etc/passwd`) to escape intended local storage or file directories.
* **Requirements:** Use UUID object identifiers, decoupled cloud object storage, or strict canonical path resolution. Never trust raw user-controlled filesystem paths.
* **Core Question:** *Can users directly influence local file system paths?*

### 5. Blast Radius Reduction
* **Exploitation:** Horizontal and vertical privilege expansion following an initial single-service or container compromise.
* **Requirements:** Enforce non-root containers, minimal Linux capabilities, least-privilege cloud IAM, scoped credentials, and network micro-segmentation.
* **Core Question:** *If this specific service is fully compromised, what else becomes reachable?*

### 6. Fail-Closed Security Controls
* **Exploitation:** Exploiting undefined states where validation exceptions or errors allow execution to continue by default.
* **Requirements:** The default fallback state of any conditional check or exception catch block must be a hard `DENY`.
* **Core Question:** *What happens to system access if a code validation error occurs?*

### 7. Secrets and Cryptographic Isolation
* **Exploitation:** Leaking persistent credentials via standard outputs, application logs, build system environment outputs, or source code management repositories.
* **Requirements:** Use external Secret Managers, automated key rotation, secure pseudo-random generators, and ephemeral execution credentials.
* **Core Question:** *Can this credential survive an active infrastructure compromise?*

### 8. Supply Chain Security
* **Exploitation:** Malicious code updates introduced silently via compromised third-party package ecosystems.
* **Requirements:** Strict dependency pinning, cryptographic lockfiles, package signature verification, and a minimal external dependency footprint.
* **Core Question:** *What third-party code executes that we do not explicitly own or audit?*

### 9. Event-Driven Integrity
* **Exploitation:** State corruption through message replays, duplicate webhooks, out-of-order queue events, or malicious message retries.
* **Requirements:** Enforce idempotent processing states, cryptographic event signatures, and isolated dead-letter queue fault handling.
* **Core Question:** *Can replaying an event alter the existing database state?*

### 10. AI and LLM Security Controls
* **Exploitation:** Direct or indirect prompt injection causing unauthorized execution or data leakage via agentic tool use.
* **Requirements:** Treat all model outputs as untrusted data inputs. Enforce explicit tool-level authorization gateways, strict output schemas, and mandatory human-in-the-loop validation for privileged actions.
* **Core Question:** *What authorization boundaries exist between the model's output and execution layer?*

---

## Agent Verification Protocol
Whenever reviewing or modifying system architecture, sequentially process these tasks:
1. **Deconstruct Trust:** Map out all input boundaries and strip assumptions of inherent safety.
2. **Analyze Concurrency:** Evaluate execution state changes under parallel or overlapping conditions.
3. **Inspect Boundaries:** Confirm authorization is validated sequentially on every request layer.
4. **Review Privileges:** Apply the principle of least privilege to access management.
5. **Simulate Full Compromise:** Map the potential blast radius assuming this logic is broken.

*Final Constraint: The target is not to write code that works under perfect conditions. The target is to build software that continues behaving 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.

DEV Community: Shubham

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

The Architecture: Hanger-Based Edge Proxies

Atomic, Split-Manifest Synchronization

The Hybrid Layer: GSM Failover for Critical Telemetry

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

The Missing Layer in AI-Assisted Development

What Is SKILLS.md?

Why Traditional Security Checklists Fail

The Evolution From Builder To Breaker

The Specifications: SKILLS.md

Installation Guide

1. Claude Code

Real-World Transformations: Before and After

Example: Payment Balance Deduction

Example: User-Configured Webhooks

The Bigger Shift

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

1. Eradicating the Myth of the "Trusted Database"

2. Eliminating IDOR by Architecting Hard Boundaries

3. Anticipating SSRF and CSRF in Component Design

The Verdict: Offensive Experience is a Defensive Superpower

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

The Core Concept: Values in a Context

1. Functor: Mapping over a Context

The Definition

Usage Example

2. Applicative: Function and Value Both in Contexts

The Definition

Usage Example

3. Monad: Dependent Chaining (The Heavy Lifter)

The Definition

Usage Example (PureScript do notation)

Summary: Choosing Your Tool

Final Thoughts

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

The Good Part: AI Removes the Annoying Work

The Bad Part: Senior Engineers Became Human Validators

AI Increased Output, But Also Increased Noise

Context Engineering Is Becoming More Important Than Coding

The Hidden Burnout Nobody Talks About

Junior Engineers and the Experience Gap

The Reality Nobody Wants to Admit

Final Thoughts

Usage Example (PureScript `do` notation)