TIL: Claw confidently generated a working script... for the wrong cloud provider.

I was building a new ELT pipeline to ingest some Salesforce data into BigQuery and decided to test the capabilities of a popular coding assistant for a routine task: generating a Python script to upload a local CSV file to cloud storage as a staging step. The prompt was quite specific:

"Write a Python script that uses the Google Cloud client library to authenticate via a service account JSON key, read a CSV file from the local `/tmp/salesforce_export.csv`, and upload it to a Google Cloud Storage bucket named `staging-bucket` with the object name `salesforce/contacts.csv`. Include proper error handling."

The assistant responded promptly with a detailed, well-structured script. It included imports for `google.cloud.storage`, setup for the `Client` using `from_service_account_json`, a function with try-except blocks, and even a `blob.upload_from_filename` call. The code was syntactically correct and followed Google Cloud Python SDK conventions. I was initially impressed.

However, upon closer inspection, I noticed a critical flaw. The authentication method it used was not from the `google-cloud-storage` library at all. The script contained this line:

```python
from azure.identity import ClientSecretCredential
```

And later:

```python
credential = ClientSecretCredential(
tenant_id="your-tenant-id",
client_id="your-client-id",
client_secret="your-client-secret"
)
```

The assistant had confidently generated a working script for Azure Blob Storage, not Google Cloud Storage, despite the explicit request for Google Cloud libraries and a GCS bucket. It seamlessly blended correct GCS method calls (`blob.upload_from_filename`) with Azure Identity SDK authentication, creating a hybrid that would fail at runtime with a confusing `ModuleNotFoundError` for `azure.identity` or, if those packages were installed, a complete mismatch in credential object types.

The correct script, of course, should have used the `google.cloud.storage` client exclusively. The proper authentication block for a service account JSON key is:

```python
from google.cloud import storage

def upload_to_gcs(service_account_key_path, bucket_name, source_file_path, destination_blob_name):
try:
storage_client = storage.Client.from_service_account_json(service_account_key_path)
bucket = storage_client.bucket(bucket_name)
blob = bucket.blob(destination_blob_name)
blob.upload_from_filename(source_file_path)
print(f"File {source_file_path} uploaded to {destination_blob_name}.")
except Exception as e:
print(f"Failed to upload: {e}")
```

This failure is instructive for several reasons:
* **Contextual Hallucination:** The assistant likely has strong patterns for "cloud storage upload scripts" in its training data. The specific keywords "authenticate," "service account," and "JSON key" may have triggered an Azure pattern (which uses similar concepts like client secrets) more strongly than the Google Cloud pattern, even with "Google Cloud" in the prompt.
* **Syntactic Correctness Over Semantic Accuracy:** The script was valid Python and used real library methods, making it appear correct at a glance. The failure was semantic—the libraries and services were incoherently mixed.
* **The Danger of Assumed Context:** As a practitioner, I would spot the Azure import immediately. But a less experienced engineer might spend considerable time debugging why `pip install google-cloud-storage` didn't resolve the `azure.identity` import, or worse, install the Azure SDKs and then be baffled by credential errors.

This underscores the necessity of treating generated code as a first draft requiring rigorous, line-by-line validation, especially for infrastructure and cloud provider integrations where the cost of a mistake can be data exposure or pipeline failure. The assistant didn't fail to generate code; it failed to maintain a consistent technical context.