Yes, but the amount of work needed here is overstated. With good orchestration/prompting in the task[1] (and token budget), the work on this end is significantly reduced.
… and then the brain drain issue returns.
[1] https://claude.dev/blog/solving-code-review-at-anthropic/
The sentence is maybe ambiguous, but it sounds like it's saying to not use the AI at all until you understand what's happening in the area that needs to change.
I don't agree with this as you can spend quite a bit of time digging around to first find the correct place which needs to be updated and then more time reading the code (likely in multiple files or places) to build up a mental model of what's going on.
I typically have more than one AI conversation on the go at any given time, so I'll always start by asking it to make a plan to solve a problem and while it's busy exploring to make a plan I review some other AI conversation's work in the meantime, when the AI's plan is ready I review it.
If at this point there is anything that is unclear to me about its approach to implement the plan, or I don't already have familiarity with the part of the system it's proposing to update, I start questioning the AI on how the system works. I will scrutinize the AI's plan until I'm absolutely sure that it's going to implement something that is sound from a system design perspective and as a senior software developer with architecture level experience I am capable of making such judgments.
I'm not sure what it might be like for comparitively inexperienced developers, but I would expect that AI's capacity for infinite patience allows them to ask as many questions as they need to get a clear mental model of what's happening, so if I were mentoring such a person in this age of AI I would drill into them on how to interact with AIs to ensure they have this clarity before the AI starts implementing anything.
The difference between vibe coding and highly accelerated agentic development is having the expertise and judgment to ensure you're building properly sound software.
(Before someone asks: "not using it right" could mean a lot of things, but intentionally constraining its search by telling it how to do everything is one example. Or by not giving it a way to hill-climb: no tests, no iteration on a solution, etc.)