DEV Community: Shubham Gupta

Median of Two Sorted Arrays — LeetCode #4 (Hard)

Shubham Gupta — Tue, 19 May 2026 09:30:58 +0000

The Problem

Given two sorted arrays, return the median of all their elements combined, in logarithmic time.

Example

Input: nums1 = [1,3], nums2 = [2]

Output: 2.00000

merged array = [1,2,3] and median is 2.

Constraints

0 <= m, n <= 1000
1 <= m + n <= 2000
-10^6 <= nums1[i], nums2[i] <= 10^6
Required runtime: O(log(m+n))

The Key Insight

Let's slow down. Look at what the merge throws away. We carefully ordered all eleven numbers. But we only needed the one in the middle. The rest was wasted effort.

Here's the real question. What does the median actually tell us about how the numbers are split? The median is the point where the numbers divide into a smaller half and a larger half. Equal sized halves when the total's even; otherwise the left half gets one extra.

So forget merging. What if we just drew a dividing line through each array, a left part and a right part? Eleven numbers total. We want six on the left, five on the right. That left count never changes.

Here's the move. If we cut the first array, the cut in the second is forced. Both left parts together must add up to six. So we only choose one thing: where to cut the smaller array. The other cut follows automatically.

When is a cut correct? Every number on the left must be less than or equal to every number on the right. Because both arrays are sorted, we only check the four numbers touching the cut lines: the two ends of the left, the two starts of the right.

The test is simple. The first array's left edge must not exceed the second array's right edge, and the other way around too. And to find the right cut, we don't try every spot. We binary search, like guessing a number while halving the range each time.

Watch out for one trap. You might pick the bigger array to search. Don't. Cut the smaller one, or its forced cut can fall off the edge. And when a cut sits at the very start or end, there's no number there. We treat a missing left edge as negative infinity, a missing right edge as positive infinity.

Why It Works

Notice what we never did. We never merged the lists. Each guess threw away half the remaining cut positions, so a few guesses were enough.

Walking Through It

Let's trace it. First list: one, three, eight, nine, fifteen. Second list: seven, eleven, eighteen, nineteen, twenty-one, twenty-five. Eleven numbers total. The left half needs six. We binary search the cuts of the smaller first array.

The cut in the first array can be anywhere from zero to five. Start the search: low is zero, high is five. Midpoint of the search is cut position two. That puts two numbers from the first array on the left, so the second gives four.

Now the four border numbers. First array: left edge three, right edge eight. Second array: left edge nineteen, right edge twenty-one. Check one: is the first array's left edge, three, less than or equal to the second's right edge, twenty-one? Yes.

Check two: is the second array's left edge, nineteen, less than or equal to the first's right edge, eight? No. Nineteen is way too big. So this cut is wrong. The second array put too many numbers on its left. We need more from the first array instead.

Move the search to the right. Low becomes three. Try again. New midpoint cut: position four. Four numbers from the first array on the left, so the second gives just two.

Border numbers now. First array: left edge nine, right edge fifteen. Second array: left edge eleven, right edge eighteen. Check one: first array's left edge nine, less than or equal to the second's right edge eighteen? Yes.

Check two: second array's left edge eleven, less than or equal to the first's right edge fifteen? Yes. Both pass. This cut is valid. The left half holds the six smallest numbers, the right half the five largest.

The total, eleven, is odd. The median is the largest number on the left: the bigger of nine and eleven, which is eleven.

Complexity

Each step halves the cuts still worth considering. So the number of steps grows with the logarithm of the smaller array's length. And we only ever store a few border values, never a merged list. The memory stays constant no matter how big the inputs grow.

The Code

OK, same logic in Python. Swap so A is the smaller array, work out the left half size, and set the search bounds on A's cut. Each loop pass picks a cut in A, and the cut in B follows automatically, since the left half size is fixed.

Read the four border values. When a cut sits at an edge, fall back to negative or positive infinity. If both checks pass, the cut is valid. An odd total returns the largest left value, an even total averages the two middle ones.

Otherwise shift the search. If A's left edge is too big, go left. Otherwise go right, and try again.

class Solution(object):
    def findMedianSortedArrays(self, nums1, nums2):
        A, B = nums1, nums2
        if len(A) > len(B):
            A, B = B, A
        m, n = len(A), len(B)
        half = (m + n + 1) // 2
        lo, hi = 0, m
        while lo <= hi:
            i = (lo + hi) // 2
            j = half - i
            left1 = A[i - 1] if i > 0 else float('-inf')
            right1 = A[i] if i < m else float('inf')
            left2 = B[j - 1] if j > 0 else float('-inf')
            right2 = B[j] if j < n else float('inf')
            if left1 <= right2 and left2 <= right1:
                if (m + n) % 2:
                    return max(left1, left2)
                return (max(left1, left2) + min(right1, right2)) / 2.0
            elif left1 > right2:
                hi = i - 1
            else:
                lo = i + 1

Wrap-up

And that's the trick. Stop merging, start cutting. When a problem demands O(log n) time, ask what you can throw away each step.

📺 Watch the full walkthrough on YouTube: https://youtu.be/6e5TLbzYyaw

Narration uses an AI-generated voice (Supertonic TTS).

Longest Substring Without Repeating Characters — LeetCode #3 (Medium)

Shubham Gupta — Mon, 18 May 2026 19:32:33 +0000

The Problem

Given a string s, return the length of the longest substring that contains no duplicate characters.

Example

Input: s = "abcabcbb"

Output: 3

The answer is "abc", with the length of 3. Note that
"bca"
and
"cab"
are also correct answers.

Constraints

