I am not a pilot. I am a software/systems engineer by trade with a strong interest in aerodynamics. My point here is to discuss cockpit design issues and how they may have contributed. While this is Airbus specific, there is significant overlap with Boeing and so I am not trying to start a Boeing/Airbus flame war.
One thing that strikes me about this incident is that there are a number of immediate similarities to AF447. The plane climbs, appears to lose at least ground speed, may have stalled and subsequently crashed. If course without FDR/CVR we don't know exactly what happened so this is just speculation.
Yes, AF447 was proximally pilot error. But errors occur in contexts and one of the important areas that was also covered in the report and discussed in IEEE publications was the role of what is called the automation paradox, namely that the more reliable the automation system in place, the less a human can contribute to the success of the system when something goes wrong. One serious issue is that heavy automation in aircraft may make pilot error inevitable. That has some significant implications as we look at assigning blame for this accident, AF447, and the like. IEEE Spectrum had an article that is easily accessible to non-techies called "
Automated To Death". I would recommend reading it. There has been some more AF447-specific coverage as well in Spectrum and other publications, and the fact is that the final report did discuss how the error reporting obscured the cause of the problems and contributed to pilot error.
Automation is a funny thing. There's a saying, that computers make it possible to make more mistakes faster than any invention since handguns and hard liquor. Unfortunately just because you put a person in charge, that problem doesn't go away. And when you add the fact that Airbus sidesticks do not provide significant feedback to the other side, you have a situation where things can be more difficult to recover from than they should.
In my view early indications point to pilot disorientation coupled with bad weather, turbulence, etc leading to a stall. Given the heavy automation in the systems, the question is, how does being suddenly thrown into a situation where the automation *isn't* working as expected and where you have to rapidly figure out both the technical and human elements of it, something which makes these sorts of mistakes more likely than they should be? Now throw the pilot into a situation where the automation isn't working as expected and weather is bad, and you have a real recipe for disaster. The question we should be trying to figure out is how we rethink the interface between pilot and avionics to minimize these issues. That's not as trivial as who has final authority, but it has to go into everything. On this I don't have immediate answers. it is however a field of on-going research. I don't think though that this issue can be left to computer scientists, aerospace engineers and the like. I think we need to be looking at getting a lot of pilot feedback as well.
In the end I think one has to be careful in assuming that if pilot error was the proximal cause (AF447) that this is where we place the blame. This case is shaping up to look eerily similar.
I do wonder though whether, as taboo as the subject is, if it is even possible to make much greater gains in safety automation without bringing back the flight engineer albeit in modified form. Yes, this has been marketed as reducing staff by eliminating this role. So yes there is a money vs further risk mitigation issue that comes into play (and it may not be worth it). But you can't just throw pilots into the role of troubleshooting a complex automated solution and expect that they will filter things out always correctly.
TL;DR: I am wondering what the role of automation was in any crew confusion and pilot error that resulted here was. I think it is likely that, as with AF447, that this interplay will prove important.