Bandit of Borrowed Brilliance

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.

From Volume 1 of The AI Developer's Field Guide