Anything unforeseen. Aviation is still a craft, not a science even if a very large number (a huge number, actually) of hours have gone into making it a science. The basic problem here is that you're dealing with chaotic natural systems on one end and machinery at the other. All it takes is a flight of geese or some unusual weather pattern and all your careful programming is worth zip. In situations like that humans tend to do better than computers.
The BA 38 example highlights why we need to get humans out of the loop. Good software would have instantly detected the uncommanded loss of power, and immediately started raising the flaps and landing gear. In fact, good software would probably have exercised the control surfaces and engines before descent and diagnosed the problem then, when the aircraft had tens of kilometers of glide remaining.
Approaches like that are common for playing board games like chess, for finding clever transfer orbits for spacecraft, etc.
So you want to detect a fail to spool? OK you need to put a sensor on the engine to detect speed. And one on the throttle to detect position. Maybe there is another way to detect fail to spool but this is what we're going with because linear and rotational sensors are pretty common and well sorted.
Now you need to make sure that those sensors are 100% correct before factoring it into your code. So you add another of each sensor. But what if one of those sensors is out of calibration or broken? You need another one to vote for majority. Ok so now you've got 3 sensors on both the throttle and engine shaft.
Nothing really crazy here and pretty common.
Now you've got to build the software to model the engine. Jet engines have a delay in spool times that depends on air speed, how fast you feed in the throttle, how fast the engine is already turning, and other factors I have no clue about.
Now that you've got the model setup you have to add in some hysteresis to keep things nominal and to deal with glitches in readings due to iPods and cosmic radiation and vibration.
And then you have to remodel the whole thing depending on which engine is fitted (there are 3 available for the 777 plus variations). And then you've got to test it.
Now that you've tested that you are able to detect a fail to spool situation you have to generate the model of what to do in various flight modes. And that depends on how much thrust was lost, air speed, altitude, attitude, rate of decent, wing configuration, weight, landing gear configuration, etc.
And then you have to test the flight model. And then you have to update the operational handbook to inform the pilot of what to do if the above fails to work. You also have to amend the inspection and maintenance books to inform the A&P how to test and verify the sensors. You also have to modify the flight recorder to record the sensor positions and software behavior. And you have to modify the sat recording and playback software to handle the new data.
You have to do all of the above because if the fail to spool code activates on a normal approach it can very easily lead to a stall and kill 200+ people. You want to be 99.99999% sure your code is correct.
You've now spent millions of dollars and years of development to replace something a pilot can detect in 3 seconds by simply listening and feeling to what the plane is doing. AND you have created a liability if a bug crops up.
The control software does not need to know about the different models of engine. Each engine should measure its own performance and report the results to the self-fly software.
In the case of BA 38, this was done: the aircraft automatically detected the loss of power. Unfortunately the (dumb) autopilot had used a flight profile that was unsalvageable if loss of power had occurred at that point.
The future of travel is self-controlling vehicles. We have usable self-driving cars today. Airplanes are easier to control than cars, and the aviation market has a huge pent up demand for short hop travel that cannot be met by the heavily crewed business model.
And we'd need to be able to do this even for a cargo plane with no passengers on board, since a disabled plane crashing into a populated area would cause a lot of deaths.
Cars also enjoy much safer failure modes than aircraft - if a catastrophic failure occurs in all likelihood you can pull the car over to a stop without issue. When a catastrophic failure occurs in an aircraft's controls it hits the ground and everybody dies.
We're not even quite there yet for self-driving cars, though we are close - and that is a problem orders of magnitude easier than fully-competent autopilots.
We already have the technology to take off, fly, and land planes in the Happy Case. But the devil is really in the unhappy cases.
Nobody is saying we won't ever have full autopilots - but that we are very, very far away from such a capability, and simply throwing engineers at the problem is unlikely to give you the solution substantially faster. When you're pushing the absolute edges of scientific and engineering knowledge progress does not correlate strongly with workforce.
If you still think it's possible take some time to learn of all the novel failure modes that have occured over the past few decades in commercial aviation. Pay special attention to the ones requiring crew to override onboard computers.