Jobs are something that tends to get modified in production without going through the normal change control process. For example, at 2:00am the DBA might disable the job or alter the execution steps or tinker with the proxy account to work around a production issue, perhaps with the intention that it's a temporary fix that will be replaced back to it's original state later. I have a Git repository just for jobs and a PowerShell script that iterates across all (100+) servers, scripting out jobs to the working folder, and then checking in a commit of what changed. Eventually, I may do the same with all user defined objects like stored procedures and views. This would be an automated Git repository that is intended for disaster recover, operating parallel to the official repository that the developers are supposed to be maintaining themselves.
I've seen something similar in the past. Same thing. More a DR thing than watching code.