TLDR: LASR Labs is a 13-week research fellowship in London to train technical talent for AI safety. I was a LASR Fellow during the Winter 2026 cohort (January to April) and did an extension from May to August, and it was one of the most rewarding experiences in my career. I'm writing this retrospective because I found few first-hand accounts about LASR when I was an applicant and fellow, and I hope this post reaches people who are interested in applying/enrolling. 

This post is structured around what I wish I'd known before joining LASR (admissions, program structure, overall experience, and some advice). I've left out the extension phase for now, but may write about it later.

LASR applications are open now. You should consider applying if you’re interested in technical AI safety research.

My Background

Before joining LASR, I was a third-year undergrad at Boston University’s Faculty of Computing & Data Sciences. I was also involved in co-founding and organizing an AI Safety & Alignment student org at my university. I have a website that has more info. After LASR, I’ll be doing MATS and interning with Redwood Research.

Application

Recently, applications for some AI safety programs have gotten some criticism for being exhausting (1 and 2), but I think the LASR application process was streamlined and pretty reasonable. I estimate that I spent ~12 hours applying for LASR, and most of this time was spent preparing for intermediate application stages. My application had four stages over two months: an initial application (~60 minutes), a conceptual research test (70 minutes), an ML assessment on CodeSignal (60 minutes), and a final interview (30 minutes).

The CodeSignal assessment was the only stage I actively prepared for: I spent roughly seven hours reviewing lecture notes from the ML courses I was taking at the time. This was mostly a wasted effort since the content I reviewed did not appear on the assessment. In hindsight, my time would’ve been better spent preparing for the conceptual research test. For that, I'd recommend reading this CG article on reasoning transparency, this EA Forum article on feedback for researchers, and Michael Aird's Theory of Change Workshop (video, slides, worksheet).

I suspect that applicants who demonstrate context (and to a lesser extent, involvement) in AI safety are more likely to fare well in the selection process, especially in the conceptual research test. I consider programs like SPAR, MARS, ARENA, CBAI, and BlueDot to be useful for this. Familiarity with past literature, having well-formed takes, and doing independent projects are also useful.

In my opinion, the application process was fairly anti-credentialist. Several fellows in my cohort were senior SWEs or held PhDs, but early-career fellows were represented in roughly equal numbers.^[1] In the Winter cohort, I was the only fellow without a bachelor’s degree (still in progress), although I know a few more fellows in the Summer cohort who were completing their bachelor’s degree when offered a position. I also know several undergrad applicants to previous cohorts who had advanced to the final-round interviews but did not receive offers. Although the admissions process seems competitive, the initial application is quite short, and I encourage you to apply even if you feel underqualified.^[2]

Working at LISA

LISA hosts many AI safety orgs (Apollo, IAPS, Arcadia Alignment Team) and fellowships (PIBBSS, Pivotal, Iliad, Anthropic Fellows). The opportunity to work alongside the AI safety community at LISA was one of the main reasons I chose LASR over my counterfactual AI safety opportunity (which was a similar fellowship hosted elsewhere), and I think this was a really good decision in hindsight. 

At some point during my extension, LISA opened several annex spaces to increase capacity and moved several members (including the LASR extension fellows) into them. Although I only spent a few weeks there, I really enjoyed my time at the LISA annex office. I’ve heard that LISA is moving to a new office soon, which may mean these annexes will close.

The density of AI safety talent at LISA makes for a serendipitous environment. There’s lots of diversity in what people are working on, including (various forms of) policy, technical governance, forecasting, technical research (interp, control, evals, agent foundations, etc.), journalism, startups, and more. LISA also hosts a few socials each month (some are also open to non-LISA members), which are very low-friction for meeting people outside your typical circles.

In general, LISA members are approachable and there’s a high degree of openness. I've met two collaborators through lunchtime conversations and social events. And more broadly, I suspect finding collaborators, mentors, or co-founders can happen semi-passively. 

