indirection is great! one of the best things you can do to look smart is recommend pulling out some shared code and make both sides point at that, this is how i pass job interviews and contribute to meetings i haven't been paying attention to.

it makes the code more complex, but for a good reason.

if you have a program b that consumes data from program a, that is simple:

(data in -> program a -> data out) -> (data in -> program b -> data out

that is great. but later, you learn there is going to be a new program c that consumes data from program a. it might be a swell idea to pull out code that is used in both places into a sharedlib, once you notice they are always changing together.

now you have something more complex! data goes into program a, program a maybe talks to sharedlib before sending it on to program b and program c who both talk to sharedlib. indirection! it takes a little longer to track down where data is being transformed, but you get a benefit in that you can make a change to sharedlib and it will be picked up by the programs without having to make a change to all three.

the idea is to make code that changes together live together.

similarly if you have a bunch of code in repo a and a bunch of code in repo b that requires a PR in both places any time there is a change then it might be good idea to pull code from repo a and repo b into repo shared too. code that changes together, lives together. if you find over time that it's requiring a change to repo a and repo b and repo shared any time you make a change, then maybe you'll want to put all of those in one repo.

however: don't pull things out into shared libraries simply because you believe they may one day be used by other things, wait until you actually need them, wait until you can see it will reduce churn or duplication to separate it. never introduce indirection simply because you believe it may one day reduce duplication. DO REPEAT YOURSELF, until you can see the patterns. do not introduce configuration, shared code, environment variables, overloaded functions, dynamic dispatch, delegation, ..., until you can see that it will make the codebase better.

do not use any indirection at all until it is needed. constantly watch your repos, if there are a lot of examples of two (or more) repos requiring synchronized PRs then either make it one repo or pull the shared concept into a new package that both of the others depend on.