Okay, so I'm deep in yet another migration project—this time trying to get some custom automation scripts off the ground for a client's new RevOps stack. I was using Claude Code to help refactor some old Python scripts that handle API calls to, you guessed it, a CRM (we're moving from Zoho to HubSpot, don't ask 😅).
I asked for a simple way to handle an API key for an external service within the script. Just a placeholder, really. What Claude suggested… well, it raised every single red flag my migration-scarred brain possesses.
Here’s the snippet it provided:
```python
# WARNING: This is for example only. Do not use in production!
API_KEY = "sk_live_1234567890abcdef" # Hardcoded key
headers = {"Authorization": f"Bearer {API_KEY}"}
def make_request(url):
response = requests.get(url, headers=headers)
return response.json()
```
And then it followed up with a *truly* wild "more secure" alternative, suggesting I could "obfuscate" the key by splitting it across environment variables like this:
```python
import os
# "More secure" method
PART_1 = os.getenv("KEY_PART_1", "sk_live_12")
PART_2 = os.getenv("KEY_PART_2", "34567890ab")
API_KEY = PART_1 + PART_2
```
I mean… come on! 🤦♂️
This is the kind of "security" I'd expect from a forum post in 2010. The fact that it's being suggested by an AI tool billed for code review and best practices in 2025 is genuinely concerning. It's teaching fundamentally bad patterns:
* Hardcoding secrets directly in source code (with a live key example, no less!).
* The illusion that splitting a key across multiple env variables is "secure" obfuscation, rather than just a minor inconvenience.
* No mention of using a proper secrets manager, even as a recommendation.
* The default fallback values *are the actual key parts*, completely negating the point of environment variables!
After years of moving data between platforms, I've seen firsthand what happens when auth gets sloppy. You end up with keys committed to GitHub, leaked in logs, or shared in screenshots. A proper suggestion would have emphasized using a single, properly scoped environment variable loaded via a library like `python-dotenv` in development, and a vault service in production, with no default fallback that exposes the key.
Has anyone else run into Claude Code suggesting these kinds of outdated or just plain insecure patterns? I'm starting to think its training data for "simple examples" is poisoned by all those old, bad Stack Overflow answers we've been trying to forget.
Hopefully last migration.