qm – काम के लिए मल्टीप्लेयर एजेंट हार्नेस
YC का एक नया open-source “multiplayer agent harness” हर कर्मचारी को एक व्यक्तिगत AI assistant देने का लक्ष्य रखता है जो कंपनी के tools में काम कर सके, जबकि shared “rooms” में scoped context साझा भी करे। टिप्पणीकार org-wide agents और contribution model—जिसमें feature ideas code के बजाय human-written text के रूप में भेजी जाती हैं—को लेकर उत्सुक हैं, लेकिन सवाल करते हैं कि यह मौजूदा Slack bots, Copilot/Cowork-शैली के products, और Hermes या OpenClaw जैसे अन्य agent frameworks से कितना आगे जाता है। एक विस्तृत “anti-slop” taste skill जैसी hype-चालित design choices को लेकर भी संदेह है, और व्यापक चिंता यह है कि हमेशा-on agents अधिक noise, security risk, और सतही automation पैदा कर सकते हैं, बजाय वास्तविक productivity gains के।
योगदान मॉडल और AI-जनित कोड
- प्रोजेक्ट केवल “मानव-लिखित” टेक्स्ट ADRs स्वीकार करता है, कोड PRs नहीं। फिर मेंटेनर बदलाव लागू करते हैं, अक्सर अपने ही एजेंटों के माध्यम से।
- कई लोग इसे लो-एफर्ट या LLM-स्लॉप PRs से बचने और कोड रिव्यू की बजाय विचारों और स्पेक्स पर ध्यान केंद्रित करने का व्यावहारिक तरीका मानते हैं।
- कुछ इसे विडंबनापूर्ण या “AI-psychotic” मानते हैं कि एक AI-भारी प्रोजेक्ट AI-लिखित प्रस्तावों पर रोक लगाता है, हालांकि कुछ ध्यान दिलाते हैं कि यह रोक वास्तव में AI-औपचारिकीकृत स्पेक्स पर है, सामान्य AI उपयोग पर नहीं।
- SQLite जैसे प्रोजेक्टों से तुलना की जाती है जो यादृच्छिक कोड योगदानों से भी बचते हैं; कई मेंटेनर कहते हैं कि वे ड्राइव-बाय PRs से बेहतर विस्तृत issues पसंद करते हैं।
“Taste” / anti-slop कौशल
- फ्रंटएंड्स के लिए shipped “taste skill” सामान्य AI-जैसे दिखने वाले डिजाइन और कॉपी से बचने की कोशिश करता है।
- कुछ लोग anti-slop नियमों को स्पष्ट रूप से एन्कोड करने के विचार को पसंद करते हैं; अन्य लोग इसके विशाल prompt size और नकारात्मक, निर्देशात्मक शैली की आलोचना करते हैं।
- विशिष्ट शैलीगत markers पर प्रतिबंध (जैसे कुछ palettes या punctuation) कुछ लोगों को overfitted और मूर्खतापूर्ण लगते हैं; दूसरे सोचते हैं कि ऐसे tells समय के साथ बस उलट जाएंगे।
Agent harnesses, Hermes, और उपयोग के मामले
- चर्चा में qm की तुलना Hermes, Openclaw-जैसे systems, और अन्य harnesses से की जाती है।
- कुछ लोग Hermes जैसे feature-rich harnesses को पसंद करते हैं; अन्य लोग minimal, extensible setups या नियंत्रण और resource usage के लिए अपना खुद का बनाना पसंद करते हैं।
- रिपोर्ट किए गए वास्तविक उपयोग: on-call alert triage, CI fixers, RCA generation, DB query optimization, inbox और RSS/news triage, charts/analytics, और webhooks के जरिए internal tools।
- एक बार-बार उठने वाली चिंता: बहुत सारा agent code बनाना आसान है; इसे review करना, provenance trace करना, और इस पर भरोसा करना कठिन है।
“Multiplayer” agents और UX
- “Multiplayer” की व्याख्या org-wide agents और shared rooms/scopes के रूप में की जाती है, ताकि हर व्यक्ति के पास एक ऐसा assistant हो जो collaborate कर सके और context साझा कर सके।
- कुछ लोग इसे सिर्फ एक और job scheduler या glorified Slack bot मानते हैं; अन्य मानते हैं कि scoped, shared context ही असली चुनौती और मूल्य है।
- नए UI और agent primitives में रुचि है (जैसे UI से जुड़े state models, MCP-based apps), लेकिन कई लोग नोट करते हैं कि मौजूदा marketing pages धुंधली और समान लगती हैं।
- bespoke harnesses बनाने बनाम generalized platforms का उपयोग करने पर बहस है; customization को महत्व दिया जाता है, लेकिन fragmentation और “yet another harness” वाली थकान स्पष्ट है।
प्रतिक्रिया, नवीनता, और संदेह
- कुछ लोगों को qm वास्तविक, उपयोगी, और पहले के व्यक्तिगत RAG/agent setups का स्वाभाविक विकास लगता है।
- अन्य इसे overengineered, hype-driven, “multiplayer AI” buzz के जवाब में जल्दबाजी में बनाया गया, या समस्याओं की तलाश में एक समाधान मानते हैं जो मुख्यतः tokens जलाता है।
- सुरक्षा को लेकर चिंताएँ उठाई गईं (agents के पास user की सभी permissions होना), Copilot या Cowork जैसे tools से अस्पष्ट भिन्नता, और YC के व्यापक रणनीतिक मकसद।