On weekdays, LISA was busy and crowded, but on weekends the office was maybe 10% occupied. The weekends were quieter and people who were in the office were less pressed for time (me included), so incidental conversations tended to be more enjoyable and unhurried. On the weekends, I’ve had many fond conversations and made memorable friends. If you’re somebody who already works on weekends,^[3] I strongly recommend coming into the office rather than working from home!

LISA hosted several speaker events during my time there, but I refrained from attending many talks because they overlapped with the hours when I'm most productive and I was reluctant to step away from project work. Of the talks I did attend, some of the most noteworthy speakers were Will MacAskill, Daniel Kokotajlo, Ryan Kidd, Marius Hobbhahn, Ryan Greenblatt, and Buck Shlegeris. Before deciding whether to attend a talk, I would often ask myself “does this overlap with my direct research interests?”

But this was a bad filter. I think that AI safety runs on tacit knowledge and undercirculated signals about where the field is heading. Knowing what other researchers think about a problem is valuable metaknowledge, sometimes as useful as the object-level answer itself. 

For example, I self-selected out of many governance-related talks and conversations because they weren't relevant to my research project at the time. But much has changed since then (in AI capabilities, in the world, in my career) and I would benefit from having more context on governance now. These speaker events are a good source of information. Consider attending many (but not all) of them.

Overall, I think LISA is an incredible environment. The ops and admin staff at LISA are super well-organized and friendly, and deserve lots of credit for making this environment special.

Project Selection and Week 0

LASR differs from most fellowships by admitting fellows directly into the program rather than into a particular stream, meaning that project selection happens after admission. As a result, the admission process is more efficient, since there are no stream-specific questions, and fellows are well-informed when selecting projects because they evaluate the proposals themselves before choosing. Project proposals and selections happen during Week 0. More information about this is available on the LASR website.

The schedule below gives a reasonable picture of Week 0. Each stream proposes two projects in a one-hour meeting. Fellows have one or two days to ask questions about each proposal (as comments on a Google Doc) and mentors have one or two days to respond. Each stream also holds a Q&A session to resolve lingering questions, but those sessions are short, so posting questions on the Google Doc is strongly encouraged. Additionally, there are several workshops and talks throughout the week to inform project selection and fellows’ theories of change. The workshops were useful for recapping recent developments in AI safety and discussing timelines and theories of change, though probably less useful for fellows who already have a lot of AI safety context, for example from reading LessWrong regularly or having done a previous fellowship like MARS.

Week 0 mostly involves processing a heavy barrage of information and trying to retain details, which can become tedious and boring. But I still enjoyed the workshops (many were interactive), meeting the other LASR fellows, and hearing their opinions on the projects. However exhausting Week 0 may be,^[4] I think it’s clearly better than the alternative of writing responses to stream-specific questions, which bloat admissions processes and give applicants far less information about their projects.

By the end of the week, I noticed that there was a near-consensus about which projects were good and which were bad (when evaluated by tractability, impactfulness, or mentorship style). Since each mentor proposes two projects but only supervises one, the project that’s least popular is always dropped. There were two or three projects/streams that were widely liked, and picking projects outside this set was considered unusual.

I think it’s surprising that everybody converged on the same two or three projects, since all projects were clearly well-developed, proposed by mentors who probably have good epistemics and coherent theories of change, and then reviewed by the LASR organizers. Moreover, all six projects from the Winter cohort turned out ~well and overall project success and satisfaction seem uncorrelated with initial popularity in Week 0. Considering this, I think that a project’s popularity among the cohort is weak evidence of its success and impactfulness. For incoming fellows, I would warn against information cascades and groupthink when selecting projects. Please consider selecting projects according to your own opinions about the project’s tractability and theory of change rather than deferring to what others think. Also, selecting projects based on mentor fit, your post-fellowship goals, and building career capital is underrated IMHO.

By the end of Week 0, fellows sort the projects into three tiers, where Tier 1 projects are the most appealing and Tier 3 the least. Once you’ve determined which projects are interesting, I would recommend being extremely parsimonious about which projects are assigned to Tiers 1 and 2 (e.g. assign ≤3 projects to Tiers 1 and 2). I was too permissive with my rankings and didn’t get matched to the projects I most wanted.

Structure

