Intensive Teaching · September 2026

The most important things

Before: Join the Iliad Discord and check you can see #intensive-september. That is where you post any material you need to share with participants. If you can't see it, tell Leonard (@leonardbereska on Discord).
During: At 17:40, make sure everyone fills out the feedback form.
After: Fill out the end-of-day log: rate the day and tell us anything that went wrong.
Fill out Who stood out: name anyone who made a positive impression.

Questions about pay, travel, logistics or materials: see the FAQ.

57 project proposals are open for review. Stars, a sentence, or both. Read them.

Your days

[C.1]ML Engineering Mon 7 Sep, leading 41 responses · energy 3.9/5

Overall +0.05 as expected

Content -0.02 as expected

Clarity -0.07 as expected

Motivation +0.02 as expected

Exercises -0.29 below expected

Readings 0.00 as expected n = 9

Other activities -0.05 as expected n = 21

Pace +0.17 about right

Difficulty -0.32 too easy

Novelty -0.29 mostly review

Read what they wrote77

Worked well27

I enjoyed the lessons before the last hour acceleration.
I really enjoyed Julians talk!
thinking through the design of the adam optimizer together was fun
I liked that the teaching was interspersed with exercises
It was nice to have a bit of time at the beginning of today to meet the other participants.
meeting the other participants and lunch was good, i think this was roughly the main purpose today?
Talking to people was useful and getting to know everyone.
Socializing was great.
The introductions were very nice, I enjoyed chatting with a series of participants one-on-one.
The hands on exercises and the capstone project.
I appreciated block-diagrams and examples. It would have been useful to introduce notation in the presentation deck, instead of having to ask and receive that information orally.
Intro to ML lecture was delivered very well.
Discussions to get to know people.
The networking with prompts
Lecture split with exercise sessions allowed to not get tired thanks to context switching. Also the breaks. The slides were good as well, albeit not sufficient for proper explanations, but that's perhaps too harsh for the overview.
- claude capstone project was very enjoyable, best part of the day - socialising/ ice breakers were effective, met nice people and didn't feel awkward/ intense as some forced ice breakers can be
Good and quick recap of things to get us warmed up
Stopping frequently during lectures for exercises and relaxation.
The short interactive parts are good, both to break up the flow, but also to get people thinking on their own, which always helps learning. The conversations during the first half of the morning were very good for getting to know people. Different formats could be beneficial to have more varied interactions (i.e. discussions in smaller groups (of 3/4/5 ppl)), and these might be better matches for some of the questions/prompts given, but these would let you get to know more people faster (which becomes more important the bigger your cohorts become).
I enjoyed the get-to-know each other in the beginning. I really enjoyed the ML fundamentals lecture, I think it was very well prepared and understandable and engaging.
The questions from the audience and answers from the lecturer were great.
Open questions to class, the Claude sessions
It was good that we spent some time introducing ourselves to each other. I gained a lot more clarity on the background of other participants, and their motivations for the intensive/fellowship.
Having a small group to learn the basics of Claude Code
I liked the exercises format. Both the claude code ones and the notebook ones.
The claude code exercises were good, although not described a priori very well.
I thought Adam explained a lot of the features of Claude Code and coding agents really well, and I got a lot of clarity on a few things I didn’t know as much about initially.

Would improve31

