Iâd like to get feedback on the writing style of this post. I want to try to write up bi-monthly updates but donât enjoy sinking time into writing.
Iâve never really stuck with blogging despite it being valuable for sharing what Iâm working on as Iâm a bit of a perfectionist. I end up spending hours combing over the posts I make. Iâd like my posts to only take 30 minutes, so my current ideas are to write quickly and post as is, or to have an AI edit out my mistakes.
Which of the two do you prefer? Do you have any suggestions on ways to make quick blog posts without potentially attaching poor communication or AI slop to myself?
Claudeâs edit of my post: ------ My Two-Month Deep Dive into AI Safety: From Imposter Syndrome to Clarity
How ARBOx and ARENA helped me navigate a career transition into AI Safetyâand what I learned about myself along the way
Two months ago, I committed to spending my summer diving headfirst into AI Safety. As someone with a background in Swift development and traditional software engineering, the world of Transformers, Linear algebra, and AI alignment research felt like an entirely different universe.
Hereâs what happened when I threw myself into ARBOx and ARENAâthe good, the challenging, and the surprisingly clarifying moments that helped shape my career transition.
Week 1-3: ARBOx in OxfordâSwimming in the Deep End
ARBOx accepted me for their intensive program: one week of prerequisites, followed by two weeks of in-person training in Oxford.
The reality check was swift. During pair programming sessions, I was often the weaker partner. While my colleagues brought post-grad experience with deep learning or career backgrounds in ML, I was frantically trying to remember basic PyTorch syntax. My years of Swift development, unit testing, and design patterns suddenly felt irrelevant when staring at Jupyter notebooks full of tensor operations.
However, being the âslowerâ partner was actually incredibly valuable. My more experienced partners were amazingly patient, and having someone literally show me concepts I didnât understand was worth twice the learning compared to struggling alone. Sometimes the best education comes from admitting what you donât know.
The human element made all the difference. Working on AI Safety material in isolation can feel overwhelmingâlike youâre trying to solve impossible problems alone. Being surrounded by 19 other people going through the same learning process, discussing niche AI Safety topics over meals, was genuinely inspiring. It reminded me that this field is built by communities of people, not just individual brilliance.
Weeks 4-7: ARENA FundamentalsâSlowing Down to Speed Up
After Oxford, I faced a choice: rush through ARENAâs materials to keep up with their intense timeline, or slow down and actually master the fundamentals.
I chose to slow down, and hereâs why that decision was crucial.
Everything builds on the basics. My biggest blockers during ARBOx were gaps in PyTorch, linear algebra, and tensor operations. Rather than continuing to build on shaky foundations, I decided to really nail these prerequisite skills. If Iâm transitioning careers, I reasoned, these fundamentals wonât just help with AI Safetyâtheyâll be essential for any ML-related work I pursue.
Active learning over passive consumption. ARENA encourages rapid progress through pair programming, often skimming reading materials to finish notebooks in a day. While this works well for exposure to topics, I found more value in:
Writing Anki flashcards for key concepts
Watching YouTube videos to visualize complex topics
Going through additional reading materials
Actually understanding rather than just completing exercises
Iâve created a fork of the ARENA syllabus to work at my own pace, and Iâm considering building demos of my favorite exercises to start developing a deep-learning portfolio.
The Career Reality Check: Research vs. Engineering
Midway through this journey, I applied for SPAR (Supervised Alignment Research)âa 3-month program requiring 10-30 hours per week. On paper, it seemed perfect: hands-on AI alignment research experience during my career transition.
But as I worked through the application, something became clear: I was applying for the wrong reasons.
Hereâs what gave me pause:
Time commitment vs. exploration breadth: Committing 3 months to one niche area when I only have 12 months total for career transition
Skills mismatch: The program values my software engineering background, but I need to develop ML skills most
Practical constraints: Iâll be working from Bali for 2 of the 3 months, limiting my in-person or synchronous involvement.
Motivation misalignment: I found myself struggling to get excited about reading & writing papers, applying for funding, and running scaffolding experiments
Realising that pure research might not be my best fit helped clarify what actually excites me. AI Safety engineeringâbuilding robust systems, tinkering with deep-learning model, creating tools that researchers can useâaligns much better with my background and interests.
Sometimes the most valuable outcome of an application process is discovering what you donât want to do.
What Iâve Learned About Career Transitions
Imposter syndrome is data, not truth. Feeling like the weakest person in the room doesnât mean you donât belongâit often means youâre in exactly the right place to learn quickly.
Community matters. The isolation of solo learning can make career transitions feel impossible. Finding your peopleâeven temporarilyâprovides motivation and perspective that no amount of individual study can replace.
When to go slow or fast. The pressure to quickly âcatch upâ in a new field can lead to surface-level learning. Sometimes the best strategy is to thoroughly understand the foundations, even if it feels like youâre moving slowly. For less foundational topics a quicker approach can pay dividends so you can get a sense of which topics interest you and go in greater detail later when youâve a better idea of what to focus on or can apply the knowledge in a real project.
Career fit-testing is as important as skill building. Donât just ask âCan I do this work?â Ask âDo I want to do this work?â The difference between research and engineering roles, for instance, isnât just about skillsâitâs about what energises you.
Whatâs Next
Iâm continuing through ARENA fundamentals with a focus on building solid foundations rather than racing through material. Iâm also exploring AI Safety engineering opportunities that better align with my background and interests.
The goal isnât to become an AI Safety researcher in two monthsâitâs to understand the landscape well enough to make informed decisions about where I can contribute most effectively.
For anyone considering a similar transition: Donât underestimate the value of being honest about what you donât know, finding communities of fellow learners, and taking time to understand not just what you can do, but what you want to do.
Whatâs been your experience with career transitions in technical fields? Iâd love to hear about your journey in the comments below.
I canât see the original, but this is easily clockable as written by AI, in the same style as a thousand other spam posts that pop up occasionally. Whether or not the style is inherently bad, it has been devalued from overuse.
Part of the appeal of reading a personal reflection is hearing it in somebodyâs own voice. Donât give that up!
Thanks, this is just the feedback I was looking for.
Hereâs the original looks like I need to publish drafts for them to be visible, Iâve edited the original post. Iâm weighing the AI version vs the 30 minute unedited brain-dump as the thing which puts me off writing these sort of updates is that my perfectionism can cause me to put several hours in to something I intend to publish and I donât want to put too much time in to this.
On the other hand sloppily written blog posts might be a net negative thing to be publishing in the first place so not doing them or keeping them private is also a valid choice. A fourth choice could be designing a prompt to do less invasive editing. What do you think is the best approach if Iâm looking to keep the time I spend writing this sort of thing to a minimum?
My thoughts are similar to titotalâs above: I found it hard to get through. There are a lot of stock Claude/âLLM phrases, such as the âItâs not this. Itâs thisâ and the usage of âReality checkâ, the use of slightly too uncommon synonyms, and the slightly too fancy vocabulary.
I think thereâs value in LLM feedback but when it rewrites whole sections it usually starts to feel annoying to me. I donât know if you have a âsystem promptâ for your Claude, but prompting it to preserve your voice much more, or just give you a specific list of improvements to implement might work. It could also be worth giving Claude some other things youâve written as context for âyour voiceâ and to give it strict instructions to avoid certain ways of writing.
Some of the things I did like from the Claude version because they made it more skimmable and easier to figure out what was happening:
The weeks in the section headers
Key points bolded
The section recapping what you learned about career transitions
Relatedly, I think having a TL; DR at the top of posts is generally helpful
I struggle with the same perfectionism, but reading your original post, it does not seem net-negative to me. It works very well for the personal reflection blog post format, and is much more enjoyable to read. If you were applying for writing/âblogging positions it would probably be too unpolished, but even then they wouldnât care if you had older material that was less polished. If youâre concerned about it you could probably mostly mitigate it by adding a disclaimer at the top that you wrote it in a limited amount of time.
You also canât really make a mistake in this kind of post because it is a personal reflection. Itâs about your experience, rather than e.g. you presenting research results or carefully arguing for an opinion which would be much higher stakes and would require more carefulness. You canât get your own experience wrong.
I think this post is very valuable as a resource for other people considering going to a future iteration of ARBOx or self-studying the ARENA curriculum. It reminds me a bit of the ML4Good experience reports [1] [2] [3] [4]
Iâd like to get feedback on the writing style of this post. I want to try to write up bi-monthly updates but donât enjoy sinking time into writing.
Iâve never really stuck with blogging despite it being valuable for sharing what Iâm working on as Iâm a bit of a perfectionist. I end up spending hours combing over the posts I make. Iâd like my posts to only take 30 minutes, so my current ideas are to write quickly and post as is, or to have an AI edit out my mistakes.
Which of the two do you prefer? Do you have any suggestions on ways to make quick blog posts without potentially attaching poor communication or AI slop to myself?
My original post.
My prompt.
Claudeâs edit of my post:
------
My Two-Month Deep Dive into AI Safety: From Imposter Syndrome to Clarity
How ARBOx and ARENA helped me navigate a career transition into AI Safetyâand what I learned about myself along the way
Two months ago, I committed to spending my summer diving headfirst into AI Safety. As someone with a background in Swift development and traditional software engineering, the world of Transformers, Linear algebra, and AI alignment research felt like an entirely different universe.
Hereâs what happened when I threw myself into ARBOx and ARENAâthe good, the challenging, and the surprisingly clarifying moments that helped shape my career transition.
Week 1-3: ARBOx in OxfordâSwimming in the Deep End
ARBOx accepted me for their intensive program: one week of prerequisites, followed by two weeks of in-person training in Oxford.
The reality check was swift. During pair programming sessions, I was often the weaker partner. While my colleagues brought post-grad experience with deep learning or career backgrounds in ML, I was frantically trying to remember basic PyTorch syntax. My years of Swift development, unit testing, and design patterns suddenly felt irrelevant when staring at Jupyter notebooks full of tensor operations.
However, being the âslowerâ partner was actually incredibly valuable. My more experienced partners were amazingly patient, and having someone literally show me concepts I didnât understand was worth twice the learning compared to struggling alone. Sometimes the best education comes from admitting what you donât know.
The human element made all the difference. Working on AI Safety material in isolation can feel overwhelmingâlike youâre trying to solve impossible problems alone. Being surrounded by 19 other people going through the same learning process, discussing niche AI Safety topics over meals, was genuinely inspiring. It reminded me that this field is built by communities of people, not just individual brilliance.
Weeks 4-7: ARENA FundamentalsâSlowing Down to Speed Up
After Oxford, I faced a choice: rush through ARENAâs materials to keep up with their intense timeline, or slow down and actually master the fundamentals.
I chose to slow down, and hereâs why that decision was crucial.
Everything builds on the basics. My biggest blockers during ARBOx were gaps in PyTorch, linear algebra, and tensor operations. Rather than continuing to build on shaky foundations, I decided to really nail these prerequisite skills. If Iâm transitioning careers, I reasoned, these fundamentals wonât just help with AI Safetyâtheyâll be essential for any ML-related work I pursue.
Active learning over passive consumption. ARENA encourages rapid progress through pair programming, often skimming reading materials to finish notebooks in a day. While this works well for exposure to topics, I found more value in:
Writing Anki flashcards for key concepts
Watching YouTube videos to visualize complex topics
Going through additional reading materials
Actually understanding rather than just completing exercises
Iâve created a fork of the ARENA syllabus to work at my own pace, and Iâm considering building demos of my favorite exercises to start developing a deep-learning portfolio.
The Career Reality Check: Research vs. Engineering
Midway through this journey, I applied for SPAR (Supervised Alignment Research)âa 3-month program requiring 10-30 hours per week. On paper, it seemed perfect: hands-on AI alignment research experience during my career transition.
But as I worked through the application, something became clear: I was applying for the wrong reasons.
Hereâs what gave me pause:
Time commitment vs. exploration breadth: Committing 3 months to one niche area when I only have 12 months total for career transition
Skills mismatch: The program values my software engineering background, but I need to develop ML skills most
Practical constraints: Iâll be working from Bali for 2 of the 3 months, limiting my in-person or synchronous involvement.
Motivation misalignment: I found myself struggling to get excited about reading & writing papers, applying for funding, and running scaffolding experiments
Realising that pure research might not be my best fit helped clarify what actually excites me. AI Safety engineeringâbuilding robust systems, tinkering with deep-learning model, creating tools that researchers can useâaligns much better with my background and interests.
Sometimes the most valuable outcome of an application process is discovering what you donât want to do.
What Iâve Learned About Career Transitions
Imposter syndrome is data, not truth. Feeling like the weakest person in the room doesnât mean you donât belongâit often means youâre in exactly the right place to learn quickly.
Community matters. The isolation of solo learning can make career transitions feel impossible. Finding your peopleâeven temporarilyâprovides motivation and perspective that no amount of individual study can replace.
When to go slow or fast. The pressure to quickly âcatch upâ in a new field can lead to surface-level learning. Sometimes the best strategy is to thoroughly understand the foundations, even if it feels like youâre moving slowly. For less foundational topics a quicker approach can pay dividends so you can get a sense of which topics interest you and go in greater detail later when youâve a better idea of what to focus on or can apply the knowledge in a real project.
Career fit-testing is as important as skill building. Donât just ask âCan I do this work?â Ask âDo I want to do this work?â The difference between research and engineering roles, for instance, isnât just about skillsâitâs about what energises you.
Whatâs Next
Iâm continuing through ARENA fundamentals with a focus on building solid foundations rather than racing through material. Iâm also exploring AI Safety engineering opportunities that better align with my background and interests.
The goal isnât to become an AI Safety researcher in two monthsâitâs to understand the landscape well enough to make informed decisions about where I can contribute most effectively.
For anyone considering a similar transition: Donât underestimate the value of being honest about what you donât know, finding communities of fellow learners, and taking time to understand not just what you can do, but what you want to do.
Whatâs been your experience with career transitions in technical fields? Iâd love to hear about your journey in the comments below.
I canât see the original, but this is easily clockable as written by AI, in the same style as a thousand other spam posts that pop up occasionally. Whether or not the style is inherently bad, it has been devalued from overuse.
Part of the appeal of reading a personal reflection is hearing it in somebodyâs own voice. Donât give that up!
Thanks, this is just the feedback I was looking for.
Hereâs the original looks like I need to publish drafts for them to be visible, Iâve edited the original post. Iâm weighing the AI version vs the 30 minute unedited brain-dump as the thing which puts me off writing these sort of updates is that my perfectionism can cause me to put several hours in to something I intend to publish and I donât want to put too much time in to this.
On the other hand sloppily written blog posts might be a net negative thing to be publishing in the first place so not doing them or keeping them private is also a valid choice. A fourth choice could be designing a prompt to do less invasive editing. What do you think is the best approach if Iâm looking to keep the time I spend writing this sort of thing to a minimum?
My thoughts are similar to titotalâs above: I found it hard to get through. There are a lot of stock Claude/âLLM phrases, such as the âItâs not this. Itâs thisâ and the usage of âReality checkâ, the use of slightly too uncommon synonyms, and the slightly too fancy vocabulary.
I think thereâs value in LLM feedback but when it rewrites whole sections it usually starts to feel annoying to me. I donât know if you have a âsystem promptâ for your Claude, but prompting it to preserve your voice much more, or just give you a specific list of improvements to implement might work. It could also be worth giving Claude some other things youâve written as context for âyour voiceâ and to give it strict instructions to avoid certain ways of writing.
Some of the things I did like from the Claude version because they made it more skimmable and easier to figure out what was happening:
The weeks in the section headers
Key points bolded
The section recapping what you learned about career transitions
Relatedly, I think having a TL; DR at the top of posts is generally helpful
I struggle with the same perfectionism, but reading your original post, it does not seem net-negative to me. It works very well for the personal reflection blog post format, and is much more enjoyable to read. If you were applying for writing/âblogging positions it would probably be too unpolished, but even then they wouldnât care if you had older material that was less polished. If youâre concerned about it you could probably mostly mitigate it by adding a disclaimer at the top that you wrote it in a limited amount of time.
You also canât really make a mistake in this kind of post because it is a personal reflection. Itâs about your experience, rather than e.g. you presenting research results or carefully arguing for an opinion which would be much higher stakes and would require more carefulness. You canât get your own experience wrong.
I think this post is very valuable as a resource for other people considering going to a future iteration of ARBOx or self-studying the ARENA curriculum. It reminds me a bit of the ML4Good experience reports [1] [2] [3] [4]
I prefer the original FYI.