In the past, I used to work in a codebase that had a lot of // @TODO: comments in it. Those TODOs would rank from obvious, small improvements to calls for features that would require an entire rewrite. The TODOs always caused frustration on my end: Why did they not finish their work? Why is everything broken? I realize that the mere presence of a TODO would make me judge the code differently, worse. Implicitly, I would compare the existing code against the ambition that someone else set by writing down all the things that could be improved.
It is of course misleading and unhelpful to judge code that exists and works today against a hypothetical better solution that doesn’t even exist yet. Recently, those TODOs have re-appeared in my life, and I have put in work to re-anchor my relationship to those TODOs. By now, I welcome // @TODO comments: All code is imperfect, and all features incomplete. There is no end-point other than “I stopped changing the code because it now supports the features I need right now” (which is notably different from “all the features I wanted”). To state the obvious: if your code is (say) inefficient, then that is true regardless of whether someone added // @TODO: this quadratic loop is terrible! or not. Or in other words, the TODO always existed, it’s just a matter of whether someone wrote it down. (And no, I don’t think these comments would be better off in Jira.)