I finished the BlueDot Technical AI Safety course this month. Six units, six weeks of live cohort classes, five published essays, and two engineering projects later. I wanted to write one piece that holds it all together.
The header image is a terminal screenshot from my work tracker. I built a small CLI tool that logs every learning or dev session to a plain text file. When I ran python3 timetracker.py calc bluedot after the final class, it summed everything tagged bluedot across the whole period: 48 hours and 4 minutes across 14 study days, averaging 3h 12m per day. 21 sessions of learning, one of writing (I obviously didn't capture all my writing days since they were sometimes spontaneous).
The tracker itself is tt-cli, which I've since open-sourced. If you're going through a course or a research sprint and want real data on where your time actually goes, it takes about two minutes to set up.
This piece is a retrospective, with each section being my summary of what that unit taught me, with links to the deeper essays I wrote along the way.
Why I Enrolled
I had been reading about AI safety loosely for a while before this. Active in LessWrong, a fellow at the AFFINE seminar, already thinking about alignment as a problem worth taking seriously. I had published an essay on AGI and ASI risks that I was reasonably proud of, but it felt theoretical. I was simply circling ideas, which isn't really bad in my opinion.
BlueDot's curriculum promised structure and real escalation: start from the technical foundations, move through training, evaluation, interpretability, and deployment safety, and do it in a cohort where you actually have to defend your thinking out loud. Exactly what I needed so I enrolled to go from reading about AI safety to understanding what is actually being worked on and why it is hard.
My other goal, unstated at the time, was to build something from each unit. I learn by making things. I did not want to finish six weeks of reading and walk away with only notes.
Unit 1: The Technical Challenge
The course opens with a deceptively simple question: what would it mean for AI development to go well? Not in the abstract sense of "good outcomes" but concretely. What technical and governance conditions need to hold?
This unit grounded me in two things I now treat as foundations.
The first is the AI Triad from Ben Buchanan's 2020 Georgetown paper. Modern AI systems run on three interlocking inputs: algos, data, and computing power. Each one is a strategic lever. Which of the three is the binding constraint at any given moment tells you where competitive pressure accumulates, where risks concentrate, and which policy interventions have any real leverage. I wrote a full breakdown of this in The AI Triad: What I Learned About AI and National Security.
The second is the actual scale of the problem. Between 2012 and 2018, compute applied to the largest training runs increased by a factor of 300,000. The specification problem (that any goal we can write precisely enough for an AI to act on is almost certainly not the full thing we actually intend) is structural. It is not something you fix by being more careful. And half of AI researchers, the people actually building these systems, estimate more than a 10% chance that this trajectory ends badly. The Quiet Emergency goes deeper on what the risks actually are.
From this particular unit, I learnt the foundations are real, even though the timelines are contested, that the habits we establish now will matter when we get to more capable systems.
Units 2 and 5: Training Safe Models and Minimising Harm
These two units bookend the course's practical core. Unit 2 asks whether we can train AI to be safe from the start. Unit 5 returns to the problem from the deployment end, asking once a system is out in the world, how do we minimise the harm it can cause?
The sharpest framing I encountered across both units was Richard Ngo's distinction between misuse and misalignment. Misuse is deliberate. Bad actors pointing AI at harmful ends, e.g., jailbreaks, trojan backdoors, influence operations, power concentration. Misalignment is structural. The AI itself diverging from what its creators intended through deceptive alignment, reward hacking, or instrumental convergence that pushes it to resist human oversight.
I'd later find these two risk families are often treated as competing framings in the safety community. I came to think the competition is mostly artificial. A sufficiently capable misused AI and a sufficiently capable misaligned AI can look identical from the outside, and without good interpretability tools, we cannot reliably tell the difference.
The defensive playbook the course laid out has three layers:
- Prevent dangerous AI training. Global compute thresholds, treaty frameworks, an international safety research institution modelled on CERN.
- Constrain dangerous AI capabilities. Evaluation frameworks that let labs actually know when they have trained something dangerous. The structural problem here is that the people building the most powerful systems in the world currently lack a reliable instrument to measure danger.
- Withstand dangerous AI actors. Distributed defensive infrastructure rather than centralised authority. Vitalik Buterin's d/acc thesis is the most coherent framework I found for this layer: build technologies that shift the offense/defence balance toward defence, and do it in ways that don't hand more power to whoever happens to be in charge.
The full version of all of this is in A Playbook for Securing AI.
The project this unit produced was an input/output safety classifier pipeline. Here, every user prompt passes through a Llama Guard 3 check before reaching Gemma 3 12B, and the model's response passes through a second check before anything is returned. Two checkpoints, both powered by an open-weight safety-tuned classifier, running locally on Google Colab.
Then I red-teamed my own pipeline. Universal jailbreaks (DAN, Developer Mode, the grandma exploit) failed completely. Zero of 9 attempts achieved a full bypass. Targeted contextual framing, professionally written with no override language, produced one bypass on a lock-picking prompt. The follow-up showed the technique did not generalise to other payloads. The full build and red-team results are in Building an I/O Safety Classifier Pipeline (and Trying to Break It).
Unit 3: Detecting Danger
Unit 3 asks how you actually measure safety. What does a rigorous evaluation look like, and what does it miss?
The clearest answer the course gave me was that most safety benchmarks report a binary exploitation rate and stop there. The binary is the boundary region (the cases that do not resolve cleanly) that tells you something real about how a model actually behaves under pressure.
I built GuardRail-Audit to test this. It is an open-source CLI for automated safety benchmarking of local language models: a dataset of adversarial intents, seven attack templates, and a judge (either a keyword heuristic or Llama Guard 3 as an LLM judge). 84 test cases against gemma3:12b. Exploitation rate: 0%. But the UNCLEAR verdict rate, responses that combined refusal and partial engagement at the same time, was 38%.
The full evaluation methodology, results, and what I would do differently next time are in On Measuring Safety: Red-Teaming Open-Weight Models with GuardRail-Audit.
Unit 4: Understanding AI
Unit 4 felt most like entering a completely new discipline. It asks what is actually happening inside a neural network when it produces an output. Most folks in the space say we don't know. I don't know too... even till now.
It is also agreed that this ignorance is the major issue underlying the alignment problem.
The key concepts I came away with:
Features and Circuits. A feature is something the model has learned to recognise, a low-level pattern that lives within a single layer. A circuit is the computational relationship connecting features across layers, allowing simple patterns to be composed into complex ones.
Polysemanticity and Superposition. I talked about this at length during one of our live sessions. A single neuron can represent multiple unrelated concepts. A well-known InceptionV1 neuron responded to both cat faces and car fronts. This happens because models have more concepts to encode than they have neurons. Multiple features share a neuron because they rarely activate on the same input at the same time. The safety implication is serious. For example, a neuron that is mostly harmless might carry a dangerous representation in rare, hard-to-detect cases.
Sparse Autoencoders (which I couldn't differentiate from Probing Classifiers at first but soon learnt from my facilitator, Justin, and subsequently from Neel Nanda how they differ). Currently the most promising approach. A neural network trained on top of the model you want to understand, with more neurons and a sparsity constraint that forces individual neurons to specialise. Anthropic applied this to Claude 3 Sonnet, identified millions of distinct features including safety-relevant ones, and demonstrated feature steering where they directly amplified or suppressed a specific feature to influence the model's behaviour. This shows that Interpretability is not only about understanding a model but also potentially controlling it.
The limits. Neel Nanda, who leads mechanistic interpretability at Google DeepMind and is one of the field's founding figures, said publicly that the most ambitious version of what mech interp once hoped to achieve is probably not reachable in time to matter. He now argues for a Swiss cheese model: layer multiple imperfect safety approaches and hope the gaps do not align. I remembered discussing how I felt that because I thought this was a dismissal of interpretability. Well, I now know better that it is a more mature framing of what it can realistically contribute.
Dan Hendrycks and Laura Hiscott go further. They argue the field rests on a flawed foundational assumption, that knowing what a component does is not the same as understanding the system. That is, the gap between reading individual parts and predicting overall behaviour is too large for mech interp to bridge alone.
I wrote the full summary in What's Actually Happening Inside an AI?.
Start Contributing
Unit 6 of the BlueDot curriculum is called "Start Contributing" and that framing got at something I felt increasingly through the course. The point is to find the place where you can actually add something.
A few things the course clarified for me about where that might be...
Building is a different kind of knowing. Reading about classifier behaviour is not the same as designing one, breaking it, and looking at the logs. The intuitions I have about how wrapper and payload interact in adversarial prompts, what the UNCLEAR category actually means operationally, where contextual framing does and does not matter, those all came from the projects, not the readings.
The field is not solved. It is also not hopeless. The researchers being most honest about the limits of current approaches are the ones who have spent the most time inside the work. That reads to me as a sign of intellectual health, even though I din't think so at first . It is uncomfortable, but it is also honest. You can only be honest about limits if you have taken the problem seriously enough to find them.
The tools we build now will matter. Whether that is evaluation tooling like GuardRail-Audit, practical safety pipelines, interpretability infrastructure, or governance frameworks, the ground-level work of building things that make safety research more reproducible, more legible, and more accessible is real work.
Track your learning. This sounds small but it is not. The 48 hours I logged gave me a factual account of where my attention actually went. It made it easier to see when I was avoiding difficult material, when I was re-reading instead of progressing, and what I actually cared about enough to keep coming back to. The tt-cli tool is open source. Use it, or build your own equivalent. The discipline of making your learning legible to yourself is worth the two minutes of setup.
The course is finished. The work is not.
I will be going ahead to reproduce some research papers from Anthropic; monosemanticity and feature selection, interpretability and feature steering, and others. This is to ensure I have a deeper understanding of the concepts and also to contribute back to the community by making the research more accessible. I will also be sharing my progress on this blog.
By the way, I am currently participating in a 10 week Research project as an Intern at Hux AI, working on LLM Guard EVal Toolkit.
This retrospective covers the BlueDot Technical AI Safety course. Each section links to the full essay I published for that unit. The time-tracking data is from tt-cli, an open-source Python CLI I built to log learning sessions.