Satu Perubahan Parameter AI Menghabiskan Saya $54/Bulan

Saya mempercayai Claude untuk membantu saya bermigrasi dari AWS Lambda ke Google Cloud Run. Migrasinya berjalan sempurna - layanan di-deploy, workflow berjalan, pengguna senang. Lalu saya mengecek tagihan API kami dan hampir jatuh dari kursi.

*Ini adalah bagian 3 dari seri engineering DIALOGUE saya. Kalau terlewat: [Bagian 1: Pengenalan DIALOGUE] dan [Bagian 2: Dari Periklanan ke Engineering] mencakup fondasinya.*

Ini adalah kisah tentang apa yang terjadi ketika kamu membiarkan AI menulis kode produksi tanpa eksplisit tentang constraint produksi. Spoiler: "buat berfungsi" dan "buat siap produksi" adalah request yang sangat berbeda.

Migrasi yang Terlalu Mulus

Setelah bergulat dengan AWS Lambda berbulan-bulan (cold start, batas layer, dan sebagainya), saya memutuskan untuk bermigrasi semuanya ke Google Cloud Run. Sebagai developer pragmatis (baca: males), saya merekrut Claude sebagai pair programmer saya.

"Bantu saya bermigrasi fungsi Lambda ini ke Cloud Run," kata saya. "Ini kode yang sudah ada."

Claude mengirim dengan indah. Dockerfile bersih, konfigurasi layanan proper, Cloud Workflows yang berfungsi. Migrasi hanya memakan satu hari alih-alih berminggu-minggu yang saya perkirakan. Saya girang!

Semuanya di-deploy dengan lancar. Layanan start up cepat. Pengguna membuat podcast tanpa masalah. Sukses, kan?

Lalu saya melihat sesuatu yang aneh di log kami:

```
[ERROR] Segment generation failed: Unexpected token in JSON
[RETRY] Attempting segment generation again...
[SUCCESS] Segment generated successfully
```

Sekitar 30% panggilan AI kami gagal pada percobaan pertama tapi berhasil saat retry. Bukan akhir dunia - logika retry saya berfungsi! Pengguna tidak menyadari masalah apa pun. Tapi wah, panggilan API ekstra itu bertambah.

Investigasi: Salahkan Migrasi?

Pikiran pertama saya adalah ada yang salah selama migrasi. Mungkin lingkungan Cloud Run yang baru berbeda? Masalah networking container? Saya menghabiskan berjam-jam membandingkan konfigurasi AWS dan GCP.

Semuanya terlihat identik. Prompt yang sama, logika retry yang sama, error handling yang sama. Jadi mengapa kami tiba-tiba mendapat respons JSON yang malformed?

Lalu saya mulai membandingkan kode yang sebenarnya. Ini yang saya temukan:

Versi AWS Lambda (berfungsi baik berbulan-bulan):

```python
response = anthropic.messages.create(
      model="claude-3-7-sonnet-20250219",
      temperature=0,  # Deterministic for JSON
      response_format=\{"type": "json_object"\},  # JSON mode
      system="You are a JSON generation assistant. Output only valid JSON.",
      messages=[\{"role": "user", "content": prompt\}]
)
```

Versi GCP Cloud Run (migrasi Claude):

```python
response = anthropic.messages.create(
    model="claude-3-7-sonnet-20250219",
    temperature=0.7,  # <-- Tunggu, apa?
    messages=[\{"role": "user", "content": prompt\}]
)
```

Itu dia. Temperature 0.7.

"Tapi itu default yang wajar!" mungkin kamu bilang. Dan kamu benar. Untuk penulisan kreatif, eksplorasi, brainstorming - 0.7 sangat masuk akal. Tapi untuk generasi JSON terstruktur? Itu bencana.

Bukti: JSON yang Kreatif

Setelah menambahkan logging detail untuk menangkap respons AI yang sebenarnya, saya menemukan persis apa yang terjadi. Ini yang Claude kembalikan pada temperature 0.7:

```
Here's the podcast segment you requested:

\{
  "title": "The Rise of AI Podcasting",
  "content": "Welcome back, listeners! Today we're diving into something really fascinating...",
  "duration": 120
\}

I hope this segment captures what you were looking for!
```