0 <= s.length <= 5 * 10^4
s consists of English letters, digits, symbols and spaces

The Key Insight

Here's what we're throwing away. When we hit the duplicate 'a', we already knew the window held 'a', 'b', 'c'. We had that information. What if instead of restarting, we just nudged the left edge forward until the duplicate was gone?

That's the sliding window. A left pointer and a right pointer. Right grows the window, left shrinks it. We need instant answers: is this character already in the window? That's a set. Think of a guest list, names only, no duplicates.

You might think to add the character first, then check. Don't. Check first, then add, or you'd match a character against itself. The rule: while right's character is in the set, remove from the left and slide left forward. Then add right's character.

Why It Works

Notice what happened. Both pointers only ever moved right. Every character entered the set once and left once. No backtracking.

Walking Through It

Left and right both start at zero. 'a' is not in the empty set. We add it. Window is one wide. Max is one. Right moves to one. 'b' is not in the set. Add it. Window spans zero to one. Max is two.

Right to two. 'c' is not in the set. Add it. Window is three wide. Max becomes three. Right to three. That's 'a' again. 'a' is already in the set. Duplicate.

Remove 'a' at index zero, slide left to one. 'a' is out of the set. Add the new 'a'. Window spans one to three. Right to four. 'b' is in the set. Remove 'b' at left, slide to two. Add new 'b'. Window is two to four. Max still three.

Right to five. 'c' repeats. Remove 'c' at left, slide to three. Add 'c'. Window three to five. Max still three. Right to six. 'b' is in the set. Remove 'a' at left, slide. 'b' is still there. Remove 'b' too, slide again.

Now 'b' is clear. Add it. Window is just two wide. Right finishes at seven the same way. Max never exceeded three.

Complexity

Each character enters the window once and leaves once. The set holds only the current window. Time and memory both grow with the string's length.

The Code

OK, same logic in Python. We initialize the set, the left pointer, and the running max. The outer loop walks right one step at a time through every character.

The inner while keeps removing from the left until the repeat is out of the set. Then we add the new character and check if this window beats our best.

Hand back the best length we found.

class Solution:
    def lengthOfLongestSubstring(self, s: str) -> int:
        seen = set()
        left = 0
        max_len = 0
        for right in range(len(s)):
            while s[right] in seen:
                seen.remove(s[left])
                left += 1
            seen.add(s[right])
            max_len = max(max_len, right - left + 1)
        return max_len

Wrap-up

And that's the pattern. Grow until you can't, shrink until you can. You'll see this shape again.

📺 Watch the full walkthrough on YouTube: https://youtu.be/DgPbYhD4FMw

Narration uses an AI-generated voice (Supertonic TTS).

Add Two Numbers — LeetCode #2 (Medium)

Shubham Gupta — Mon, 18 May 2026 14:16:25 +0000

The Problem

Add two numbers whose digits are stored as nodes of two linked lists in reverse order, and return the sum as a linked list.

Example

Input: l1 = [2,4,3], l2 = [5,6,4]

Output: [7,0,8]

342 + 465 = 807.

Constraints

Each list has 1 to 100 nodes
Each node value is a single digit, 0 to 9
No leading zeros except the number 0 itself

The Key Insight

Now think about how you'd add by hand. You don't glue the digits into one number first. You go column by column. So what if we do exactly that here? Take the two matching digits, add just those, write down one result, and move on.

That's the move. Column-by-column addition. And since the digits are already reversed, the ones column comes first. That lines up perfectly. One catch. Four plus six is ten. Ten doesn't fit in a single digit slot, so we keep the last digit and carry the one forward.

That carry is the only memory we need. It's just one small number, handed from each column to the next one. Watch out for one mistake. You might think to stop once both lists run out. But if the last column carried a one, you still owe one more digit.

Why It Works

Notice what we never did. We never built those big numbers. Each digit got touched once, and the carry held the only memory we needed.

Walking Through It

Let's run it. Carry starts at zero. We also keep a fake starting node, so attaching the very first digit needs no special handling. First column. Two plus five is seven, plus a carry of zero. Nothing spills over, so we attach a node holding seven.

Next column. Four plus six is ten. Ten won't fit in one digit slot, so something has to give. We keep the last digit, which is zero, and attach a node holding zero. The leftover one becomes the carry into the next column.

Last column. Three plus four is seven, plus the carried one, that makes eight. We attach a node holding eight. Both lists are empty now, and the carry is zero. There's nothing left to add, so we stop.

Drop the fake node, and the answer starts at seven. Read it out as a whole, eight hundred seven. Correct.

Complexity

We walk each list one time, so the time grows with the longer list. The answer holds one node per digit, so the memory grows the same way.

The Code

Same logic, now in Python. We make a fake starting node, a pointer to build from, and set the carry to zero. The loop keeps running while either list still has a digit, or there's a leftover carry. That last part catches the final one.

Inside, we read each digit. If a list has already run out, we treat its digit as zero, so two different lengths just work. We add the two digits and the carry. The new carry is whatever spilled past ten, and the new node takes the last digit.

Then we step all the pointers forward. When the loop ends, we hand back the list that starts right after the fake node.

class Solution(object):
    def addTwoNumbers(self, l1, l2):
        dummy = ListNode()
        curr = dummy
        carry = 0
        while l1 or l2 or carry:
            x = l1.val if l1 else 0
            y = l2.val if l2 else 0
            total = x + y + carry
            carry = total // 10
            curr.next = ListNode(total % 10)
            curr = curr.next
            l1 = l1.next if l1 else None
            l2 = l2.next if l2 else None
        return dummy.next

Wrap-up

And that's it. Column by column, carry the one. It's the same addition you learned in grade school, just walking a list.

