DEV Community: Sohaib Hassan

Every AI Answer Is a Bet: What I Learned Teaching Stanford's Probability for AI

Sohaib Hassan — Sat, 24 Oct 2026 15:38:15 +0000

Ask an AI a question and watch the words arrive, one after another. It feels like the machine is looking something up. It is not. At every step, the model is placing a bet. Given everything written so far, it assigns a probability to each possible next token, picks one, and moves on. The paragraph you finally read is a chain of weighted guesses, and the quality of the whole answer depends on how well those guesses were calibrated. It is also why asking the same question twice can give you two different answers.

We are used to computers being certain. A calculator never hesitates over 7 times 8. But the systems now writing our emails, reading our medical scans and ranking our search results live inside uncertainty, and the mathematics of living inside uncertainty is probability.

That is why a Stanford course called Probability for AI exists, and why I am proud to be a small part of it. I am a section leader in the course, and this post is what I have learned so far.

The Course in One Paragraph

Probability for AI is a free online course created by Chris Piech, an Assistant Professor (Teaching) of Computer Science at Stanford and a Faculty Affiliate of Stanford HAI, the university's institute for human-centered AI (his Stanford profile). Piech describes it as a course that teaches you "the math language that AI speaks." Stanford HAI describes it as a six-week program for anyone who wants to understand how AI works, not just how to use it, with no prerequisites and no experience needed.

"Not just how to use it" is the whole point. Anyone can call an API. Understanding why an answer came out the way it did, why it is sometimes confidently wrong, and how much to trust it, requires the language of probability. And although the course welcomes beginners, it does not stay shallow. In my section, we go deep into how probability actually does its work inside AI.

How I Ended Up in the Room

I was selected as a section leader out of more than 2,700 participants from over 70 countries. A section is a small group where students work through the week's ideas together and get to ask questions. Mine is made up of working professionals and technologists from around the world.

I do it alongside a full-time job and all the usual weight of daily responsibilities, and it asks for real effort every single week. But I am enjoying this journey seriously, and being trusted to teach in a Stanford course is an honor I do not take lightly.

One Question That Shows Why Probability Matters

Try this one. It is the kind of question the course trains you to answer correctly.

A medical screening test catches 95 percent of people who have a certain condition. It also gives a false alarm for 5 percent of healthy people. The condition affects 1 percent of the population. You take the test and it comes back positive. What is the chance you actually have the condition?

Most people say about 95 percent. The real answer is about 16 percent.

Imagine 10,000 people. Of them, 100 have the condition and 95 of those test positive. Of the 9,900 healthy people, 5 percent, which is 495, also test positive. So among the 590 people with a positive result, only 95 are truly sick. That is roughly one in six.

Nothing in that calculation is advanced. Yet our intuition gets it badly wrong, and the same mistake hides inside AI systems that flag fraud, detect disease or screen applicants. If you build or use such systems, this is basic literacy, not a luxury.

Week 1: Same Prompt, Twice

Week 1 opened with something every AI user has quietly noticed: ask the same question twice and you may get two different answers. Why?

In our section, we explored it with a toy language model small enough to hold in your head. Give it the prompt "A sleepy robot dreams about" and it has exactly five possible outputs: electric sheep (44 percent), counting stars (20), sample spaces (14), counting outcomes (13) and robot puppies (9). Each call picks one at random, independently of the last.

So what is the chance that two calls give two different outputs? Three simple rules are enough: NOT, OR and AND. The chance that both calls give the same output is the sum of each output's probability squared, which comes to 0.2782. The chance of two different outputs is 1 minus that, about 72 percent. Even a model with a clear favorite disagrees with itself most of the time.

Then came a question that catches almost everyone. "Robot puppies" appears with a 9 percent chance on each call. How many calls until you are more likely than not to see it at least once? The tempting answer adds the chances: six calls, 6 times 9 percent, is 54 percent. But those chances overlap, so adding them overcounts. The right way is to ask for the chance of never seeing it. That is 0.91 on each call, so 0.91 multiplied by itself n times. After six calls the real chance is only 43 percent. It takes eight calls to pass 50 percent.

Finally, we met the dial that every AI tool hides behind a slider: temperature. It raises each probability to the power 1/T and rescales them so they add up to 1. Here it is in a few lines of Python, applied to the first-word chances of our toy model:

import numpy as np

p = np.array([0.44, 0.33, 0.14, 0.09])  # first word: electric, counting, sample, robot

def with_temperature(p, T):
    q = p ** (1 / T)       # raise each chance to the power 1/T
    return q / q.sum()     # rescale so they add up to 1

for T in (0.5, 1, 2):
    q = with_temperature(p, T)
    print(T, q.round(4), round((q ** 2).sum(), 4))

# 0.5 [0.5863 0.3298 0.0594 0.0245] 0.4567
# 1   [0.44   0.33   0.14   0.09  ] 0.3302
# 2   [0.3469 0.3005 0.1957 0.1569] 0.2736

The last number on each line is the chance that two calls start with the same word. At T = 0.5, "electric" climbs from 44 to about 59 percent, "robot" shrinks from 9 to about 2.5 percent, and two calls match about 46 percent of the time. At T = 2, the chances even out and two calls match only about 27 percent of the time. In real models, the same thing is done by dividing the logits by T before the softmax, which is mathematically the same operation.

The randomness setting in an AI tool is not magic. It is probability, rescaled.

I turned this section into a detailed solutions PDF with every step worked out, and a Manim animation so that students could revisit the ideas at their own pace, long after the live session ended.

