Mythos के साथ काम करना कैसा लगता है

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

समग्र भावना

  • थ्रेड उत्साह और संदेह के बीच तीखे रूप से बँटा हुआ है।
  • समर्थक जटिल कोडिंग और विश्लेषण के लिए 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 चाहिए।