Maybe, maybe not
As much as I think the chief is lying, I have to say that I've been doing embedded software since the 1980s, and for most of that time I was the only one on God's green Earth who knew what most of the lines of code that I wrote actually did. Sure, we had peer review and SQA and audits, but If I wrote a line of code that turned off the Clean Mode and labeled it with a // Enable Clean Mode comment, then it would make it past the reviewers. Especially if there were pointers involved and maybe an enumeration in the mix. It is hard enough to detect unintentional errors in embedded C code. Finding an obfuscated intentional "error" is pretty unlikely. So, if I were doing embedded code for VW, why would I turn off the emissions controls? Maybe I think that the emissions rules are BS and that our customers deserve a better running car (not my personal opinion, mind you). Maybe I do it so that I earn the respect of my fellow engineers, or so I get to keep my job in a downturn because I am the Diesel Engine Wizard at VW. Embedded software doesn't have to be a black art, but in most organizations it is still practiced within a narrow slice of the organization without much visibility upward.