At every company I've ever worked at, I've had to distill whatever problem I'm working on to something incredibly simple. Only then have I been able to make real progress. In my current role, at an autonomous driving company, I'm working in the context of a rapidly growing group that is attempting to solve at least 15 different large engineering problems, each of which is divided into many different teams with rapidly shifting priorities and understandings of the problem. The mission of my team is to make end-to-end regression testing rock solid so that the whole company can deploy code updates to cars without killing anyone. But that wasn't the mission from the start: at the start it was a collection of people with a mandate to work on a bunch of different infrastructural and productivity issues. As we delved into mishmash after mishmash of complicated existing technical pieces, the problem of fixing it all became ever more abstract. We built long lists of ideas for fixing pieces, wrote extravagant proposals, and drew up vast and complicated architecture diagrams. It all made sense, but none of it moved us closer to solving anything.
At some point, we distilled the problem down to a core that actually resonated with us and others in the company. It was not some pithy marketing-language mission statement; it was not a sentence at all -- we expressed it a little differently every time. It represented an actual comprehension of the core of the problem. We got two kinds of reactions: to folks who thought the problem was supposed to be complicated, out distillation sounded childishly naive. They told us the problem was much more complicated. We told them it was not. To folks who really wanted to solve the problem with their own hands, the distillation was energizing. They said that yes, this is the kind of problem that can be solved.
I have never encountered a real problem without a simple distillation at its core. Some problems have complex solutions. Some problems are difficult or impossible to solve. But I have never encountered a problem that did not have a deeply simple core to it, and I have always found that enunciating this core is helpful.
So here is my distillation of the AI safety problem.
First, there is the technical engineering problem of building a safe superintelligence. This is a technical engineering problem, and nothing more. Yes, it is very difficult. Yes, it has a deep and unusual philosophical component. But it is an engineering problem no fundamentally different from building an electric car or deploying a cryptocurrency. Do not put this part of the problem into some special category in your mind. Stare at it until it looks like a very very difficult version of building a house from scratch.
Second, there is the coordination problem of making sure that an unsafe superintelligence is not built first. This is a coordination problem. It is also very difficult. It is in the same category as getting the whole world to agree to stop using CFCs in airconditioners, or to reduce carbon emissions.
The problem really is that simple: build a safe superintelligence; coordinate to not build an unsafe one first. It is not at all easy, but it really is simple. Solving the problem will require research, engineering, funding, management, and other more and less familiar ingredients you may or may not recognize from elsewhere in the world.
If the problem seems scary to you, that is a fact about your mind, not about the problem. The problem itself is merely difficult.
It is a problem that you can work on.