Mythos के साथ काम करना कैसा लगता है
Anthropic के नए Mythos/Fable AI coding agent की एक प्रशंसात्मक समीक्षा इस बात पर तीखी बहस छेड़ती है कि क्या ये बड़े language models वाकई कितने परिवर्तनकारी हैं। टिप्पणीकार multi-hour autonomous coding sprints और जटिल data visualizations जैसी प्रभावशाली उपलब्धियों को स्वीकार करते हैं, लेकिन buggy demos, unmaintainable code, ऊँची token लागत और भारी guardrails को इस बात के सबूत के रूप में इंगित करते हैं कि human oversight और सावधानीपूर्वक architecture अभी भी आवश्यक हैं। थ्रेड में hype, job displacement, “code quality” की बदलती धारणाओं, और यह कि मौजूदा लाभ क्रमिक हैं या software development में एक वास्तविक step change, जैसी व्यापक चिंताएँ भी सामने आती हैं।
समग्र भावना
- थ्रेड उत्साह और संदेह के बीच तीखे रूप से बँटा हुआ है।
- समर्थक जटिल कोडिंग और विश्लेषण के लिए Mythos/Fable को एक वास्तविक क्षमता-उछाल मानते हैं।
- आलोचक इसे अतिशयोक्तिपूर्ण मार्केटिंग, “vibes-based” मूल्यांकन, और गैर-इंजीनियरों से मिले कमजोर तकनीकी प्रमाण के रूप में देखते हैं।
क्षमताएँ और उपयोग-केस
- कुछ उपयोगकर्ता पहले के मॉडलों (Opus 4.8, GPT‑5.5, Qwen, DeepSeek) की तुलना में स्पष्ट जीत की रिपोर्ट करते हैं, खासकर इन कामों में:
- बड़े प्रोजेक्ट्स में गहरा कोड रिव्यू और रिफैक्टरिंग।
- जटिल परफ़ॉर्मेंस कार्य (जैसे Rust Lua interpreter)।
- स्पेक्स से बड़े वेब ऐप्स और टूल्स बनाना।
- प्रॉम्प्ट गाइडलाइन्स और “agent” कॉन्फ़िगरेशन को व्यवस्थित करना।
- अन्य लोगों को यह सिर्फ़ क्रमिक रूप से बेहतर लगता है, और वही परिचित समस्याएँ दिखती हैं: hallucinations, बहुत ज़्यादा बोलना, constraints को नज़रअंदाज़ करना, loops में फँस जाना।
लंबे समय तक चलने वाले agents और harness
- 9.5 घंटे का “Concord” build बहस छेड़ता है:
- Pro: कोई मानव डेवलपर एक दिन में 19-पेज के स्पेक से इतनी बड़ी चीज़ नहीं दे सकता।
- Con: उद्योग को सेकंडों में latency चाहिए; लंबे agent runs अक्सर भटक जाते हैं और rollback की ज़रूरत पड़ती है।
- कई लोग तर्क देते हैं कि ज़्यादातर “magic” harness से आता है: sub-agents की टीमें, tooling, और अच्छी project structure, न कि सिर्फ़ base model से।
कोड गुणवत्ता, शुद्धता, और maintainability
- कई इंजीनियर गायब विवरणों पर ध्यान देते हैं: tests, security, architecture, extensibility, और भविष्य के बदलावों की लागत।
- रिपोर्ट की गई समस्याएँ:
- Isochrone map में गंभीर तथ्यात्मक और UI त्रुटियाँ हैं।
- Games और demos buggy हैं या कुछ steps के बाद टूट जाते हैं।
- उदाहरण repo के code को “slop” / “unmaintainable” कहा गया।
- इस लेख के इस हल्के दावे को लेकर कड़ी चिंता है कि “एक software engineer बाकी bugs को ठीक कर देगा।”
- जारी बहस:
- एक पक्ष: अगर behavior अच्छा है और models लगातार refactor कर सकते हैं, तो internal code quality उतनी मायने नहीं रखती।
- दूसरा पक्ष: complexity, silent corruption, और जमा होते “oopsies” अभी भी strong human design और verification के बिना इसे अस्थिर बनाते हैं।
सुरक्षा, guardrails, और censorship
- Fable के aggressive cybersecurity/bio guardrails अक्सर ठीक उसी code-review काम को block कर देते हैं जिसकी लोगों को ज़रूरत होती है, और उन्हें कमजोर models पर वापस जाना पड़ता है।
- कुछ लोग model के task को unsafe मान लेने पर “gaslighting” और silent self-corruption की रिपोर्ट करते हैं।
अर्थशास्त्र, ROI, और पहुँच
- उपयोगकर्ता high token burn की ओर इशारा करते हैं: एकल sessions weekly quotas का बड़ा हिस्सा खा जाते हैं; promo periods के बाद “priced out” हो जाने की चिंता।
- इस पर बहस है कि क्या मौजूदा कीमत और गुणवत्ता पर automation सचमुच humans से सस्ती है; concrete cost-per-deliverable numbers की माँग की जाती है, जिन्हें लेख शामिल नहीं करता।
डेवलपर्स और काम पर प्रभाव
- कुछ devs खुद को 2–3× अधिक productive महसूस करते हैं और मजबूत ROI देखते हैं; अन्य लोग quality और outage risks के कारण LLM usage पहले ही घटा चुके हैं।
- व्यापक सहमति यह है कि:
- Models low-stakes, short-lived या side projects के लिए शक्तिशाली हैं।
- High-stakes, long-lived systems को अभी भी significant human architecture, domain understanding, और review चाहिए।