Astra for Coding: हम यह फिर से क्यों कर रहे हैं?

मूल लेख ↗ Hacker News चर्चा ↗

GPT‑6 Astra जैसे नए OpenAI coding models लंबे, जटिल software tasks में प्रभावशाली रूप से सक्षम हैं, फिर भी कई engineers रिपोर्ट करते हैं कि वे अब over-engineer करते हैं, sub-agents spawn करते हैं, बड़े test suites चलाते हैं, और unreadable “slop” code बनाते हैं, जबकि पहले के models की तुलना में कहीं अधिक tokens और समय खर्च करते हैं। Commenters का तर्क है कि हाल का training autonomous, long-horizon task completion के लिए optimize लगता है, न कि human-friendly, concise code के लिए, जिससे ये agents शक्तिशाली लेकिन ठीक से socialized न किए गए coworkers जैसे महसूस होते हैं जो guidance का विरोध करते हैं और scope को नज़रअंदाज़ करते हैं। कुछ लोग इन्हें greenfield prototypes या tightly scoped features के लिए, मजबूत tests और specs के साथ, transformative मानते हैं, जबकि अन्य पाते हैं कि बिना सावधानीपूर्ण constraints और review के, वे जल्दी code quality गिरा देते हैं और teams को धीमा कर देते हैं।

Astra के कोडिंग के लिए समग्र भाव

  • कई लोगों को Astra सक्षम लेकिन निराशाजनक लगता है: लंबे, जटिल कार्यों में मजबूत, लेकिन ओवरइंजीनियरिंग, स्कोप क्रीप, और unreadable “slop” कोड की प्रवृत्ति के साथ।
  • कई उपयोगकर्ताओं ने पहले के मॉडलों (जैसे 5.6-series, Luna, Sonnet) पर वापस लौटकर बेहतर cost–benefit और अधिक पूर्वानुमेय व्यवहार का हवाला दिया।
  • कुछ लोग बताते हैं कि tightly guided होने पर Astra greenfield या छोटे-से-मध्यम प्रोजेक्ट्स में वास्तविक उत्पादकता बढ़ाता है।

कोड गुणवत्ता, पठनीयता, और “slop”

  • बार-बार शिकायतें: घना, अत्यधिक abstract, खराब ढंग से formatted कोड; massive ternaries; सरल कार्यों के पुनर्लेखन; tests का implementation details से कड़ा coupling।
  • जब Astra (और ऐसे ही मॉडल) मौजूदा, अच्छी तरह से structured codebases में काम करते हैं, output quality बेहतर होती है और existing patterns का पालन करती है।
  • कुछ उपयोगकर्ता low-stakes या “disposable” प्रोजेक्ट्स के लिए AI code पढ़ना जानबूझकर नहीं करते; अन्य कहते हैं कि जल्दी review न करने से code unmaintainable हो जाता है और भविष्य में slowdown आता है।

टूल उपयोग, Python scripts, और tests

  • Models increasingly built-in edit tools, sed, आदि की बजाय सामान्य “patching tool” के रूप में Python (या अन्य scripts) लिखना पसंद करते हैं।
  • इसे इस तरह देखा जाता है:
    • कुछ लोगों के अनुसार token-efficient और bulk edits के लिए scalable।
    • दूसरों के अनुसार review करना कठिन, error-prone, और अक्सर overkill।
  • Astra प्रवृत्त होता है:
    • छोटे बदलावों के लिए full test suites बार-बार चलाने की ओर।
    • बहुत सारे subagents और auxiliary artifacts (HTML reports, docs, workflows) बनाने की ओर, जिससे cost और wall-clock time बढ़ जाता है जब तक इसे constrained न किया जाए।

Long-horizon agents और training incentives

  • कई लोगों को संदेह है कि हाल का training “complete long tasks autonomously” को optimize करता है, न कि “clean, human-readable code” बनाने को।
  • परिणाम: computer use, orchestration, और complex debugging में अच्छा, लेकिन एक cooperative teammate होने में बदतर जो questions पूछे या code को simple रखे।
  • चिंता है कि providers को verbose, token-heavy, self-gilding behavior की ओर वित्तीय प्रोत्साहन मिलता है।

प्रक्रिया, specs, और human role

  • मजबूत सहमति: सफलता इस पर निर्भर करती है:
    • स्पष्ट, tightly scoped specs या “groomed epics”।
    • मजबूत testing, architecture, और API boundaries।
    • human oversight जो line-by-line code की बजाय design, interfaces, और constraints पर केंद्रित हो।
  • इस पर असहमति है कि क्या यह workflow लंबे समय में वास्तव में समय बचाता है या सिर्फ effort को implementation से review और refactoring में स्थानांतरित करता है।