Week 2: The Palpatine Poll

In Week 2, our section centered on a problem called the Palpatine Poll, and it was my favorite kind of problem: simple mathematics wrapped around a clever idea.

The question is how you measure something people will not say out loud. If you ask directly, many will hide the truth. The trick is called a list experiment. Split people into two groups. Show the first group a list of a few harmless statements and ask only how many they agree with, never which ones. Show the second group the same list with one sensitive statement added, and ask the same question. Nobody reveals a single individual answer, yet the second group's average count comes out higher, and that gap estimates how many people agree with the sensitive statement.

Underneath this trick sit two of the most useful ideas in probability. A single yes or no answer is a Bernoulli random variable, the simplest random event there is. Add up many of them and you get a binomial distribution, which tells you not only the expected count but also how much it is likely to wobble from one group of people to the next. That wobble is what separates a trustworthy estimate from a lucky one.

Where This Shows Up in Your ML Work

Every time a team reports that a model is "90 percent accurate," they are reporting a binomial experiment: run the model on n test examples and count how many it gets right. Treat each test example as an independent trial with a 90 percent chance of success, and you can compute exactly how much the reported number will wobble:

from scipy.stats import binom

p = 0.9  # the model's true accuracy

# Chance the observed accuracy lands between 84% and 96% on 100 test examples
print(binom.cdf(96, 100, p) - binom.cdf(83, 100, p))            # about 0.97

# Chance it lands within 0.6 points of 90% on 10,000 test examples
print(binom.cdf(9060, 10_000, p) - binom.cdf(8939, 10_000, p))  # about 0.96

On 100 examples, the number correct will land anywhere from about 84 to 96 in roughly 97 out of 100 runs. On 10,000 examples, the same model lands within about 0.6 of a percentage point of 90 percent, about 95 percent of the time.

Same model, same skill, wildly different certainty. Whether a headline number deserves your trust depends on a calculation most people never see.

Making the Hard Parts Visible

After each week, I do something extra. I write a detailed solutions PDF, and I build a Manim animation that shows the idea moving, not just written down. After Weeks 1 and 2, I shared both with my students and posted them on the section leaders' forum so that every section leader could use them too.

The reaction was the best surprise of the whole experience. Prof. Chris Piech replied to my post, calling a Manim video for Week 2 a real gift to students and to every section leader in the course, and a fellow section leader added kind words as well.

A formula on a slide asks you to trust it. An animation lets you watch the reason. When a binomial distribution widens and narrows as you change the number of trials, it stops being a symbol and becomes something you have seen. That has been true in my own classroom as well, and it is why I animate everything I can.

If you want to explore the material yourself:

Detailed PDFs for Week 1 and Week 2: open the folder
The animation playlist: Stanford Probability for AI on YouTube

What I Am Taking Away

Teaching this course has changed how I read AI headlines. When I see that a model is "accurate," I ask how many examples it was tested on. When a system is described as "confident," I ask whether that confidence is calibrated. When someone says an AI "knows" something, I remember that it placed a bet.

That habit of asking is worth more than any single formula, and you do not need to be a mathematician to build it. You need a good teacher, a few well chosen examples, and the patience to look at an idea until it moves. If you want to see where this course lives, it is at pai.stanford.edu.

About the author

I'm Sohaib Hasan. I have 9+ years of teaching experience in advanced mathematics and statistics, and I turn the ideas I teach into Manim animations, the kind that Prof. Chris Piech and fellow section leaders of Stanford's Probability for AI have appreciated.

I share these animations on my YouTube channel, PlotLab Algorithms, where I teach data science, machine learning, cryptography, math, DSA and statistics visually, in the style made popular by 3Blue1Brown. Shorter clips live on Facebook (80K+ followers) and Instagram (15K+ followers).

Want an animation like this for your own work? If you have a project, a research article, a thesis defense, a YouTube video, or any idea that is hard to explain with slides alone, I can turn it into a clear, professional animation. Reach out through my Work With Me page and tell me what you are working on. If you would rather learn to build animations yourself, start with my Manim CE Beginner's Handbook. And I'd like to hear what you think of this post, drop a comment.

The One Idea Quietly Running Every Prediction App on Your Phone

Sohaib Hassan — Thu, 22 Oct 2026 06:27:12 +0000

Open your phone and look at three numbers. A weather app saying tomorrow will be 34 degrees. A property site showing what a house in your area is roughly worth. A ride app quoting your fare before the driver has even arrived.

Every number like that comes from a model that learned from past data. Real products use far more sophisticated models than what I am about to show you. But the simplest, oldest member of that family is called linear regression, and almost everything fancier is built on the same core move. Understand that move once, in plain words, and you will start noticing it behind every prediction you see.

I teach undergraduate mathematics, and I wrote this the way I would explain it to a friend who has never opened a statistics book. If you already write code, stay for the last third, there is a short Python section for you.

You Already Do This, You Just Never Named It

Think about the last time you sold an old phone on OLX or eBay. You did not open a calculator. You looked at what three or four similar phones sold for, same model, similar condition, and landed on a number somewhere in between. You did the same thing if you ever guessed what a plot of land was worth from the sales next door, or guessed how a student would do in a final exam after seeing the first two tests.

Each time, your brain did one specific thing. It looked at a handful of known examples, noticed the pattern connecting them, and stretched that pattern forward to guess something it had never seen. Draw a line through what you know, then use it to predict what you do not. That is linear regression. You already had the instinct. A computer simply does it with numbers instead of a gut feeling.