The 12-week research phase begins immediately after Week 0 and is structured similarly to other research fellowships. The recurring commitments are:

• A 20-minute individual meeting with the RM to discuss your career progress or address general concerns about how things are going. Weekly or fortnightly. 
• A 1.5-hour block composed of the following contiguous meetings:
  • A 15-minute meeting with your Research Manager (RM) to review the past week's progress and prep for mentor meetings. Weekly.
  • A one-hour team meeting with the mentor(s) and RM to ask questions, get advice, etc. Weekly.
  • A 15-minute meeting with the RM after the mentor meeting to review feedback and set goals. Weekly.
• Occasional workshops offering advice on writing and research. Approximately every three weeks.
• An optional reading group covering mostly general ML topics rather than AI safety specifically. Weekly.

LASR requires each team to submit a paper draft by the end of the fellowship, which is unlike many other programs. In my opinion, this requirement is best understood as a forcing function for developing a coherent thesis and identifying key results instead of a mandatory publication target. Across all LASR teams, these drafts were not used for dissemination and every team continued to develop their papers afterward to post on arXiv or for workshop/conference submission. Since I planned to work on an entirely different project after the main phase, I think this deadline helped prevent open-ended iteration.

Since “write a paper” is an awfully broad target, the research phase was divided into four-week trimesters, each of which loosely defined what teams should be working on. Apart from a deliverable submitted at the end of each trimester, there were no hard requirements on how teams should spend their time, and each team tended to move at its own pace.

• Weeks 1 through 4: Conduct exploratory research. Deliverable: A short presentation which states the headline result and main claims and shows preliminary results.
• Weeks 5 through 8: Run any additional experiments to build a coherent thesis and begin writing the paper. Deliverable: A paper draft which will be reviewed by other LASR fellows.
• Weeks 9 through 12: Wrap up experiments, finalize the paper’s main claims, send drafts to external researchers, and iterate on their feedback. Deliverable: The paper submitted to LASR.

Working with Research Managers (RMs)

Mentor meetings generated a lot of unstructured feedback, but RMs were particularly valuable in specifying weekly plans at the level of individual tasks. When faced with uncertainty, for example, my team would sometimes tend toward some vague plan like “look into X and think about Y,” but our RM would help us determine tractable tasks and give feedback on which tasks ought to be (de)prioritized. They also helped in less visible ways, such as helping us communicate our progress and expectations with our mentor.

Also, the one-on-one career advising meetings were very valuable to me.^[5] RMs are deeply invested in your career outcomes after LASR and are happy to make introductions within their networks, write LORs, and/or help you find post-LASR opportunities. I recall one RM staying late on a Friday evening to help a team hit a submission deadline, and the same RM providing me with feedback on a grant application for my LASR extension.

My team worked with three RMs throughout the research phase, and my experience with each was very positive. In my opinion, working with RMs significantly improved my experience at LASR.

Working with Mentors

All mentors are full-time researchers who work at safety organizations such as UK AISI and Apollo or on safety teams at frontier labs. Mentorship style is highly variable, but all mentors commit to a weekly one-hour meeting at minimum. I estimate that roughly half of the mentors were involved in day-to-day work (e.g. reviewing results as they came in, being active on Slack most days), while the other half participated on an as-needed basis or largely through the weekly meeting.

I think that neither style is obviously better, but mentorship will be a large determinant of your overall experience, so it’s probably good to account for each stream’s mentorship style when submitting project preferences.

Working with Teammates

Fellows are organized in teams of three or four, and LASR puts heavy emphasis on collaboration. In my own team of three, our working arrangement was very fruitful.

LASR claims that teams are formed so that their members collectively have heterogeneous skillsets. In my team, one member had several years of software engineering experience and the other was a recent PhD graduate, so working alongside them was a valuable learning experience for me. Thirteen weeks of close collaboration tends to produce fast friendships, which certainly was true of my team! I also made good friends among fellows on other teams, but by a wide margin I spent the most time with my own. Shout out to Oli and Nic!

