DEV Community: Sanu Ranjan

How ChatGPT Understands Your Questions?

Sanu Ranjan — Wed, 01 Jul 2026 18:28:45 +0000

"My cat cant read this"

Held my laptop up, my cat stared at the screen for two seconds, then walked off like I'd personally offended her. Zero understanding. Fair enough, she's a cat.

But here's the thing that actually gets interesting, I can't fully explain how I read either. I'm doing it right now, obviously, but no neuroscientist on the planet can fully explain how my brain turns these squiggles into "oh, a cat joke." That one's still unsolved.

ChatGPT though, we can actually try to understand, not every step of it start to finish but can have an over all idea, no mystery here. So let's go through it properly, follow one sentence on its entire journey, from raw text to a reply showing up on our screen.

You type this into ChatGPT:

"My cat cant read this"

...and it immediately starts judging you(pun intended)

So how did it know? Let's actually go underneath the chat window, because that's the whole point of this post, not what ChatGPT is, but what it's actually doing to your sentence in the half second before it replies.

Underneath, it's a model doing exactly one job, look at some text, guess what word comes next. That's genuinely it. There's no separate grammar checker bolted on, no dictionary it's flipping through. Catching your missing apostrophe, understanding what you meant, replying like a smug know it all, all of that comes out of "guess the next word," just done at a scale that's hard to picture. Let's watch it happen on your actual sentence.

Step 1: Chopping the sentence up (Tokenization)

Computers can't read English, not even a little. All they work with is numbers. So before anything else happens, your sentence gets cut into small pieces called tokens , and each piece gets a number.

My cat cant read this → [My] [cat] [can] [t] [read] [this]

"cant" gets split weird, into [can] and [t]. That's because "cant" isn't actually a real word, it's missing its apostrophe, so the tokenizer, which only knows the chunks it was trained on(its vocabulary), does its best and breaks it apart. Every token maps to a fixed number, and that mapping doesn't change based on our intended meaning.

Step 2: Vector Embeddings

A number alone tells you nothing. 47 doesn't mean anything about "cat". So each token's number gets swapped for something bigger, a long list of numbers called an embedding , which works like a personality profile for that word. Words with related meaning end up with similar looking profiles. "cat" and "dog" sit close together numerically. "cat" and "computer" don't.

These profiles aren't invented fresh for our sentence. They're premade. Learned once during training, and just sitting there in a giant table afterward we can visualize it as words positioned in 3d space such that the distance between words represent how closely they are related. When our sentence comes in, the model isn't building a personality for "cat" on the spot, it's pulling "cat"'s profile off the shelf, already fully formed from having seen the word a billion times before during training.

Step 3: Remembering the order (Positional Encoding)

Small problem, the next step processes every token at once, together, not one after another. Which is fast, but it also means word order gets lost by default. "My cat cant read this" and "this cant read my cat" would otherwise look the same to it.

So before that step, each token gets a small stamp added to its profile, basically marking "I was word 1," "I was word 3," and so on, so the order survives even though everything's being processed together.

Step 4: Where the actual understanding happens (Self Attention)

Quick reminder before this part, by now every token isn't a word anymore, it's the number profile from Step 2, already stamped with its position from Step 3. That stamp matters here because attention checks every token against every other token all at once, not in order, so without it, the model would have no way to tell "My cat cant read this" apart from "this cant read my cat", same words, same profiles, totally different meaning.

When "cant" "looks at" every other word, it's doing a direct number comparison, checking how closely its numbers align with "cat"'s, "read"'s, and "My"'s. The closer the alignment, the more of that word's numbers get mixed into "cant". These alignments come from patterns the model picked up during training, but here's the honest part, we can't actually read those numbers and say "this is the grammar bit" or "this is the meaning bit." Nobody can point at them and narrate what each one means in plain English. What we can say is what happens mechanically, closely aligned words get blended in heavily, weakly aligned ones barely at all, and this runs for every token at once, all comparing against each other simultaneously. That's also why it doesn't lose track in long sentences, word 2 and word 200 can compare directly in one step, instead of that information passing hand to hand through every word in between.

Step 5: A private pass (Feed Forward Layer)

After the mixing in Step 4, each token's profile is just a blend of other tokens' numbers. This step takes that blend and reworks it through another formula, also learned during training, using only what this one token already has, no borrowing from others this time. As for what this reworking actually captures, same honest answer as before, we can't point at it and say in plain words what it's doing. What we can say is the shape of it, Steps 4 and 5 together repeat many times, stacked on top of each other, and across all those rounds each token's profile gradually shifts from a generic word into a word shaped by this specific sentence. The exact thing each round contributes isn't something anyone can narrate, but the end result is that every token's numbers end up reflecting the whole sentence around it, not just the word on its own.

Step 6: Actually picking a word (Softmax)

After all those rounds of Steps 4 and 5, the model has one final set of numbers for the position where the next word should go. Now it has to turn that into an actual word. It compares those numbers against every word in its vocabulary, tens of thousands of them, and produces a raw score for each one, how well each word fits given everything so far. Those raw scores are messy and hard to work with, some could even be negative, so they get run through softmax, which just squashes them all into clean percentages that add up to 100%. Something like "You" at 38%, "That" at 20%, "Well" at 9%, and so on down the list.

Then it picks a word from that list, usually leaning toward the higher percentages, adds it to the sentence, and runs the entire thing again from the start, tokenizing, embedding, comparing, reworking, all of it, to figure out the next word after that. One word at a time, which is why you watch the reply type itself out instead of appearing all at once. It's not being revealed to you from somewhere, it's being built, live, one word at a time, right in front of you.