Where This Family of Ideas Shows Up

Once you know what to look for, it appears anywhere someone needs to predict a number from past data.

A property site can estimate a home's price by learning how size, location and age related to price in thousands of past sales. A retailer can plan stock for Eid or Black Friday by learning how sales behaved in the weeks before it in past years. A bank scoring a loan applicant uses a close cousin of the same idea, usually logistic regression, which predicts a probability instead of a number. In my own classroom, I notice how revision hours relate to test scores, and I use that pattern to tell a new student roughly what to expect.

The real systems behind big apps combine many more inputs and use more elaborate models than a single straight line. That is exactly the point: a straight line is the simplest version, and the elaborate versions are built on the same foundation.

Why a Gut Feeling Needed Math

If people have guessed this way for centuries, why did it become a formal piece of mathematics?

Because instinct breaks when the problem gets big or the stakes get real. Ask ten people to price a plot from the same five examples and you will get ten different answers, because everyone draws the pattern a little differently in their head. That is fine for a phone resale. It is not fine when a system makes a million decisions a day.

Math replaces "roughly in between" with one exact rule for finding the single best line through any data: the line that keeps the total mistake, across every example, as small as it can be. The method behind it, least squares, was first published by Legendre in 1805. It does not change with who runs it, does not get tired, and does not care whether there are five data points or five million. That is the real power math adds. Not a smarter guess, but a guess that can be trusted, repeated, and scaled.

For Developers: The Whole Thing in Five Lines

Here is a tiny version with four students: hours studied against marks scored.

import numpy as np

hours = np.array([1, 2, 3, 4])
marks = np.array([1, 3, 2, 4])

m, b = np.polyfit(hours, marks, 1)
print(round(m, 2), round(b, 2))   # 0.8 0.5
print(round(m * 5 + b, 2))        # 4.5, the predicted marks for 5 hours

The best line is marks = 0.8 * hours + 0.5. Every extra hour of study is associated with 0.8 extra marks in this toy data, and a student who studied 5 hours is predicted to score 4.5. Those two numbers, the slope and the intercept, are the entire trained model.

Two things are worth knowing as a developer:

There are two ways to find those numbers. For a straight line there is a closed-form answer, which is what polyfit uses. You can also start with a random line and nudge it downhill on the error, step by step, which is gradient descent.
That second way is how neural networks learn. A single neuron with no activation function, trained to minimize squared error, is exactly this model. Stack many of them with nonlinear bends in between and you get the networks behind modern AI. The training loop looks conceptually the same: measure the error, nudge the parameters so the error shrinks, repeat.

So when people say linear regression is the grandparent of machine learning, it is not just a nice phrase. It is the smallest working example of how learning from data actually works.

Want to See the Math by Hand?

Most readers do not need to see a formula to use what they just learned. But if you are a student, or you simply want to watch the best line get calculated step by step with real numbers, I built a complete animated walkthrough using the same four point example:

It covers why the mistakes are measured the way they are, what the error looks like when you plot it, and how the two numbers above, 0.8 and 0.5, are worked out from scratch.

The Next Time You See a Prediction

When an app gives you a price, a fare or an estimate before you have told it much, you now know the shape of what is behind it: look at what happened before, find the pattern, and stretch it forward. The models get bigger and the code gets cleverer, but that core idea has barely changed in over two hundred years.

About the author

I'm Sohaib Hasan. I have 9+ years of teaching experience in advanced mathematics and statistics, and I'm currently a section leader for Stanford's Probability for AI course, selected out of 2,700 participants from 70 countries to teach students from around the world. After each class, I explain the same ideas again through Manim animations, and I'm glad that Stanford professors and fellow section leaders have appreciated them.

On my YouTube channel, PlotLab Algorithms, I teach data science, machine learning, cryptography, math, DSA, and statistics visually, in the style made popular by 3Blue1Brown. Shorter clips live on Facebook (80K+ followers) and Instagram (15K+ followers).

How I Got 40,000 Facebook Followers in Just Two Months

Sohaib Hassan — Wed, 02 Sep 2026 07:01:08 +0000

Two months ago, my Facebook page had a small, quiet following. Today, more than 40,000 people follow it. I did not expect this to happen so fast, and I do not believe there is a secret trick behind it. But I do understand why it happened, and I want to explain it honestly, because the reason is actually more useful than a trick would be.

What I Actually Post

My page is called PlotLab. I use it to turn mathematics into animation, using a Python library called Manim, the same one that powers the diagrams in my other posts here. A definition that feels dry on a whiteboard becomes something a student can actually watch happen. A limit is not just a symbol anymore. You see a point moving closer and closer, step by step, until the idea makes sense on its own.

This is not a new idea. Channels like 3Blue1Brown made this style popular for a general audience. What I do is narrower and, I think, more practical: I build these animations for the exact topics that undergraduate and school-level students struggle with the most, the ones I see them struggle with in my own classroom, every single semester.

Why It Actually Worked

Here is the part I think matters most. I do not build an animation and then hope it is useful. I teach first, in a real classroom, with real students in front of me. When I notice the same confusion coming up again and again, on the same topic, I build the animation for that exact topic. Only after that does it go on Facebook or Instagram.

So the content was never designed for social media first. It was designed for my own students first, and social media is simply where it happens to travel well too. I believe this order matters. It means every animation already solved a real confusion for a real student before a single stranger on the internet ever saw it.

What People Actually Tell Me

