“I haven’t worked on this module.”
Every PM has probably heard this at some point.
We used to ask a developer who had worked on the payment module to work on the dashboard, or fix an RBAC bug while the developer who originally built it was on leave. As a PM, I had to make a call: ask the available developer to debug something unfamiliar, or wait until the right person was back.
The reason this decision was hard has nothing to do with skill. It comes down to cost.
Context switching: The real cost is context, not code
A developer new to a module has to rebuild a mental model before they can touch anything. They read the code, trace the logic, guess at decisions someone else made months ago, and try to figure out why a certain shortcut exists. That process can take hours before they write a single useful line.
A developer who already carries that context in their head can solve the same bug in a fraction of the time. Not because they are more skilled, but because the expensive part is already done.
This is why context switching has always been treated as a real cost in delivery planning, even when it never shows up as a line item anywhere.
Where AI agents change the equation
An AI agent with access to the right code, documentation, tickets, and past decisions can compress that ramp-up time. It can summarize what a module does, point to the reasoning behind a design choice, flag where similar bugs were fixed before, and in some cases attempt the fix itself.
This does not mean context stops mattering. It means context stops living only in one person’s head. More of it can sit in a system that any developer, or the agent itself, can query on demand.
That is a meaningful shift. For years, the practical answer to “who can fix this” was “whoever built it.” AI agents make “whoever is available, with the right access” a real option too. It is worth pairing that with a related tradeoff I wrote about in AI Made Shipping Fast. It Made Deciding Slower: moving faster on one part of the process does not automatically mean the whole team is deciding faster.
What this does not solve
It would be easy to read this as AI removing the problem completely. It does not.
An agent trained on incomplete documentation will confidently produce a wrong answer with the same tone as a right one. If the original developer never wrote down why a workaround exists, the agent will not know either. It will guess, and the guess will look reasonable.
This is where review still matters. AI can shorten the distance to a first draft of understanding. It cannot replace someone checking that the fix actually respects the business rule behind the code, especially for modules like payments, permissions, or compliance, where a plausible-looking fix can quietly break something that matters.
There is also a team dynamic worth naming. If developers start leaning on an agent instead of ever building context themselves, you end up with a team that can operate a system but does not deeply understand it. That is fine for low-risk areas. It is a real risk for the parts of the product that carry legal, financial, or security weight.
Where this fits and where it does not
Teams working on well-documented, lower-risk modules will see the biggest benefit early. Ticket history, code comments, and design docs give the agent something solid to reason from.
Teams with thin documentation and tribal knowledge concentrated in one or two people will get less out of this, at least at first. The agent can only surface context that exists somewhere. If the “why” behind a decision was never written down and only lives in one developer’s memory, no amount of AI access fixes that gap. In those cases, the real fix is still the boring one: write things down.
The guardrail that does not change
None of this changes what a PM is actually responsible for. I have written before about what that work actually looks like when AI is doing more of the execution. The customer persona and the actual product problem still need to sit at the center of the decision, whether a human or an agent is doing the work. AI can carry more of the context load. It cannot decide what the fix should protect or who it is for.
So the honest version of the question is not whether AI removes the “I haven’t worked on this module” problem. It is how much of that problem was really about code, and how much was about documentation and ownership we never fixed in the first place.
If AI can carry the context, how much of this problem was ever really about the code?
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
