ASTs (Abstract Syntax Trees) are an appealing tool for developers. If you don't know what they are, see my references below -- it's worth getting a base understanding so that you'll know when they could help you. One much spoken of possibility of ASTs is automatically refactoring code, so-called code-mods.
Another compelling application for them is to gain insights into your code or to help speed up tasks that your team needs to do every day. For example, a tool currently being worked on at Accelo is a component-to-URL tracker. What's the use case? Let's say a dev is fixing a bug, and in the process, they make a modification to the component `CoolComponent`. Given the name of this component, the tool gives a series of URLs that use the component. The URLs can be used for testing, either by the dev or passed on to our QA team.
It's worth mentioning that the tool is highly specific to our codebase as it deals with:
Which mean there would be little benefit to sharing the tool.
Without the tool being able to regression test components directly in our app is either guess-work that is likely incomplete or a gruelling task of chasing all the links through files to find each use. The latter option is more robust and is what the tool does for us now. What we've done is taken developer knowledge and embedded it in the tool so that it no longer exists only in our heads. Here lies a subtle befit of such a tool, that it becomes a type of living documentation. If otherwise I was tasked with documenting the steps a dev needs to take to track a component to the URLs, I would be hesitant. This kind of documentation is likely to get forgotten about, out of date and become a source of misinformation. But embedding the knowledge into a tool ensures that it stays up-to-date so long as the tool is used. As I mentioned above, about what our tool deals with, having multiple frameworks, and so on. It means that there is a lot of dev knowledge now bundled into it.
So that's our use-case. You could do the same for your codebase too, or here are some other ideas that might be useful to your team:
Please note the above is probably bias to web development (as that's what I do). The point is to think of code as a source of data and to pull out useful information and in the process, document knowledge.
A good place to start for ASTs
Perl's lack of an AST