Isang AI Parameter Change ang Nagkahalaga sa Akin ng $54/Buwan

Nagtiwala ako kay Claude para tulungan akong lumipat mula AWS Lambda sa Google Cloud Run. Perpekto ang migration — nag-deploy ang mga services, nag-execute ang mga workflows, masaya ang mga users. Tapos chineck ko ang API bills namin at halos mahulog ako sa upuan ko.

*Ito ay part 3 ng aking DIALØGUE engineering series. Kung namiss mo sila: [Part 1: DIALØGUE Introduction] at [Part 2: From Advertising to Engineering] ang nagsasabi ng pundasyon.*

Ito ang kwento ng mangyayari kapag hinahayaan mong sumulat ang AI ng production code nang hindi eksakto sa production constraints. Spoiler alert: ang "gawing gumagana" at "gawing production-ready" ay magkaibang kahilingan talaga.

Ang Migration na Masyadong Maganda

Pagkatapos makipaglaban sa AWS Lambda nang ilang buwan (cold starts, layer limits, at iba pa), nagdesisyon akong ilipat ang lahat sa Google Cloud Run. Bilang isang pragmatic developer (sabi nga: tamad), inenlista ko si Claude bilang pair programmer ko.

"Tulungan mo akong i-migrate ang mga Lambda functions na ito sa Cloud Run," sabi ko. "Narito ang existing code."

Nagdeliver nang maganda si Claude. Malinis na Dockerfiles, tamang service configurations, gumaganang Cloud Workflows. Isang araw lang ang migration sa halip na ilang linggo na inaasahan ko. Sobrang tuwa ko!

Maayos na nag-deploy ang lahat. Mabilis na nag-start ang mga services. Gumagawa ng podcasts ang mga users nang walang problema. Tagumpay, di ba?

Tapos may napansin akong kakaiba sa logs namin:

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

Mga 30% ng AI calls namin ang nafe-fail sa unang pagsubok pero nagta-tagumpay sa retry. Hindi naman katapusan ng mundo — gumagana ang retry logic ko! Hindi napapansin ng mga users ang anumang issues. Pero grabe, tumataas talaga ang mga extra API calls na iyon.

Ang Imbestigasyon: Sisihin ang Migration?

Ang unang iniisip ko ay may nagkamali sa panahon ng migration. Siguro iba ang bagong Cloud Run environment? Container networking issues? Ilang oras akong nagkumpara ng AWS at GCP configurations.

Magkapareho ang lahat. Parehong prompts, parehong retry logic, parehong error handling. Kaya bakit biglang nakakakuha kami ng malformed JSON responses?

Tapos nagsimula akong ikumpara ang aktwal na code. Eto ang nahanap ko:

AWS Lambda version (gumagana nang maayos sa loob ng ilang buwan):

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

GCP Cloud Run version (migration ni Claude):

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

Nandiyan na. Temperature 0.7.

"Pero reasonable default naman iyon!" baka sabihin mo. At tama ka. Para sa creative writing, exploration, brainstorming — 0.7 ay perpektong sensible. Pero para sa structured JSON generation? Isa itong sakuna.

Ang Smoking Gun: Creative JSON