The most encouraging part of the last two months has not been the follower count. It has been the messages. Almost every day, someone writes to me in the comments or in my inbox to say that a concept they had struggled with for a long time finally made sense after watching one of these animations. Some are students preparing for exams. Some are people revisiting mathematics years after leaving school, just out of curiosity. The message is almost always some version of the same thing: this is the first time this idea actually made sense.

That kind of feedback is why I keep making these, far more than the follower count itself.

Where to Find These Animations

The main page is on Facebook, where the 40,000+ follower community lives. The same animations are also on Instagram, which has grown to 15,000+ followers of its own.

Two Things I Built Because of This

Once people started asking for more than just short videos, I built two things to answer that.

The first is for people who want to learn to build animations like these themselves. I wrote everything I know about getting started with Manim into a single guide, from installing it correctly to the mistakes that waste the most time when you're new to it. It's called the Manim CE Beginner's Handbook, and it's written the same way I'd explain it to a student sitting next to me, not the way the official documentation explains it.

The second is for students specifically preparing for IGCSE, O-Level, and GCSE exams. I built a complete set of notes covering the full syllabus, where every topic that's genuinely hard to picture from text alone is paired with a scannable code linking straight to the matching Manim animation. Alongside the theory, each topic includes worked examples, exam tips, the mistakes students make most often, and practice problems with a formula sheet for quick revision before an exam. You can find the full set on my Gumroad page.

The Result I Did Not Expect

The most useful outcome of the last two months was not on Facebook at all. Researchers preparing for conference presentations started reaching out, asking if I could build an animation to explain a concept from their own research, the kind of concept that is genuinely hard to present clearly in a short talk using only slides and text. I said yes, and it turned into something I now offer properly: custom Manim-built explainers for research talks, thesis defenses, conference presentations, or coursework, built in the same style as PlotLab, with a fast turnaround.

If that sounds like something you need, whether it's a concept from your own research, a topic for your students, or anything else where an idea needs to be seen and not just read, you can see how this works and reach out on my Work With Me page.

What I Take From This

I did not grow this page by studying growth tactics. I grew it by solving a real problem for real students first, and only sharing the result afterward. If there is a lesson in that for anyone building an audience around their own work, I think it's this one: build for the person in front of you first. The audience online tends to follow, not the other way around.

I lead the Mathematics Department at my college, and PlotLab is where I turn what I teach into animation. If you'd like to see more of the work, follow along on Facebook (40,000+ followers) or Instagram (15,000+ followers). If you're a researcher, teacher, or student who needs something explained visually, reach out through my Work With Me page. I'd like to hear from you, drop a comment.

I Built My Students an AI Assistant That's Not Allowed to Make Things Up

Sohaib Hassan — Wed, 19 Aug 2026 18:40:41 +0000

How I built Classroom AI System, a free, RAG-grounded teaching assistant that only answers from my own course notes, plus the teacher dashboard it feeds, on a budget of exactly $0.

Ask a generic AI chatbot a question about your course, and it will answer confidently, using its own notation, its own conventions, and occasionally its own facts. It doesn't know that you define a term slightly differently than the textbook does, or that a particular proof technique hasn't been covered yet, or that the "obvious" shortcut it just suggested isn't one your students are allowed to use on the exam. It will still answer. That's the problem.

I teach undergraduate mathematics, and every semester the same pattern repeats: a handful of students ask sharp, specific questions in office hours, while dozens more ask ChatGPT the same questions late at night, when I'm not there to catch the moment an AI politely gets something wrong. So I built something that only answers from my own course notes, refuses to guess when it doesn't know, and, as a side effect, shows me exactly where an entire class is actually getting stuck. It's called Classroom AI System, and the code is public: github.com/Sohaib-Hasan/classroom_ai_system.

Grounded, Not Generic

The technical name for what makes this different is retrieval-augmented generation, RAG for short. Instead of asking a language model to answer from everything it was trained on, the system first retrieves the exact passage from my own LaTeX course notes most relevant to a student's question, then instructs the model to answer strictly from that passage and nothing else. Right now the knowledge base covers Calculus, Discrete Mathematics, and Number Theory, chunked chapter by chapter from the same notes I hand out in class.

The system is two separate apps sharing one brain:

A student assistant, PIN-gated, where students type a question and get an answer grounded in the actual notes.
A teacher dashboard, password-gated, where I see what's being asked across the whole class: which topics come up again and again, which questions the cache is already handling, and where the same confusion is repeating across different students.

How a Question Actually Gets Answered

Getting from ".tex notes" to "trustworthy answer" happens in two stages. The first, indexing, happens once, offline, whenever my notes change:

python3 chunk_notes.py      # .tex notes  ->  raw chunks (one per definition/example/theorem/proof)
python3 clean_chunks.py     # strips decorative LaTeX, keeps the real math
python3 embed_chunks.py     # embeds every cleaned chunk into knowledge_base.json

The second stage happens live, every time a student asks something: the question gets embedded and compared against the knowledge base by cosine similarity, the closest matching chunks get pulled out, and only those chunks, together with the question, get sent to Gemini for an answer.

The Step That Almost Broke Everything

The middle step, clean_chunks.py, sounds like the least interesting part of the pipeline. It's the one that mattered most.

