This is a summary of the months of January and December. I read some technical papers about LLMs and some cross disciplinary topics like radiology. However, I realised that I need to learn more about conducting research. I looked at some guides and recommendations from other researchers based on their experience and career. There were lots of great blogs and articles. I already follow some of the advice, and some of it was things I probably wouldn’t have thought of on my own. I will discuss what I have learnt and how I intend to apply it to my own life. As I usually do, I’ll put all the links to the material at the top of the page.
Papers Read
2025-12
- Taking AI Welfare Seriously by Long et al. (2024)
- Concrete Problems in AI Safety by Amodei et al. (2016)
- A sketch of an AI control safety case by Korbak et al. (2025)
2026-01
- Performance of GPT-5 vs GPT-4V for radiological image analysis by Brin et al. (2026)
- Ethics and Governance of Artificial Intelligence for Health: Large Multi-Modal Models. WHO Guidance by World Health Organization (2024)
- Emergent Misalignment: Narrow finetuning can produce broadly misaligned LLMs by Betley et al. (2026)
Research blogs
- How I Think About My Research Process: Explore, Understand, Distill by Neel Nanda (2025)
- My Research Process: Key Mindsets - Truth-Seeking, Prioritisation, Moving Fast by Neel Nanda (2025)
- My Research Process: Understanding and Cultivating Research Taste by Neel Nanda (2025)
- Highly Opinionated Advice on How to Write ML Papers by Neel Nanda (2025)
- Tips for Empirical Alignment Research by Ethan Perez (2024)
- How to Find Research Problems by Jason Eisner (1997)
- How to Read a Technical Paper by Jason Eisner (2009)
Here’s what I’ve learnt about doing research
I’ve mostly been reading papers and trying to understand the landscape of AI safety. That’s useful, but I realised that I was spending a lot of time doing research without actually getting better at it. It’s easy enough to justify reading another paper, but it’s a whole other ball game compared to designing an experiment, testing a hypothesis or working out which question is actually worth your time. I was looking for advice from people who’ve done this at a high level, and I found that there was a lot of crossover between sources written years apart and from very different parts of the field. For example, Neel Nanda was writing about mechanistic interpretability at DeepMind, Ethan Perez on empirical alignment at Anthropic, and Jason Eisner on NLP research at Johns Hopkins back in the late 90s.
A Framework for the Research Loop
Nanda’s approach to framing was really useful, talking about how research moves through phases: explore, understand, distill. When you’re exploring, you’re basically building a map – running cheap experiments, collecting clues and coming up with lots of hypotheses. When you’re in the understanding phase, you move on to testing: designing experiments to see which hypotheses are right and actively trying to disprove your best-looking story. When you distil things down, you take all the info and boil it down to a few key points that you can stand by. The key point to remember is that a lot of research failures come from doing the wrong kind of work for the phase you’re in. If you’re still exploring but already defending a single theory, you’ll miss things. If you’re testing hypotheses but keep running interesting experiments that don’t actually settle anything, you’re just spinning your wheels.
I can see this pattern in myself. When I started reading about alignment, I spent weeks getting into the zone and building a mental model, but I wasn’t asking myself any testable questions or putting my understanding to the test. Nanda and Eisner both say the same thing: don’t spend forever on background reading without doing your own thinking. The solution isn’t to stop reading. The idea is to switch it up by asking “what would I actually test next?” and to keep a short list of open questions rather than letting the backlog get out of control.
Three ways of thinking that are worth keeping
Nanda talks about three ways of thinking that should go hand in hand with whatever phase you’re in: looking for the truth, sorting out what’s important and getting things done quickly.
The hard part is always trying to see things as they really are, because we all have our own biases. You naturally gravitate towards evidence that supports your hypothesis and away from evidence that doesn’t. When it comes to truth-seeking in business, it’s best to keep an open mind and not jump to any conclusions. Just ask “What’s the simplest boring explanation?” before you get carried away. Ask “what would I see if I’m wrong?” and actually look for that. When you’re doing case studies, it’s better to take a few from each group than to pick the ones that back up your point.
Prioritisation is all about knowing that the main problem isn’t that you’re not doing enough work. It’s that you’re doing a lot of work that’s not really useful, instead of the few things that actually matter when it comes to making decisions. Perez makes a similar point: if your iteration loop is slow, almost everything else becomes irrelevant. I liked the practical test Nanda’s best: If I only had two days left on this project, what would I do? Whatever the answer is, there’s usually a version of it you should be doing right now.
Being quick doesn’t mean being sloppy. Basically, it means reducing unnecessary waiting times by creating environments where you can try out ideas without much risk, testing them out first on a small scale, and running experiments to see if they’re working before committing to the full version. The right speed includes deliberate pauses for reflection, but these should be intentional, not the result of poor tooling or unclear next steps.
Building Taste and Finding Problems
I was pretty surprised by Nanda’s claim that you can learn to make “research taste” decisions, like what to explore, what’s noise, and what experiment will actually be decisive. It’s not some kind of magical talent. It’s all about getting the feedback right, and often the issue is that the feedback loops just aren’t quick enough. You can speed things up by making explicit predictions about what will happen, doing post-mortems when you’re surprised, and keeping a research log that you actually revisit.
Eisner’s advice on finding research problems fits in well with this. He sets out a range of contribution sizes, from copying existing work (which is useful for education and a good starting point) to coming up with completely new problems. The key point to take away is to watch out for random choices and “harmful simplifications” that everyone just accepts without question. Keep your eyes peeled for places where people say something is important but nobody’s really tried it properly. Take a look at what went wrong with real systems and turn those into research questions. These are often where you’ll find easy, valuable problems.
Reading papers more easily
Eisner also changed how I think about reading. His multi-pass method is pretty straightforward: skim first for shape, then read carefully where it matters. But the best thing about it is that he encourages you to write while you’re reading. This means you can restate unclear points, generate examples and counter-examples, connect to other work and propose follow-ups. Read creatively, not just critically. Instead of just asking “is this right?”, try asking “what’s the good idea here, and where else could it be used?” I’ve started doing this with a simple note template: one-paragraph summary, key claims, evidence quality, confusions, and an “if I were continuing this work…” section. It takes more effort per paper, but I get way more out of it and I actually come up with ideas instead of just taking them in.
Here’s what I’ve learnt
If I had to distil everything into a handful of habits and questions, it would be these:
-
Before I start work each day, I think about what I want to learn or establish, and what the fastest experiment would be to settle it. If I’m stuck, what observation would quickly kill this idea?
-
After each experiment, I need to think about what I predicted, what actually happened, and what the difference between the two tells me about my judgment.
-
Weekly: I need to work out where I’ve been wasting time and what the most important question is for next week. So, when you’re reading a paper, you should ask yourself: what’s the good idea here, and where else could it be used?
-
When I’m working on a design for an experiment, I’m always trying to keep it simple. But what if the hypothesis is wrong? What would I see in that case?
The lesson we can learn from all of these sources is that research skill is mostly about what you choose to do next, not how clever you are at any single task. As time goes on, things like prioritisation, tight feedback loops and honest self-assessment all add up. I’m still at the start of my research journey, so I’m building these habits now to save myself time and effort in the long run. The advice from Nanda, Perez, and Eisner is pretty similar, even though they’re from different eras and subfields, which makes me trust it more. These aren’t just their own preferences, they’re patterns that keep showing up wherever research works well.