I'm building EduTrack, a school management system, and asked Gemini CLI to check my Django views for errors and report back.
It didn't report anything. It rewrote the file.
Here's what happened: I have two Django apps, academics and students. The agent decided some student-related views belonged in students instead of academics — which honestly wasn't a bad instinct — but instead of asking or reporting that observation, it just duplicated the functions across both apps with different implementations.
I ended up with two versions of edit_student: one in academics/views.py that returned a redirect, another in students/views.py that returned JsonResponse. Two versions of delete_student, same story. Some views had @login_required, others quietly didn't. Nothing crashed — which is exactly what made it dangerous. Silently broken code is worse than code that throws an obvious error, because it ships.
The real lesson:
"Check for errors and report" and "fix the errors" are fundamentally different instructions. An agent that isn't explicitly told read-only will, by default, assume permission to act. And once it starts acting, the scope of its edits tends to expand well past the original bug — touching anything it judges as "related."
If you're delegating to an AI agent:
Be explicit: "list issues, do not edit anything" vs "fix this specific function"
Review diffs before trusting the result, especially across multiple files
Treat broad instructions ("check for errors," "clean this up") as an invitation for the agent to make architectural decisions you didn't sign off on
I spent the next hour doing something more valuable than writing new code: reading every change, deciding which app should actually own which views, and rebuilding the parts that needed real architectural intent — not just pattern-matching.
AI agents are powerful collaborators. But power without scope is how you end up debugging your debugger.