Yes, this was my gut reaction to the Gettier exceptions as well. But you picked out the specific detail that seems to clinch it for me: the framing of the "fact" under question matters greatly.
From the author's first example, the framing of the statement was also critical. Rebasing introduced the bug, and it would be a correct statement to say "something I just did broke autofocus." However, it would be incorrect to state "my code in the last commit broke autofocus."
In many ways, programmers need to be as fussy in their statements as philosophers. Since computers are stupid, and do exactly what you specify (usually...) it is important to pay close attention to these exact details. Assuming that the new code contains the bug is incorrect, and proper debugging requires careful attention to these details.
Ive certainly had bugs that were caused by some other, hidden factor like this, and typically the best way to find them is to carefully examine all your assumptions. These may be ugly questions like "is the debugger lying to me?" or "did the compiler actually create the code I intended it to make?" So while these may not be strict Gettier cases (and the author admits this in the article) they nevertheless are fairly common classes of similar problems, and framing them as such does provide a useful framework for approaching them.
