The tooling approach is an interesting one, but I think the most important thing remains documentation. The "treat code like data" analogy breaks down because u

The tooling approach is an interesting one, but I think the most important thing remains documentation. The "treat code like data" analogy breaks down because unlike (most) data, code is a thing that was intentionally crafted, one piece at a time, by a relatively small number of people, many of whom are probably still in the building. It isn't some foreign artifact, understood by no-one, that's been measured from impersonal processes. It was made. Almost by definition someone has already had an understanding of it at some point. Reverse-engineering a new understanding from scratch - even via powerful tooling - remains a wasteful path to take compared to simply reading a (written-down) understanding that already exists.