chunk_notes.py extracts each definition, example, or theorem box straight out of the raw .tex source, decorative markup and all: color commands, tables, diagram code, spacing macros. That raw text becomes part of the prompt the model sees for every question. Skip the cleaning step, and the model will occasionally echo a fragment of that raw markup straight back to a student, so instead of a clean explanation they see broken LaTeX code on their screen. clean_chunks.py strips all of that decoration out while leaving the real $...$ math completely untouched, so the model only ever sees the content, never the formatting noise around it. It's a small, unglamorous script, and the whole system's credibility depends on it running before every embedding pass.

Making It Work on a Budget of Exactly $0

This runs entirely on Gemini's free tier, which means every question costs quota, and quota is the actual scaling limit. A few decisions keep that from becoming a wall:

Multi-key rotation. Gemini's rate limits apply per Google Cloud project, not per key, so keys from separate accounts draw from independent quota pools. The system supports up to three keys and falls through to the next one only if a call fails, invisibly to the student asking the question.
Caching. A SQLite-backed cache means a rephrased version of a question someone already asked skips the generation call entirely, which matters a lot in a class where dozens of students hit the same handful of confusing topics.
Local embeddings. Every question needs an embedding call, even on a cache hit, which makes it the single biggest quota consumer in the whole system. Swapping the embedding provider to a free local model removes that cost entirely, at the price of having to rebuild the knowledge base once, since Gemini and local embeddings aren't compatible with each other.
A per-session rate limit. Eight questions per rolling 60 seconds per browser session, mostly as a safety net against an accidental double-submit rather than a real constraint on normal use.

Two Apps, One Shared Brain

The student assistant and the teacher dashboard are deployed as two separate Streamlit Cloud apps, on two different URLs, each running in its own isolated container. That last part turned into the trickiest infrastructure problem in the whole project: a local SQLite file that one container writes to simply doesn't exist for the other one.

The fix is Turso, a free, hosted, SQLite-compatible database that both apps point to instead of their own local files. Two details in that setup cost real debugging time and are worth writing down: the connection string has to use https://, not libsql://, because the WebSocket handshake libsql:// relies on can fail inside Streamlit Cloud's sandboxed environment, and the secret key has to be named exactly TURSO_AUTH_TOKEN. Get either of those wrong and there's no crash, no error message, just a dashboard that stays quietly empty with nothing to explain why.

What the Teacher Actually Sees

This is the part that matters most to me as a teacher, and it's the part a generic AI chatbot can never give you. Office hours show me the questions the handful of students who show up are willing to ask out loud. The dashboard shows me every question the whole class actually had: which topic keeps coming back, which confusion is repeating across students who've never spoken to each other, what the cache is already absorbing versus what's genuinely new. It's the difference between a handful of anecdotes and an actual signal.

Built to Not Break Quietly

The business logic lives in core.py, which deliberately has no dependency on Streamlit at all, so it can be tested completely independently of the app itself. Right now it's backed by 91 automated tests, and every one of them exists because a specific bug was found and fixed, not because of abstract coverage targets. One example I'm particularly fond of: the system's verify_computation() check samples the negative, positive, and near-zero domains of a function, not just the positive ones, specifically because a positive-only check would miss domain-sensitive errors like treating sqrt(x**2) as equal to x, which only holds when x is non-negative. That's the kind of bug that looks fine in a quick demo and quietly produces wrong math for a student six weeks later.

Where It's Still Rough

A few honest limitations, because a system that grades student proofs owes its builder the same standard: nested LaTeX boxes of the same type (a definition box inside another definition box) aren't parsed cleanly yet, though a safety check flags this loudly the moment it happens rather than letting it reach a student silently. The automated cleaning handles the large majority of decorative LaTeX but not all of it: roughly 3% of chunks, mostly color commands sitting inside real math, still need a manual look. And there's an optional third-party fallback provider for when every Gemini key is exhausted that I've built but haven't yet stress-tested in production, so for now it's a safety net I wouldn't lean on.

What's Next

The next thing I'm building on top of this is a guided answering mode: instead of jumping straight to a full solution, the system will offer a hint first, then a guiding question, and only give the complete answer if the student actually wants it. The goal was never to hand out finished proofs faster. It's to get a student unstuck without doing their thinking for them.

That's really the whole premise behind this project, and behind the broader direction I want to take my teaching: AI that's useful specifically because it's constrained, not despite it.

I lead the Mathematics Department at my college and build tools like this one alongside my Manim animation work as PlotLab. If you teach and are curious whether something like this could work for your own courses, or if you'd like help building it, reach out. I write more like this at sohaib-hasan.github.io, and if you want to see the kind of animated explanations I build separately from this project, they're on Facebook (35K+ followers) and Instagram (15K+ followers). I'd like to hear what you think, drop a comment.`

AI Just Posted a Perfect Score at the Real Math Olympiad. I Spent Months Building One of These Systems. Here's What It Actually Takes

Sohaib Hassan — Sat, 08 Aug 2026 08:55:32 +0000

In July 2026, in Shanghai, something happened that mathematicians had been debating for two years: AI systems from Huawei and Xiaohongshu were each reported to have solved all six problems of the International Mathematical Olympiad, a perfect 42 out of 42. Several other labs reported matching results on their own. It followed a 2025 breakthrough where Google DeepMind's Gemini Deep Think, officially graded by IMO coordinators, and an OpenAI experimental model both reached the gold-medal threshold of 35/42.

Headlines called it AI "beating" the world's best teenage mathematicians. I want to tell you what's actually behind a headline like that, not as a journalist, but as someone who spent the past several months building a much smaller, much less glamorous version of exactly this kind of system.

