So I built AI Stack Advisor. You describe what you want AI to do, and it compares the four options on monthly cost, 36-month total cost of ownership (TCO), break-even volume, and ROI, then writes a consultant-style recommendation with every assumption listed. You can try it live.

How it works

1. Start from goals. Pick what you want AI to do, like answering customers, processing invoices, or finding answers in company data. Each goal becomes a workload, and you can pick several.
2. Volume. Users per day, requests per user, or documents and pages, growing month by month.
3. Cost of each option. API cost comes from tokens times published prices, plus hosting, databases, and maintenance. Self-hosting picks a model size, the cheapest GPU with enough memory, and enough GPUs for peak traffic. SaaS uses the cheapest plan whose limits fit.
4. Value. What a conversation is worth in sales, or how many staff hours an internal tool saves.
5. Recommendation. A weighted score of cost and non-cost factors (privacy, time to launch, team fit, quality, lock-in, and scalability), plus a check on whether the answer is robust or a close call.

Every formula is written out in the methodology.

The parts I care most about

Showing the workings. A recommendation is only useful if you can see why. Click any monthly cost and it breaks down into quantity × rate. Every number has a source, a last-checked date, and a confidence level, and the high-impact guesses are flagged as "check these first".

Being honest about uncertainty. You can mark inputs you are unsure about, and the tool shows results as ranges. It also runs 300 simulations that vary prices, GPU throughput, labour costs, and model quality, then reports how often each option wins. A tornado chart shows which assumptions move the answer most. This is the same instinct as in my physics and quant work: a single number without error bars can mislead.