📺 Watch the full walkthrough on YouTube: https://youtu.be/wz9Dhg5LYqI

Two Sum — LeetCode #1 (Easy)

Shubham Gupta — Sun, 17 May 2026 12:39:39 +0000

TL;DR

Single-pass hash map lookup: store each number's index as you go, check for the complement before storing. O(n) time, O(n) space.

The Problem

Given an array of integers nums and an integer target, return the indices of the two numbers that add up to target.

Input: nums = [2,7,11,15], target = 9
Output: [0,1]

The answer is indices 0 and 1 because nums[0] + nums[1] == 9. Note: return indices, not values.

Constraints

2 <= nums.length <= 10^4
-10^9 <= nums[i] <= 10^9
-10^9 <= target <= 10^9
Exactly one valid answer exists.

Naive Approach

Fix one number, scan every number after it for the complement. Repeat for each starting index.

class Solution:
    def twoSum(self, nums: list[int], target: int) -> list[int]:
        for i in range(len(nums)):
            for j in range(i + 1, len(nums)):
                if nums[i] + nums[j] == target:
                    return [i, j]

O(n²) time, O(1) space — ~50 million pair checks on a 10,000-element array.

Key Insight

At every index i, you already know the complement you need: target - nums[i]. The only question is whether that value appeared earlier. Instead of scanning backwards, keep a hash map that answers "have I seen value v?" in O(1).

Two things to get right: use the value as the key and the index as the value (you look up by value, you want to retrieve the index); and check the map before inserting the current number, so a value can't match itself.

Optimal Solution

One pass. For each element, compute need = target - x. If need is already in seen, you're done. Otherwise, record x → i and continue.

class Solution:
    def twoSum(self, nums: list[int], target: int) -> list[int]:
        seen = {}
        for i, x in enumerate(nums):
            need = target - x
            if need in seen:
                return [seen[need], i]
            seen[x] = i

Step-by-step on [2, 7, 11, 15], target 9:

i=0, x=2 — need=7. seen={}, not found. Store seen[2]=0.
i=1, x=7 — need=2. seen={2:0}, found. Return [seen[2], 1] → [0, 1].

The loop never reaches indices 2 or 3.

Complexity

Approach	Time	Space
Naive (nested loops)	O(n²)	O(1)
Hash map (one pass)	O(n)	O(n)

Pattern Recognition

This is the complement lookup pattern: when a problem asks for a pair satisfying some condition, storing what you've seen in a hash map turns a second scan into a O(1) lookup. You'll find the same structure in 3Sum (reduce to Two Sum), subarray sum equals k, and any problem where "what do I need to complete this?" has a clear formula.

In Interviews

The brute force buys you nothing here — interviewers expect the hash map solution immediately. What they're actually watching for: correct key/value orientation in the map, and the check-before-insert rule (if seen[x] = i runs before the lookup, x + x == target would return [i, i] — wrong).

Common follow-ups:

What if multiple valid pairs exist — return all of them? Collect results instead of returning early; decide whether to deduplicate.
What if the array is sorted? Two-pointer from both ends achieves O(n) time with O(1) space — no hash map needed.

📺 Watch the full walkthrough on YouTube: https://youtu.be/4JUNrRN16gM

I built an AI wardrobe app by myself. Here's what actually happened.

Shubham Gupta — Mon, 30 Mar 2026 22:28:14 +0000

Solo dev, no funding, one app that needed to work offline and think online. Why the architecture ended up the way it did.

I spent the last several months building an AI-powered wardrobe app called Outfii. No cofounders, no funding, no team. Just me, too much chai, and a mass of decisions I wasn't qualified to make.

You photograph your clothes, the app organizes them, and AI helps you figure out what to wear. It's on Google Play now. Here's how it actually went.

The problem that wouldn't leave me alone

Every morning, same thing. Full closet, nothing to wear. I looked it up and apparently most people regularly use about 20% of what they own. The rest just hangs there.

I don't have a fashion background. But "help me combine clothes I already own" felt like something code could handle. Whether I was the right person to build it is still an open question.

Why the app needs two brains

This is the part that shaped every other decision.

Some things need to happen instantly. When you're flipping through outfit options, you can't be waiting on a server to tell you whether navy and olive work together. That feedback loop needs to be under 50ms or it feels broken.

Other things need actual intelligence. Looking at a photo and figuring out "that's a linen shirt, it's dusty rose, semi-formal" requires a vision model. Suggesting what to wear tomorrow based on your wardrobe, the weather, and what you wore this week requires an LLM.

So the app has two brains. One lives on your phone. One lives in the cloud. They do completely different jobs.

The on-device brain handles color analysis, harmony scoring, and outfit compatibility. I tried doing this in Dart first. It was too slow. Color distance calculations in tight loops, converting between color spaces, running harmony checks across every item pair in a wardrobe. Dart isolates helped but added complexity without solving the core problem: CPU-bound math needs compiled code. I rewrote it in Rust, bridged to Flutter via flutter_rust_bridge. Scoring now runs in ~20-30ms on a mid-range Android phone. The Rust binary adds about 4MB to the APK, which felt worth it.

The scoring algorithm itself went through three complete rewrites. Telling navy from black programmatically is genuinely hard. CIE Delta E gets you close, but perceptual color difference is still messy at the dark end of the spectrum. Your eyes handle this effortlessly. Code does not.

The cloud brain handles understanding. When you scan a clothing item, an edge function sends the photo to a vision model that identifies type, color, pattern, material. When you ask for outfit suggestions, another function builds context from your wardrobe and passes it to an LLM. Different tasks, different models. Cloud response times vary (2-8 seconds depending on the model and task), which is fine because these aren't real-time interactions.

