Me too! :)
The last year or so of the GraphQL spec has been about honing what we have, and making sure how GraphQL works is clear and that it can be implemented in many environments. In many ways, GraphQL works and should be considered nearly stable, but there are also a lot of opportunities for GraphQL in the mid-term future.
One of the things I'm most excited about is extending GraphQL from the single-request-single-result model to single-request-multiple-results. For example, to enable some information in a request to be delivered before the server starts preparing other information, or even to keep an open connection to subscribe to live-updating fields. Right now GraphQL doesn't have a great story for reactive applications, but we're already seeing that start to change. I think a lot of future focus will be around this kind of exploration.
As for tools, most of what we do at Facebook and what we hope to see in the community is leveraging introspection to automate the things you would usually do manually. GraphiQL was a pretty obvious one for us in the early days, and we're excited that we could release it. Automating documentation and illustrating what a good IDE should look like was important to us. We're now seeing some of the GraphiQL features being integrated into existing IDEs where you're actually writing your code. At Facebook, we rely a lot on automated code generation (e.g. https://github.com/facebook/remodel). Especially in our iOS and Android codebases, we have tools which generate parsers, models, caches and other data layer code based on our GraphQL queries. That helps us protect against under-fetching and maintain type safety on those platforms.