Better explanations of technical concepts (such as transformer architecture), and I would have enjoyed a deeper (perhaps more formal) approach when it comes to teaching in general. I think that there was not a great time control. No time for solving the exercises, and I think the socializing exercises took too much time.
Sometimes when the group was split, it was unclear what the options were regarding the possible choices. Discussion games at the start could've been improved a bit, but I think the main restriction was the room shape. Would've been nice to mix a bit more, and maybe having another in the future where you talk to other people would be useful.
maybe scale down the introduction part in the morning and split the intro to ML into 2 sessions, by the end of the ML intro I couldn't focus on the content which was still very interesting just due
Adam was great, but I don't think the "claude basics" activity was super useful. I felt like it was an intro to vide coding, but I think it would've been useful to go from the very start to the paper replication and getting hints as to how this could be done efficiently. Learning about worktrees whilst doing this project would've been more valuable.
I found the today's content very helpful but I felt like it went too fast. I think I would've appreciated if the same content was instead spread over two days. As someone who had a low level understanding of about half the content before hand I would've liked a bit more of a chance to work through exercises and have the instructors roaming around for questions.
I think choosing between ML fundamentals + Claude Code intro is not the most ideal - naturally I wanted to cover everything so chose the former which left less time for the latter. I wonder if the first half of the day (intro stuff) could be shortened, or start an hour earlier, to fit in both?
We were given a couple of choices today for what material we could learn. I think it would have been helpful to know in advance what was going to be covered, as there was a bit of a rush to decide (and without really know what would have been done in each session). I did the ML basics in the afternoon, but in hindsight, I think intro to Claude would have been more useful for me. My answers below reflect the fact that I did the ML basics, parts of which felt fairly familiar. I think it might just be difficult for people to choose, so I'm wondering if it'd be possible to compress the ML basics / intro to Claude so everyone gets to do both? I felt the "try to get Claude to replicate the paper" exercise was a bit less helpful. Perhaps it could have been helpful to have a bit more guidance on this part (what would be the "best practices" way of doing this)?
If you put formulas on slides explain the terms (what is the sum over, what is y and what is y hat). I would prefer to do deeper reading over a rather superficial lecture. Smaller group size would help for that.
The Reinforcement learning section was somewhat too quick, I would have spent some more time on that.
It felt that the ML/AI intro was not too well structured. Arguably, that's a common problem for many such intro classes. E.g. RL was surely too math-y compared to the beginning, and perhaps not as relevant in fact to RLHF (or the model lifecycle is not relevant to "intro to ML"). I also felt that there is a real discrepancy in participants' knowledge (it was to fast and superficial for those who didn't know it before; boring for those who already knew), so it seems reasonable to run a small test in the morning of the first day and then split into groups where the intro would be more targeted. Also, it looked like the diagrams in the presentation were a bit rough (in my experience it was similar to unpolished tikz code generated by a model). Finally, it may be worthy to emphasize that this is not academic setting anymore, so people should not be afraid to give wrong answers -- at times there was a bit of awkward silence. Socializing part was cool, but the room is too small for 40 people talking simultaneously, so it was overwhelming.
I'm not sure if I got very much out of the Claude Code session. I learned a little more about how it works, and a few handy tips, but nothing that I expect to really transform the way I use it. This may be my fault for choosing said session; I already use Claude Code quite a lot and was at least somewhat aware of most of the features we covered. So my only pedagogical suggestion is probably the session could've been a bit shorter. Working through the exercises was mostly a matter of waiting while Claude ran, only a little bit of the time was spent trying new things.
Claude code exercises are poorly explained and assume a lot of prior experience using claude code.
The session in the morning designed to get to know each other was way too long in my opinion. After the session, there was also a break and lunch which achieve the same objective. Because we spent all morning on this, the afternoon session was a bit rushed. I would try to include a part of the afternoon session into the morning.
It's better for Claude Code exercises to have more structure and well-defined goals to verify your abilities upon. Another way to approach it is to build it around designing skills and workflows yourself. Yet an exercise should incentivize the participants to do it.
Voice projection. Unfortunately, it was very difficult to hear instructions when organising the introduction rounds, or to understand when there were breaks. Regarding the lecture: a poll among participants well before the course would have saved awkward hand-raising moments to decide what to cover, or how to distribute groups and in which rooms.
I would not do the 'intro to claude code' vs 'intro to ML' split - I think it would be better if everyone does the same thing so it doesn't feel like you are missing out on an option.
Pace could be a bit slower. Temperature in the room is too low.
Improve the pedagogical value of the Claude Code exercises. I didn't feel like I knew what I was supposed to do. Most of it was guess work and hoping things would work. The paper replication is the same. Some guidance would have been interesting instead of simply saying "reproduce figure 3 in this paper". The use of the research project template itself was not well introduced. Slow it down, narrow the scope and pass a cleaner message.
While I appreciate that this intensive needs to cover a lot of (rapidly evolving content), I think the speed at which the fundamentals were covered clearly divides our cohort into those who are more theoretically-oriented with almost no AI or coding experience and those that have used AI tools.
Define the variables in all equations or include on slides
I think I was missing a clearer vision of what will be taught in the fours weeks, this week, and today in particular, how this fits within Iliads vision, what we want to take away from this etc. With the afternoon exercises on agents, I think I would have benefited from a sort of best/good practice for agentic coding. the exercises were nice to get us working straight away, but it was often only through questions or confusions that better workflows became clear to me
Desk placements (happy to help with moving them around!) into more of a school / uni structure (facing the lecturer). Clearer outline of what we would be missing out on if choosing to attend one session rather than the other / choose one exercise rather than the other. Ideally to announce such choices beforehand so we can say skim over the materials and decide in a more improved manner [Generated by my FOMO]. Also the air conditioning over the tables closer to the door make it chilly, and not just if you are under it -- I would switch it off for the afternoon sessions.
- would be nicer to have lecture notes, especially ones that are clear. since this is an earlier program, it makes sense this doesn't exist. suggestion: look for volunteer scribes? you can ask for 2 volunteers per day and get claude to smush it together (although i would put high emphasis on creating lecture notes which don't read as ai generated, this is very off putting) - similarly, it would be nice to sort of do a pass over any slides / material. i think using models to create materials is efficient and fine, but one should do a pass over it or use it to create a skeleton as reading something that reads as "claudish" can be similarly off putting
Introduce motivation of something with pictures during the slides. Sometimes it was not clear. Rest was great. Especially the discussions during the lecture and the exercises.
Simply too little time. I think it's worth extending to get everyone up to speed. This naturally depends on the coming days and in what way they rely on deeper understanding of today's material. Also, the people who most need a break are (generally speaking) also the people who would most benefit from the excercises, i.e. they are the people with the least prior experience. Please keep this in mind when offering for people to solve the excercises during the breaks.
We were given a choice between different exercises/different lectures (either ML fundamentals or Claude Code, and then either Claude Code capstone project or exercises). I found it difficult to choose. I think I didn't have enough information to make an informed decision. It would have been useful to know more precisely what each of the options would entail beforehand!
The introductions parts were working fine without suggestions on what to talk about with each other. Otherwise everything perfect.
Perhaps a more targeted course (i.e. covering less topics), and have people read the prereq. material one week earlier! The Claude exercises were fun, but there were some small API topup issues
More time for exercises. But maybe this will improve in the coming days, because this was just the first day.
The lecture for the ML basics lecture was too rapid for me. I understood what I already knew, and not the concepts I didn't know. Maybe less time for people to try and come up with various gradient descent algorithms from scratch. There are lots of reasonable answers, hard to converge on momentum etc.
I worked through the CC exercises with Adam. While I appreciate that the exercises were a substrate for learning about CC, it felt a bit strange to work through knowing that frontier models can probably one-shot these exercises with no need for e.g. subagents. It might have been cool for the exercises to really show the power of these techniques if possible.

