"However, engineers cannot cross code bases. It would be too much,
each code base has its own architecture and purpose."
I would challenge the notion that this means engineers cannot swarm or work as a team. I've worked with teams of developers who have very silo'd skills - each one having knowledge of a particular system written in a particular language - and who are still working towards a single purpose very effectively.
Mostly they do this by working out what the downstream service needs from the upstream; collaborating on interfaces (service, application or library interface), changing the information provided or the information processed, and talking to each other.
I saw that the team had come together when one showcased some work to the stakeholders, saying,
"Last week, you saw Y's work on this application. I also showed you how my service would save your information. This week I'd like to show you how they work together."
It isn't the technologies or understanding of it which makes a team. It's the desire to ensure that each person's work contributes to the work of others, building into a greater whole.
However, this worked because they had a specific problem to solve. You can't create a team just by putting people of different abilities and experience together; instead, put a team together that has appropriate skills for the problem they're trying to solve, and allow them to learn or ask for help if they need it.
If you do this well, it's not a matter of putting them on the same team. They are the same team, as soon as you allow them to be.