Quick recap since this is the part that trips people up, the token list, the embedding profiles, and all the internal formulas are fixed. Learned once during training, frozen after that. None of it changes while you are chatting, no matter what you type. And to answer the obvious question, no, the model isn't learning from your conversation as you go. Your chats may still be collected and used to help train future versions, depending on the service and your settings, but even then that training happens later, offline, not while you type. It does improve over time, but only when the company trains and releases a newer version, and the version you're talking to right now stays exactly the same its whole life until it's swapped for a new one. What's fresh every single time is the computation itself, your specific words getting run through those frozen numbers in a way that's never happened before, because your exact may sentence have never existed before either.

JavaScript Closures: How They Actually Work

Sanu Ranjan — Fri, 26 Jun 2026 21:13:35 +0000

A quick note before we start: this post is for beginners trying to understand how closures actually work. I have done my best as per my limited knowledge to explain what happens under the hood, so if I have gotten anything wrong, please correct me in the comments.

When I was first learning closures, I could recite the definition but still could not explain why they actually work. Information that goes past the definition and into the "why" and "How" is sometimes harder to find than expected. One of my dear friends finally explained it to me in a way that made it click, so I thought I should pass it on for any beginner going through the same thing.

The definition we have probably heard: an inner function remembers variables from its outer function, even after the outer function has finished running. That is correct, but it is only the surface. The real question is, what is so special here? Why does that memory survive at all? The answer lives in how the JavaScript engine handles memory behind the scenes.

Here is the example we will use the whole way through:

function counter(n = 0) {
  var count = n;

  function innerCounter() {
    count++;
    console.log(count);
  }

  return innerCounter;
}

var a = 2;

var myCounter1 = counter();
myCounter1(); // 1
myCounter1(); // 2

var myCounter2 = counter(a);
myCounter2(); // 3
myCounter1(); // 3

I'm using var here just to make the breakdown easier to visualize.

How the Engine Runs the Code

Contrary to the popular belief that JavaScript is just a simple, line-by-line interpreted language, the engine handles the code in distinct steps. There are two phases:

The Compilation Phase: the engine scans the code and registers all variable declarations and function definitions before anything runs. For each function, it creates a function object in memory, and the function's name points to that object.

The Execution Phase: the code finally runs, line by line.

Separately from these, there's garbage collection: the cleanup process that runs in the background. Normally, once a function finishes executing, its local execution scope is freed from memory so it doesn't waste space. With a closure, that cleanup gets blocked. The executed function's local execution scope persists, letting the inner function reach back up the scope chain and grab what it needs.

Quick recap of the example above: counter takes a parameter n (default 0), stores it in count, and returns an inner function innerCounter that increments and logs count. We create myCounter1 from counter() and myCounter2 from counter(a), and the outputs come out as 1, 2, 3, 3. Now let's see how.

Step 1: Mapping the Global Scope

Before a single line runs, JavaScript sets up the global scope in memory during compilation, registering the names a, myCounter1, and myCounter2.

When it hits the counter definition, it creates a function object for it in memory, and the name counter points to that object. Here's the secret sauce: every function gets a hidden internal property (often written [[Scope]]) that points back to the environment where it was born. For counter, that points to the global scope.

Step 2: Creating myCounter1

Now execution starts. It sets a = 2, then calls counter() with no argument.

Invoking the function spins up a brand new local execution context, which points back to wherever its function definition's [[Scope]] is pointing to. Inside this temporary space, a mini-compilation happens:

n defaults to 0.
count is registered and initialized to 0.
innerCounter function is defined and stored and innerCounter holds reference to its function definition, and its hidden [[Scope]] points right back to this local scope.

Finally, counter() returns innerCounter, which returns the reference of its function definition and we store it in myCounter1.

Normally the local execution scope of counter() would now be wiped by the garbage collector. But JavaScript has a golden rule: if an environment can still be reached from the global scope, it can't be garbage collected. Since myCounter1 points to the inner function's definition, and the inner function points back to this local scope counter(), a bridge remains. The memory survives.

Climbing the Scope Chain

Now we call myCounter1(). A fresh local execution scope is created for the function execution which points back to wherever its [[Scope]] is pointing to, here it points to counter()'s local execution scope which is still in memory.

Then in execution phase for this function it encounters count++.

First it checks its own local context for count. Nothing there. So it follows up its scope chain into the preserved parent memory the counter() execution context, finds count at 0, increments it to 1 in that parent scope, and logs 1, and then myCounter1() local execution context is garbage collected.

The second call myCounter1() repeats exactly: it looks locally, finds nothing, climbs the chain, finds count now at 1, increments it to 2, and logs 2.

We get updated value here all because counter()'s local execution scope is still not garbage collected.

Step 3: Total Isolation with myCounter2

What happens when we create myCounter2?

Because we invoke counter fresh, JavaScript generates a completely separate, second local execution context. Here n receives the value of a (which is 2), so count starts at 2.

Calling myCounter2() climbs its own scope chain, finds its own count at 2, increments it, and outputs 3.

To prove the two environments share nothing, look at the final myCounter1(). It ignores whatever myCounter2 did, goes right back to its original environment, finds its old value of 2, increments it to 3, and logs 3.

Final Thoughts

At the end of the day, that's all a closure is. The outer function's local execution scope escapes garbage collection because the inner function's definition, whose reference is present in the global scope, keeps a live, reachable path back to the outer function's local execution scope via [[Scope]]. That persistent connection is what keeps the data alive across separate instances.