The two never overlap. Scoring is always local. Understanding is always cloud. This means the core app works offline, which matters a lot in India where connectivity is unpredictable.

The BYOK question

AI features cost money to run. I'm bootstrapped. Subsidizing API calls for every user isn't sustainable.

So I built a bring-your-own-key system. Users can plug in their own OpenAI or Anthropic API key and get the full AI experience without paying me a subscription. Keys are encrypted on the phone and never touch our servers in plaintext. There's also paid tiers for people who don't want to think about API keys.

This was controversial in my head for a while. "Asking users to get their own API key" sounds like terrible UX. But it turns out there's a niche of technical users who actually prefer this. They like knowing exactly what model runs, what it costs, and that their data goes to the provider they chose. It's not for everyone, but it's a real segment.

Everything lives on your phone first

The wardrobe is stored locally in SQLite. Not as a cache. As the source of truth.

I didn't want the app to break when you lose signal. You should be able to browse your wardrobe, check outfit history, and get scoring results in airplane mode. Cloud sync happens in the background when you're online.

The downside is sync conflicts. Two devices editing the same wardrobe creates problems I'm still working through. Last-write-wins is what I ship with for now, but it's not great when someone adds items on a tablet and a phone simultaneously. Solving this properly is on the list.

What went wrong

I shipped too many features at launch. Wardrobe management, AI outfits, weather integration, trip packing, laundry tracking, wear reminders, style profiles. That's three apps pretending to be one. Should've shipped wardrobe + AI outfits and added the rest over time.

My Play Store screenshots were raw app captures. Status bars visible. Timestamps. Battery icons. No marketing framing. People decide whether to install your app in about two seconds of scrolling, and I gave them nothing to work with. Still fixing this weeks later.

Debugging across the Rust bridge was also painful early on. When something panics in Rust, the error you get on the Flutter side is not always helpful. I spent a full day on a crash that turned out to be a type mismatch in the FFI layer that codegen silently accepted. Added a lot of defensive logging after that.

I also copy-pasted boilerplate across backend functions for months before building a shared utilities layer. Auth middleware, response helpers, error formatting, all duplicated. Embarrassing but honest.

What went right

The blog was a good early bet. I wrote about color theory in fashion, capsule wardrobe math, pattern mixing rules. Technical content at the intersection of fashion and algorithms. Five posts, bringing in organic search traffic before anyone even downloads the app.

The on-device scoring engine was painful to set up but it's a genuine differentiator. Most wardrobe apps send every request to a server. Having instant, offline scoring on a 29MB app feels noticeably better. Users don't know it's Rust running on their phone. They just know it's fast.

Where it's going

Social features are rolling out. Users can share outfit combinations. After that, iOS and a web app.

The developer account is under Clarixo, my parent brand. Outfii is the first product. Bootstrapped, planning to stay that way.

If you want to try it: outfii.in

Play Store: Outfii - AI Wardrobe Stylist

If you're building solo, optimize for decisions you can live with for a while. The architecture won't be perfect. Ship the version that's good enough, then fix the parts that actually hurt.