Changed my mind14

Being the first day, got to know other points of view about AI safety, from other participants. Discovered other AI safety institutions and interesting career paths.
n/a
I was expecting today to learn in depth the transformer architecture. Instead we spent a lot of time on basics. I also expected to work on the exercises and set up claude code with vs code before but there were other necessary setups eg GitHub that we were not informed of in advance. Overall I would have learnt more by working through the transformer material on my own and spent rest of the day on the exercises.
n/a
Claude Code in VSCode is a bit clunky
No
1. Gradient descent was improved heuristically rather than mathematically (Newton's method) or physically (energy-based approaches which give smth similar to Newton). 2. That is sometimes does happen that an input from the engineer leads to an improvement (RoPE giving better results than basic encoding) -- which is not how it usually works.
n/a
Not yet
Yesterday night I was feeling very anxious and feeling like an impostor, and I thought the atmosphere at Iliad would be much more competitive, I was happy to find out that I needn't have worried about that!
Attention as a mechanism is more complex than I thought.
Not really yet!
I should get familiar with coding agents
N/A

Other thoughts5

no
n/a
1. Do I need to say in advance if I need to take a call at 17:00? Can I book the box in the Iliad building ? 2. I cannot attend Friday 11th and need to leave at 17:45 on Thursday.
Ad question on exercises: I only really did one exercise (pair programming with someone) - implementing the SGD update. I thought that was pretty easy but I actually learned that you cannot do self.params = self.params ... so that little exercise was very helpful!
I will have a doctor’s appointment on the 14th to forewarn I may not be able to attend in the morning.

[C.2]Mechanistic Interpretability Tue 8 Sep, leading 41 responses · energy 3.7/5

Overall +0.27 better than expected

Content +0.27 better than expected

Clarity -0.27 below expected

Motivation +0.27 better than expected

Exercises -0.15 as expected

Readings -0.25 below expected n = 16

Other activities -0.20 as expected n = 30

Pace +0.68 too fast

Difficulty +0.54 too hard

Novelty +0.63 mostly new

Read what they wrote78

Worked well22

I think the lecture was great, I liked that there were questions to the audience, and I also love the questions from the audience, they are often very thought-provoking. I think the lecturer does a great job answering questions and I also respect his epistemic honesty. And he is enthusiastic which makes it easier to keep paying attention
discussion with peers helped clarify concepts
I really enjoyed the overview of Mechinterp - It was really helpful for me to get a good overview of the area so I can go and learn more about what i'm interested in.
I think the explanations of the topics, and then going on to neuronpedia to actually see it in real models was helpful. I also thought that the exercise of thinking about the induction circuits was helpful
Some more intuitional explanations, motivations, discussions with pears
playing around with Neuronpedia was good to show us how poorly mech interp techniques can work. I didn't find any of the techniques particularly convincing, and maybe that's a good thing.
Julian is a very good lecturer and that helped to understand new and more complicated topics
The initial discussion was well motivated, and examples given were useful.
The first half of the day established the basis of the field very well .
It was a good intro to Mech Interp, covering a broad range of ideas, older and newer. It’ll definitely help anyone choosing to learn more about any topic in mech interp.
The mixing of theory and practice. The exercises were quite interactive, that helped switching. The slides were quite comprehensive and informative, with references etc. Very good job with the slides I'd say
It was easy to find the source articles on the slides
I liked the transformer circuit thinking exercise
Some small exercises with coding part were great. It's valuable to at least sometimes do them yourself without deferring everything to coding agents. Discussions were great as well.
Doing the exercise about the attention with key, queue value adn hearing the explanation of a colleague.
Interactivity.
The coding exercises in pairs were really useful. The fact that we can spend a big chunk of time asking questions is really good too.
the pair programming exercise on logitlens, understanding circuits through concrete examples and trying to understand how queries and keys are combined from different tokens and how positional encoding of the tokens play a role here.
teaching and slides were great!
The teaching.
I'd previously seen most of the material from auditing the ARENA course, but working through the exercise on K-composition vs Q-composition clarified things for me a lot, so that was good.
The pair coding exercise was the most helpful part of the day. It was very nice.

Would improve32

I would have preferred a slightly more rigorous, in depth coverage of fewer topics. Having said that, I think the lecture was great given how much material was covered
I think the pace was a bit too fast today, I think it's just too much material to fit in one day. I was already familiar with many of the topics covered today, but I imagine for someone without that background it must have been quite difficult to follow.
I think more time for the exercises would be nice.
Great content - just felt slightly rushed for 1 day; I think 2 mechinterp days are probably worth it given how central the field is (vs. some of the more esoteric areas covered).
Overall, I thought that the day was well structured and well done. Pretty small thing, but I think I would've enjoyed spending a bit more time on the fuzzy interp stuff, and perhaps slightly less on the early CNN stuff (though I suppose this was already quite short).
Pictures on slides are small and hard to see, but I pulled the presentation on computer so that helped
Seems like reducing the number of slides from 140 to maybe <100 might be a good idea, and then spend more time explaining the most important results. Some parts went way too fast. Usually, if you spend 30 seconds on a slide, its best to remove it. I find the K and Q-composition circuits are better understood when you make each component appear sequentially instead of all at once. You can also draw it on the board and describe what each component is doing. The Q-composition exercise was not very clear.
The material is very interesting, but perhaps too compressed, I would reduce the material (especially on some of the latter part of the lecture) and leave space for a longer coding session! I find that coding the algorithm yourself helps a lot with understanding.
This was a lot of material for one day. I'd split it in two.
It would be nice if the lecturer repeat the questions because you can't hear them well if you are in a corner of the room
As a broad survey it seemed good to me, although of course I probably don't know about anything you chose to leave out. There were a couple occasions where I struggled to follow this "why is it done this way"/"why does this property matter", so possibly there is room for pedagogical improvement in terms of how to introduce and motivate the core concepts? Or possibly this is irreducible complexity and one must start somewhere. Also, it felt like there was very little time for any exercises today. This may be because we asked too many questions during lecture, so perhaps a worthwhile tradeoff.
I think I would skew the content more towards fundamental concepts such as feature and circuits so that they are explained in more details.
Like yesterday, the time is simply too short. This is worse than yesterday as we had a full day of teaching.
1. The position of the laptop that connects to the monitor ends up forcing the lecturer to stay in front of the slides, covering them. The laptop stand should be moved to the side, to the right most likely (the whiteboard on the right can be moved even more to the right as well). 2. Needed more mixing up theory and practice. The interludes with neuropedia were great and gave an opportunity to switch the brain from theory to practice. 2.5. I felt lost at the long SAE section where we did go in depth of too many approaches. Perhaps a brief overview of each would be enough, as otherwise gives mental overload. 3. J-lens wasn't represented on the slides, only mentioned briefly in the end. 4. The breaks should be separated by 45 mins tops. I think a survey / poll on Discord or WhatsApp would be great about the maximum acceptable interval between breaks. We might also create a button for breaks -- during the lecture, if people feel tired they can "push" the button, and once it gets pushed by more than 33% or 50% of the audience, we have to stop in the next 1-2 or 5 mins. 5. To add on the subject of breaks: right now we have 2.5 hours before lunch and 4 hours after to study, which makes it imbalanced and calls for a big break (at least 20 mins) during the afternoon session. 6. In-depth explanations should employ the whiteboard more, or be more example / exercise driven I guess. As it gets literally hand-wavy, but that's perhaps the hardest to improve
Some places around the class are not well suited to see clearly what happens at the board so if possible it would be great to find a disposition that allows more people to sit in front of the teacher.
I would spend some more time on the circuits in transformers and look at some explicit examples on the board. Exactly how the features were used in the IOI or ACDC, the final attribution graph circuit and the motivation did not feel clear. I would also have benefit from some more explicit (low level) examples in the identifying SAE features section, though I'm not sure how feasible that is. I didn't find the exercises useful in understanding the presented material, more for understanding how to code various bits (which is fine if that was the purpose).
Even though I knew a lot from the material today, I find the pace uneven: too much time is spent on simpler or older concepts, while more complicated or/and newer ideas and methods are rather skimmed through. It is not clear what is the pedagogical goal of the day: is it to give a historical perspective of the field? to explain the basics? explain the latest developments? I think that stating a clear priority would help with shaping the material. Going quickly over complicated concepts towards the end of the day increases mental load and disengages from following. It might be beneficial to simply go slowly and drop the volume of the material. Then, even though the excitement is clearly communicated, there's always this thread about uselessness of mechinterp. I understand that it is reasonable to give a realistic assessment of the state of the art, but it demotivates quite a bit.
Non physicist opinion: be more mathematically precise or tell me when you are not attempting to; define all notation on slides (x_i: what is the i?) Include more practical exercises like the transformer thinking exercise The coding exercise in the morning was bad: the google notebook was too slow, and i mostly struggled with syntax (which felt artificial and not helpful to learn) General: 1. Maybe try to screen participants more strongly for caring about AI safety? I feel that some are just here because of trying to ride the general AI hype wave (not crazy sure about this, just an impression). 2. facilitate more socializing (city tour, etc)
A bit more attention to universality and corner cases will be great. I suppose it's fine to introduce most known concepts / approaches and skip some (like cross-coders etc.), and leave them as links for interested people to explore. What can be most valuable is sharing knowledge about some corner cases, limitations and reasons methods might not work instead. I.e. something that is hard to extract and summarize from papers and which requires lecturer's experience and opinion. I might be slightly biased as I'm at least familiar with the field, and I suppose that perspective of someone less familiar will be different.
- Put the course material in one channel, and then in the messages mark the day and the topic. - Be clear what mathematical topics will be explained in detail and if not where to find resources on the ideas. Some of the formulae and proof I could not follow.
Dense slides, hard to follow if you don't already have a reasonable background.
Better than yesterday. Teacher seemed a little bit more prepared.
A lot of material was covered, sometimes at the expense of depth. It was not always clear when results were robust or cherry picked.
I personally need two weeks to do this two day bloc, and it would still feel intense. Perhaps a series called "Iliad Fundamentals" could also be introduced, where each run lasts two weeks and does an intense deep-dive into specific topics covered in the Intensive.
More paired coding exercises. These were super valuable. We also had a decent amount of time to complete this so it didn't feel rushed.
more hands on things and i liked the parts where students are asked to explain something.
- overall very good, would be nicer to have easier access to slides, notes, etc i.e is the https://iliad-team.github.io/iliad-intensive/ website going to be updated? i think something like this which has direct link to readings, slides, exercises, notes would be nice - teaching was very well done
Overall I think Julian did an amazing job of covering a lot of material in a short length of time and the teaching was great. I think the demos could be improved as it was not super clear how to use e.g. Neuronpedia. Perhaps instead of breaking into pairs this could be demo'd to the group as a whole (and still be interactive for people to guide the prompting etc.).
I think the lecture (and lecturing!) were really very good - although I can imagine the pace would have been very difficult for someone not already familiar with the material. I think some of the precise mathematical statements of results could be corrected. Naturally the statements have to be abbreviated for clarity, but for example, the statement on the Compressed Sensing slide (s58) is clearly false as written.
I enjoyed the content we covered today but I felt like we went too fast. Especially during the second half of the day I felt like I was accumulating lost-ness. I really enjoyed the pair coding and would love to have much more time dedicated to exercises (not just the breaks). I feel like my capacity for new content will grow as we go through the month so I think I would benefit from less content, more examples in the first week.
We went really quickly through the slides.
The redirections to neuronpedia were great. It might have helped to include at least one slide explaining what to look for. Same applies to the many graphics (which looked awesome btw).

Changed my mind17

not too interested to mech interp anymore
I have a clearer idea of what is mechanistic interpretability and I find it really interesting as a potential line of research I would like to work in.
I am new to the filed and I found the topic interesting and worth learning about
Mech interp seems less promising than I thought. SAEs seem pretty useless, most features looked uninterpretable.
I realized probes could be a very promising direction to study.
I have a much more detailed understanding of what's up with mech interp now, but I think my overall feelings about it are roughly the same.
Maybe was a bit discouraged that mech interp will be “successful”.
I did note down quite a few insights, but I am spent for today, no tokens left
I have a clearer view of what we call a feature in MechInterp
It might be that I underestimated some method's promise, and i.e. NLAs, if done properly, might be useful overall.
No
I previously had the impression that mech interp was more rigourous than I do now. A lot of techniques seemed to work in some instances and fail in others, without a clear explanation of why.
I am not super convinced on the utility of mech interp for safety but I think it's valuable that someone is pursuing this.
became slightly more pessimistic about mech interp but more about the other parts of ai safety coming up next :)
n/a
I was a little surprised to hear about how unreliable mechanistic interpretability methods are, which makes me a little less likely to consider research in this field as opposed to another subfield of AI safety.
I discovered the sota of Mech interpretability, its limitations and directions. Maybe worth considering for my future career.

