Seconded. You should be able to create tickets or at least file an initial ticket that a PM can flesh out. Tickets (or any type of change control system including git) really serve two purposes. 1) To track what changed 2) To track WHY something changed. A dev should be able to look up your ticket a year from now and be able to untangle the logic in your code changes tied to that ticket. If your ticket only has a title, or the briefest of descriptions you'll find it hard to debug any issues introduced by this (and you'll also be going to dev hell)

That really assumes that

1) Tickets are detailed enough and have been for a long enough period of time.

2) The functionality that's to blame was implemented in one ticket.

Unfortunately, that's almost never true anymore for anyone.

git bisect + git blame I find usually more useful than verbose likely partially correct notes.

That often tells What changed, but rarely does it seem to tell Why. When the logic changes (and tests too) because the sales team now needs Different Things, it's very useful to have a ticket.

That doesn't scale to large or multiple teams.