Real-world details. Taxes (VAT, GST, and US sales tax, counted only when a business can't reclaim them), data-protection rules that rule out options when data must stay in-house, labour costs from official statistics, and eight currencies, including lakh and crore formatting for India.

Tech stack

• Plain HTML, CSS, and JavaScript modules, with no framework and no build step
• A pure-function engine that runs the same in the browser and in Node tests
• Chart.js for the charts
• GitHub Actions that refresh exchange rates from the European Central Bank and flag prices older than 30 days

Everything runs in your browser. There is no backend, no API key, no LLM call, and no tracking.

The numbers are estimates for planning, not quotes. Vendor prices change often, so test with your own data before deciding.

The workflow

The whole pipeline is one n8n workflow, built in five stages:

1. Request. A webhook or a simple form takes the ticker (and optional peers) and checks that it is valid.
2. Parallel data pulls. Prices, fundamentals, and peers come from yfinance; recent filings come from SEC EDGAR; and headlines come from Google News and Yahoo Finance RSS. Every branch keeps going if its source fails, so one broken feed never blocks the report.
3. Analysis in Python. A small FastAPI service computes ratios, peer comparisons, technical indicators (RSI, MACD, moving averages, and Bollinger bands), drawdown, volatility, news sentiment, and a simple scorecard.
4. LLM drafting. A local model writes the narrative in three passes: fundamentals, then technicals and news, then a lead-analyst summary. Each pass returns structured JSON.
5. Publish. The report is saved as JSON and a PDF, and the report site opens it.

The design choice I care most about

The LLM never calculates anything. Every number it sees has already been computed in Python, and it only writes the words around them. If the model is unavailable or returns broken JSON, that section falls back to rule-based text, and a Method tab shows exactly which parts came from the model and which came from rules. Small local models can still misread numbers, so being open about where each sentence came from felt important.

Tech stack

• n8n (self-hosted in Docker) for orchestration
• yfinance, SEC EDGAR, and RSS feeds as key-less data sources
• Python, FastAPI, and pandas for the analytics, with VADER plus a finance vocabulary for sentiment
• Ollama (qwen3:4b by default) for the three LLM passes
• WeasyPrint and matplotlib for the PDF, and Apache ECharts for the interactive charts

It runs entirely on my machine with free tools. It also works for Indian listings like RELIANCE.NS, with NIFTY 50 as the benchmark.

This is a learning project, not investment advice.

What it does

Every 15 minutes, an n8n workflow scores a fresh batch of simulated "production" traffic and logs every prediction to Postgres. It then checks three things: has the input data drifted, have the predictions drifted, and is the model still accurate? If something crosses a threshold, a local LLM reads the numbers and writes a short explanation of the likely cause. That explanation lands in Slack, with links to the full report and a Grafana dashboard.

The part I enjoyed most: the LLM is never told what went wrong. It has to work it out from the metrics alone, and because the true cause is stored separately, I can score how often its explanation was right.

The scenarios

The model predicts breast cancer diagnoses from the UCI Wisconsin dataset, and I simulate a few realistic ways things break:

• Calibration shift: a software update makes measurements about 25% larger, and accuracy drops from about 96% to about 80%.
• Population shift: a new clinic sends far more malignant cases. The data drifts, but the model stays accurate, which is a useful reminder that drift doesn't always mean failure.
• Data quality bug: one feature arrives in the wrong unit, and another is often missing.

Tech stack

• n8n for scheduling and the alert workflow
• FastAPI + Evidently AI for drift and quality metrics (K-S tests, PSI, and KL divergence per feature)
• scikit-learn (a random forest) as the model being watched
• Postgres for logging and Grafana for the dashboard
• Ollama (llama3.1, running locally) for the root-cause explanation
• Slack for alerts, and Docker Compose to run everything

Everything runs on my machine, and nothing leaves it except the Slack message.

How it works

There are two flows, both running in n8n:

1. Ingestion. I upload a PDF, TXT, DOCX, or MD file through a form. It is split into chunks of 400 characters with 100 characters of overlap, each chunk is embedded, and the vectors are stored in ChromaDB.
2. Question answering. I ask a question in a chat window. The agent retrieves the 15 most relevant chunks and passes them to a local LLM with a strict system prompt: answer only from this context, and say so plainly when the answer isn't there.

That last rule mattered more than I expected. A small model will happily fill gaps with confident guesses, and forcing it to admit "I can't find this in the document" made the answers far more trustworthy.

Tech stack

• n8n (self-hosted in Docker) for orchestration
• Ollama running llama3.2:1b for answers and nomic-embed-text for embeddings
• ChromaDB (also in Docker) as the vector store
• One docker compose up to start everything

What I learned

Retrieval quality depends heavily on chunk size and top-k, and the right values change with the kind of document. I also chose a deliberately small model for speed, and it shows its limits on multi-item reasoning, such as correctly pairing items in a list with their attributes. Swapping in a larger model like llama3.2:3b or qwen2.5:3b fixes much of that, at the cost of speed. It is a nice, hands-on way to feel the trade-offs in a RAG system rather than just read about them.

I've been reading about and experimenting with RAG a lot lately, so I wanted to write a clear explanation of what it is, why it has become so important, and the parts that are harder than they look.

The problem RAG solves

A language model like GPT or Claude learns from a huge amount of text during training. But that knowledge has three big limits:

1. It's frozen in time. The model doesn't know anything that happened after its training data was collected.
2. It doesn't know your private data. Your company's policies, your contracts, your internal wiki, your research notes. None of that was in its training.
3. It can make things up. When a model doesn't know something, it may still produce a confident, plausible-sounding answer. This is called hallucination.

You could retrain or fine-tune the model on your data, but that's expensive, slow, and has to be redone every time your documents change. And fine-tuning is better at teaching style and behaviour than at reliably storing facts.

The idea: look it up first

RAG stands for retrieval-augmented generation. The name comes from a 2020 paper by researchers at Facebook AI (now Meta), and the idea is simple:

Before the model answers, find the most relevant pieces of your documents and give them to the model along with the question.

It's the difference between a closed-book exam and an open-book exam. Without RAG, the model answers from memory. With RAG, it answers with the right pages open in front of it.

How it works, step by step

A RAG system has two phases.

Phase 1: preparing your documents (done once, updated as needed)

1. Load your documents: PDFs, web pages, emails, notes, whatever you have.
2. Chunk them: split each document into smaller pieces, often a few paragraphs each. Models can only take in so much text, and smaller pieces make retrieval more precise.
3. Embed each chunk: an embedding model turns each piece of text into a vector, a long list of numbers that captures its meaning. Texts with similar meanings get vectors that point in similar directions, even if they use different words. "How do I reset my password?" and "I forgot my login" end up close together.
4. Store the vectors in a vector database (like Chroma, Pinecone, or pgvector), which is built to quickly find the closest vectors to a new one.

Phase 2: answering a question (every time someone asks)

1. Embed the question with the same embedding model.
2. Retrieve the chunks whose vectors are closest to the question's vector, usually the top 3 to 10.
3. Augment the prompt: put those chunks into the prompt with an instruction like "Answer using only the context below. If the answer isn't there, say so."
4. Generate the answer with the language model, ideally with citations pointing back to the source chunks.

That's it. The model doesn't learn anything new permanently. It just gets the right information at the right moment.

Why it matters so much

1. It works with data that changes. Update a document, re-embed it, and the system knows the new version immediately. No retraining.

2. It's cheap. You use an existing model as is. The main costs are embedding your documents (cheap) and the model calls.

3. It reduces hallucination. Grounding answers in real documents makes them far more reliable. Not perfect, but much better.

4. It can cite sources. Users can click through to the exact paragraph the answer came from. For businesses, legal teams, and researchers, this trust matters more than almost anything else.

5. It respects access control. You can filter retrieval by who's asking, so people only get answers from documents they're allowed to see.

6. It fits almost every business. Customer support, internal knowledge bases, legal and compliance search, research assistants, onboarding guides. Any company with lots of documents has a use for it.

This is why RAG has become one of the most important building blocks for companies adopting AI. It's practical, relatively easy to start, and the value is easy to explain.

The parts that are harder than they look

The basic version takes an afternoon. Making it actually good takes much longer. What I found most interesting while experimenting with it is that the language model is rarely the problem. Retrieval is.

• Chunking matters a lot. Chunks too small lose context; chunks too large bury the relevant sentence in noise. Splitting in the middle of a table or a list can break the meaning entirely.
• Similar isn't always relevant. Vector search finds text that sounds similar, but it can miss exact terms like product codes, names, or error numbers. That's why many systems use hybrid search, combining vector search with classic keyword search (like BM25).
• Reranking helps. Retrieve a broader set of chunks first, then use a second, more careful model to reorder them by true relevance before passing the best few to the language model.
• Messy documents. Scanned PDFs, tables, charts, and headers repeated on every page all need cleaning before they're useful.
• Questions that need many documents. "Summarise all complaints from last quarter" can't be answered from five chunks. Approaches like GraphRAG (from Microsoft) build a map of entities and relationships across documents to handle these broader questions.
• Evaluation. How do you know it's good? You need a set of test questions with known answers and to measure both parts separately: did retrieval find the right chunks, and did the model use them faithfully?

Isn't long context going to kill RAG?

Models can now read hundreds of thousands, even millions of tokens in a single prompt. So why not just paste in all your documents?

For small collections, that can work well. But for anything large, RAG still wins on cost (you pay for every token you send), speed, and focus (models can still miss details buried in very long inputs). And most companies have far more documents than any context window can hold. In practice, the two work together: retrieve the right material, then use long context to read it properly.

Where it's going: agentic RAG

The newer versions are less of a fixed pipeline and more of an agent. Instead of always retrieving once and answering, the model decides for itself: should I search? What should I search for? Was that result good enough, or should I try a different query? Should I check another source?

That's much closer to how a person researches something, and it's where a lot of current work is heading. Tools like MCP (Model Context Protocol) make it easier to connect models to many data sources this way.

Why I like it

I love RAG as an idea because it makes the strengths and weaknesses of language models very visible. The model is great at reading and explaining. It's bad at remembering specific facts reliably. RAG plays to the strength and covers the weakness.

If you're starting with AI engineering, it's probably the single most useful thing to build first. Next, I'm planning to build a fully local version that runs entirely on my own machine, and I'll write about it once it's done.

The idea

Most productivity trackers watch you: they log which sites you visit and hand you a report at the end of the week. FocusPulse goes the other way. You tell it what you are doing, right now, with one click:

• Green for deep focus
• Blue for working with music or a podcast on
• Orange for mindless tab-switching (you estimate the minutes lost, and it adds a 10-minute penalty)
• Red for a break

A floating widget sits on every tab and shows today's colour ratio filling up in real time. The bet is that watching your own green bar grow is its own reward. You are not being tracked; you are tracking yourself, and I think that difference matters. It is honesty-based and non-punitive: orange and red are just time you can win back.

Tech stack

• Chrome extension on Manifest V3, written in plain JavaScript and CSS
• A background service worker holds the single source of truth: the active colour, time per colour, widget position, and session history
• A content script injects the widget into every tab and keeps it in sync through runtime messages and storage-change events
• Everything lives in chrome.storage.local: no backend, no account, and no data leaving the browser

Phase 1 (the persistent widget and basic logging) works. Next up are an analytics dashboard, streaks, small nudges, end-of-day summaries, and eventually export and idle detection.

Help me make it better

The whole point is for FocusPulse to be a little addictive, in a good way. If you have ideas on how to make it more engaging (or you try it and something feels off), drop me an email or message me on LinkedIn. I would love to hear them.

I'd had some ideas of my own around evaluation for a while, mostly from testing models on physics problems and noticing how differently they behaved from what the leaderboards suggested. But I went into this much deeper after coming across a job post from Epoch AI for an AI researcher. Epoch is one of the groups that takes measuring AI progress seriously, and reading about the role made me realise I couldn't clearly explain what makes a benchmark good. Not which benchmarks exist, but how you'd design one from scratch.

So instead of another list of benchmark names, this note is about the design itself. As a physicist, I find it easiest to think of a benchmark as a measuring instrument. Every instrument has to answer the same questions: what are you measuring, how do you read the result, how precise is it, and what can fool it?

1. Start with the thing you actually want to measure

Physics has a clean version of this problem. You can't measure "temperature" directly. You measure something that tracks it, like how far mercury expands in a tube, and you trust the link between the two.

Benchmarks work the same way. Nobody can measure "coding ability" or "reasoning" directly. So you pick a set of tasks where success should depend on that ability, and you measure success on those tasks instead.

This gap between the thing you care about (the construct) and the thing you can score (the proxy) is the root of almost every benchmark problem. A multiple-choice science test measures "can pick the right letter among four," which overlaps with "understands science" but is not the same thing. The first design question is always: if a model scores high here, what am I actually allowed to conclude?

2. Choose the tasks: a sample from a much bigger world

A benchmark is never the full skill. It's a sample. If you want to know how good a model is at fixing bugs in real software, you can't test it on every bug that will ever exist. You collect, say, 500 real bugs and hope they're representative.

That means the way you collect tasks decides what you can claim:

• Where do tasks come from? Written fresh by experts, taken from exams, scraped from real work (like GitHub issues), or generated by a program.
• How varied are they? 500 bugs from just three projects measure something much narrower than 500 bugs from 100 projects.
• How hard should they be? This is subtle. If every task is easy, all good models score 100% and you learn nothing. If every task is impossible, they all score 0% and you also learn nothing. The useful information lives in tasks that some models solve and others don't.

That third point is why good benchmarks deliberately spread difficulty from easy to very hard. Epoch's FrontierMath, for example, runs from hard undergraduate problems up to research-level ones that take expert mathematicians hours or days. A spread like that keeps the instrument useful as models improve, the same way a good ruler has both millimetre and centimetre marks.

There's also a trap here. Some benchmarks keep only the questions that current top models get wrong (Humanity's Last Exam was built partly this way). That makes the benchmark hard on day one, but it also means scores are artificially low at launch and then jump quickly, partly because models were selected against rather than because they suddenly got much smarter.

3. Decide how to score: the "ground truth" problem

Once a model gives an answer, how do you decide if it's right? There are only a few basic options, and each has trade-offs.

Exact answers. The answer is a number, a letter, or an expression that can be checked automatically. Cheap, objective, and repeatable. This is why so many maths benchmarks ask for a final number. FrontierMath goes further and designs problems so the answer is hard to guess, like a large specific number rather than "yes" or "no."

Executable checks. For code, run it against tests. SWE-bench does this with real projects: the fix counts only if the project's own tests pass. It's objective, but only as good as the tests. Weak tests let wrong solutions slip through.

Rubrics and judges. For open-ended work like essays, analyses, or plans, there is no single right answer. Someone has to grade it, either human experts with a rubric or another AI model acting as a judge. More realistic, but also more expensive, slower, and less consistent. An AI judge can also share the blind spots of the model being judged.

Human preference. Show people two answers and ask which is better, like LMArena does. With enough votes, you can turn pairwise comparisons into a single rating, the same way chess ratings work. This captures what people actually like, but people also reward confidence, length, and nice formatting, which aren't the same as correctness.

What I found most interesting: the more realistic the task, the harder it is to score objectively. Benchmark designers are always trading realism against reliability of grading.

4. Treat the score as a measurement with error bars

This is the part I think most launch charts ignore, and it's pure statistics.