Lihat masalahnya? Claude berkreasi dengan format respons. Kadang hanya JSON, kadang JSON dengan komentar yang membantu, kadang JSON dibungkus dalam blok kode markdown. Pada temperature 0.7, ia berimprovisasi seperti musisi jazz padahal saya butuh metronom.

Blind Spot AI Pair Programming

Ini masalahnya tentang bekerja dengan AI sebagai pair programmer: ia sangat bagus membuat kode berfungsi, tapi tidak selalu mengoptimalkan untuk concern produksi kecuali kamu secara spesifik meminta.

Ketika saya bilang "migrasi fungsi Lambda ini ke Cloud Run," Claude fokus pada requirement migrasi:

- Buat berjalan di Cloud Run

- Tangani input dan output yang sama

- Pertahankan fungsionalitas yang sama

- Optimasi untuk efisiensi produksi

Claude memilih temperature 0.7 karena itu "default yang wajar" untuk aplikasi AI. Dan memang! Untuk kebanyakan use case, 0.7 memberikan keseimbangan kreativitas dan konsistensi yang bagus.

Tapi ini yang saya pelajari: AI tidak tahu constraint produksi spesifikmu kecuali kamu memberitahunya.

Kode AWS asli saya menggunakan temperature 0 DAN JSON mode karena saya sudah belajar (dengan cara yang sulit) bahwa generasi JSON membutuhkan output deterministik dan formatting eksplisit. Tapi selama migrasi, saya tidak pernah secara eksplisit bilang "ini untuk generasi data terstruktur" atau "pertahankan semua optimisasi spesifik JSON."

Jadi Claude menulis kode yang berfungsi sempurna dengan default yang masuk akal. Masalahnya bukan AI — tapi requirement saya yang tidak lengkap.

Perbaikannya: Spesifik dengan AI

Setelah saya mengidentifikasi masalah, saya kembali ke Claude dengan requirement yang lebih baik:

"Bantu saya memperbaiki kode ini. Ini untuk generasi JSON di produksi. Saya butuh 100% reliabilitas, nol kreativitas. Gunakan temperature 0 dan optimisasi lain untuk data terstruktur."

Claude langsung menyarankan:

```python
response = anthropic.messages.create(
    model="claude-3-5-sonnet",
    temperature=0,  # Deterministic outputs
    response_format=\{"type": "json_object"\},  # JSON mode
    system="You are a JSON generation assistant. Output only valid JSON.",
    messages=[\{"role": "user", "content": prompt\}]
)
```

Tunggu, Claude melewatkan JSON mode yang kami punya! (Inilah yang terjadi ketika kamu tidak secara eksplisit menyebutkan setiap requirement produksi selama migrasi!)

Tingkat keberhasilan melompat dari 70% ke 99,9%. Sisa 0,1%? Network timeout. Tidak bisa menyalahkan Claude untuk itu.

Bedanya? Kali ini saya eksplisit tentang constraint produksi. Saya tidak hanya meminta migrasi — saya meminta kode yang dioptimalkan untuk produksi dan fokus pada reliabilitas.

Biaya Nyata dari Default yang "Wajar"

Biarkan saya rincikan berapa sebenarnya biaya pengaturan temperature yang "wajar" ini:

- Generasi podcast harian: ~200

- Tingkat kegagalan: 30% membutuhkan retry

- Panggilan API ekstra per hari: 60 panggilan gagal yang perlu retry

- Pemborosan bulanan: ~1.800 panggilan API yang tidak perlu

- Harga Claude 3.7 Sonnet: $3 input + $15 output per juta token

- Rata-rata token per panggilan: ~2.000 input + 1.500 output

- Biaya per retry: ~$0,03 per percobaan gagal

- Kelebihan biaya bulanan: ~$54 dalam panggilan API terbuang

Tapi biaya nyata bukan hanya $54/bulan. Setiap retry menambahkan 3-5 detik ke waktu generasi. Pengguna menunggu lebih lama, instance Cloud Run saya berputar lebih sering, dan saya membakar kuota lebih cepat.

Kuncinya? Ini semua terjadi karena saya mempercayai AI untuk membuat keputusan produksi tanpa memberikan konteks produksi. Kasus klasik "berfungsi" vs "berfungsi secara efisien."

Apa yang Saya Pelajari Tentang AI Pair Programming

1. Eksplisit Tentang Requirement Produksi

