The chess programs had the rules of chess programmed into them, and the move to play was calculated by rating different moves in the search space using an algorithm that was programmed by the developers of the AI system. This means that it is only specialised to chess.

To be the AI in movies like The Terminator, the program will need to be able to learn the rules and strategies of chess itself, and adapt its algorithm over time. To simplify the problem of recognising the elements on the board (machine vision), you could represent the board as an 8x8 array of Unicode characters.

Teaching the rules is difficult because you need a way of communicating those rules, which means that the program will need to understand language and the meaning behind the language (or enough meaning to understand rules to a particular game). Also, chess has a lot of rules that can be complex (en passant, castling, etc.) so it would be better to start with a simple game like tic tac toe or connect 4.

The real threat is not in a generic AI that deems humans as a threat, but a specially tasked program or AI that miscalculates: allowing machines to control drones or military aircraft to perform air strikes, or similar things. There, if a machine gets things wrong it can cause untold destruction. Think SkyNet/The Terminator, but here the machines do not know what they are doing (they don't have independent thought or understanding like humans and animals), they just classify humans (or buildings) as a threat -- that is, this can be via a decision tree like in the chess games and the best "move" is to attack any building.

They are all tools that can be applied to improve the quality of the code. No one thing is "The Solution".

* Test Driven Development (TDD) is a good approach to ensure that the code you write is testable. This will not work for things like UI code, but other code will benefit.

* Unit Tests can either be developed via a TDD-like approach (easier to do), or after the code is written (harder to do).

* Automated Regression Tests (a superset of Unit Tests) provide good coverage for ensuring code works as expected without involving a large manual testing team. These will only detect the things covered by the automated tests.

* Static Code Analysis tools can pick up a lot of problem areas, but will not detect every problem. These results can be used to identify what tests need to be created to prevent future regression.

* Fuzz testing is good at providing strange data to e.g. a protocol or file format parser. These are intended to be soak tests -- e.g. "does my regular expression parser handle all these strange and possibly invalid constructs". Fuzz testing would have most likely found the heartbleed bug (because it would have permutated the length of data to request). Any failures here should be converted to Unit/Regression tests to ensure that the problem is (a) fixed by any code changes made and (b) does not occur in the future. Fuzz testing will typically find hard to identify bugs (e.g. data races) that are not easy to identify from manually constructed tests or static analysis.

* Manual/ad hoc testing is important as it can uncover bugs that the developers are not aware of.

* Code and Security Reviews help identify potential issues (e.g. if you have someone knowledgeable about SQL injection, they can assess whether some code is vulnerable to that attack).

None of these is a silver bullet, but the more you have the better the code will be.

If you read the blog post, they don't use letters: N=NVIDIA, X=Mesa, I=Intel, A1=AMD, A2=ARM/Mali, Q=Qualcomm/Adreno, P=PowerVR. There is no mention of Apple.