Anyone else run into this? The inconsistency is maddening. Claude will refuse to write a simple three-line script to scrape a public website (safety/ethics), but then happily write a complex, multi-step automation that involves the same data source if you frame it as a "data analysis exercise" with a hypothetical CSV.
It feels less about capability and more about how the request triggers its internal filters.
From a practical standpoint, I've noticed:
* **Direct vs. Indirect:** Asking "scrape example.com" gets a refusal. Asking "write a script that processes this HTML string (from a file I pretend I have)" works fine.
* **Specificity is key:** Vague tasks seem to raise more flags. A detailed, technical prompt for a complex job often sails through.
* **The "Academic" loophole:** Framing something as a theoretical example or for educational purposes has a much higher success rate, even for simple things.
This makes it unreliable for straightforward, real-world scripting. You waste time re-prompting to find the magic wording that doesn't set off alarms.
// chris
metrics not myths
Spot on about the filters. It's like navigating a CRM's lead scoring rules - you learn what triggers the "mark as spam" flag and work around it.
I've had the same thing with email copy. Ask for a promotional blast targeting a scraped list? Refusal. Ask for a "template for re-engagement, assuming you have a list of opted-in contacts from a trade show" - it writes the whole campaign, personalization fields and all. The *assumption* changes everything.
Your point on specificity is key. I wonder if the vague prompts get hit by a broader, more cautious filter, while a technical spec looks like a legitimate project. Still, it shouldn't be our job to reverse-engineer the guardrails.
Marketing ops nerd
You're describing the exact reason I don't use these tools for anything that needs to be reliable in a production context. The behavior you're seeing is a direct result of having safety filters bolted on after the model was trained, not designed into its core function. It's a pattern-matching game, not a reasoning one.
Your "academic loophole" observation is spot on. I've seen the same thing with database connectors. Ask for a script to pull data from a live public API and you get a lecture. Ask for "a Python class that handles pagination and rate limiting for a REST API, using example.com as a placeholder base URL" and it'll spit out perfect, production-ready code with retry logic. It's absurd.
The real cost isn't just the re-prompting time. It's that you can't document or automate a process that depends on this kind of linguistic jiu-jitsu to work. What passes today might get flagged in next week's update.