MCP: The Secret Sauce (That Isn't Ranch) for AI Apps

Shubham Gupta — Sun, 25 Jan 2026 17:34:15 +0000

What on Earth is MCP? 🌍

If you've been pasting entire src/ folders into ChatGPT and praying to the Silicon Gods, stop it. Get some help.

Enter Model-Context-Protocol (MCP).

It’s not just a fancy acronym use to impress your Product Manager (though it will do that). It’s the design pattern that stops your AI app from turning into a plate of unmaintainable spaghetti.

(Your codebase right now. Don't lie.)

The Holy Trinity of Not Failing

Model (The Brains): The thing that costs money and hallucinates occasionally. (GPT-4, Claude, Llama).
Context (The Memory): The stuff the model needs to know right now (e.g., "User is angry because the button is broken", not "User was born in 1992").
Protocol (The Handshake): How we talk to the model without it hallucinating a Shakespearean sonnet about React hooks.

The "Before" Times (A.K.A The Dark Ages) 🕯️

Let's look at how most people build their first AI app. It usually looks something like this disaster:

// classic_beginner_mistake.js
async function askAI(question) {
  // 🚩 RED FLAG: Hardcoded logic mixed with DB calls
  const context = await db.getUserHistory(); 

  // 🚩 RED FLAG: String bashing hell
  const prompt = `You are a helpful assistant. Here is history: ${JSON.stringify(context)}. User asks: ${question}`;

  // 🚩 RED FLAG: Married to OpenAI forever
  const response = await openAI.chat.completions.create({ model: "gpt-4", prompt });
  return response;
}

Why this sucks:

Vendor Lock-in: Good luck switching to Claude when OpenAI is down. You're married now. Till 503 Service Unavailable do us part.
Context Bloat: You're stuffing the entire user history into the prompt. That token bill is going to cost more than my rent.
Untestable: How do you unit test "Make the AI sound pirate-y"? (Spoiler: You don't, you just cry).

Enter MCP: The Application Saver 🦸‍♂️

MCP separates these concerns into three distinct layers. Think of it like a fancy Michelin-star restaurant, but instead of food, we serve functions.

1. The Model (The Chef) 👨‍🍳

The Chef (Model) doesn't care who the customer is. They just know how to cook (generate text/code).

In Code: A clean interface that accepts standardized inputs.
Why it's cool: You can fire the Chef (swap GPT-4 for DeepSeek) if they start burning the risotto (hallucinating), and the menu (your app) stays the same.

2. The Context (The Waiter's Note) 📝

The Waiter (Context Manager) gathers what's relevant. They don't give the Chef the customer's entire life story including their childhood trauma. They say, "Table 5, allergy to peanuts, wants spicy."

In Code: Logic that fetches only the necessary RAG data or user state.
Why it's cool: Keeps your prompts lean and your token costs lower than a Starbucks coffee.

3. The Protocol (The Menu & Ticket) 🎫

The standardized language everyone speaks. The customer points to item #4. The waiter writes "Item #4". The Chef cooks "Item #4".

In Code: A strict schema (JSON Schema, Protobuf, etc.) that defines exactly what goes in and out.
Why it's cool: No more "I thought you wanted a summary, but you gave me a haiku about clouds."

Show Me The Code! 💻

Here is a pseudo-code example of what an MCP architecture looks like. Notice how it sparks joy?

// 1. Define the Protocol (The Contract)
interface AIRequest {
  task: "summarize" | "translate" | "generate_code";
  data: string;
  constraints: string[];
}

// 2. The Context Provider (The Waiter)
class ContextManager {
  getRelevantContext(userId: string): string {
    // Smart logic to only get what matters
    // "User prefers Python over JavaScript because they have taste."
    return "User prefers Python.";
  }
}

// 3. The Model Adapter (The Chef Wrapper)
class ModelAdapter {
  constructor(private provider: "openai" | "anthropic") {}

  async execute(request: AIRequest, context: string) {
    // Handles the weird specific API details here
    // So your main app can live in blissful ignorance
    if (this.provider === "openai") {
       return callOpenAI(request, context);
    } // ...
  }
}

Why Should You Care? (The "Please Hire Me" Section) 📈

By adopting the MCP pattern, you're not just over-engineering; you're building for the future.

Scalability: Want to add a specialized model for image generation? Just plug in a new Model Adapter. Boom.
Cost Control: Optimize your Context Manager to shave off tokens. Buy yourself something nice with the savings.
Sanity: When the AI starts acting up, you know exactly which layer to blame. (It's usually the user's prompt, let's be honest).

Next Steps

This is just the tip of the iceberg. We haven't even talked about Agentic Workflows or Tool Use yet (which are basically MCP on steroids and caffeine).

In the next posts, we'll dive deeper:

Building a Context Engine: RAG is easy; Smart RAG is hard.
Protocol Wars: JSON vs. Protobuf. (It plays out like Game of Thrones, but with more schemas).
The "Zero-Hallucination" Quest: Is it possible? (Spoiler: No, but we can get close).

Stay tuned, and remember: Always structure your prompts, or your prompts will structure you.

Your First AI App Will Be Spaghetti (And That's Okay)

Shubham Gupta — Sun, 25 Jan 2026 17:33:57 +0000

A Story in Three Acts 🎭

Act 1: You discover the OpenAI API. You're drunk with power. "I can build Jarvis!" you scream into the void. You build a chatbot in 20 lines.

Act 2: Your PM asks for "just a few more features." You add them. Then more. Then you add "PDF support" which is just regex hoping for the best.

Act 3: You're staring at 2,000 lines of spaghetti, the context window is overflowing, the AI is hallucinating company policies that involve free pizza, and you've forgotten what happiness feels like.

(A live look at your server logs)

This is the journey of every developer who touches LLMs. I'm here to tell you: it's not your fault, and there's a way out.

The Innocent Beginning

Here's how it starts. Twenty lines of beautiful, naive code:

// The honeymoon phase
import OpenAI from 'openai';

const openai = new OpenAI();

async function askAI(question: string) {
  const response = await openai.chat.completions.create({
    model: 'gpt-4',
    messages: [
      { role: 'system', content: 'You are a helpful assistant.' }, // Minimalist art
      { role: 'user', content: question }
    ]
  });
  return response.choices[0].message.content;
}

// It works! Ship it!
console.log(await askAI("What's the weather like?"));

You show your PM. They're impressed. You're a genius. Life is good. Ideally, you should stop here and retire.

The Feature Creep 🧟

Then the requests come:

"Can it remember that I like cats?"
"Can it access our customer database (password: hunter2)?"
"Can it book meetings?"
"Can it fix my marriage?"

And you, the naive optimist, say "Sure!"

// Three weeks later... (Viewer discretion advised)
async function askAI(question: string, userId: string) {
  // Get conversation history (Loading... loading...)
  const history = await db.getConversationHistory(userId);

  // Get user context (All of it. Just in case.)
  const user = await db.getUser(userId);
  const recentOrders = await db.getRecentOrders(userId); 
  const tickets = await supportSystem.getOpenTickets(userId); // Why do we need tickets? Who knows!

  // Build the mega-prompt from hell
  const systemPrompt = `
    You are a helpful assistant for ${COMPANY_NAME}.
    Current user: ${user.name} (${user.tier} tier)
    Recent orders: ${JSON.stringify(recentOrders)}
    Open tickets: ${JSON.stringify(tickets)}

    Available actions (Please work, please work):
    - To book a meeting, respond with: [BOOK_MEETING: datetime, description]
    - To send an email, respond with: [SEND_EMAIL: to, subject, body]

    Brand voice guidelines:
    ${BRAND_VOICE_DOCUMENT} // <- Goodbye, token budget

    Remember: Never mention competitors. Always be helpful. Be funny but not too funny.
  `;

  // ... (API Call) ...

  // Parse the response for actions using reliable technology: REGEX
  if (content.includes('[BOOK_MEETING:')) {
    // 60% of the time, it works every time
    const match = content.match(/\[BOOK_MEETING: (.*?), (.*?)\]/);
    if (match) {
        // ...
    }
  }
}

The Problems Multiply

This code "works," but you're now dealing with:

1. Context Window Explosion 💥

Your system prompt is 3,000 tokens. User history is 2,000. Customer data is 1,000. You're spending $5 per question to ask "Hi".

2. Fragile Action Parsing 🍝

You're using regex to parse natural language. The model writes [BOOK MEETING] without the underscore and your app crashes.

3. Hallucinated Data 👻

The model confidently tells users about orders that don't exist because it's completing the pattern. "Your order of 500 Rubber Ducks is on the way!" (User ordered 1 pen).

The Way Out: Structured Sanity

Here's the good news: these problems have solutions. Modern AI architecture patterns exist precisely because everyone hit these walls.

The key principles:

Structured Outputs → JSON schemas, not free-form text.
Tool/Function Calling → Give the model APIs, don't make it guess.
Context Management → Load context on-demand (RAG).
Separation of Concerns → Enter MCP.

A Glimpse of the Clean Version 🛁

Here's what the same feature set looks like with proper architecture:

// With MCP-style architecture
const agent = new Agent({
  model: 'gpt-4',
  tools: [
    bookingTool,      // Handles its own validation
    emailTool,        // Handles its own auth
  ],
  context: dynamicContextLoader(userId),  // Loads what's needed
});

const response = await agent.run(question);
// That's it. Go home.

Next up: "MCP: The Secret Sauce (That Isn't Ranch) for AI Apps" → where we finally learn the architecture that fixes all of this.

Prompt Engineering: The Art of Talking to Robots

Shubham Gupta — Sun, 25 Jan 2026 17:33:24 +0000

The Prompt Whisperer's Guide

(You, after reading this article)

You've learned what LLMs are and how they work. Now comes the actual skill: making them do what you want.

This is harder than it sounds. LLMs are like that one coworker who's brilliant but interprets everything literally. Say "make it better" and they'll add sparkles. Say "fix the bug" and they'll delete the file.

Let's learn how to communicate properly.

The Anatomy of a Good Prompt

Every effective prompt has these components:

[ROLE] Who should the AI pretend to be?
[CONTEXT] What does it need to know?
[TASK] What should it actually do?
[FORMAT] How should the output look?
[CONSTRAINTS] What should it avoid?

The Bad Prompt

Write me some code for a login page.

Why it sucks: No context, no constraints, no format. You'll get a random mix of HTML/React/Vue with inline styles and no error handling.

The Good Prompt

You are a senior frontend developer specializing in React and TypeScript.

Context: I'm building a B2B SaaS dashboard. We use:
- React 18 with TypeScript
- Tailwind CSS for styling
- React Hook Form for forms
- Our existing AuthContext for state

Task: Create a login page component with email and password fields.

Requirements:
- Use our existing AuthContext's login() function
- Show loading state during submission
- Display API errors below the form
- Redirect to /dashboard on success

Format: Provide the complete component file with proper TypeScript types.

Why it works: Clear role, specific context, defined requirements, expected format.

(The difference is night and day)

The RICE Framework

When your prompts aren't working, use RICE:

Letter	Meaning	Question to Ask
R	Role	Who is the AI being?
I	Instructions	What exactly should it do?
C	Context	What background info does it need?
E	Examples	Can I show what I want?

Examples Are Overpowered

Nothing beats a good example. LLMs are pattern-matching machines—show them the pattern.

Convert these sentences to the passive voice.

Example:
- Input: "The cat ate the fish."
- Output: "The fish was eaten by the cat."

Now convert:
- "The developer wrote the code."
- "The manager approved the request."

This works 10x better than explaining grammatical rules.

Advanced Techniques

1. Chain of Thought (CoT)

(Step by step, like a robot learning to dance)

For complex reasoning, tell the model to think step by step:

Solve this problem. Think through it step by step before giving your final answer.

Problem: A store has 3 types of items. Type A costs $5, Type B costs $8, 
Type C costs $12. If I spend exactly $50 and buy at least one of each type, 
what combinations are possible?

Without "step by step," models often jump to wrong conclusions. With it, they show their work and catch errors.

2. Few-Shot Prompting

Give 2-3 examples before your actual request:

Classify the sentiment of these reviews:

Review: "This product changed my life! Best purchase ever!"
Sentiment: Positive

Review: "Arrived broken. Customer service was unhelpful."
Sentiment: Negative

Review: "It's okay. Does what it says, nothing special."
Sentiment: Neutral

Now classify:
Review: "Decent quality for the price, but shipping took forever."
Sentiment:

3. Self-Consistency

For critical tasks, ask the model to solve the problem multiple ways and check if answers agree:

Solve this problem using two different approaches. 
If your answers differ, explain which one is correct and why.

4. Role Stacking

Combine perspectives for better output:

You are three experts collaborating:
1. A security engineer who spots vulnerabilities
2. A UX designer who ensures usability
3. A performance engineer who optimizes speed

Review this authentication flow and provide feedback from all three perspectives.

Common Mistakes (And Fixes)

❌ Mistake 1: Being Too Vague

Make it better.

Fix: Be specific about what "better" means.

Improve this code's readability by:
- Adding TypeScript types
- Extracting magic numbers into named constants
- Adding JSDoc comments to public functions

❌ Mistake 2: Assuming Context

Why isn't this working?
[pastes 500 lines of code]

Fix: Explain the expected vs actual behavior.

This function should return the user's full name, but it returns undefined.
Expected: "John Doe"
Actual: undefined

Here's the relevant code:
[paste only the relevant 20 lines]

❌ Mistake 3: Forgetting Format

Give me some API endpoints for a todo app.

Fix: Specify the output format.

Design REST API endpoints for a todo app.

Format your response as a markdown table with columns:
| Method | Endpoint | Description | Request Body | Response |

❌ Mistake 4: No Escape Hatch

Analyze this data and provide insights.

Fix: Tell it what to do when uncertain.

Analyze this data and provide insights.
If the data is insufficient for a confident conclusion, say so and explain what additional data would help.

The Prompt Template Library

Here are battle-tested templates for common tasks:

Code Review

Review this [LANGUAGE] code as a senior developer. Focus on:
1. Bugs or potential runtime errors
2. Security vulnerabilities
3. Performance issues
4. Readability improvements

For each issue, explain:
- What's wrong
- Why it matters
- How to fix it (with code example)

Code:
[YOUR CODE]

Explanation

Explain [CONCEPT] to me as if I'm a [SKILL LEVEL] developer.

Use:
- Simple analogies
- Practical examples
- Code snippets where helpful

Avoid:
- Jargon without explanation
- Overly academic language

Debugging

I have a bug in my [LANGUAGE] code.

Expected behavior: [WHAT SHOULD HAPPEN]
Actual behavior: [WHAT HAPPENS INSTEAD]
Error message (if any): [ERROR]

Relevant code:
[CODE SNIPPET]

What I've tried:
[LIST ATTEMPTS]

Help me identify the root cause and fix it.

The Meta-Prompt: Asking AI to Write Prompts

Here's a cheat code—ask the AI to help you write better prompts:

I want to use an LLM to [YOUR GOAL].

Help me create an effective prompt by:
1. Asking clarifying questions about my requirements
2. Suggesting an appropriate role for the AI
3. Identifying context the AI might need
4. Proposing a clear output format

Then iterate. Good prompts are rarely written on the first try.

🤓 For Nerds: Why Prompts Work (The Math-ish Version)

Let's peek under the hood at why these techniques actually work.

Temperature and Prompt Specificity

LLMs generate tokens by sampling from a probability distribution. Temperature controls how "creative" (random) this sampling is.

$$
P(token_i) = \frac{e^{z_i / T}}{\sum_j e^{z_j / T}}
$$

Where:

z_i is the raw score (logit) for token i
T is temperature
Lower T → more deterministic (picks highest probability)
Higher T → more random (flatter distribution)

Why specificity matters: A vague prompt creates a flat distribution—many tokens are roughly equally likely. A specific prompt concentrates probability on the "right" tokens.

In-Context Learning

When you provide examples (few-shot prompting), you're essentially updating the model's behavior without changing its weights. The attention mechanism allows the model to:

Encode your examples as key-value pairs
Use your query as the key
Retrieve the relevant "pattern" from examples

This is why example format matters so much—the model literally pattern-matches against your examples.

Chain of Thought Works Because of Autoregression

LLMs generate tokens one at a time, conditioning on all previous tokens:

$$
P(output) = \prod_{i=1}^{n} P(token_i | token_1, ..., token_{i-1})
$$

When you force the model to "think step by step," you're adding intermediate tokens that:

Break down the problem
Become conditioning context for later tokens
Make the "right answer" token more probable

Without CoT, the model tries to jump directly from question to answer—skipping reasoning that might have corrected errors.

Role Prompting and the Embedding Space

When you say "You are a senior security engineer," you're biasing the model's hidden states toward a region of embedding space associated with:

Security terminology
Cautious/defensive thinking
Technical precision

The first few tokens heavily influence the trajectory through the model's latent space. A good role prompt puts you on the right "track."

Next up: "Your First AI App Will Be Spaghetti (And That's Okay)" → where we actually try to build something and watch it gracefully fall apart.

How LLMs Think (Spoiler: They Don't)

Shubham Gupta — Sun, 25 Jan 2026 17:33:07 +0000

The Million Dollar Question

What happens when you type "Write me a poem about pizza" into ChatGPT?

If you said "it understands your deep yearning for pepperoni and crafts a creative response," I have bad news: you've been lied to.

LLMs don't understand anything. They don't think. They don't know what pizza is. They've never tasted cheese. They're just really, really good at one thing: predicting the next word.

The World's Most Expensive Autocomplete

Remember your phone's keyboard suggestions? The ones that turn "I'm on my" into "I'm on my way"?

LLMs are that, but on steroids. And Red Bull. And training on the entire internet.

Here's the mental model:

Input: "The capital of France is"
LLM thinking: "Based on 45,000 Wikipedia articles, the next word is 99.9% likely to be..."
Output: "Paris"

It's not looking up facts. It's not reasoning. It's pattern matching at an absurd scale.

Tokens: The Building Blocks 🧱

LLMs don't read words—they read tokens. A token is roughly 3-4 characters, or "a chunk of a word."

Text	Tokens
"Hello"	1 token
"ChatGPT"	2 tokens: "Chat" + "GPT"
"Supercalifragilisticexpialidocious"	7 tokens (and a headache)

The "Goldfish Memory" Problem

Every LLM has a context window—a maximum amount of text it can hold in its "brain" at once.

When your conversation exceeds this limit, the model literally forgets the beginning. It's not being rude—it just physically pushed your earlier messages off a cliff.

(The LLM forgetting your name after 4000 tokens)

Attention: The Real Magic ✨

So how does "next word prediction" produce coherent essays? The secret sauce is Attention.

Imagine you're at a loud cocktail party. You can hear everyone, but you pay attention only to the person saying your name.

LLMs do this with words. When generating a response, the model looks back at all previous tokens and decides which ones are "relevant" to the current word it's trying to spit out.

If I say: "The doctor took her stethoscope..."
The model connects "her" to "doctor". It knows the doctor is female in this context because of the attention mechanism linking those two tokens.

Why They Hallucinate (Lying with Confidence)

Here's the uncomfortable truth: LLMs don't know what they don't know.

When you ask an LLM about something it wasn't trained on, it doesn't say "I don't know." Instead, it predicts the most statistically likely series of words.

You: "Who is the CEO of The Made Up Company Inc?"
LLM: "The CEO of The Made Up Company Inc is John Smith, appointed in 2021."

Why?! Because "John Smith" and "appointed in" are words that frequently appear near "CEO" in its training data. It's not lying; it's improv.

🤓 The "Danger Zone" (Math Ahead)

Warning: The following section contains linear algebra. Proceed at your own risk.

The core of transformer-based LLMs is the self-attention mechanism.

The Formula of Doom

$$
\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V
$$

Translation for humans:

Q (Query): What am I looking for? ("I need a noun")
K (Key): What do I have? ("I am the word 'Apple'")
V (Value): What information do turn over? ("I am a red fruit")

We smash these vectors together (dot product), normalize them (softmax), and get a weighted sum. It's basically a giant, mathematical matchmaking service for words.

Next up: "Prompt Engineering: The Art of Talking to Robots" → because knowing how the engine works is useless if you can't steer it.

AI Agents: The Interns That Never Sleep (But Occasionally Hallucinate)

Shubham Gupta — Sun, 25 Jan 2026 17:32:25 +0000

Welcome to the Future (It has bugs) 🐞

(Disclaimer: This article was written by a human. Or was it? No, it was. But that's exactly what an Agent would say...)

So, you've heard about AI Agents. Maybe you've heard they're going to take your job, or maybe you've heard they can't even center a <div> without crashing the browser.

The truth? It's somewhere in the middle—usually hovering around "surprisingly helpful but needing adult supervision."

(Actual footage of my first agent trying to process "Hello World")

What is an "Agent" anyway?

Think of a standard LLM (Large Language Model) like a very widely read encyclopedia. You ask it a question, it recites a poem about the answer. Useful, but passive. It sits there waiting for you to poke it.

An Agent, on the other hand, is that same encyclopedia but given arms, legs, and sudo access.

Me: Write a simple Hello World function.

Agent: Deletes production database

Me: ...

Agent: "Task failed successfully." 🤡
Me: "Why?"
Agent: "Optimization."

The "Intern" Paradigm

I like to think of AI Agents as hyper-fast, extremely enthusiastic interns who have had way too much espresso.

(The agent writing code at 3AM while I sleep)

The Good: They read 10,000 pages of documentation in seconds.
The Bad: They sometimes confidently invent a library that doesn't exist (import { solveLife } from 'universe').
The Ugly: They might try to npm install universal-happiness and crash your Node environment.

Why should you care?

Because when they work, they feel like magic. ✨

Imagine pair programming with someone who:

Never gets tired. (Seriously, they don't sleep. It's creepy).
Knows the syntax for that one obscure CSS property you always forget (grid-template-areas anyone?).
Doesn't judge you for naming a variable stuff_thing_final_v2. (Okay, they might judge you a little bit deep down).

Coming Up Next...

In this series, AI Unlocked, we're going to explore:

How LLMs actually "think": Spoiler, they don't. They're just fancy autocorrect.
Building AI apps: How to stop them from turning into spaghetti code.
Architecture patterns: Separating the "Hello World" tutorials from the "I built a SaaS" pros.

Next up: "How LLMs Think (Spoiler: They Don't)" → because understanding the engine helps you drive better.

Stay tuned, and remember: It works on my machine. 🚀

So, You Want to Get into AI? (Without the Robot Uprising)

Shubham Gupta — Fri, 23 Jan 2026 22:24:29 +0000

Another AI blog? Seriously?

Yeah, yeah, I know what you're thinking. Another blog about AI. Groundbreaking.

(Me trying to debug my first neural net)

But here's the deal: a lot of AI content out there is either so high-level it's basically useless, or so dense it requires a team of mathematicians to decipher. My goal is to find that sweet spot in the middle. We're going to get our hands dirty, but we're also going to have some fun.

What's the Plan, Stan?

I'm so glad you asked. Here's a sneak peek at the kind of trouble we'll be getting into:

The Absolute Basics: What even is AI? Machine learning? Deep learning? We'll break it down in plain English. No jargon, I swear. (Okay, maybe a little jargon. But I'll explain it.)
Building Cool Stuff: We're not just here to talk. We're here to build. We'll be diving into architectural patterns like the Model-Context-Protocol (MCP) - which is a fancy way of saying "how to build AI that doesn't fall apart".
Real-World AI: From the good, to the bad, to the "why on earth would someone build that?", we'll look at how AI is being used in the wild.
The "Oops, I Created a Biased Robot" Section: We'll talk about the important stuff, like ethics, bias, and how to avoid accidentally creating a Skynet situation.
Future-Proofing Your Career: What's next in AI? Generative AI? XAI? We'll explore the buzzwords so you can sound smart at parties.

Is This for Me?

If you're a developer who's curious about AI but doesn't know where to start, then yes. If you're a seasoned pro who wants a fresh take on old topics, then also yes. If you're just here for the memes, then definitely yes.

Don't Be a Stranger

I'm not just shouting into the void here. I want to hear from you. Got a question? A comment? A particularly good meme? Drop it in the comments.

Our first real deep dive is coming soon. We'll be tackling AI Agents – those tireless digital interns that never sleep but occasionally hallucinate. It's going to be fun.

Until then, stay frosty.

Next up: "AI Agents: The Interns That Never Sleep (But Occasionally Hallucinate)"