I would propose slightly different solution, I was doing software development for 30 years learning first patterns from Martin articles and what always felt strange was the fact that we had top 20 programming languages living in kind of silos.
I stride to address that by implementing runtime bridge for Java and .net and it was quite successful but only in niche use cases where somebody badly needed to use jar in .net or other way. One of funny achievement was that we managed to allow our customers use wpf user controls inside Java jframe! And it was living nicely in the UI and was binding events allowing to call methods etc..
That led me to though why if we take unzip library in Java we just add it as dependency via maven but if we call the same remotely or want to use unzip from Nuget we suddenly host it on separate node, write either rest, gRPC, subscribe queue via sdk or use thrift and then we write client for that and call it through those artificial layers up to unzip(string:filename) methods we wanted to call. WHY?
And therefore looking how to broaden our runtimebridge market we tried a crazy idea to allow any tech use any other tech by simple calling their public methods regardless if it’s in memory or remotely.
It took building runtime bridge for 143 tech pairs supporting clr, jvm, python, ruby, php, c++, go, node (js/ts), browsers js/ts etc…
NEXT we made it possible so they can call each other in memory and remotely.
Than we made that strongly typed interface is obtainable via simple package manager call.
And now users can take any module write just public methods and host it on our gateway running in their container/vm/machine and immediately they get api browser with commands for any package manager to get strongly typed client on the fly that always stays up to date.
Whenever anyone uses the module obtained (we call it graft) and calls any method it gets routed via any channel based on runtime config i.e. via env var and it can go http2, WebSocket, tcp/ip, any queue/event bus etc, or in memory!
And the system design is super simple just public methods and classes using them. It fits 1:1 what we see in OOP uml, code is fully decoupled from integration method, so we can change architecture in runtime even extracting logic to microservices from monolith. All services clearly reference their dependencies and get always up to date strongly typed client.
All of that makes AI, understand such system much better, use much less tokens, use much more efficiently context, and makes pull request review much easier!
The team either before or after code is written has much better control through simple OOP design.
It’s still evolving but we already achieved enterprise readiness and have many great POCs including IBM. We support full open telemetry, authentication, standard encryption of underlying channels purely removing the difference from same tech, cross tech, remote or local calls. Now everything feels like local method calls.
You think it would help to solve the issue of reviewing that code? @martinfowler?