I would be interested in your use case.
Generally speaking, a database schema (including a graph database schema = graph) does not change frequently. I am not saying it will never change, but it’s not likely it would change on daily basis, so I do not think it should become painful to manage the code.
And in most of the cases, designing and updating a schema is a human activity, as it requires thorough thinking. Certain parts can be automated, but I would be concerned about a fully automated schema building. Not from technical point of view: TigerGraph can easily handle agile schema changes (e.g. incorporating new data sources), and scripting it is fairly simple; it’s the efficiency of the schema that would concern me. TigerGraph is highly optimised and can store and process/analyse data very fast, but poor schema design negatively impacts query performance. To avoid that, someone has to put some thinking into the design process.