इंजीनियरिंग निर्णय आईडीई साइड बार में नहीं होते हैं. वे स्लाक थ्रेड में होते हैं, उसी स्थान पर आपकी टीम पहले से ही बात कर रही है, डिबगिंग कर रही है, पहले से ही समस्याओं के माध्यम से काम कर रही है। That disconnect is a problem. बातचीत के बारे में निर्माण करने के लिए एक जगह पर होता है, और वास्तविक निर्माण पूरी तरह से कहीं और होता है. संदर्भ खो जाता है. निर्णयों को फिर से समझाया जाता है. कोई अनिवार्य रूप से किसी AI चैट में एक समस्या को कॉपी करता है और जवाब को वापस फिट करता है, और हर कोई ऐसा लगता है कि यह एक सामान्य कार्यप्रवाह है। क्या बस कुछ भेजा है जो वास्तव में इस बात को संबोधित करता है: इसके पीछे की टीम महीनों से आंतरिक रूप से बॉट का उपयोग कर रही है, और यह मौलिक रूप से बदल गया है कि वे कैसे बनाते हैं और शिपिंग करते हैं। किलो Slack एकीकरण Kilo for Slack आपको सीधे अपने टीम के वार्तालापों में एक एआई कोडिंग एजेंट का उल्लेख करने की अनुमति देता है. यह पूरे थ्रेड संदर्भ को पढ़ता है, आपके GitHub रॉब से कनेक्ट करता है, और कोई भी Slack छोड़ने के बिना प्रश्नों का जवाब दे सकता है या पीआर खोल सकता है. अपने आईडीई के लिए बैग को फिर से समझाने के बाद आप पहले से ही उन्हें अपने टीम के साथ हैश कर चुके हैं. पीएचडी और डॉ: Slack के लिए Kilo . पीएचडी और डॉ: Try Kilo for Slack Slack के लिए Kilo . संदर्भ स्विच कर यहाँ एक दृश्य है जो शायद परिचित है। किसी ने एक टीम स्लाक चैनल में एक बग की रिपोर्ट की है. तीन इंजीनियर सिद्धांतों के साथ झुकते हैं. एक डेवलपर थ्रेड के माध्यम से स्क्रॉल करता है, संदर्भ को अवशोषित करता है, फिर अपने आईडीई में alt-tabs देता है. वे अपने एआई कोडिंग एजेंट को खोलते हैं और स्थिति को शून्य से फिर से समझाना शुरू करते हैं. वे त्रुटि को फिस्ट करते हैं. वे वर्णन करते हैं कि क्या कोशिश की गई है. वे उस स्लाक थ्रेड में पहले से ही मौजूद संदर्भ प्रदान करते हैं, मगर अब वे इसे फिर से टाइप कर रहे हैं. मरम्मत को लागू किया जाता है. एक पीआर ऊपर जाता है. फिर, यह लिंक साझा करने और परिवर्तनों को संक्षेप में साझा करने के लिए स्लैक पर वापस जाता है। यह सक्रिय इंजीनियरिंग टीमों पर सप्ताह में दर्जनों बार होता है. और हर बार, एक घर्षण टैक्स होता है. संदर्भ हस्तांतरण, पुनः स्पष्टीकरण, "विमर्श मोड" और "प्रयोग मोड" के बीच मानसिक गियर-विमर्श। यह एक एकल उदाहरण के लिए एक विशाल कर नहीं है, लेकिन यह जोड़ता है और सबसे महत्वपूर्ण बात यह है कि यह उस जगह के बीच एक कृत्रिम सीमा बनाता है जहां निर्णय किए जाते हैं, और जहां काम किया जाता है। Slack के लिए किलोग्राम वास्तव में क्या करता है यहां नया कार्यप्रवाह है. एक ही स्लाक थ्रेड लें: बग पर चर्चा की गई है, सिद्धांतों को फ्लोट किया गया है, और क्या होने की जरूरत है पर एकजुटता है. एक आईडीई के लिए संदर्भ स्विच करने के बजाय, आप बस टैग कर सकते हैं @Kilo: @Kilo based on this thread, can you implement the fix for the null pointer exception in the Authentication service? बॉट पूरे थ्रेड को पढ़ता है, और चूंकि यह Kilo प्लेटफॉर्म के माध्यम से टीम के GitHub रॉब से जुड़ा हुआ है, यह एक स्पिन करता है कुछ मिनट बाद, स्लाक में वहां एक पीआर लिंक है। Cloud एजेंट कोई कॉपी-पेस्टिंग नहीं, कोई एलटीटी-टाबिंग नहीं, एक ही चीज को दो बार समझाना नहीं, वार्तालाप में पहले से ही मौजूद संदर्भ कार्यान्वयन के लिए इनपुट बन जाता है। सरल प्रश्नों के लिए, यह एक ही तरीके से काम करता है: @Kilo how is error handling implemented in the payment module? यह आपके कोडबेस को पढ़ता है और थ्रेड में जवाब देता है। टीम के सहयोगी जवाब देख सकते हैं, और आप अनुसरण पूछ सकते हैं और कार्यान्वयन निर्देश दे सकते हैं. ज्ञान स्लाक में रहता है, जहां इसे बाद में संदर्भित किया जा सकता है. किलो टीम वास्तव में इसका उपयोग कैसे करती है Kilo अपने स्वयं के उपकरणों को कुत्ता खिलाने के बारे में आक्रामक है. टीम ने सार्वजनिक लॉन्च से पहले के बाद से आंतरिक रूप से Kilo for Slack का उपयोग किया है, और यह कई बदलावों का डिफ़ॉल्ट तरीका बन गया है। प्रकट होने वाले पैटर्न उम्मीद से अधिक विविध हैं: 1. वास्तविक समय बग फिक्स संभवतः सबसे स्पष्ट उपयोग मामला, और वह जो लगातार हिट होता है. उत्पादन में एक त्रुटि दिखाई देती है. कोई इसे स्लाक में चिह्नित करता है. टीम चर्चा करती है कि इसका कारण क्या हो सकता है. और फिर किसी के बजाय "इस पर एक नज़र डालें," वे सिर्फ @Kilo टैग करते हैं। मुख्य बात: बॉट उस समस्या को पढ़ते समय शून्य से शुरू नहीं होता है. इसमें वार्तालाप का पूरा संदर्भ है, और पूरे कोडबेस तक पहुंच है. यह पढ़ सकता है कि टीम क्या संदिग्ध है, और क्या अस्वीकार कर दिया गया है. यह जानता है कि अपेक्षित व्यवहार क्या होना चाहिए. यह एक ही जानकारी के साथ काम कर रहा है कि एक मानव डेवलपर्स को थ्रेड पढ़ने के बाद होगा: @Kilo I'm seeing this error in production: [stack trace]. Based on what we discussed above, can you create a PR with a fix? पीआर तार में उतरता है. कोई इसे समीक्षा करता है. यदि यह अच्छा दिखता है, तो यह एकीकृत हो जाता है. पूरे चक्र बिना किसी को औपचारिक रूप से "पिकअप" कार्य होता है। 2. बातचीत से तेजी से कोड परिवर्तन यह कुछ ऐसा है जो किलो में कई लोगों के लिए एक दैनिक अनुभव बन गया है. एक बातचीत एक विशेषता या व्यवहार के बारे में होती है. कोई कहता है, "हमें शायद एक्स को Y में बदलना चाहिए." पारंपरिक कार्य प्रवाह में, यह एक मानसिक नोट बन जाता है, या टिकट, या कुछ ऐसा जो "दूसरे के बाद" संभाल जाता है। Slack बॉट के साथ, "दूसरे" "अब" बन जाता है। व्यक्ति जिसके पास विचार था बस किलो टैग करता है और वर्णन करता है कि क्या बदलना चाहिए। @Kilo please change "2025" to "2026" through all of the announcement files in our kilo-org/kilocode repo एक टीम के लिए तेजी से चलने के लिए, यह मायने रखता है. छोटे परिवर्तनों पर घर्षण यह है कि उन्हें जमा करने का कारण है. उस घर्षण को हटाने से कोडबेस साफ और अधिक वर्तमान रहता है। 3. दस्तावेज और सामग्री अद्यतन यह कम तकनीकी या गैर तकनीकी भूमिकाओं में लोगों के लिए लागू होता है. किलो टीम लगातार पूरे किलो प्लेटफॉर्म पर सभी प्रकार के परिवर्तनों के लिए बॉट का उपयोग करती है. लैंडिंग पेज कॉपी, मैनुअल आइटम, दस्तावेज अद्यतन, README सुधार। पैटर्न एक ही है: स्लाक में एक चर्चा होती है कि क्या बदलने की आवश्यकता है, और फिर बॉट इसे लागू करता है. किसी को भी "लेखन मोड" में संदर्भ स्विच करने या एक अलग उपकरण खोलने की आवश्यकता नहीं है: @Kilo the getting started guide is missing the new authentication flow. Can you update it based on what we discussed in this thread? एक रीपो में रहने वाले सामग्री के लिए (जो, यदि आप docs-as-code कर रहे हैं, तो आपका अधिकांश सामग्री है), यह कार्यप्रवाह एक विशाल समय बचाने वाला है। विशेष रूप से उन लोगों के लिए जो विकास कार्यप्रवाह में डुबकी में डुबकी महसूस करते हैं बस एक सरल गंतव्य पृष्ठ परिवर्तन करने के लिए। 4. Spec Discussions से विशेषताओं को लागू करना कभी-कभी एक थ्रेड "क्या हमें यह करना चाहिए?" से "यहां लगभग यह कैसे काम करना चाहिए" से "ठीक है, चलो वास्तव में इसे बनाते हैं" तक विकसित होता है। @Kilo please implement the caching improvements we discussed in this thread यह सबसे अच्छा काम करता है जब थ्रेड में पर्याप्त विशिष्टता होती है। बॉट इरादों को निष्कर्ष निकालने में अच्छा होता है, लेकिन अधिक स्पष्ट संदर्भ बेहतर आउटपुट के लिए नेतृत्व करता है। 5. क्रॉस-रेपो समन्वय वास्तविक इंजीनियरिंग काम आमतौर पर कई रिपोरेटरी तक फैलता है। फ्रंटेंड, बैकेंड, साझा लाइब्रेरी, इन्फ्रास्ट्रक्चर कॉन्फ़िगर। कुछ अन्य स्लाक एकीकरणों के विपरीत, किलो स्वचालित रूप से निष्कर्ष निकालता है कि कौन सा रिपो संदर्भित किया जा रहा है। @Kilo the API change we discussed needs updates in both the backend service and the frontend client. Can you create PRs for both? चैनल प्रति कोई मैनुअल कॉन्फ़िगरेशन नहीं है। कोई स्विंग संदर्भ नहीं है जो निर्दिष्ट करेगा कि कौन सा रिपो उपयोग करना है. यह थ्रेड पढ़ता है, समझता है कि क्या संदर्भित किया जा रहा है, और इसके अनुरूप कार्य करता है। यह अन्य स्लैक बॉट्स से अलग क्यों है कई एआई स्लाक एकीकरण नवाचारों की तरह महसूस करते हैं - वे सामान्य उद्देश्य एआई के प्रत्येक श्रेणी में एक विशेषज्ञ के रूप में मास्क करने की कोशिश कर रहे हैं. वे सवालों का जवाब देते हैं, शायद कुछ कोड स्नैप्स उत्पन्न करते हैं, लेकिन जब कुछ गैर-ट्रिवाइन आता है, तो यह एक आईडीई में कॉपी-पस्टिंग करने के लिए वापस आता है। किलो का दृष्टिकोण वास्तुकला से अलग है जिस तरह से यह मायने रखता है। बहुमुखी बातचीत अधिकांश एआई स्लाक बॉट एक-शॉट बातचीत के लिए डिज़ाइन किए गए हैं. एक प्रश्न पूछें, एक उत्तर प्राप्त करें. Follow-ups मूल रूप से एक नई बातचीत शुरू करें. Kilo पूरे थ्रेड पर बनाता है. यह कई एक्सचेंजों के माध्यम से संदर्भ बनाए रखता है. एक वापस और पीछे चर्चा हो सकती है, दृष्टिकोण को परिष्कृत किया जा सकता है, स्पष्ट प्रश्न पूछे जा सकते हैं, और फिर कार्यान्वयन को शुरू किया जा सकता है. यह संदर्भ चलता है। यह दर्शाता है कि मानव वार्तालाप कैसे काम करते हैं. कोई भी पूरी स्थिति को हर बार फिर से समझाता है जब वे एक चर्चा में जोड़ते हैं. बॉट को भी ऐसा करने की आवश्यकता नहीं होनी चाहिए. Multi-Repository द्वारा डिफ़ॉल्ट Cursor का Slack एकीकरण प्रत्येक कार्यक्षेत्र या चैनल के लिए एक ही रिपोर्टर को कॉन्फ़िगर करना आवश्यक है. यह सरल सेटिंग्स के लिए अच्छा है, लेकिन यह तेजी से टूट जाता है जब इंजीनियरिंग काम कई रिपोर्ट को फैलाता है. Kilo बातचीत से संबंधित रिपोरेटरी को निष्पादित करता है. यदि फ़ाइलों या सेवाओं को जो अलग-अलग रिपो में रहते हैं, उन्हें उल्लेख किया जाता है, तो यह इसे संभालता है. कोई पूर्वानुमान कॉन्फ़िगरेशन. अलग-अलग कोडबेस के साथ काम करने के लिए चैनलों के बीच कोई स्विच नहीं। यह एक छोटी चीज की तरह लगता है जब तक कि आप एक परियोजना पर काम नहीं कर रहे हैं जहां फ्रंटेंड, बैकेंड, और बुनियादी ढांचे अलग-अलग repos में रहते हैं। वास्तविक निष्पादन, न केवल चैट यह मूल अंतर है. Kilo for Slack एक Q&A बॉट नहीं है. यह एक निष्पादन परत है. जब किसी चीज को लागू करने के लिए कहा जाता है, तो यह एक क्लाउड एजेंट को स्पिन करता है, एक शाखा बनाता है, परिवर्तन करता है, और एक पीआर खोलता है। और चूंकि यह किलो के क्लाउड एजेंटों का उपयोग कर रहा है, इसलिए कोई स्थानीय मशीन शामिल नहीं है. रीपो को स्थानीय रूप से क्लोन करने की आवश्यकता नहीं है. कार्यान्वयन क्लाउड में होता है और परिणाम समीक्षा के लिए तैयार एक पीआर के रूप में दिखाई देता है. PRs के साथ निरंतर संदर्भ एक बार एक पीआर मौजूद होने के बाद, बॉट उस पर काम करना जारी रख सकता है. यदि समीक्षा प्रतिक्रिया आती है, तो किलो को इसे एक ही थ्रेड में संबोधित करने के लिए कहा जा सकता है. पीआर और परिवर्तनों के कार्यान्वयन के बारे में बातचीत एक ही स्थान पर होती है: @Kilo the reviewer asked for better error handling in the auth flow. Can you update the PR? यह युग्म प्रोग्रामिंग कैसे काम करता है के करीब है. इस बारे में एक निरंतर बातचीत है कि क्या बनाया जा रहा है, और कोड उस बातचीत के जवाब में विकसित होता है. तकनीकी विवरण उन लोगों के लिए जिज्ञासा है कि यह वास्तव में कैप के तहत कैसे काम करता है: जब @Kilo को एक चैनल या डीएम में उल्लेख किया जाता है, तो बॉट थ्रेड संदर्भ को पढ़ता है. यह कनेक्टेड GitHub रिपोरेटरी तक पहुंचता है (किलो डैशबोर्ड में एक बार सेटअप किया जाता है). अनुरोध के आधार पर, यह जानकारी के साथ जवाब देता है या परिवर्तन करने के लिए एक क्लाउड एजेंट को बंद करता है. के Kilo CLI या डैशबोर्ड से उपलब्ध समान हैं. वे Kilo की बुनियादी ढांचे में चलते हैं, शाखाएं बनाते हैं, प्रतिबद्धताएं बनाते हैं, और रिपॉस्ट के खिलाफ PR खोलते हैं. परिणाम वापस Slack थ्रेड में पोस्ट किए जाते हैं. Cloud एजेंट मूल्य निर्धारण उपयोग पर आधारित है, जो किलोग्राम के माध्यम से सीधे मॉडल का उपयोग करने के समान प्रति टोकन लागत के साथ है - जिसका अर्थ है कि आपको केवल मॉडल प्रदाताओं द्वारा निर्धारित मूल्यों पर शुल्क दिया जाता है। इसे ऊपर रखें स्थापना लगभग दो मिनट लगते हैं: एक Kilo खाता बनाएं (श्री शुरू करने के लिए) app.kilo.ai पर एकीकरण टैब में GitHub repos को कनेक्ट करें एक ही Integrations पेज से Slack एकीकरण जोड़ें कार्यक्षेत्र में @Kilo का उल्लेख करना या DM-ing करना शुरू करें किलोग्राम खाता एकीकरण टैब Slack एकीकरण बॉट को निजी प्रश्नों के लिए सीधे डीएम-एड किया जा सकता है, या किसी भी चैनल में उल्लेख किया जा सकता है जहाँ इसे टीम के दृश्य बातचीत के लिए जोड़ा गया है। GitHub कनेक्शन महत्वपूर्ण हिस्सा है - और लगभग 10 सेकंड और 2 क्लिक लेता है. बॉट को कोडबेस के बारे में प्रश्नों का जवाब देने और पीआर बनाने के लिए पुनर्प्राप्त करने के लिए एक्सेस की आवश्यकता होती है. इसके लिए क्या उपयोग करें कुछ पैटर्न दिखाई दिए हैं जहां यह चमकता है: त्वरित मरम्मत और छोटे बदलाव. एक आईडीई खोलने, सही फ़ाइल ढूंढने, एक बदलाव करने और एक पीआर को धक्का देने का ओवरहेड काम के स्वयं के संबंध में उच्च है. Slack कार्य प्रवाह उस सभी ओवरहेड को टूटता है. जब "क्या" और "क्यों" पहले से ही एक थ्रेड में कब्जा किया जाता है, तो अंत में "यह करें" जोड़ना स्वाभाविक लगता है। दस्तावेज और सामग्री. सब कुछ जो एक रेपो में रहता है लेकिन सख्त रूप से कोड नहीं है. READMEs, गाइड, कॉन्फ़िगरेशन फ़ाइलें, लैंडिंग पेज कॉपी। जब एक परिवर्तन को कई रिपोरेटरी को छूने की आवश्यकता होती है, तो एकल स्लाक थ्रेड से इसे प्रबंधित करना आईडीई विंडो के बीच बोनस करने की तुलना में साफ होता है। मोबाइल और async स्थितियों. एक PR एक फोन से शुरू किया जा सकता है. काम क्लाउड में होता है. समीक्षा बाद में होता है. जब विचार अभी भी जीतता है यह एक विकास वातावरण के लिए एक प्रतिस्थापन नहीं है. यह एक पूरक है। तेजी से पुनरावृत्ति, स्थानीय परीक्षण, और वास्तविक समय परिष्करण अभी भी IDE या Kilo CLI चाहते हैं। गहरी डिबगिंग सत्र. कोड के माध्यम से कदम, राज्य की निरीक्षण, और व्यवहार को समझने के लिए पूर्ण उपकरणों की आवश्यकता होती है। बड़े पैमाने पर वास्तुकला परिवर्तन एक आईडीई द्वारा प्रदान की जाने वाली पूरी संदर्भ से लाभ उठाते हैं। किलोग्राम CLI मानसिक मॉडल: Slack-पहले उन परिवर्तनों के लिए जो बातचीत से उत्पन्न होते हैं, IDE-पहले उन परिवर्तनों के लिए जो गहरी इंजीनियरिंग की आवश्यकता होती है। व्यापक प्लेटफॉर्म Kilo for Slack Kilo के बड़े, अंत से अंत एजेंट इंजीनियरिंग प्लेटफॉर्म का हिस्सा है. Kilo पहले से ही उपलब्ध है , के और किलोग्राम के एक ही प्लेटफॉर्म, एक ही 500+ मॉडल विकल्प, और एक ही गुणवत्ता, बस एक अलग सतह से सुलभ है। कोड के खिलाफ जेटब्रेन किलोग्राम CLI Cloud एजेंट Slack एकीकरण जब आप किलो में निर्माण कर चुके हैं, तो आप एआई-आधारित भी सक्षम कर सकते हैं एक क्लिक , और यहां तक कि अपने सत्रों को अपने टीम के भीतर साझा करें . कोड समीक्षा तैनाती कुंडली सीटें एआई कोडिंग उपकरणों का मूल्यांकन करने वाले टीमों के लिए, यह विचार करने लायक है. यह न केवल इस बारे में है कि कौन सा उपकरण सबसे अच्छा कोड उत्पन्न करता है - जो निस्संदेह महत्वपूर्ण है - लेकिन यह भी यह है कि कौन सा उपकरण कम से कम घर्षण के साथ वास्तविक कार्य प्रवाह में फिट होता है. यदि एक टीम स्लाक में रहती है, तो एआई जो संदर्भ स्विच की आवश्यकता के बिना उन वार्तालापों में भाग ले सकता है, एक मायने रखने वाला सुधार है. यह एक कम सीमा है जहां निर्णय होते हैं और जहां वे लागू होते हैं। जहां टीमों कोड पर चर्चा कर सकते हैं वह जगह है जहां कोड लिखा जाता है. चर्चा और कार्यान्वयन एक साथ होते हैं. संदर्भ स्वाभाविक रूप से एक से दूसरे तक बहता है. यह कार्य प्रवाह में सुधार का एक प्रकार है जो समय के साथ मिलता है। > Slack के लिए Kilo आज़माएं Slack के लिए Kilo आज़माएं Kilo 1 मिलियन से अधिक उपयोगकर्ताओं के साथ एक खुला स्रोत एआई कोडिंग एजेंट है. यह VS कोड, JetBrains, और CLI, Cloud Agents, लाइव पूर्वावलोकन ऐप बिल्डर, एक क्लिक तैनाती, स्वचालित कोड समीक्षा, और अब Slack एकीकरण में उपलब्ध है। किलोग्राम . किलोग्राम
