Darrell asked an AI assistant for the URL to some demo data. It pointed him towards the destroy path.
That was a funny moment to look back on. It was also a fairly clear reason to read the answer before using it.
When you're moving quickly, suggestions can become something you skim. The tool gives you a plausible route, a command or a chunk of code, and you want to keep working. Checking it feels like slowing the process down.
But in this case, the question and the answer were heading in very different directions. Darrell wanted to find data. The suggested path was for destroying it. Understanding what we were looking at mattered more than the confidence of the response.
I joked at the time that I might have a job for a little longer. Underneath that was a practical concern about accepting changes without reading them, particularly when several pieces of work are happening at once.
Speed gives you more output to review. You still need someone who can look at the proposal and ask whether it makes sense for the task.
I want to keep that check in the workflow, even when the request seems small. A URL can be wrong in a way that matters. So can a command that looks routine.
Before running a suggestion, understand what it will do. The time you spend reading a short answer is small compared with dealing with the wrong operation afterwards. This particular example was a good reminder for us.
