Also, we're entering a paradigm in which a lot of research is constrained by compute, and it can be very difficult to just "do AI research projects" when such projects involved training policies in virtual environments or designing the next transformer, for instance.
Still, after hearing this story, my takeaway is not "Do not fix AI researchers' code if you want to become an AI researcher."
Rather, "Good news! It turns out a software engineer has much to offer AI researchers! However, as all too often, beware of politics - you need to find an organization where the AI folks won't be threatened by your fast work but will welcome you."
I am no longer in academia but have promised myself not to engage with an academic open source software. There is simply no incentive for development. Well, when you think about it, most academic work is publish and forget: maintenance is not a strict requirement.
You're being evaluated based on how many papers you can publish, so the academic process selects for good (well, fast...) writers, not good coders. Papers are selected for novelty, so it's much easier to publish a paper based on a 'novel' algorithm than to publish a paper based on v2.0 of the algorithm. There might be novelty in the v2.0, but it's risky, reviewers and editors might not agree. There's always novelty in the v1.0 (well, it's academia, so it's more v0.1)
> Every great open source math library is built on the ashes of someone’s academic career.
From William Stein, lead developer of the computer algebra system, Sage: http://wstein.org/talks/2016-06-sage-bp/bp.pdf
Very different worlds.