Bandit of Borrowed Brilliance
I just tried a few approaches and this one worked
The Bandit doesn't usually copy in the obvious sense. They curate. They prompt an AI with examples from one project, patterns from another, and the result looks original but is fundamentally assembled from other people's work without much understanding. The gap between apparent capability and actual understanding holds exactly until someone asks them to modify, debug, or extend the code they 'wrote.'
Symptom
Sudden, inexplicable jumps in code sophistication. Code that's good but doesn't match the developer's demonstrated skill level. Evasive about process. Can defend correctness but not design philosophy, because the design philosophy belongs to whoever originally wrote the code the AI remixed.
Why It Matters
Borrowed solutions are unmaintainable by the Bandit themselves. The team ends up maintaining code its nominal author can't explain. Over time, senior developers question everything the Bandit produces, poisoning the review process.
What the Chapter Gives You
Why design reviews should require walking through decision-making, not just the final solution, and how pair programming during design reveals the understanding gap quickly.
Want the full chapter? Grab the free cheat sheet, read an excerpt, or get the book.
Recognize this one in your codebase?
Free cheat sheet, excerpts, and interactive diagnostics.