LASR designates one lead team member for each project, and fellows indicate whether they want to be considered for the role during Week 0. The lead team member is mainly responsible for administrative work, such as preparing slides for the weekly meetings, but they’re not expected to provide additional contributions as a researcher or author (i.e. these are not the same responsibilities expected of a first author). Leads are nonetheless listed first in the byline by default, though in most cases the whole team shares equal-contribution first authorship. Not being the lead team member also has some advantages, especially in being exempt from the admin tasks!

I had never worked on a long-term team project, and LASR’s team structure partly drew me to the program over my counterfactual AI safety opportunity. In retrospect, it was among the most rewarding parts of my LASR fellowship. For prospective applicants and admits, I consider the team structure on its own a strong reason to consider LASR.

Random Advice

I basically think all the advice given in Boyd Kane’s MATS retrospective and Ethan Perez’s Tips for Empirical Research is relevant, so please consider giving both a read. Additionally, here are a few pieces of advice that were useful to me and that upcoming LASR fellows should consider. 

Produce a Paper Draft or Outline (Very) Early

Our mentor encouraged my team to produce a workshop-style draft by the second or third week. Our earliest draft held placeholders for pending experiments, reported minimal results, and only vaguely articulated the main contributions. Amid our first attempts to get oriented in the project and understand relevant literature, drafting felt premature and took time from initial experiments, which we believed to be the obvious priority. Meanwhile, other teams had gone straight to experiments and found promising results; so maybe we had set the cart before the horse?

When we started running experiments in the following weeks, the draft became more valuable. It was straightforward to weigh potential experiments against our narrative and determine how a given result should fit into the paper. We never felt beholden to the draft and still pursued digressions when they were interesting, but there tended to be a higher bar for accepting experiments into the paper. Relatedly, this helped us identify holes in our argument quickly rather than discovering them once the project was coming to a close.

Because we merged new results periodically, we could spend the final weeks backfilling and tightening prose rather than constructing a narrative from scratch. And throughout the program, no deadline ever felt too soon because having an early draft helped pace our research.

Parallelize Aggressively and Communicate More Than Feels Necessary

Fast iteration and efficient team collaboration will be cornerstones of your experience at LASR. An efficient team may produce far more in thirteen weeks than three individual researchers. The prerequisites for efficiency are being able to parallelize tasks among team members and being able to communicate progress to team members.

Try to carve out tasks such that interdependencies are rare. This is especially straightforward in the final weeks, when there are plenty of disjoint tasks and you’ll likely find one team member (re-)running experiments, another improving prose, and a third designing figures. 

The temptation to run experiments serially is strongest during the early stages, when your priors are least calibrated and you’re gaining many bits per experiment. Don’t over-plan tasks; delegate as much implementation freedom as possible to whoever is responsible. This may be an indictment of micromanaging in general, but over-planning a task is time-consuming and signals low trust to your teammates. If a teammate can’t be trusted with executing a task end-to-end, they probably shouldn’t be assigned to it.

Communication is also extremely important. Sometimes, a team member accumulates context mid-experiment that would inform how others would approach their work, and fails to communicate this information. Ideally, each teammate has a high-level understanding of what all other teammates are working on. A simple way to achieve this is a morning stand-up and an evening progress update.

Acknowledgements

This post is inspired by Boyd Kane's MATS retrospective, which is a very helpful resource! Thanks to Ivo Dimitrov, Gabriel Konar-Steenberg, Nikita Menon, and Tamkeen Nawab for proofreading this post and providing feedback.

1. ^{^}

   Admittedly, I don’t have access to admission statistics and it’s possible that early-career applicants are more numerous yet less likely to receive acceptance. My observation only applies to those who actually ended up joining the program.

2. ^{^}

   Across fellowships like LASR, MATS, Pivotal, PIBBSS, and Anthropic Fellows, I've met ~10 fellows who were surprised to receive admission because they felt underqualified and expected rejection. Selection processes are unpredictable and noisy!

3. ^{^}

    To be clear, working weekends is not required or expected.

4. ^{^}

   If you anticipate jet lag, I'd recommend arriving in London three or four days before Week 0.

5. ^{^}

    I had these meetings every two weeks, but I believe future cohorts will have them weekly.