Christian Rackerseder argues that the real axis for testing decisions isn't integration versus end-to-end, it's control: whether a team can make a dependency predictable enough for a given test and actually act when it fails.
This is a working example of using red/green testing to fix a bug - one that starts in the issue description and lives in the code. You can fix the issue, but the bug remains because it's part of an unexamined specification. Testing - and caring - are the fix.
Junior programmers mess up paradigms because they think they're more experienced than they actually are. They end up blaming the system for not working the way they think it should. I trusted the wrong thing, just like a junior programmer: I assumed my tests were wrong, my results were wrong, that I was wrong, and I was - but the error was in the location of the problem.
Yury Selivanov recently released lat.md, a knowledge graph for your codebase, stored as user-editable markdown. The tool itself sounds useful enough, but checking it out and working out what it provides for your code was more useful than the tool's existence itself: effective agent management means going through an onboarding process.