My teammate Samuel Koh and I entered AIMO3, the third AI Mathematical Olympiad Progress Prize, hosted on Kaggle. We scored 42 out of 50, placing 495th out of 4,138 teams, the top 12% globally. Here's the honest, unglamorous story of how we got there, what we tried that failed, and what the finished system actually looks like under the hood.

What AIMO Actually Is (And Why It's Not the IMO)

First, an important distinction, because the acronyms get confusing fast: AIMO is not the IMO.

The AI Mathematical Olympiad is a $10 million prize fund, created in 2023, that exists specifically to close the gap between what the closed, proprietary models at OpenAI and Google can do and what the open community can build. Its grand prize, $5 million, goes to the first team that publicly shares a model capable of gold-medal-equivalent performance at the actual IMO. Along the way, Kaggle hosts periodic "Progress Prize" competitions to measure how far the open field has come.

AIMO1 was won by Project Numina in 2024. AIMO2 was won by NVIDIA's team, NemoSkills, who solved 34 of 50 problems. AIMO3, the one we entered, raised the difficulty again: 110 entirely original problems, ranging from national-olympiad level up to full IMO standard, spanning algebra, combinatorics, geometry, and number theory. "Entirely original" matters enormously here: it means no amount of memorization from training data helps you. Every problem has to be reasoned through, not recalled.

Competitors were also given access to H100 GPUs, roughly double the compute of AIMO2, which meant we could run larger open-weight models than previous years: models like GPT-OSS-120B and Qwen3-Next became viable for the first time.

So when you read that an AI "scored a perfect IMO," understand what's actually being claimed. In 2026, most of those results, including the ones from Huawei and Xiaohongshu, were the companies' own self-reported submissions, run after the human competition window closed, evaluated against the same problems and time limit but not scored live by IMO coordinators. Only a small number of 2025 and 2026 results have been independently, officially graded. That's not a reason to dismiss the progress. It's real, and it's fast. But it's worth knowing the difference between "officially certified" and "self-administered" when you see the next big claim.

Two Rules That Shaped Every Decision We Made

Before I describe what we built, you need to understand the two constraints that made this hard, because they killed almost every "obvious" idea we had.

Rule one: five hours of GPU compute, total, per problem set. Not per problem. Per set. That immediately rules out anything computationally greedy.

Rule two: binary scoring, no partial credit. A problem is either fully correct or fully wrong. This sounds simple, but it has a brutal implication: a system that produces a plausible, confident-sounding, but wrong answer is worse than a "generic" wrong answer, because it's confidently wrong. Under this rule, knowing when your system is unsure is almost as valuable as getting the right answer.

I handled the mathematical side: interpreting problems, checking whether a given line of reasoning was actually valid, and sourcing harder test cases beyond the standard dataset to stress-test our system. Samuel handled the engineering: building and running the inference pipeline under that fixed compute budget. Neither role alone was enough. The problems weren't purely mathematical, and they weren't purely a systems problem either.

Four Ideas We Killed Before Writing a Line of the Final System

Here's what we considered and rejected, and why each one matters as a lesson, not just a footnote:

Supervised fine-tuning. The obvious first instinct. Rejected immediately: it needs massive GPU clusters and months of runway, not a fixed five-hour, competition-scale budget.
Fully agentic search, a system that breaks a problem into steps, calls tools, verifies intermediate results, and loops back on itself. Conceptually, this is the closest thing to how a human mathematician actually thinks. We rejected it anyway, because Kaggle's environment has no outbound internet access, and an open-ended agentic loop risked silently burning our entire compute budget before ever producing a final answer.
Monte Carlo Tree Search. Not used.
Long, verbose chain-of-thought prompting. We tested it. Concise prompting consistently outperformed it.

The pattern across all four rejections is the same one that ended up defining our whole approach: under a fixed, non-negotiable compute budget, a simpler system you can actually trust beats a theoretically more powerful one you can't fully control.

The Architecture: A Parallel Self-Consistency Pipeline

What we actually built and submitted, we called a Parallel Self-Consistency Pipeline. Here's how a single problem moves through it, end to end:

The problem is written in LaTeX and gets converted into a structured prompt.
The base model, GPT-OSS-120B (OpenAI's open-weight mixture-of-experts model, around 120 billion total parameters but only about 5 billion active per token, which is exactly why it fits on a single H100 despite its size), generates a reasoning attempt at temperature 0.8.
The Parallel Sampler does this eight times, independently, all at once. This is the "self-consistency" idea, and it's built on a real insight from a 2022 paper by Wang et al.: a single reasoning chain can silently go wrong at any step with no way to catch it, but across eight independent attempts, correct reasoning tends to converge on the same answer while failure modes tend to scatter in different directions.
Tool-Integrated Reasoning. Each of those eight attempts is paired with a live Python interpreter. The moment a reasoning chain hits a calculation it can't reliably do purely in text, it hands that calculation off to Python instead of guessing, a small design choice that removes an entire category of careless arithmetic errors.
The Entropy-Weighted Aggregator. This is the part I'm proudest of. Instead of a simple majority vote across the eight candidate answers, each one is scored by:

score = \frac{1}{H} + 8.0 \cdot V

Here, H is the mean generation entropy of that attempt (how "confident" the model was, token by token, while producing it) and V is a verifier score. Because the formula uses 1/H, a low-entropy, confident attempt scores higher than a scattered, uncertain one, even if it wasn't the majority answer. There's also an early-stopping rule: if any single answer already has four or more votes, the aggregator stops and submits it immediately, saving compute for the next problem instead of waiting out the clock.

I actually animated this entire pipeline in Manim: every arrow, every fan-out, every step of the aggregation, so you can watch it play out visually instead of just reading a static diagram:

From 8/50 to 42/50: What the Climb Actually Looked Like

Our first working version of this pipeline scored 8 out of 50. The final version scored 42. That climb didn't come from one clever trick. It came from three unglamorous things, repeated over and over: systematically diagnosing bugs in the pipeline itself, upgrading the base model as better open-weight options became available, and steadily refining the few-shot prompts feeding into step one.

There's one more data point that told us we were on the right track, and it came after the competition closed. The eventual first-place team's public writeup also centered on GPT-OSS-120B, and their approach was also built around entropy-weighted self-consistency, refined further with things like adaptive runtime scheduling, but directionally the same idea we'd arrived at independently. When a team with more resources converges on the same core mechanism you did, without either of you seeing the other's work, that's a stronger signal than any single benchmark score.

The One Lesson I'd Give Anyone Building AI Under Real Constraints

Every rejected idea (fine-tuning, agentic search, tree search, verbose prompting) failed for a version of the same reason: it added complexity we couldn't fully control inside a budget we couldn't negotiate. The thing that actually worked was the opposite: precision and reliability over architectural cleverness.

That's not a lesson specific to Kaggle competitions. It's true anywhere you're building an AI system against a real constraint: a latency budget, a cost ceiling, a compliance requirement. The fanciest architecture on paper is worth nothing if you can't trust what it does when the clock is running.

As for the "AI beat the Olympiad" headlines, they're not wrong, exactly. The field genuinely moved from silver-medal level in 2024, to officially certified gold in 2025, to multiple perfect-score claims in 2026, in about two years. I watched a smaller version of that same curve happen inside my own project, going from 8/50 to 42/50 in a few months of iteration. The trend is real. Just read the fine print on "official" versus "self-reported" before you decide how impressed to be by any single claim.

I've taught undergraduate mathematics for 9+ years, and I build Manim-animated math content as PlotLab. If you want to learn the exact animation workflow shown in the diagram above, from your first Scene to a full multi-step pipeline animation, I wrote a complete, copy-paste-ready guide: Manim CE Beginner's Handbook. If you'd rather have someone build it for you, for an undergraduate or graduate thesis defense, a research paper, or any project where the math needs actually to look as good as it sounds, I take on that work directly; you can see the quality for yourself on Facebook (35K+ followers) and Instagram (15K+ followers), and reach out if you'd like to work together. I write more essays like this one on mathematics, AI reasoning, Manim Animations, and teaching at sohaib-hasan.github.io. I'd genuinely like to hear what you think of the pipeline above; drop a comment.

I Spent 5 Years Making Math Animations in Python. Here's Everything I Wish I Knew on Day One.

Sohaib Hassan — Wed, 29 Apr 2026 12:04:54 +0000

A complete, honest guide to building 3Blue1Brown-style math animations with Manim CE — from zero setup to your first polished scene. No fluff, just what actually works.

The first time I tried to make a math animation, I spent four hours staring at an error message I didn't understand.

No one warned me about LaTeX dependencies. No one explained the difference between Text and MathTex. No one told me why my equation was rendering in the wrong position — or why my animation was playing twice — or why the camera was cutting off half my scene.

I figured it out eventually. But it took months, not days.

If you're reading this, you probably want to create math animations. Maybe you've watched 3Blue1Brown explain calculus and thought "I want to make something like that." Maybe you teach mathematics and you're tired of static diagrams that put students to sleep. Maybe you're just curious whether Python can actually produce beautiful, publication-quality math visuals.

It can. And it's more accessible than you think.

But only if someone shows you where to actually start.

What Is Manim — And Why Does It Matter?

Manim is an open-source Python library built specifically for mathematical animations. Every equation you render is typeset through LaTeX. Every shape, every graph, every transformation is mathematically precise — not visually approximate.

This is what separates Manim from every other animation tool.

When you draw a circle in Manim, it's a perfect circle — defined mathematically, rendered with zero distortion. When you write a quadratic formula, it looks exactly like a published research paper. When you animate a transformation, every frame is calculated programmatically.

This is why educators, researchers, and content creators around the world have adopted it. Not because it's easy — but because nothing else produces results like this.

The Mistake Everyone Makes on Day One

Most beginners open Manim, look at the documentation, and immediately feel overwhelmed.

The documentation is comprehensive — but it's not written for beginners. It assumes you already know what you're looking for. If you don't, you'll spend hours reading without actually building anything.

Here's the truth: you learn Manim by writing scenes, not by reading documentation.

Every concept clicks the moment you run working code and see it render. Not before.

This is why the copy-paste-first approach works so much better than theory-first learning.

What You Actually Need to Get Started

Before writing your first scene, you need four things — and three of them are completely free.

1. Python 3.9 or later
If you already have Python installed, you're halfway there. If not, the official Python website has a one-click installer for every OS.

2. Manim CE v0.20.1

pip install manim==0.20.1

3. A LaTeX Distribution ← This is where most beginners get stuck

Manim uses LaTeX to render equations. You need either:

MiKTeX (Windows)
TeX Live (Mac/Linux)

Both are free. Both take about 15 minutes to set up. Do not skip this step — skipping it is why 80% of "Manim doesn't work" posts exist on forums.

4. VS Code
Any text editor works, but VS Code gives you syntax highlighting, terminal integration, and extensions that make Manim development significantly smoother.

That's the entire setup. No subscriptions. No expensive software. No complicated configuration beyond these four things.

Your First Scene — What It Looks Like

Here is the simplest possible Manim scene. Copy this exactly, save it as first_scene.py, and run it:

from manim import *

class HelloManim(Scene):
    def construct(self):
        equation = MathTex(r"x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}")
        self.play(Write(equation))
        self.wait(2)

Render it with:

manim -pql first_scene.py HelloManim

In under ten seconds, you'll have a video of the quadratic formula writing itself onto the screen — typeset perfectly, animated smoothly.

That's Manim. That's what three lines of actual code produce.

💡 Always use -pql (low quality) while developing. High-quality renders take minutes. Save -pqh for your final output only.

The Five Concepts That Unlock Everything

After years of building animations, I can tell you that 90% of what you'll ever need in Manim comes down to five core concepts.

1. `MathTex` and `Text`

MathTex renders LaTeX equations. Text renders plain words. Knowing when to use which — and how to color individual parts of an equation — is the foundation of every math explainer.

# Correct — renders LaTeX
equation = MathTex(r"E = mc^2")

# Wrong for equations — won't render LaTeX
label = Text("E = mc^2")

2. Shapes and Geometry

Circles, squares, triangles, lines, arcs — all mathematically defined, all fully customizable. Once you understand how positioning works in Manim, placing objects exactly where you want them takes seconds.

circle = Circle(radius=1, color=BLUE)
square = Square(side_length=2, color=GREEN)
square.next_to(circle, RIGHT, buff=0.5)

3. Animations and Transforms

Write, Create, FadeIn, Transform, ReplacementTransform — these are the verbs of Manim. Each one does something specific, and choosing the right one makes the difference between an animation that feels natural and one that feels jarring.

self.play(Write(equation))           # draws stroke by stroke
self.play(FadeIn(circle))            # fades in from transparent
self.play(Transform(square, circle)) # morphs one shape into another

4. `NumberPlane` and Graphs

Plotting functions in Manim is remarkably clean. Define your axes, pass a lambda function, and Manim draws it — with full control over color, range, and style.

axes = Axes(x_range=[-3, 3], y_range=[-1, 9])
graph = axes.plot(lambda x: x**2, color=YELLOW)
self.play(Create(axes), Create(graph))

5. Updaters and `ValueTracker`

This is where Manim becomes truly powerful. Updaters let objects respond dynamically to changing values — this is how you create animations where a tangent line moves along a curve, or a point traces a parametric path in real time.

tracker = ValueTracker(0)
dot = always_redraw(
    lambda: Dot(axes.c2p(tracker.get_value(), tracker.get_value()**2), color=RED)
)
self.play(tracker.animate.set_value(2), run_time=3)

The Common Mistakes That Cost Beginners Hours

I made every single one of these. You don't have to.

Mistake	What to do instead
Rendering high quality every time	Use `-pql` while building. Switch to `-pqh` only for the final render.
Not using `VGroup` for positioning	Group related objects with `VGroup` — positioning a group is infinitely cleaner than positioning each object individually.
Hardcoding coordinates	Use `.next_to()`, `.shift()`, `.move_to()`. Your layout will survive any change you make.
Using `Text` for equations	If your equation looks wrong — jagged, unstyled, broken — you're almost certainly using `Text` when you should be using `MathTex`.
One long `construct()` method	Break your scene into helper methods. A readable scene is a maintainable scene — especially when you return to it three weeks later.

A Complete Working Example — From Zero to Polished

Here's a scene that combines everything above. Copy it, run it, and modify it as your own starting template:

from manim import *

class QuadraticExplainer(Scene):
    def construct(self):
        # Title
        title = Text("Solving a Quadratic Equation", font_size=36)
        self.play(Write(title))
        self.wait(1)
        self.play(title.animate.to_edge(UP))

        # Standard form
        standard = MathTex(r"ax^2 + bx + c = 0", font_size=48)
        self.play(Write(standard))
        self.wait(1)

        # Transform to quadratic formula
        formula = MathTex(
            r"x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}",
            font_size=48
        )
        self.play(ReplacementTransform(standard, formula))
        self.wait(2)

        # Highlight the discriminant
        formula[0][9:19].set_color(YELLOW)
        discriminant_label = Text("discriminant", font_size=24, color=YELLOW)
        discriminant_label.next_to(formula, DOWN)
        self.play(Write(discriminant_label))
        self.wait(2)

Run with:

manim -pql scene.py QuadraticExplainer

Where to Go From Here

Manim has a learning curve — but it's not as steep as it looks from the outside. The moment your first animation renders, something shifts. You stop seeing it as code and start seeing it as a creative tool.

The path forward is simple: build scenes. Start with something small — an equation, a shape, a simple transform. Then add complexity one layer at a time.

I spent years on this path. I documented everything — every mistake, every shortcut, every pattern I kept returning to — into a structured beginner handbook:

📘 Manim CE v0.20.1 Beginner Handbook

Ten complete chapters. Copy-paste-ready code for every concept above. Common mistakes are prefixed before you hit them. 60 pages.

If you want to see what Manim looks like in practice before committing to anything, the animations are here:

📱 @plotlab01 on Instagram

Start building. The best math animation you'll ever make is the next one.

About the author: Sohaib Hasan is a Mathematics Lecturer with 9 years of experience and 1,500+ students taught. He creates 3Blue1Brown-style math animations using Python and Manim, and shares them at @plotlab01.