"Buat berfungsi" menghasilkan kode fungsional. "Buat berfungsi secara efisien di produksi dengan constraint ini" menghasilkan kode yang dioptimalkan. AI bagus dalam menyelesaikan masalah yang kamu deskripsikan, bukan masalah yang ada di pikiranmu.

2. AI Menggunakan Default "Wajar", Bukan "Optimal"

Temperature 0.7 wajar untuk kebanyakan aplikasi AI. Tapi sistem produksi sering membutuhkan optimisasi spesifik seperti temperature 0 DAN JSON mode. AI tidak akan mempertahankan ini kecuali kamu secara eksplisit menyebutkannya.

3. Code Review Berlaku untuk Kode yang Dihasilkan AI Juga

Hanya karena AI yang menulisnya tidak berarti siap produksi. Saya seharusnya menangkap ini saat code review, tapi saya terlalu fokus pada apakah migrasinya berfungsi sehingga tidak mengaudit parameternya.

4. Konteks Lebih Penting dari yang Kamu Kira

Kode AWS asli saya memiliki temperature 0 DAN JSON mode untuk alasan yang baik — dipelajari melalui pengalaman yang menyakitkan. Selama migrasi, konteks itu hilang karena saya tidak secara eksplisit menyebutkannya. Sekarang saya mendokumentasikan "mengapa" di balik setiap parameter dan fitur.

Workflow AI Pair Programming Saya yang Baru

Sekarang ketika saya bekerja dengan AI pada kode produksi, saya jauh lebih eksplisit tentang constraint:

Sebelum:

"Migrasi fungsi Lambda ini ke Cloud Run"

Sekarang:

"Migrasi fungsi Lambda ini ke Cloud Run. Ini untuk generasi JSON produksi - utamakan reliabilitas di atas kreativitas. Gunakan temperature 0, JSON mode jika tersedia, dan optimisasi lain untuk output data terstruktur."

Ini konfigurasi yang dioptimalkan untuk produksi yang Claude bantu saya buat:

```python
def get_ai_json_response(prompt: str) -> dict:
    """Production-optimized JSON generation with AI"""
    response = anthropic.messages.create(
        model="claude-sonnet-4-20250514",
        temperature=0,  # Zero creativity for structured data
        response_format=\{"type": "json_object"\},  # Force JSON mode
        system="You are a JSON generation assistant. Output only valid JSON.",
        messages=[\{
            "role": "user",
            "content": f"{prompt\}\n\nRespond with valid JSON only."
        }]
    )

    # Explicit error handling for production
    try:
        return json.loads(response.content[0].text)
    except json.JSONDecodeError as e:
        logger.error(f"JSON parse failed: \{e\}")
        logger.error(f"Raw response: {response.content[0].text}")
        raise
```

Bedanya? Saya memberikan AI konteks yang dibutuhkan untuk mengoptimalkan use case spesifik saya.

Hasilnya

Biaya API 30% lebih rendah, generasi 40% lebih cepat. Semua dari satu percakapan di mana saya benar-benar spesifik tentang arti "siap produksi".

Yang lucu? Bahkan generasi dialog "kreatif" kami menggunakan temperature 0. Ternyata deterministik tidak berarti membosankan — artinya reliable. Percakapan tetap terdengar natural karena prompt dan riset konten yang memberikan variasi, bukan fluktuasi temperature acak.

Ternyata AI pair programming berfungsi dengan baik ketika kamu ingat itu tetap programming — presisi dalam requirement menghasilkan presisi dalam hasilnya.

Pernahkah asisten AI membuat pilihan yang "wajar" yang ternyata benar-benar salah untuk use case kamu? Saya ingin mendengar war story-mu — saya curiga kita semua pernah tergigit oleh default yang masuk akal di suatu titik :)

Salam,

Chandler

Ingin membuat podcast AI kamu sendiri dengan JSON yang dijamin valid? Coba DIALOGUE — 2 kredit gratis untuk memulai! :P

Bagian 3 dari Seri Engineering DIALOGUE. Masih belajar bahwa "buat berfungsi" dan "buat berfungsi secara efisien" adalah request yang benar-benar berbeda. Ikuti lebih banyak petualangan AI pair programming di chandlernguyen.com.

Selanjutnya dalam seri: Datang dalam sekitar 7 hari - "From 3 Minutes to 500ms: The Signup Bug That Made No Sense"