You're adding additional custom functionality to an application so using tablespaces as a proxy is not appropriate. The performance impact of your new functionality will depend on the workload that your new functionality generates which is independent of what tablespace(s) the object(s) the new code references happen to reside in. The tablespace that an object resides in does not affect performance.
Knowing how the buffer cache is being used at present doesn't give you much insight into how additional functionality, which would cause new blocks to be cached and would force some existing blocks to age out more quickly, would impact the performance of existing functionality. Unless you have a tiny toy application, the buffer cache will be full of something. The fact that the buffer cache is full, though, doesn't tell you whether, at the margin, the additional blocks that would be aged out in order to support the new functionality would cause millions of additional physical reads or whether they would have no impact on performance.
Beyond the buffer cache, though, the new functionality might impact performance by consuming additional CPU cycles, putting additional load on the I/O subsystem, or by locking rows that would negatively impact the performance of existing functionality. In theory, it's possible to do some ballpark estimates of how additional pieces of functionality are likely to impact an existing system. This is not, however, a task for the faint of heart, it's a pretty sophisticated endeavor.
Fortunately, since you're the one building the new functionality, you have a much easier solution. You can benchmark the existing application in your lower environments, add the new functionality, and then benchmark the existing functionality with the new functionality in place. That lets you do a much more level comparison-- you're comparing transaction times before and after the change, for example, rather than measuring something like CPU consumption and trying to model how that would impact transaction times. And it is typically much easier to implement-- all you need is some sort of load test that exercises the existing functionality in a way that is generally similar to how it is used in prod.