Pagkatapos magdagdag ng detalyadong logging para makuha ang aktwal na AI responses, nahanap ko ang eksakto kung ano ang nangyayari. Eto ang binabalik ni Claude sa 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!
```

Nakikita mo ba ang problema? Si Claude ay naging creative sa response format. Minsan pure JSON, minsan JSON na may helpful commentary, minsan JSON na naka-wrap sa markdown code blocks. Sa temperature 0.7, nag-i-improvise siya tulad ng jazz musician samantalang kailangan ko ng metronome.

Ang AI Pair Programming Blind Spot

Eto ang bagay tungkol sa pagtatrabaho kasama ang AI bilang pair programmer: sobrang galing nito sa pagpapaandar ng code, pero hindi nito kinakailangang i-optimize para sa production concerns maliban kung espesipikong hihingin mo.

Noong sinabi kong "i-migrate ang Lambda function na ito sa Cloud Run," nag-focus si Claude sa migration requirements:

- ✅ Gawin itong tumakbo sa Cloud Run

- ✅ Hawakan ang parehong inputs at outputs

- ✅ Panatilihin ang parehong functionality

- ❌ I-optimize para sa production efficiency

Pinili ni Claude ang temperature 0.7 dahil isa itong "reasonable default" para sa AI applications. At totoo iyon! Para sa karamihan ng use cases, nagbibigay ang 0.7 ng magandang balanse ng creativity at consistency.

Pero eto ang natutunan ko: **Hindi alam ng AI ang iyong specific production constraints maliban kung sasabihin mo.**

Ang original kong AWS code ay gumamit ng temperature 0 AT JSON mode dahil natutunan ko (nang mahirap na paraan) na ang JSON generation ay nangangailangan ng parehong deterministic outputs at explicit formatting. Pero sa panahon ng migration, hindi ko kailanman eksplisitong sinabi na "ito ay para sa structured data generation" o "panatilihin ang lahat ng JSON-specific optimizations."

Kaya nagsulat si Claude ng perpektong gumaganang code na may sensible defaults. Ang problema ay hindi ang AI — ito ay ang hindi kumpletong requirements ko.

Ang Fix: Maging Specific sa AI

Pagka-identify ko ng problema, bumalik ako kay Claude na may mas magandang requirements:

"Tulungan mo akong i-fix ang code na ito. Ito ay para sa JSON generation sa production. Kailangan ko ng 100% reliability, zero creativity. Gamitin ang temperature 0 at anumang iba pang optimizations para sa structured data."

Agad na nag-suggest si Claude:

```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}]
)
```

Teka, inalis ni Claude ang JSON mode na mayroon kami! (Ito ang mangyayari kapag hindi mo eksplisitong binanggit ang bawat production requirement sa panahon ng migration!)

Tumalon ang success rate mula 70% sa 99.9%. Ang natitirang 0.1%? Network timeouts. Hindi mo masisisi si Claude para doon.

Ang pagkakaiba? Sa pagkakataong ito, eksplisito ako sa production constraints. Hindi lang ako humingi ng migration — humingi ako ng production-optimized, reliability-focused code.

Ang Tunay na Halaga ng "Reasonable" Defaults

Hayaan mong i-break down kung magkano talaga ang nagastos ng "reasonable" temperature setting na ito:

- **Daily podcast generations**: ~200

- **Failure rate**: 30% na nangangailangan ng retries

- **Extra API calls bawat araw**: 60 failed calls na kailangan ng retries

- **Monthly waste**: ~1,800 hindi kailangang API calls

- **Claude 3.7 Sonnet pricing**: $3 input + $15 output per million tokens

- **Average tokens bawat call**: ~2,000 input + 1,500 output

- **Cost kada retry**: ~$0.03 bawat failed attempt

- **Monthly overage**: ~$54 sa nasayang na API calls

Pero ang tunay na gastos ay hindi lang ang $54/buwan. Bawat retry ay nagdagdag ng 3-5 segundo sa generation time. Mas matagal na naghihintay ang mga users, mas madalas na nagsi-spin up ang Cloud Run instances ko, at mas mabilis akong nag-burn ng quota.

Ang pinakamasakit? Lahat ng ito ay nangyari dahil nagtiwala ako sa AI na gumawa ng production decisions nang hindi ko binibigyan ng production context. Classic case ng "gumagana" vs "gumaganang mahusay."

Ano ang Natutunan Ko Tungkol sa AI Pair Programming

1. Maging Eksplisito sa Production Requirements

Ang "gawing gumagana" ay nagbibigay sa iyo ng functional code. Ang "gawing gumaganang mahusay sa production na may mga constraints na ito" ay nagbibigay sa iyo ng optimized code. Magaling ang AI sa paglutas ng problemang inilalarawan mo, hindi ang problemang nasa isip mo.

2. Gumagamit ang AI ng "Reasonable" Defaults, Hindi "Optimal" na Mga Ito

Ang Temperature 0.7 ay reasonable para sa karamihan ng AI applications. Pero ang mga production systems ay madalas na nangangailangan ng specific optimizations tulad ng temperature 0 AT JSON mode. Hindi ito pananatilihin ng AI maliban kung eksplisitong babanggitin mo.

3. Ang Code Review ay Naaapply din sa AI-Generated Code

Dahil lang sinulat ng AI ay hindi ibig sabihin na production-ready na ito. Dapat ko sanang nahuli ito sa code review, pero sobrang naka-focus ako kung gumagana ba ang migration kaya hindi ko na-audit ang mga parameters.

4. Mas Mahalaga ang Context Kaysa sa Iniisip Mo

Ang original kong AWS code ay may temperature 0 AT JSON mode dahil sa mabuting dahilan — natutunan sa pamamagitan ng masakit na karanasan. Sa panahon ng migration, nawala ang context na iyon dahil hindi ko ito eksplisitong binanggit. Ngayon, dini-document ko ang "bakit" sa likod ng bawat parameter at feature.

Ang Bagong AI Pair Programming Workflow Ko

Ngayon kapag nagtatrabaho ako kasama ang AI sa production code, mas eksplisito na ako sa mga constraints:

**Dati:**

"I-migrate ang Lambda function na ito sa Cloud Run"

**Ngayon:**

"I-migrate ang Lambda function na ito sa Cloud Run. Ito ay para sa production JSON generation — unahin ang reliability kaysa creativity. Gamitin ang temperature 0, JSON mode kung available, at anumang iba pang optimizations para sa structured data output."

Narito ang production-optimized config na tinulungan akong gawin ni Claude:

```python
def get_ai_json_response(prompt: str) -> dict:
    """Production-optimized JSON generation na may AI"""
    response = anthropic.messages.create(
        model="claude-sonnet-4-20250514",
        temperature=0,  # Zero creativity para sa 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 para sa 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
```

Ang pagkakaiba? Binigyan ko ang AI ng context na kailangan nito para i-optimize para sa specific use case ko.

Ang Mga Resulta

30% na mas mababang API costs, 40% na mas mabilis na generation. Lahat mula sa isang usapan kung saan talagang specific ako sa kung ano ang ibig sabihin ng "production-ready."

Ang nakakatawa? Kahit ang "creative" naming dialogue generation ay gumagamit ng temperature 0. Lumabas na ang deterministic ay hindi ibig sabihin na boring — ibig sabihin ay reliable. Natural pa rin ang tunog ng mga usapan dahil ang mga prompts at content research ang nagbibigay ng variety, hindi ang random temperature fluctuations.

Lumabas na magaling ang AI pair programming kapag naaalala mong programming pa rin ito — ang precision sa requirements ay nagbibigay sa iyo ng precision sa mga resulta.

May naging experience ka na ba na ang AI assistant mo ay gumawa ng "reasonable" na pagpili na lumabas na ganap na mali para sa use case mo? Gusto kong marinig ang mga war stories mo — suspetsa ko na lahat tayo ay nasaktan na ng sensible defaults sa isang punto :)

Maraming salamat,

Chandler

Gusto mong gumawa ng sarili mong AI podcasts na may guaranteed valid JSON? Subukan ang DIALØGUE — 2 libreng credits para magsimula! :P

Part 3 ng DIALØGUE Engineering Series. Natututo pa rin na "gawing gumagana" at "gawing gumaganang mahusay" ay ganap na magkaibang kahilingan. Sundan ang higit pang AI pair programming adventures sa chandlernguyen.com.

**Susunod sa series**: Paparating sa mga 7 araw - "From 3 Minutes to 500ms: The Signup Bug That Made No Sense"