If a benchmark has $n$ questions and a model gets a fraction $p$ right, the uncertainty in that score (the standard error) is roughly

$$\text{SE} \approx \sqrt{\frac{p(1-p)}{n}}$$

Take a benchmark with about 200 questions and a model scoring 70%:

$$\sqrt{\frac{0.7 \times 0.3}{200}} \approx 0.032$$

That's about ±3 percentage points for one standard error, and closer to ±6 for a 95% confidence range. So when one model scores 71% and another 73% on a 200-question test, that difference is basically noise. Small benchmarks can only tell apart models that are far apart.

There's a second source of noise: the model itself. Ask the same question twice and you can get different answers. So designers also have to decide:

• How many attempts? Score only the first try, or count it as solved if any of several attempts is right ("pass@k")?
• How to combine attempts? Majority vote across several runs often scores higher than a single run.

Two labs reporting the "same" benchmark with different choices here aren't really reporting the same number.

5. Control how the test is run

In physics, you'd never compare two measurements taken under different conditions without saying so. In AI benchmarks, conditions vary a lot:

• The prompt: exact wording and examples given can shift scores noticeably.
• Tools: can the model search the web, run code, use a calculator?
• Thinking budget: reasoning models score higher when allowed to think longer.
• The scaffold: for agent benchmarks, the surrounding software (how the model sees files, how many steps it gets, what happens when it errs) matters as much as the model.

So a benchmark score is really a score for a model plus a setup. This is a big reason independent evaluators matter: they run every model under the same, documented conditions, using open evaluation frameworks such as Inspect, so the comparisons are actually fair. Good evaluations also report the cost of each run, because a slightly higher score at ten times the price isn't the same achievement.

6. Protect the test from leaking

A benchmark only works if the model hasn't seen the answers. But models are trained on huge amounts of internet text, and benchmarks tend to end up on the internet. When that happens, the score starts measuring memory instead of ability. This is called contamination.

The main defences, from first principles:

• Keep tasks private. Release only a few examples and keep the real test set hidden. FrontierMath keeps most problems private for this reason.
• Use fresh tasks. Draw from problems created after a model's training data was collected, like each year's new maths competition, or continuously updated question sets.
• Mark the data. Some benchmarks embed a unique "canary" string so labs can filter them out of training data, and so researchers can test whether a model has seen it.
• Check for memorisation. If a model can complete a benchmark question word for word from a partial prompt, that's a warning sign.

7. Plan for the benchmark's death

Every benchmark eventually saturates: the best models score close to the maximum, and it stops separating them. Often the last few percent can't even be reached, because some questions have mistakes in them. If 3% of answers in the key are wrong, 97% is effectively a perfect score.

There's also Goodhart's law: when a measure becomes a target, it stops being a good measure. Once a benchmark becomes famous, labs optimise for it, sometimes in ways that improve the number more than the skill.

Good designers expect this and build in headroom: tasks well beyond current ability, private holdout sets, and versions that can be updated.

8. Connect benchmarks across time

Here's a problem I hadn't thought about before. Each benchmark lives only a few years. So how do you compare a model from 2021 with one from 2026, when no single benchmark covers both?

The solution borrows from how standardised exams compare students across different test papers, a method called item response theory. The idea: every model has an underlying ability, every benchmark (or question) has a difficulty, and the chance of success depends on the gap between the two. If you have enough overlapping results, with some models tested on both old and new benchmarks, you can estimate abilities and difficulties together on one shared scale.

That's essentially what Epoch's Capabilities Index does: stitch many benchmarks together into one long ruler, so progress can be tracked across years even as individual benchmarks saturate. I loved this, because it's exactly how physicists calibrate instruments that each work only over a limited range.

My own ideas, revisited

Thinking about benchmarks this way made the ideas I'd had before more concrete:

• Consistency deserves its own number. Ask a model the same physics question five times and you can get different answers. A single score hides that. Reporting how often a model is reliably right across repeated runs would tell you more about whether you can trust it.
• Verifiable research problems. In my field, many derivations end in a checkable result, like the maximum efficiency of an energy extraction process for a given black hole spin. A set of these could test real derivation ability with exact, automatic grading, in the same spirit as FrontierMath.
• Cost per correct answer. For real use, accuracy per dollar often matters more than raw accuracy.

Some of these already exist in some form, which was humbling and also reassuring. It meant I was thinking in the right direction.

A checklist I now use

When I see a new benchmark result, I ask:

1. What exactly is being measured, and what am I allowed to conclude from it?
2. How many tasks? Is the difference between models bigger than the error bars?
3. How is it graded? Exact answers, tests, rubric, AI judge, or human votes?
4. Under what conditions? Tools, attempts, thinking time, scaffold, cost.
5. Could it be contaminated? Public or private, old or fresh?
6. Is it saturated? Are all top models bunched near the ceiling?
7. Who ran it? The lab itself, or an independent evaluator?

Benchmarks are imperfect, but they're the closest thing we have to a shared ruler for AI progress. And designing a good ruler turns out to be one of the most interesting problems in the field.

The idea

Typing the same name, email, links, education, and work history into form after form gets old quickly. Browser autofill handles the basics, but not the longer fields like a summary or a job description. So the idea was simple: keep your details in one file you control, and let the extension map them onto whatever form is in front of you.

You upload a profile as Markdown, JSON, TXT, or CSV, open any form, and click Auto-Fill All Fields. Filled fields turn green and unmatched ones turn yellow, so you can see exactly what happened. You can keep several profiles (say, one for tech roles and one for academic applications) and save custom mappings for sites you use often.

Tech stack

• A Chrome/Edge extension with a popup UI, a content script for field detection, and a background service worker
• Multi-strategy field matching, where the highest-confidence match wins: input type first (type="email"), then a keyword map of labels, then direct key matching, and finally fuzzy matching with Levenshtein distance for typos and variations
• Native event dispatch, so React, Angular, and Vue forms register the filled values
• IndexedDB for storage: no server, no API calls, and no analytics

What I enjoyed

I had a lot of fun with this one beyond the code. Working through the product ideation, deciding what the extension should and shouldn't do, designing the popup, and thinking about how a first-time user would feel was the best part for me.

Why

A lot of statistics is taught as a toolbox: memorise the test, plug in the numbers, report the p-value. I have always found it more useful (and more fun) to rebuild ideas from the ground up, the way I learned to approach physics. If you understand where a formula comes from, you know when it applies and when it quietly breaks.

The plan

The series starts before probability, with randomness and uncertainty themselves, and then builds step by step: events and sample spaces, how probabilities add and multiply, counting, and onwards toward inference. Each post leans on everyday examples (cards, passwords, lotteries, and locks) rather than heavy notation, so the intuition comes first and the maths follows.

If you have ever used a statistical test without being sure why it works, this series is for you. Follow along on Medium.

The result is the ArXiv Research Analysis Agent.

What it does

1. Each morning it checks arXiv's new-submissions listing for the categories I care about (General Relativity and Quantum Cosmology, and Quantitative Finance by default).
2. It filters the new papers against my keyword list.
3. For every match, I get a Telegram message with the title, the abstract, and a yes/no prompt.
4. If I reply yes <arxiv_id>, it downloads the full PDF, extracts the text, and asks a local LLM to explain the paper's derivation and methodology from first principles. The analysis comes back to me on Telegram as a Markdown report.
5. If I reply no, it marks the paper as skipped and moves on.

The yes/no step is the part I like most. I stay in control of what gets a deep read, without doing any of the busywork.

Under the hood

• n8n (self-hosted) orchestrates two branches: a daily schedule that queries and filters arXiv, and a one-minute poller that reads my Telegram replies.
• Ollama runs the model locally (qwen3:4b), so paper content never goes to a third-party API.
• ChromaDB is used purely as a small key-value store for paper status (pending, in progress, or declined) and the Telegram polling offset, which turned out more reliable than n8n's built-in static data across separate triggers.
• The Telegram Bot API handles both the daily briefs and my replies.
• arXiv's public listing pages need no API key.

It now runs every morning, and I spend that time actually reading the papers that matter.

So I tried to work it out from first principles, the way I'd approach a physics problem: strip it down to what learning actually is, and see where the two approaches split.

What does "learning" mean, mathematically?

Every supervised learning problem has the same shape. You have inputs $x$ (an image, a row of customer data, a sound clip) and outputs $y$ (a label, a price, a yes/no). You believe there's some function connecting them:

$$y \approx f(x)$$

You don't know $f$. You only have examples. Learning means finding a function that matches the examples and, more importantly, works on new ones.

To do that, every learning method makes three choices:

1. A family of possible functions to search through (straight lines, decision trees, neural networks...).
2. A way to measure error (how wrong is a given function on the examples?).
3. A way to search for the function with the lowest error.

Machine learning and deep learning differ mostly in the first choice, and that one difference ripples through everything else.

The key idea: representation

Here's a small example that, for me, explains the whole topic.

Imagine points scattered on a flat sheet. Points inside a circle are red; points outside are blue. You want a model that separates them.

If you describe each point by its coordinates $(x_1, x_2)$, a simple model that draws straight lines can't do it. No straight line separates the inside of a circle from the outside.

But change how you describe the points. Add one new quantity:

$$r^2 = x_1^2 + x_2^2$$

Now the problem is trivial: red if $r^2$ is less than some number, blue otherwise. The model didn't get smarter. The description of the data got better.

Physicists do this all the time. Choose the right coordinates and a nasty problem becomes simple. Planetary orbits are a mess in Cartesian coordinates and clean in polar ones.

In machine learning, this description is called the representation, or the features. And this is the real dividing line:

• In classic machine learning, a human usually designs the representation. The model learns a fairly simple function on top of it.
• In deep learning, the model learns the representation itself, along with the function on top.

Classic machine learning: you build the features

Say you're predicting whether a customer will repay a loan. A data scientist would think about what actually matters and build features: debt divided by income, number of late payments in the past year, length of credit history, change in balance over six months.

Then a model like logistic regression, a decision tree, or gradient-boosted trees learns how to combine those features into a prediction.

Why this works well:

• The search is easy. For logistic regression, the error landscape is a single smooth bowl (it's convex), so there's exactly one best answer and you're guaranteed to find it.
• It needs less data. The human has already done much of the thinking through the features, so the model has less to figure out.
• It's explainable. You can see which features mattered and by how much.

The weakness: the model can only be as good as the features someone thought of. If the important pattern is something no one thought to compute, the model will never see it.

Deep learning: the model builds the features

A neural network is a chain of simple steps. Each layer takes numbers in, multiplies them by weights, adds them up, and passes them through a simple bend (a non-linear function). Stack many layers and the output of each becomes the input of the next:

$$f(x) = f_L\big(\cdots f_2(f_1(x))\big)$$

Each layer re-describes the data a little. Train the whole chain together, and the early layers learn to build whatever representation makes the final step easy.

In the circle example, a small network would essentially discover something like $r^2$ by itself. Nobody tells it to.

In images, this is very visible. Inspect a trained network and you find:

• early layers responding to edges and colour changes,
• middle layers responding to textures and simple shapes,
• deeper layers responding to eyes, wheels, or letters.

Nobody programmed edges or eyes. They emerged because they were useful for reducing the error.

Why depth, specifically?

Why many layers instead of one very wide one? Two reasons.

The world is built from parts. A face is made of eyes and a mouth, which are made of curves, which are made of edges. A sentence is made of phrases, which are made of words. Stacking layers matches this structure: each layer builds on the pieces found by the one before. A single layer would have to learn every combination directly, which needs vastly more units.

Composition is powerful. Each layer can bend and fold the data space. Folding a sheet of paper a few times creates many creases; folding it many times creates exponentially more. In the same way, a deep network can represent very complicated functions with far fewer parameters than a shallow one.

The price: data, compute, and a harder search

Learning the representation yourself isn't free.

It needs more data. A model searching through a much bigger family of functions needs more examples to pin down the right one. With little data, a flexible model memorises the examples instead of learning the pattern (overfitting).

It needs more compute. Millions or billions of weights, adjusted again and again by gradient descent. This is why deep learning only took off once GPUs made it practical, around 2012, when the AlexNet network won the ImageNet image competition by a huge margin.

The search is harder. The error landscape is no longer a single smooth bowl. It's full of hills and valleys, and gradient descent gives no guarantee of finding the best point. In practice it works surprisingly well, and why it works so well is still an active research question.

It's harder to explain. The learned features are spread across thousands of numbers rather than named columns like "debt-to-income."

So when does each one win?

Once you see the difference as "who builds the representation," the practical rules follow naturally.

Raw, high-dimensional, structured data like images, sound, and text: deep learning wins. A small photo has hundreds of thousands of pixel values, and no human can hand-design features for "is there a dog in this photo" that hold up across angles, lighting, and breeds. The representation is the hard part, so you want the model to learn it.

Tables with meaningful columns: classic ML often wins. In a spreadsheet, each column already means something (age, income, balance), so much of the representation work is already done. Here, gradient-boosted trees still often match or beat neural networks. A 2022 study by Grinsztajn and colleagues looked into why, and found a few reasons: tables often contain irrelevant columns that trees simply ignore, and the patterns in tabular data are often irregular and step-like, which trees capture naturally while neural networks tend to prefer smooth functions.

Credit scoring, which I worked on in one of my projects, is a good example of the second case: tree-based models with sensible features are the natural starting point, and they're easier to explain to the people who have to act on the decisions.

Side by side

The one-line version

Classic machine learning is mostly about learning a decision on top of a description that humans designed. Deep learning is about learning the description too.

Everything else, more data, more compute, harder training, less transparency, and better results on raw signals, follows from that single difference. Once I saw it that way, choosing between the two stopped feeling like following a rule and started feeling obvious.

With DeepSeek-R1 out this week and everyone talking about it, it felt like the right time to write it down. The broad recipe is shared across labs. The interesting part is where each one puts its own spin on it.

The big picture

Training a modern assistant happens in roughly four stages:

1. Data: collect and clean an enormous amount of text.
2. Pretraining: teach a model to predict the next token on all of it.
3. Post-training: turn that raw model into a helpful, safe assistant.
4. Evaluation and safety testing: check what it can do and what could go wrong before release.

Pretraining builds the knowledge. Post-training shapes the behaviour. Most people only see the last stage, but the first two are where most of the compute and cost go.

Stage 1: data

Everything starts with data, and it's less glamorous than it sounds.

• Sources: public web pages (often from Common Crawl, a giant open archive of the web), books, Wikipedia, scientific papers, code from public repositories, and licensed datasets.
• Cleaning: removing spam, duplicate pages, broken text, and low-quality content. Labs also filter out personal information and harmful material.
• Mixing: deciding how much of each kind of data to include. More code tends to make models better at reasoning; more maths helps with maths.
• Tokenising: splitting text into tokens, small chunks of words that the model actually reads.

The scale is hard to picture. Meta's Llama 3 was trained on over 15 trillion tokens. What I found most interesting is how much labs say data quality matters. Removing junk and duplicates often helps as much as making the model bigger. From my own work I can relate: a clean dataset beats a clever model on bad data almost every time.

Stage 2: pretraining

This is the expensive part. The model starts with random numbers as its parameters and reads through the data, predicting the next token over and over. Each wrong guess nudges billions of parameters slightly in the right direction using gradient descent.

• Hardware: thousands to tens of thousands of GPUs (or Google's TPUs) running in parallel for weeks or months. Llama 3's largest model used up to 16,000 Nvidia H100 GPUs.
• Engineering: at this scale, hardware fails regularly, so a lot of work goes into checkpoints, recovery, and splitting the model across many chips efficiently.
• Planning: labs use scaling laws to predict how good a model will be before training it, by running smaller experiments first. Nobody wants to discover a mistake after spending tens of millions of dollars.

The result is a base model. It knows an enormous amount, but it's not an assistant. Ask it a question, and it may continue with more questions, because that's what text on the internet often looks like. It's a brilliant autocomplete, not yet a helper.

Stage 3: post-training

This is where the model gets its personality, its helpfulness, and its safety behaviour. It's also where labs differ the most.

Supervised fine-tuning (SFT)

First, the model is trained on curated examples of good conversations: a prompt and an ideal response, written by people or carefully generated and filtered. This teaches the format of being an assistant, like answering the question, following instructions, and saying "I don't know."

Preference tuning

Examples only go so far, because it's hard to write the perfect answer but much easier to say which of two answers is better. So:

1. The model writes several answers to the same prompt.
2. People (or another model) rank them.
3. The model is trained to produce more answers like the preferred ones.

The classic version is RLHF (reinforcement learning from human feedback): train a separate reward model to predict human preferences, then use reinforcement learning to push the language model towards high-reward answers. A simpler method from 2023, DPO (direct preference optimisation), skips the separate reward model and learns from the preference pairs directly. Many labs now use some mix of both.

Reinforcement learning for reasoning

This is the newest and most exciting piece. Instead of only learning what humans prefer, models are trained with reinforcement learning on problems where the answer can be checked automatically: does the maths answer match? Does the code pass the tests?

The model tries, gets rewarded for correct answers, and gradually learns to work through problems step by step, check itself, and backtrack when stuck. This is what's behind OpenAI's o1 and o3, and DeepSeek's R1. I go into it more below.

Stage 4: evaluation and safety

Before release, labs test models on benchmarks (maths, coding, knowledge, reasoning), but also on risks:

• Red-teaming: people deliberately try to make the model misbehave or give dangerous information.
• Dangerous capability tests: for example, could it meaningfully help with cyberattacks or biological weapons?
• Model cards and system cards: documents describing what was tested and what was found.

Anthropic, for example, has a Responsible Scaling Policy that ties how carefully a model must be handled to how capable it is. OpenAI publishes system cards with each major release.

How the labs differ

OpenAI popularised RLHF with InstructGPT in 2022, which became the basis for ChatGPT. With o1 (September 2024), they added large-scale reinforcement learning on reasoning. The model learns to "think" in a long hidden chain of thought before answering, and a key finding was that performance keeps improving the longer it's allowed to think. That's a new way of scaling: spend more compute when answering, not only when training.

Anthropic developed Constitutional AI. Instead of relying only on human ratings, the model is given a written set of principles (the "constitution"). It critiques and revises its own answers against them, and AI feedback based on those principles is used in preference training. I loved this idea because the values are written in plain language, so you can actually read what the model is being steered towards rather than guessing from thousands of individual ratings.

Google DeepMind trains Gemini to be natively multimodal: text, images, audio, and video are part of training from the start, rather than added later. They train on their own TPU chips, which gives them a big hardware advantage.

Meta releases the weights of its Llama models openly. Anyone can download them, fine-tune them, and run them on their own machines. A large share of the open-source AI world is built on Llama, and their technical papers are some of the most detailed public descriptions of how a frontier model is trained.

DeepSeek is the story of the month, and for good reason.

• DeepSeek-V3 (December 2024) uses a mixture-of-experts design: the model has 671 billion parameters in total, but only about 37 billion are active for each token. Think of a team of specialists where only the relevant few work on each question. They reported the final training run took about 2.8 million GPU hours, roughly $5.6 million in compute. That doesn't include all the research and experiments before it, but it's still remarkably cheap for a model this strong.
• DeepSeek-R1 (20 January 2025) is a reasoning model like o1, and they published how they built it. Their R1-Zero model was trained with pure reinforcement learning from the base model, without any supervised examples first. It learned to reason step by step, double-check, and even reconsider its approach mid-answer, just from being rewarded for correct answers. That surprised a lot of people, me included.
• They used an algorithm called GRPO (group relative policy optimisation). The model answers the same question several times, and each answer is scored relative to the group average. This avoids training a separate "critic" model, saving memory and compute.
• R1-Zero's answers were sometimes hard to read or mixed languages, so the final R1 added a small amount of supervised data first, then more rounds of RL and fine-tuning.
• They also distilled R1's reasoning into much smaller open models, which then reason far better than their size suggests.

Ingredients everyone uses

• Synthetic data: strong models generate training examples for other models, which are then filtered for quality. This is now a huge part of post-training.
• Distillation: a large "teacher" model trains a smaller, cheaper "student" model to mimic it.
• Evaluation-driven development: labs build internal tests for every capability they care about and train against them, which is probably the least visible but most important habit.

A caveat

Most of the details are secret, especially at OpenAI, Anthropic, and Google. Papers and model cards describe the outline, not the full recipe. DeepSeek and Meta share much more. So treat this as the shape of the process, not a blueprint.

What I took away

Underneath all the different techniques is one idea in different forms: define what "better" means, measure it, and optimise towards it. Next-token prediction, human preferences, written principles, and verifiable rewards are all just different ways of defining "better."

For my own work, the lesson is that the hard part is rarely the training loop itself. It's the data, the definition of success, and the evaluation. That's true whether you're training a 600 billion parameter model or a small one on a laptop.

At the time it read like a joke from someone deep in the neural network world. Going into 2025, after watching what coding models did last year, I keep coming back to it. Here's what he meant, and how true it has turned out to be.

First, what is gradient descent?

Gradient descent is how neural networks learn. Picture standing somewhere on a hilly landscape in thick fog. You want to reach the lowest point, but you can only feel the slope under your feet. So you take a small step downhill, feel the slope again, take another step, and repeat thousands of times.

In a neural network, the "landscape" is how wrong the model is (its error), and your position is the setting of all its parameters, often millions or billions of numbers. Every step nudges all of them slightly in the direction that reduces the error. Nobody tells the network how to solve the problem. It finds its own way downhill.

Software 2.0

A few months after the tweet, Karpathy expanded the idea in an essay called Software 2.0. His argument went like this:

• Software 1.0 is the code we all know. A human writes explicit instructions: if this, do that; loop over these; call this function.
• Software 2.0 is a neural network's weights. You don't write them. You collect a dataset, define what "good" looks like, and let gradient descent search for a program that does it.

For many problems, Software 2.0 wins easily. Try writing rules by hand for recognising a cat in a photo: pointy ears, whiskers, fur... and then a cat sits in a strange pose, or the lighting is odd, and your rules fall apart. A trained network handles this far better than any handwritten code ever did.

He gave real examples: speech recognition, image recognition, and machine translation all moved from handwritten rules and features to trained networks, and got much better. Google Translate's switch to a neural system in 2016 is a famous case.

What I loved about this idea

It flips what programming means. Instead of writing the solution, you write down what a good solution looks like (the data, the goal, and how you'll measure success) and let the optimiser find the solution.

As someone who has spent years tuning parameters in physics code by hand, that framing really landed for me. The skill shifts from "can you write the algorithm?" to "can you define the problem and evaluate the answer well?"

Now it writes the 1.0 code too

Here is the twist: Software 2.0 now writes Software 1.0. Models trained with gradient descent generate ordinary Python, JavaScript, and SQL that humans can read and run.

Here's roughly how that happened:

2021: GitHub Copilot. Built on OpenAI's Codex, a GPT model trained on public code. It sits in your editor and suggests the next line or a whole function as you type. GitHub's own experiment found developers completed a task about 55% faster with it.

2022 to 2023: chat models. ChatGPT, then GPT-4 and Claude, could write, explain, and debug code from a plain-language description. DeepMind's AlphaCode showed models could compete in programming contests at roughly the level of an average human competitor.

2024: whole projects. Models started editing entire codebases: reading many files, making changes across them, running tests, and fixing their own mistakes. On SWE-bench, which tests models on real GitHub issues, the best scores went from low single digits at the start of the year to solving around half the problems by the end.

December 2024: o3. On 20 December, OpenAI announced o3, a model trained to reason step by step before answering. They reported:

• A Codeforces rating around 2727. Codeforces is a competitive programming site, and this rating would put it among the top couple of hundred human competitors in the world.
• 71.7% on SWE-bench Verified.

It isn't publicly available yet, so these are OpenAI's own numbers. But even with some caution, the trend is hard to ignore.

So is the tweet true?

For contest problems and well-defined tasks with clear right answers: increasingly, yes.

For real software, it's more complicated. Most of the work in a real project isn't typing code. It's figuring out what to build, understanding messy and changing requirements, making trade-offs, knowing the context nobody wrote down, and being responsible when something breaks. Models are very fast and know a huge amount. People still bring judgement and ownership.

There are also real risks: code that looks right but has subtle bugs, security holes, or depends on libraries that don't exist. Reviewing AI code carefully is now a core skill.

How I actually use it

I let the model write the first draft, especially boilerplate, data cleaning scripts, and plotting code. Then I spend my time on the parts that matter: the design, the edge cases, testing, and checking whether it actually solves the problem.

My code has got better, not because I write more of it, but because I review more of it and think more about structure. In a way, I've become a bit of a Software 2.0 programmer myself: my job is defining the goal clearly and judging the result.

I switched most of my own work to Claude this year, so I wanted to understand whether that was just me or a real shift. Here is the timeline, and what I think explains it.

Quick background: who makes Claude?

Claude is made by Anthropic, a company founded in 2021 by a group of former OpenAI researchers, including siblings Dario and Daniela Amodei. Their focus from the start was AI safety: how to build models that are helpful but also predictable and honest.

The first Claude came out in March 2023, a few months after ChatGPT. For most of 2023, Claude was "the other one." It was good at long documents (Claude 2 could read around 100,000 tokens, roughly a full book, in one go), but GPT-4 was clearly ahead on most tasks.

March 2024: the first crack

In March, Anthropic released the Claude 3 family in three sizes: Haiku (small and fast), Sonnet (balanced), and Opus (largest).

A few weeks later, Claude 3 Opus reached the top of the LMSYS Chatbot Arena. This is a public leaderboard where people type a prompt, get two answers from anonymous models, and vote for the better one. Thousands of blind votes add up to a ranking. It was the first time a GPT-4 model had lost the top spot.

It didn't stay there forever. OpenAI responded with updated models, and GPT-4o in May. But the point was made: GPT was beatable.

June 2024: Claude 3.5 Sonnet

This is when things really changed for developers. Claude 3.5 Sonnet was a mid-sized model, so faster and cheaper than Opus, but better than Opus at almost everything, especially code.

What people around me noticed:

• It wrote cleaner code and changed only what you asked it to change.
• It followed instructions carefully, including long, detailed ones.
• It understood whole projects, not just one file at a time.

Anthropic also launched Artifacts alongside it, where Claude shows generated code, documents, or small apps in a separate panel next to the chat. You could ask for a small web tool and actually use it right there. It sounds like a small UI change, but it made Claude feel like a workspace instead of a chatbot.

Around the same time, AI code editors like Cursor took off among developers, and Claude 3.5 Sonnet became the model most people picked inside them. For a lot of programmers, their main daily AI tool quietly became Claude, even if they never opened claude.ai.

October 2024: agents and computer use

In October, Anthropic released an upgraded Claude 3.5 Sonnet. The headline number was on SWE-bench Verified, a benchmark that gives the model real GitHub issues from real open-source projects and checks whether its fix actually passes the tests. Its score jumped from 33.4% to 49.0%, the best published result at the time.

The same release introduced computer use: Claude can look at screenshots of a computer, move the mouse, click, and type, like a person would. It is slow and clunky, and Anthropic called it experimental. But it's the clearest sign yet of where things are heading: from AI that answers to AI that does.

And just last week, Anthropic released the Model Context Protocol (MCP), an open standard for connecting AI models to tools and data sources (files, databases, apps) in a consistent way. I think this will matter a lot for agents.

What I found most interesting is that all of these are skills you need for agents, not just chat: working through long multi-step tasks, using tools correctly, and not breaking things along the way. Anthropic seems to be betting on that future, and so far the bet is paying off.

The numbers

According to Menlo Ventures' report on enterprise AI, published in November 2024:

OpenAI is still ahead overall, but in one year Anthropic doubled its share while OpenAI lost about a third of its own. The same report lists code generation as one of the biggest use cases in companies, which lines up with where Claude is strongest. Amazon also announced another 4 billion USD investment in Anthropic last month, bringing its total to 8 billion USD.

Why I think it happened

1. Coding first. Developers are the earliest adopters and the most demanding users. They pick whatever saves them the most time, and they tell each other. Winning developers means winning the tools built for them.

2. Reliability over flash. For businesses, a model that follows instructions, stays on task, and admits uncertainty is worth more than one that impresses in a demo. Claude's style tends to be careful and direct, which fits real work.

3. Long context. Claude 3 models can read 200,000 tokens at once. Being able to load a whole codebase or a long contract in a single request matters a lot in practice.

4. Thoughtful product choices. Artifacts, Projects (shared knowledge for a set of chats), computer use, and MCP all point the same direction: making the model useful inside real workflows.

To be precise

"Overtook" here means in coding, developer preference, and enterprise momentum. ChatGPT is still far bigger with everyday users, with hundreds of millions using it every week. And OpenAI's o1 models, released in September, are very strong at maths and reasoning by "thinking" longer before they answer.

This race changes every few months, and I wouldn't bet on any lead being permanent. But it has been fun to watch the default choice stop being automatic.

Just like many others, I was surprised the Nobel for physics went to Geoffrey Hinton. My first reaction was: isn't this computer science? But then I tried to understand what physics and maths go behind LLMs, to see why the committee made this choice. This note is what I found. I've tried to keep it readable even if you haven't touched an equation in years.

Why physics, at all?

The answer starts in the 1980s.

Hopfield networks (1982). John Hopfield built a network that stores memories the way a physical system settles into a stable state. He borrowed the idea of energy from physics, specifically from models of magnets where tiny atomic spins point up or down and try to line up with their neighbours. Each stored memory is a valley in an energy landscape. Show the network a noisy or partial pattern, and it rolls downhill to the nearest valley, recovering the full memory. It's like recognising a friend's face from a blurry photo.

Boltzmann machines (1985). Hinton and colleagues took this further using statistical mechanics, the physics of systems with huge numbers of particles where we deal in probabilities, not certainties. A Boltzmann machine learns by adjusting itself until the patterns it generates match the probabilities of patterns in the data. Its name comes from Ludwig Boltzmann, and the core formula is lifted straight from thermodynamics.

So neural networks didn't just borrow a few physics words. Their foundations were built with physics tools. Modern LLMs are much bigger and quite different, but a lot of that DNA is still there.

Step 1: words become vectors (linear algebra)

A model can't read words directly. Text is split into tokens (words or pieces of words), and each token is turned into a vector: a long list of numbers, often thousands long.

You can picture each vector as an arrow in a space with thousands of dimensions. Words with similar meanings end up pointing in similar directions. "King" and "queen" sit close together; "king" and "banana" do not.

From then on, almost everything the model does is matrix multiplication: taking those vectors and transforming them, layer after layer. A large language model is, at its heart, an enormous amount of linear algebra running on GPUs.

Step 2: attention, or "which words matter here?"

The key idea in transformers is attention. For every token, the model asks: which other tokens in this text should I pay attention to?

It does this by creating three versions of each token's vector, called a query ($Q$), a key ($K$), and a value ($V$). Roughly:

• the query is "what am I looking for?"
• the key is "what do I contain?"
• the value is "what information do I pass on?"

The model compares each query with every key using a dot product, which measures how much two vectors point the same way. High overlap means "pay attention." Written compactly:

$$\mathrm{Attention}(Q,K,V) = \mathrm{softmax}\big(QK^\top / \sqrt{d}\big)\, V$$

If you've done quantum mechanics, a dot product as "how much do these two states overlap" will feel very familiar. The $\sqrt{d}$ just keeps numbers from growing too large when vectors are long.

Step 3: softmax is the Boltzmann distribution

This is the one I loved most.

At the end of each step, the model gives every possible next token a score $z_i$. To turn scores into probabilities, it uses softmax:

$$p_i = \frac{e^{z_i/T}}{\sum_j e^{z_j/T}}$$

Now compare that with the Boltzmann distribution from statistical mechanics, which gives the probability of a system being in a state with energy $E_i$ at temperature $T$:

$$p_i = \frac{e^{-E_i/k_B T}}{\sum_j e^{-E_j/k_B T}}$$

It's the same formula, with score playing the role of negative energy. And the "temperature" setting you see in AI tools behaves exactly like physical temperature:

• Low temperature: a cold system sits in its lowest-energy state. The model almost always picks its top choice. Answers are safe and repetitive.
• High temperature: a hot system jumps between many states. The model explores less likely words. Answers become creative, and eventually nonsense.

Seeing a formula from my thermodynamics classes sitting at the heart of ChatGPT made the Nobel make a lot more sense to me.

Step 4: measuring mistakes (information theory)

During training, the model reads real text and tries to predict each next token. To measure how wrong it is, we use cross-entropy loss, which basically measures how surprised the model is by the actual word:

$$L = -\log p_{\text{correct}}$$

If the model gave the right word a probability close to 1, the loss is near 0. If it gave it a tiny probability, the loss is large. This comes from Claude Shannon's information theory, and Shannon's entropy is a close cousin of entropy in thermodynamics. Training is, in a sense, making the model less and less surprised by human language.

Step 5: learning by rolling downhill (calculus)

So how does the model actually improve? Through gradient descent.

Imagine standing on a hilly landscape in thick fog, trying to reach the lowest valley. You can't see far, but you can feel the slope under your feet. So you take a small step downhill, then check again, over and over. That's gradient descent. The landscape is the loss, and your position is the setting of all the model's parameters $\theta$:

$$\theta_{\text{new}} = \theta_{\text{old}} - \eta \, \nabla L$$

Here $\nabla L$ is the slope (the gradient) and $\eta$ is the step size.

The hard part is computing that slope for billions of parameters at once. The method for it, backpropagation, is really just the chain rule from school calculus, applied carefully backwards through every layer. Hinton was one of the people who popularised it in a famous 1986 paper. Modern optimisers like Adam add momentum, a bit like a ball rolling downhill that remembers which way it was going and doesn't stop at every small bump.

Step 6: rotations that encode word order

Attention on its own doesn't know word order. "Dog bites man" and "man bites dog" would look the same. Many modern models fix this with rotary position embeddings (RoPE): each token's vector is rotated by an angle that depends on its position in the text.

When two rotated vectors are compared, the result depends on the difference in their angles, which means relative position comes out naturally. It's the same maths as rotating an arrow in a plane, or the phase of a wave. Physicists use this trick all the time with complex numbers.

Step 7: diffusion and thermodynamics

Image generators like Stable Diffusion use a different kind of model called diffusion models. The idea was inspired by non-equilibrium thermodynamics: take an image, slowly add noise until it becomes pure static (like ink spreading in water), then train a network to reverse the process step by step. To generate something new, start from random noise and "un-diffuse" it into a picture.

I honestly don't understand this part in much detail. The general picture makes sense to me, but the full mathematics of how the reverse process is learned is something I still need to sit down and work through properly. It isn't central to how text LLMs work, but it's another place where physics thinking shaped modern AI.

Step 8: scaling laws look like physics

What I found most interesting of all: when researchers plotted how a model's loss changes as you add more parameters, data, and compute, they got smooth power laws, straight lines on a log-log plot.

$$L(N) \propto N^{-\alpha}$$

Power laws show up all over physics: in phase transitions, turbulence, and earthquake sizes. Seeing one describe how an AI model improves felt strangely familiar. It also changed how labs work. Research from DeepMind in 2022 (the "Chinchilla" paper) used this kind of analysis to show many models were too big for the data they were trained on, and that you should scale data and model size together.

To me, this is the most "physics" part of modern AI: treat a complex system you can't fully explain, measure it carefully, and find the simple law hiding underneath.

So, was it a physics prize?

After going through all this, I think yes, in spirit. The early neural networks were built from statistical physics ideas, and modern LLMs still run on Boltzmann's formula, energy landscapes, information theory, and power laws.

LLMs aren't "just physics." But the toolbox overlaps far more than I expected, and it makes me feel a little less like I'm changing fields and more like I'm applying the same thinking somewhere new.

The object

In general relativity, a very heavy star that collapses under its own gravity usually forms a black hole, with an event horizon that hides everything inside. But some theoretical models, such as the JMN-1 spacetime, end in a naked singularity instead: an extremely dense core without a horizon. Studying what happens around such objects helps us ask whether everything we call a "black hole" really is one.

Real objects in space are rarely alone; they usually sit in magnetic fields. Those fields shape how charged particles move, and they play a big role in things we can actually observe, such as jets and bright glowing matter near the centre.

How it started

I was working on a different topic. In one of our research meetings, someone pointed out that the way I had defined the magnetic field around JMN-1 might have a flaw. That comment stuck with me, so I started digging.

Searching around, I found a paper by Mustapha Azreg-Aïnou that described a cleaner way to set up magnetic fields in this kind of spacetime. I used his method and managed to solve the first part of the problem myself. Then I did something I wasn't sure I should do: I emailed him, asked him to check whether my approach was right, and asked for his insight on a part involving Legendre polynomials (a family of functions that show up whenever you describe how something varies with angle around a sphere).

He replied, we started talking, and together we solved the problem in about three weeks. Within six weeks we had a draft ready for arXiv. It is probably the quickest project I have worked on.

What we found

In simple terms: JMN-1 is built by matching a region filled with matter to the empty space outside it. We found that part of the magnetic field jumps suddenly at that boundary, which means an electric current has to flow along the surface there. Yet when we looked at charged particles colliding near the boundary, the collision energy stayed smooth across it.

The paper was later published as JMN-1 singularity in weak magnetic field in the European Physical Journal C. The preprint is on arXiv.

The lesson I took from it: a critical comment is a gift, and a polite cold email to someone whose work you admire can go much further than you expect.

First, what does "GPT" mean?

Generative Pre-trained Transformer. Each word tells you something:

• Generative: it produces text, one piece at a time.
• Pre-trained: it first learns from a huge amount of general text before being used for anything specific.
• Transformer: the type of neural network underneath.

The transformer came from a 2017 Google paper called Attention Is All You Need. Its key idea, attention, lets every word in a sentence look at every other word and decide which ones matter for understanding it. In "The cat sat on the mat because it was tired," attention is what helps the model link "it" to "the cat." Older models read text strictly left to right and struggled with long-range connections like this. Transformers handle them well and can be trained in parallel on GPUs, which turns out to matter a lot.

GPT-1 (June 2018): pretrain, then adapt

OpenAI's first GPT paper was titled Improving Language Understanding by Generative Pre-Training. Back then, the usual approach was to build a separate model for each task (one for sentiment, one for question answering) trained on labelled data, which is expensive to collect.

GPT-1 proposed a two-step recipe:

1. Pretrain a transformer on lots of unlabelled text with one job: predict the next word. They used a dataset of around 7,000 unpublished books.
2. Fine-tune it on a small labelled dataset for each specific task.

The model had about 117 million parameters (the adjustable numbers it learns). Tiny by today's standards. But the lesson was big: a model that learns general language first needs much less task-specific data later. That "pretrain first, adapt later" idea became the template for almost everything that followed.

GPT-2 (February 2019): "too dangerous to release"

GPT-2 kept the same idea and scaled it up: 1.5 billion parameters, trained on about 40 GB of web text (pages linked from Reddit posts with some upvotes, a clever way to filter for quality).

Two things stood out:

• It wrote coherent text. Give it a fake news opening, and it would continue with paragraphs that sounded plausible.
• It could do tasks without fine-tuning. Ask it to translate or summarise with the right prompt, and it would try, even though nobody trained it for that specifically.

OpenAI initially released only smaller versions, worried about misuse like spam and fake news, and released the full model in stages through the year. Some people called it hype. Looking back, it was the first time a language model became a public debate, not just a research result.

GPT-3 (2020): learning from the prompt

GPT-3 jumped to 175 billion parameters, trained on hundreds of billions of words from the web, books, and Wikipedia. The paper's title says it all: Language Models are Few-Shot Learners.

What I found most interesting here is in-context learning. You could write a few examples directly in the prompt:

sea otter => loutre de mer
cheese => fromage
peppermint =>

and GPT-3 would continue with "menthe poivrée." No retraining, no new data. It figured out the task from the pattern in the prompt. Nobody explicitly designed this ability. It appeared as the model got bigger, and it was weak or absent in the smaller versions.

GPT-3 was offered through an API, and a lot of early AI startups were built on it. A version fine-tuned on code, called Codex, became the engine behind GitHub Copilot.

The missing step: making it helpful (2022)

Raw GPT-3 was powerful but awkward. It would continue your text rather than follow your instructions. In early 2022, OpenAI published InstructGPT, trained with human feedback to follow instructions. A striking result from that paper: people preferred answers from a 1.3 billion parameter InstructGPT model over the original 175 billion parameter GPT-3. Size isn't everything; alignment with what people actually want matters a lot.

That same recipe, applied to a GPT-3.5 model with a chat interface, became ChatGPT in November 2022.

GPT-4 (March 2023): more reliable, and it can see

GPT-4 brings two big changes:

• Much stronger reasoning. OpenAI reports it scores around the top 10% of test takers on a simulated bar exam, where GPT-3.5 was around the bottom 10%.
• Image input. It can take a picture along with text, such as a chart, a photo, or a hand-drawn sketch, and reason about it. This isn't widely available yet, but the demos are impressive.

It is also better at following instructions and less likely to make things up, though it still does. It can handle much longer inputs too, up to around 32,000 tokens in one version.

Something new this time: OpenAI's technical report doesn't reveal the model's size, data, or training methods, citing competition and safety. That alone tells you how much the field has changed since 2018, when the whole recipe was in the paper.

The real story is scaling

The training objective barely changed from GPT-1 to GPT-4: predict the next token. What changed was the amount of data, the number of parameters, and the compute behind it.

In 2020, OpenAI researchers also published scaling laws: the model's error drops smoothly and predictably as you increase model size, data, and compute. That gave labs the confidence to spend huge amounts on training bigger models.

As a physicist, I find this surprising. You'd expect such a simple objective to hit a wall. Instead, new abilities keep showing up as the scale grows. I loved going back through these papers because each one looks modest on its own, and only together do you see the curve.

It makes me want to understand why it works, not just that it does.

I've been playing with it a lot, so here is my attempt to explain what it is, why it suddenly feels so different, and where it still falls short.

What is it, in plain words?

At its core, ChatGPT is a language model: a program trained to predict the next word in a piece of text. Give it "The capital of France is" and it predicts "Paris." Do this one word at a time, feeding each prediction back in, and you get whole paragraphs, essays, or code.

That sounds too simple to be useful, but to predict the next word well across millions of documents, a model has to pick up grammar, facts, styles of writing, and even some reasoning patterns. All of that gets stored in the model's parameters, which are billions of numbers adjusted during training.

ChatGPT is built on a model from OpenAI's GPT-3.5 series. So the raw ability isn't new. GPT-3 has been around since 2020, and developers have been building on it through OpenAI's API.

So what changed?

Two things: how the model was tuned, and how it is presented.

1. It was trained to be an assistant

A raw language model is not trying to help you. It just continues text. Ask it a question, and it might answer, or it might write five more questions, because that's what often follows a question on the internet.

To fix this, OpenAI used a method called reinforcement learning from human feedback (RLHF). Their blog post describes three steps:

1. Show it good examples. Human trainers wrote conversations, playing both the user and the assistant. The model was fine-tuned on these to learn the format of being helpful.
2. Teach it what "better" means. The model wrote several answers to the same prompt, and trainers ranked them from best to worst. A separate reward model learned to predict those rankings.
3. Practise against the judge. The language model was then trained with reinforcement learning to produce answers the reward model scores highly.

Think of it like training a new employee: first you show them examples of good work, then you give feedback on their drafts, and they slowly learn your taste. The same team used this approach earlier this year for InstructGPT.

The result is a model that answers the question you asked, admits mistakes when you point them out, pushes back on false assumptions, and declines some harmful requests. None of that is perfect, but it changes the experience completely.

2. It's a chat box

This is the part I find most interesting. Before ChatGPT, using GPT-3 meant an API key, a "playground" with sliders for things like temperature, and carefully engineered prompts. Now it's a text box. You type like you'd text a friend, and it remembers what you said earlier in the conversation, so you can say "make it shorter" or "now explain it to a 10-year-old."

It reminds me of how the web browser didn't invent the internet but made it usable for everyone. The technology was there. The interface let normal people in.

What I've noticed so far

Where it shines:

• Explaining concepts. I asked it about the Penrose process and frame dragging, and the explanations were surprisingly clear for a first pass.
• Small coding tasks. Little Python scripts and plotting code often run on the first try.
• Rewriting and summarising. Emails, abstracts, and making messy notes readable.

Where it worries me:

• It is confidently wrong. It can invent references that don't exist or get maths subtly wrong, and it sounds exactly as sure when it's wrong as when it's right. OpenAI says this openly in their own list of limitations.
• It depends on phrasing. Ask the same question two ways and you can get two different answers.
• It doesn't know recent events. Its training data stops in 2021.
• It's already causing problems. Stack Overflow temporarily banned answers generated by ChatGPT a few days ago, because so many plausible but wrong answers were being posted.

My rule for now: treat it like a very well-read friend who sometimes bluffs. Useful for a first draft or explanation, never the final word.

Why I think this matters

For the first time, talking to a computer in plain language feels normal. My guess is that every big tech company will want its own version within months, and new kinds of work will appear around checking, evaluating, and building on top of these models.

I don't think we go back from here.

First, an honest answer

Machine learning is not calculating energy extraction for anyone. The Penrose process, the magnetic Penrose process, and the efficiency numbers we publish all still come from solving equations in a known spacetime. What ML is doing is helping with the hard parts around that calculation, and that turns out to matter a lot.

1. Measuring spin, the energy source

Every energy extraction mechanism feeds on the black hole's spin. No spin, no ergoregion, no Penrose process. So the most important number is also one of the hardest to measure.

What I found most interesting is a 2020 paper called Deep Horizon. The authors trained neural networks on around 100,000 simulated images of black holes surrounded by glowing plasma. The networks then learned to read off the mass, the accretion rate, the viewing angle, and even classify the spin from a single image, with uncertainty estimates attached.

With the Event Horizon Telescope images of M87* (2019) and now Sgr A* (May 2022), this suddenly feels very real. A network that can look at a shadow and say "this one is spinning fast" is directly useful for asking how much energy could be extracted from it.

2. Making simulations cheaper

The realistic version of energy extraction involves magnetised plasma swirling around the black hole, which needs huge general relativistic magnetohydrodynamics (GRMHD) simulations. A single run can take enormous amounts of computing time.

Here ML can act as an emulator: train a network on a set of expensive simulations, and it learns to predict the outcome for new parameters almost instantly. That means you can explore far more combinations of spin, magnetic field, and accretion than brute force would ever allow.

3. Solving the equations themselves

Physics-informed neural networks (PINNs) take a different route. Instead of learning only from data, the network is trained so that its output satisfies the governing equations directly. People have started using this idea for problems in general relativity, including solving for spacetime geometries. It is still early, but I love the idea of the physics living inside the loss function.

Where I see it helping my own work

In my papers, a big chunk of the effort is scanning parameter space: how does the efficiency change as spin, charge, magnetic field, or a deformation parameter changes? Right now that is careful grids and a lot of plots. A model that learns the efficiency surface, or flags the interesting regions to look at more closely, could save weeks.

My feeling is that the physics will stay the core, and machine learning will become the tool that helps us measure, simulate, and search faster. I want to learn it properly.

The Penrose process, simply

A spinning black hole drags space around with it. Just outside the horizon there is a region, called the ergoregion, where this dragging is so strong that nothing can stay still; everything is forced to rotate with the black hole.

In 1969, Roger Penrose noticed something surprising. Imagine throwing a rock into the ergoregion, and the rock splits in two. One piece falls into the black hole in a special way that effectively carries negative energy. The other piece flies back out carrying more energy than the original rock had. The extra energy comes from the black hole's spin, which slows down a tiny bit. You have taken energy out of a black hole.

Why it still matters

The original idea is not very efficient, but its descendants are central to black hole astrophysics:

• The magnetic Penrose process adds magnetic fields and can be far more efficient. It is one way to explain how black holes power extremely energetic particles.
• The Blandford-Znajek mechanism, an electromagnetic cousin of the same idea, is a leading explanation for the huge jets we see shooting out of galaxies with spinning black holes at their centres.
• The collisional Penrose process looks at particles smashing together near a black hole, which can reach very high energies.

What we asked

Some theorists have proposed objects that look almost exactly like spinning (Kerr) black holes from the outside, but avoid the infinitely dense point at the centre. We call them black hole mimickers. We asked: if you run the Penrose process around them, does anything change?

For one family (Simpson-Visser spacetimes), the answer was no: the efficiency matched a normal Kerr black hole. For another family (conformally transformed spacetimes), the efficiency was clearly higher. That difference could, in principle, help tell a mimicker apart from a real black hole.

Looking back, this paper taught me how research actually works: a lot of patient calculation, a lot of plots that don't work the first time, and the quiet joy when they finally do.

What the title means

In general relativity, gravity isn't a force pulling on things; it is the shape of spacetime itself. Objects simply follow the straightest possible paths through that curved spacetime. Those paths are called geodesics.

• Null geodesics are the paths of light.
• Timelike geodesics are the paths of anything with mass: particles, planets, or a spaceship.

So the thesis was really about one question: how do light and matter move around very dense objects?

What I learned about

• Black holes, both non-rotating (Schwarzschild) and spinning (Kerr), where I wrote Python notebooks to trace particle paths.
• Naked singularities, extremely dense objects without a horizon to hide them.
• Wormholes, including a metric proposed by Juan Maldacena and Alexey Milekhin in their paper on humanly traversable wormholes. It was a thrill to work with a spacetime from a paper by one of the biggest names in theoretical physics.

Shadows and precession

Two ideas from the thesis have stayed with me because they connect theory to things we can actually observe.

Shadows. Light that passes close to a black hole can be bent, trapped, or swallowed. The result is a dark patch surrounded by a bright ring, which is exactly what the Event Horizon Telescope photographed. The size and shape of that shadow depend on what the central object really is, so a naked singularity or a wormhole could leave a different shadow from a black hole.

Orbital precession. An orbit around a massive object doesn't close perfectly; the whole ellipse slowly rotates. Mercury does this around the Sun, and it was one of the first tests of Einstein's theory. Stars orbiting the centre of our galaxy do it too, and the amount of rotation depends on the geometry close to the central object.

Put together, shadows and precession give us a way to ask a deep question with real data: is the thing at the centre of our galaxy really a black hole, or something that only looks like one?

This thesis is where my research journey really started, and it led directly to my first paper a few weeks later.