एक AI Parameter Change ने मुझे $54/Month Cost किया
मुझे लगा मेरा Cloud Run migration flawless था — जब तक एक single AI parameter — temperature 0.7 की जगह 0 — ने 30% failed API calls और $54/month की बर्बादी नहीं कर दी।
मैंने Claude पर भरोसा किया AWS Lambda से Google Cloud Run migrate करने में। Migration perfectly गई — services deploy हुईं, workflows execute हुए, users खुश थे। फिर मैंने API bills check किए और लगभग कुर्सी से गिर गया।
*यह मेरी DIALØGUE engineering series का part 3 है। अगर आपने miss किया: [Part 1: DIALØGUE Introduction] और [Part 2: From Advertising to Engineering] foundation cover करते हैं।*
यह उस बात की कहानी है जो होती है जब आप AI को production code लिखने देते हैं बिना production constraints के बारे में explicit हुए। Spoiler alert: "make it work" और "make it production-ready" बहुत अलग requests हैं।
वह Migration जो बहुत अच्छी तरह गई
AWS Lambda से महीनों जूझने के बाद (cold starts, layer limits, सब कुछ), मैंने सब कुछ Google Cloud Run पर migrate करने का फैसला किया। एक pragmatic developer होने के नाते (पढ़ें: आलसी), मैंने Claude को अपना pair programmer बनाया।
"इन Lambda functions को Cloud Run पर migrate करने में मदद करो," मैंने कहा। "यह existing code है।"
Claude ने beautifully deliver किया। Clean Dockerfiles, proper service configurations, working Cloud Workflows। Migration में सिर्फ एक दिन लगा, हफ्ते नहीं जैसा मैंने expect किया था। मैं thrilled था!
सब कुछ smoothly deploy हुआ। Services fast start हुईं। Users बिना किसी issue के podcasts बना रहे थे। Success, है ना?
फिर मैंने logs में कुछ odd notice किया:
```
[ERROR] Segment generation failed: Unexpected token in JSON
[RETRY] Attempting segment generation again...
[SUCCESS] Segment generated successfully
```
हमारी लगभग 30% AI calls first attempt पर fail हो रही थीं लेकिन retry पर succeed हो रही थीं। दुनिया का अंत नहीं — मेरी retry logic काम कर रही थी! Users को कोई issue नहीं दिख रहे थे। लेकिन यार, वे extra API calls जुड़ रहे थे।
Investigation: Migration को दोष दें?
मेरा पहला विचार था कि migration के दौरान कुछ गड़बड़ हुई। शायद new Cloud Run environment different था? Container networking issues? मैंने AWS और GCP configurations की घंटों तुलना की।
सब कुछ identical दिखा। Same prompts, same retry logic, same error handling। तो हम अचानक malformed JSON responses क्यों पा रहे थे?
फिर मैंने actual code की तुलना करना शुरू किया। यह मिला:
AWS Lambda version (महीनों से ठीक काम कर रही थी):
```python
response = anthropic.messages.create(
model="claude-3-7-sonnet-20250219",
temperature=0, # JSON के लिए Deterministic
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 (Claude की migration):
```python
response = anthropic.messages.create(
model="claude-3-7-sonnet-20250219",
temperature=0.7, # <-- रुको, यह क्या है?
messages=[\{"role": "user", "content": prompt\}]
)
```
वह था। Temperature 0.7।
"लेकिन यह एक reasonable default है!" आप कह सकते हैं। और आप सही होंगे। Creative writing, exploration, brainstorming के लिए — 0.7 perfectly sensible है। लेकिन structured JSON generation के लिए? यह disaster है।
Smoking Gun: Creative JSON
actual AI responses capture करने के लिए detailed logging जोड़ने के बाद, मुझे exactly पता चला क्या हो रहा था। यह Claude temperature 0.7 पर return कर रहा था:
```
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!
```
Problem देखी? Claude response format के साथ creative हो रहा था। कभी-कभी सिर्फ JSON, कभी-कभी helpful commentary के साथ JSON, कभी-कभी markdown code blocks में wrap किया गया JSON। Temperature 0.7 पर, यह jazz musician की तरह improvise कर रहा था जबकि मुझे metronome की ज़रूरत थी।
AI Pair Programming का Blind Spot
यहाँ बात यह है कि AI के साथ pair programmer के रूप में काम करना: यह code काम करवाने में incredibly good है, लेकिन यह ज़रूरी नहीं कि production concerns के लिए optimize करे जब तक आप specifically न पूछें।
जब मैंने कहा "इस Lambda function को Cloud Run पर migrate करो," Claude ने migration requirements पर focus किया:
- ✅ Cloud Run पर run कराना - ✅ Same inputs और outputs handle करना - ✅ Same functionality maintain करना - ❌ Production efficiency के लिए optimize करना
Claude ने temperature 0.7 choose किया क्योंकि यह AI applications के लिए एक "reasonable default" है। और है! Most use cases के लिए, 0.7 creativity और consistency का अच्छा balance देता है।
लेकिन मैंने जो सीखा: **AI आपके specific production constraints नहीं जानता जब तक आप बताएं नहीं।**
मेरे original AWS code ने temperature 0 AND JSON mode use किया था क्योंकि मैंने (the hard way) सीखा था कि JSON generation को दोनों deterministic outputs और explicit formatting चाहिए। लेकिन migration के दौरान, मैंने कभी explicitly नहीं कहा "यह structured data generation के लिए है" या "JSON-specific optimizations maintain करो।"
इसलिए Claude ने perfectly functional code sensible defaults के साथ लिखा। Problem AI नहीं था — यह मेरी incomplete requirements थीं।
Fix: AI के साथ Specific होना
जैसे ही मैंने problem identify की, मैं Claude के पास better requirements के साथ वापस गया:
"इस code को fix करने में मदद करो। यह production में JSON generation के लिए है। मुझे 100% reliability चाहिए, zero creativity। Temperature 0 use करो और structured data के लिए कोई other optimizations।"
Claude ने immediately suggest किया:
```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\}]
)
```
Wait, Claude ने JSON mode drop कर दिया जो हमारे पास था! (यही होता है जब आप migration के दौरान हर production requirement explicitly mention नहीं करते!)
Success rate 70% से 99.9% पर jump की। Remaining 0.1%? Network timeouts। उनके लिए Claude को blame नहीं किया जा सकता।
फर्क? इस बार मैं production constraints के बारे में explicit था। मैंने सिर्फ migration नहीं माँगा — मैंने production-optimized, reliability-focused code माँगा।
"Reasonable" Defaults की Real Cost
चलिए break down करते हैं कि यह "reasonable" temperature setting actually हमें क्या cost हुई:
- **Daily podcast generations**: ~200 - **Failure rate**: 30% requiring retries - **Extra API calls per day**: 60 failed calls needing retries - **Monthly waste**: ~1,800 unnecessary API calls - **Claude 3.7 Sonnet pricing**: $3 input + $15 output per million tokens - **Average tokens per call**: ~2,000 input + 1,500 output - **Cost per retry**: ~$0.03 per failed attempt - **Monthly overage**: ~$54 in wasted API calls
लेकिन real cost सिर्फ $54/month नहीं थी। हर retry ने generation time में 3-5 seconds जोड़े। Users लंबे wait कर रहे थे, मेरे Cloud Run instances ज़्यादा बार spin up हो रहे थे, और मैं quota तेज़ी से burn कर रहा था।
Kicker? यह सब इसलिए हुआ क्योंकि मैंने production context दिए बिना AI पर production decisions trust किया। Classic case of "it works" vs "it works efficiently।"
AI Pair Programming के बारे में मैंने क्या सीखा
1. Production Requirements के बारे में Explicit रहें
"Make it work" functional code देता है। "Make it work efficiently in production with these constraints" optimized code देता है। AI उस problem को solve करने में great है जो आप describe करते हैं, उस problem को नहीं जो आपके mind में है।
2. AI "Reasonable" Defaults Use करता है, "Optimal" नहीं
Temperature 0.7 most AI applications के लिए reasonable है। लेकिन production systems को अक्सर specific optimizations चाहिए जैसे temperature 0 AND JSON mode। AI इन्हें preserve नहीं करेगा जब तक आप explicitly mention नहीं करते।
3. Code Review AI-Generated Code पर भी Apply होता है
सिर्फ इसलिए कि AI ने लिखा, इसका मतलब यह नहीं कि यह production-ready है। मुझे code review के दौरान यह catch करना चाहिए था, लेकिन मैं इतना focused था कि migration काम करती है कि मैंने parameters audit नहीं किए।
4. Context जितना आप सोचते हैं उससे ज़्यादा Matter करता है
मेरे original AWS code में temperature 0 AND JSON mode था अच्छे कारणों से — painful experience से सीखा। Migration के दौरान, वह context खो गया क्योंकि मैंने explicitly mention नहीं किया। अब मैं हर parameter और feature के पीछे "why" document करता हूँ।
मेरा New AI Pair Programming Workflow
अब जब मैं production code पर AI के साथ काम करता हूँ, मैं constraints के बारे में बहुत ज़्यादा explicit हूँ:
**पहले:**
"इस Lambda function को Cloud Run पर migrate करो"
**अब:**
"इस Lambda function को Cloud Run पर migrate करो। यह production JSON generation के लिए है — creativity पर reliability को prioritize करो। Temperature 0 use करो, JSON mode अगर available हो, और structured data output के लिए कोई other optimizations।"
यहाँ production-optimized config है जो Claude ने build करने में मेरी मदद की:
```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, # Structured data के लिए Zero creativity
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."
}]
)
# Production के लिए Explicit error handling
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
```
फर्क? मैंने AI को वह context दिया जो उसे मेरे specific use case के लिए optimize करने के लिए चाहिए था।
Results
30% कम API costs, 40% faster generation। सब एक conversation से जिसमें मैं actually specific था कि "production-ready" का मतलब क्या है।
Funny बात? हमारी "creative" dialogue generation भी temperature 0 use करती है। Turns out deterministic का मतलब boring नहीं है — इसका मतलब reliable है। Conversations अभी भी natural sound करती हैं क्योंकि prompts और content research variety provide करते हैं, random temperature fluctuations नहीं।
Turns out AI pair programming अच्छा काम करता है जब आप याद रखते हैं कि यह अभी भी programming है — requirements में precision आपको results में precision देती है।
क्या आपके AI assistant ने कभी एक "reasonable" choice की जो आपके use case के लिए completely wrong निकली? मुझे आपकी war stories सुनना अच्छा लगेगा — मुझे लगता है हम सब कभी न कभी sensible defaults से bite हुए हैं :)
शुभकामनाओं सहित,
Chandler
अपने खुद के AI podcasts guaranteed valid JSON के साथ बनाना चाहते हैं? DIALØGUE try करें — शुरुआत के लिए 2 free credits! :P
DIALØGUE Engineering Series का Part 3। अभी भी सीख रहा हूँ कि "make it work" और "make it work efficiently" completely different requests हैं। chandlernguyen.com पर और AI pair programming adventures follow करें।
**Series में आगे**: लगभग 7 दिनों में आ रहा है - "From 3 Minutes to 500ms: The Signup Bug That Made No Sense"
