• https://substack.com/home/post/p-188586887

Epistemic Status: Reflections from a one-month project sprint. I wrote this with Neel Nanda's post on how to become a mechanistic interpretability researcher heavily in mind, so I highly encourage skimming that first. This isn't a fundamentally new framework; rather, it's empirical validation from my own recent experience.

I participated in BlueDot’s Technical AI Safety Project Course

What this course is: A focused sprint to publish a technical AI Safety project in roughly 30 hours, all while receiving weekly direct mentorship from an AI Safety expert.

Why I decided to apply: I’m currently heavily focused on AI Safety field-building in Japan. (You can find my broader community-building project details here). I am planning to organize and scale my own mentorship initiatives. As Neel argues, mentorship is key. I figured the highest expected value way to understand the ingredients of a high-quality program was to experience a great one firsthand as a mentee.

Project Overview

Because the core focus of this post is my experience with the mentoring program itself, I won't dive too deeply into the technical weeds of my project here. But briefly:

My underlying model of the problem is that AI models might employ deceptive strategies as a form of scheming or misaligned behavior, and relying solely on output monitoring (the black-box approach) is vastly insufficient.

For the course, I focused on this work by Apollo Research, which demonstrates that a simple linear probe can distinguish between honest and deceptive internal states. We extended this methodology to evaluate Japanese models and datasets.

• Key Finding: We observed that performance degraded significantly when the probes were applied to Japanese models.

If you're interested in the actual research, I wrote up the full details of my work here.

How the course went (Logistics & Impressions)

The structure heavily indexes on agency. Participants scope, pitch, and drive their own independent projects.

• Weekly Check-ins: We had 1-hour sessions with our mentor and fellow participants to share progress and give feedback.
• High attrition rate: Only 2 out of 6 people in my group actually completed the course. I suspect people just get too busy and deprioritize the work. My intuition here is that we desperately need mechanisms to address this if I organize a similar program. For example, TARA uses a financial commitment bond—participants pay a deposit of around $60 before the course, which is only refunded upon successful completion. This is a highly promising hack for accountability.
• 1-on-1 Mentorship (Optional): Participants can proactively request 1-on-1s. Crucially, you aren't bottlenecked by your specific cohort mentor; BlueDot provides a diverse pool of expert mentors you can ping for feedback or quick sanity checks. The conversations aren't strictly bounded by the project either—seeking general career advice is highly encouraged. I personally scheduled one session, and it was valuable. Organically finding mentors is notoriously one of the hardest parts of entering this field.

What I’ve learned from the course

1. Managing Cloud GPUs: Setting up the environment taught me a lot about compute costs, configuration, and instance selection. I wrote up my specific learnings on Cloud GPUs here (in Japanese).

2. The Research Workloads: Getting my hands dirty completely updated my priors on what kind of work is needed and how much effort it actually takes.