Pull that repo. You can read that code now.

AI removed reasons to limit yourself to your own codebase

“I can’t check this part - I don’t know the technology.”

“That’s another team’s context.”

Engineers say this daily. In the worst case, they get stuck. In a better scenario, they reach out to someone who knows, wait for an answer, and move on. It feels responsible - you’re not touching things you don’t understand, and you’re collaborating with the right people. But it’s actually a pretty expensive habit. Every time someone stops and waits for context, delivery slows down. And over time, the engineer’s own growth stalls too - they never build understanding beyond the boundary of their team’s repositories.

So far, these reasons were reasonable. The cost of getting into unfamiliar technology or context was genuinely high. You’d need to read documentation that may or may not exist, trace through code you’ve never seen, build a mental model from scratch, and probably bother three people on Slack along the way. It could take days before you had enough context to form an opinion, let alone contribute. Probably still worth it, but the initial cost is quite high for a long-term investment that one rarely has time and capacity for. So we’ve built incentive structures around it - framing dependency as teamwork, ensuring engineers don’t get blocked by making sure someone else unblocks them. All reasonable. All expensive. But does that still hold?

This isn’t new. Every decade, we relearn that silos slow everything down: Conway’s Law, DevOps, cross-functional teams, and inner sourcing. All these scream “break silos”. At the same time, we value ownership - getting a deep understanding of a subset of the problems the organisation is tackling to build knowledge, become experts, and deliver even more value.

The tension between the two was always there. It led to queues, longer wait times, and lost context during handoffs. What’s worse, engineers often treat the edge of their team’s repositories as the edge of the scope they can work on. Not because of malicious intent, but as a default. Nobody told them otherwise, and the cost of crossing that boundary has historically been high enough that staying in your lane felt like the rational choice. Why spend two days understanding another team’s service, with a high risk of getting it wrong, when you can ask the owning team and wait for their answer?

Having a broader perspective as a superpower

I always believed that the best engineers, who consistently deliver the greatest impact, are curious. They ask “why,” not just “how” - and it becomes even more important as you step up in your career.

Those are engineers who refuse to limit themselves to one technology. Their identity is solving problems, not operating a specific stack. Recently, such engineers are often differentiated as “builders” vs “coders”, or as “product engineers”. Another definition I often used before was being T-shaped, π-shaped, or, as I learned recently, M-shaped professionals. Regardless of the name, those people care first and foremost about the outcome - the value they deliver - and only use their skills and experience to reach it. They pick a tool for a problem, rather than forcing the same tool for everything. And if they get stuck because of a lack of skills? They learn it.

I’ve always seen myself as such a person. I started with backend depth, but never limited myself to it - frontend when web applications needed it, databases when performance was the issue, CI/CD and infrastructure when I wanted to standardise quality. Some of these areas stuck more, and I became more experienced in them; others were there just enough to unblock myself.

This is also what I’ve usually hired for. When interviewing engineers, I look for curiosity beyond their primary focus. Most importantly, do they look outside of tech and ask why customers and businesses need the system? Such engineers are often the ones who cross boundaries and solve the hardest problems. They’re the ones who notice that the bug isn’t in their service - it’s in the upstream data transformation. They’re the ones who propose solutions that span two teams because they understand both systems well enough to see the simpler path.

In a way, this used to be a high bar. Getting into an unfamiliar codebase took effort - hours of reading, experimenting, and asking around. The engineers who did it were the ones with enough motivation to push through the friction. It was a useful signal precisely because it was hard.

A new muscle to train

AI tools have collapsed the cost of becoming that curious, cross-boundary engineer. You can now pull a repository you’ve never seen, load it into your AI tool of choice, and understand the system in minutes. Doesn’t matter if you’re investigating a bug, or clarifying open questions for a new functionality - you can get enough understanding of the system, data models, patterns and architecture. Enough to answer most questions autonomously and move forward. And when you get stuck due to greater complexity or a very specific business context, you can still revert to asking owners. But only when truly needed.

In the last few weeks, I have regularly had 5-6 repositories open with Claude Code running on top of them. Those repositories span 4 or more teams across the organisation. My teams are not the owners of those systems. I don’t contribute code to most of them. But I answer my own questions about how they work, why certain decisions were made, and where the integration points are. It allowed me to answer questions necessary to clarify the technical specification of a new feature and even implement part of the scope when needed. And when I hit a question about higher-level configuration not present in the codebase, I still went to the owner team and got the answer.

This is not replacing collaboration. It’s about raising the baseline of understanding you bring to every conversation and unblocking yourself faster than before. The old excuse - “I can’t check this, it’s not my technology” - no longer holds. The technology barrier is gone. The AI handles the syntax and framework-specific patterns. What you bring is the ability to ask the right questions. Still, I see engineers too often not doing this. It’s a new muscle to train.

One thing I realised while doing this is that I was efficient because I understood the system’s high-level architecture. In other words, I knew which repository to pull. But that’s not the case for everyone. And while AI solved “I can’t understand unfamiliar code.” It didn’t solve the problem of “I don’t know which code to look at.” As in many other aspects, when enhancing SDLC with AI, here too, the constraint just moved. Instead of code-level, it is now about architectural literacy. Do you or your engineers know the broad system? Is it clear which service handles which part and how the data flows between them? And finally, which repo to pull to get the answer?

I haven’t yet figured out how to get coding agents’ reasoning across distributed systems and multiple repositories. I’m pretty sure it will be able to do it someday; heck, maybe it can even do it now, but I haven’t figured out how yet. So for now, I see it as a place where an engineer’s experience comes into play. But aside from skills and experience, an organisation needs to provide a valid, up-to-date map to navigate the entire system. Proper architecture documentation was always important. I believe it has become even more now. And it’s an important leadership challenge - ensure engineers have the architectural context to know where to look, even in a complex network of microservices talking to each other. Organisations that will do it well will have an advantage over those that aren’t even thinking about it yet.

The excuse is gone

Wrapping this one up, there are even fewer reasons for anyone to close themselves off to a narrow scope, whether in technology or business. The tools are out there, making the cost of understanding unfamiliar code approach zero. The question isn’t whether your engineers can look beyond their team’s boundaries. They can. The question is whether they will - and whether your organisation makes it easy for them to know where to look.

If you’re an engineer: next time you hit “I don’t know that technology,” pull the repo. Load it into whatever AI tool you use. Ask it questions. You’ll be surprised how quickly you build a working mental model. Try first, ask only when you’re blocked by genuine complexity - not by unfamiliarity.

If you’re a leader: invest in the map. Make your system architecture legible. Ensure good naming, clear boundaries, and accessible documentation about how services connect. This will help engineers, which in turn will make the whole organisation faster. Because the old excuse is gone, and the engineers who realise it first will outperform those who don’t.