Other thoughts7

Today's lecture was much better paced, and pitched at a better level.
nope
I had a hard time finding the slides. It appears one of the two links to slides on this page was broken: https://iliad-team.github.io/iliad-intensive/interpretability/mechanistic-interpretability/ links to both https://raw.githubusercontent.com/iliad-team/iliad-intensive-C.2/main/lectures/output/main.pdf (404 error) and https://iliad-team.github.io/iliad-intensive/downloads/mechanistic-interpretability/mechanistic-interpretability-slides.pdf (loads, but I think was missing some slides vs the lecture)
This is actually such a great experience, I love being here among the peers. Thank you guys for making this happen, I hope it goes smoothly!
it would be nice to have more desk space, especially orient the desks so its a lecture form and they all roughly face the front?
n/a
Apologies for arriving late today! It was an unexpected delay resulting from my train being redirected, but I'll set off earlier from now on to avoid it happening again.

The day

10:00 Lecture starts

12:30 Lunch at LISA

13:30 Afternoon session

17:40 Feedback form

18:00 Day ends. Dinner at LISA

When	Where
Mon 7 Sep	LISA, 25 Holywell Row, London EC2A 4XE
Tue 8 – Mon 14 Sep	23 Curtain Road, London EC2A 3LT
From Tue 15 Sep	69 Wilson Street, Moorgate, London EC2A 2BB

Resources

Elsewhere