Forem: Shubham Gupta

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)"