I would guess that he means that when you have a lot of glue code it tends to be repetitive and so writing tools to write the glue code can be a win. Let's say you have implemented a service that exposes API X to its users, and let's say you have an internal service that provides the actual functionality you are trying to expose but uses API Y. Hence you need glue code that translates between X and Y.
There might be hundreds of API calls in X but the glue code is all going to be of the same general form: translate the X parameters to corresponding Y parameters, call the matching Y function, and then translate results back.
Within all these glue functions there will be a lot of common actions. X calls with integer parameters for instance might pass them as ASCII strings and Y might expect integers as 64-bit big-endian binary.
In this situation there is a good chance you can make a table that lists each X call, the types of its arguments and results, the Y call to map it to, and some flags to indicate that some things need special handling and what those are.
You can then have a program, probably a fairly short and straightforward program, that reads that table and writes out the glue code for you, sticking in comments marking places where you need to edit it to deal with those places marked as needing special handling.
