“अन्य मॉडल हमारे द्वारा इसे ठीक करने के बाद भी बार-बार एक ही चीज़ की ओर इशारा करते रहे। जब हमने Enter Pro को आज़माया, तो उसने पता लगा लिया कि वास्तविक कारण क्या था।”

WhyVenv ने Quackathon के लिए एक स्वायत्त घटना प्रतिक्रिया एजेंट Kronos का निर्माण किया, ताकि इंजीनियरों को प्रोडक्शन त्रुटियों से मूल कारण तक तेज़ी से पहुँचने में मदद मिल सके।

पेजर तो केवल शुरुआत है

जब प्रोडक्शन बाधित होता है, तो अलर्ट शायद ही कभी कठिन हिस्सा होता है।

Grafana आपको बता सकता है कि कुछ बंद है। लॉग आपको बता सकते हैं कि कुछ विफल हो गया। एक डैशबोर्ड इतनी ज़ोर से लाल चमक सकता है कि रात के 2 बजे किसी को जगा दे।

लेकिन उसके बाद, असली काम शुरू होता है।

एक इंजीनियर को अभी भी लॉग खोलना होता है, त्रुटि को समझना होता है, कोडबेस में खोजना होता है, अनुमान लगाना होता है कि कौन सा फ़ंक्शन मायने रखता है, यह तय करना होता है कि समस्या तत्काल है या नहीं, और यह पता लगाना होता है कि अगला सही कदम GitHub समस्या है, पैच है, या पूर्ण एस्केलेशन है।

यह जानने कि कुछ टूट गया है और यह समझने कि क्या टूटा है, के बीच का अंतर ही वह जगह है जहाँ घटना प्रतिक्रिया दर्दनाक हो जाती है।

यही वह जगह भी है जहाँ Dawood Khan को Kronos का विचार मिला।

Dawood ने AI का अध्ययन किया, लेकिन कॉलेज के बाद वे सिस्टम इंजीनियरिंग के करीब आ गए। उनकी रुचि अमूर्त नहीं थी। उन्होंने देखा था कि प्रोडक्शन सिस्टम कैसे विफल होते हैं, टीमें कैसे प्रतिक्रिया देती हैं, और एक अलर्ट और समाधान के बीच अभी भी कितनी मैन्युअल जांच बाकी रहती है।

हैदराबाद में एक Grafana कार्यक्रम में, समस्या और भी स्पष्ट हो गई। इंजीनियर उसी पैटर्न का वर्णन कर रहे थे: सिस्टम बंद हो जाता है, किसी को कॉल आती है, और फिर टीम हाथ से विफलता का पता लगाने का परिचित काम शुरू करती है।

Quackathon कुछ अलग बनाने का क्षण बन गया। WhyVenv द्वारा निर्मित, Kronos ने Quackathon में दूसरा स्थान हासिल किया, और प्रोडक्शन घटना प्रतिक्रिया को एक एजेंटिक वर्कफ़्लो में बदलने के लिए Track 01: Software - The Sentient Workspace चुनौती में अलग पहचान बनाई।

WhyVenv ने क्या बनाया

WhyVenv की परियोजना Kronos थी, जो Quackathon के Sentient Workspace ट्रैक के लिए बनाया गया एक स्वायत्त घटना प्रतिक्रिया एजेंट है।

विचार सीधा था, लेकिन महत्वाकांक्षी था:

Kronos प्रोडक्शन त्रुटियों को प्राप्त करता है, लॉग पढ़ता है, प्रासंगिक कोड पुनर्प्राप्त करता है, संभावित मूल कारण का निदान करने के लिए एक AI मॉडल से पूछता है, और फिर तय करता है कि आगे क्या होना चाहिए।

कभी-कभी इसका मतलब GitHub समस्या खोलना होता है।

कभी-कभी, समस्या की गंभीरता के आधार पर, इसका मतलब समाधान का प्रयास करना होता है।

मुद्दा केवल इंजीनियर को यह सूचित करना नहीं है कि प्रोडक्शन बाधित है। मुद्दा इंजीनियर को उस काम पर बढ़त देना है जो आमतौर पर अलर्ट के बाद होता है।

साक्षात्कार के दौरान Dawood के शब्दों में, Grafana अलर्ट ने यह जानना आसान बना दिया कि कुछ कब बंद था। समस्या उसके बाद की हर चीज़ थी: समस्या का कारण क्या था, बग कहाँ था, और टीम को क्या कार्रवाई करनी चाहिए।

Kronos को उस मध्य परत को स्वचालित करने के लिए बनाया गया था।

Kronos के पीछे की इंजीनियरिंग अंतर्दृष्टि

“जिस हिस्से पर मुझे सबसे ज्यादा गर्व था, वह पुनर्प्राप्ति चरण था। केवल ASTs या एम्बेडिंग का उपयोग करने के बजाय, हमने ट्रेस लॉग से काम किया, क्योंकि इंजीनियर आमतौर पर इसी तरह समस्या का पता लगाते हैं।”

जिस हिस्से पर Dawood को सबसे ज्यादा गर्व था, वह डैशबोर्ड, GitHub एकीकरण, या AI निदान भी नहीं था।

यह पुनर्प्राप्ति चरण था।

कई AI कोडिंग सिस्टम एम्बेडिंग, AST पार्सिंग, या व्यापक संदर्भ लोडिंग के माध्यम से कोडबेस को समझने की कोशिश करते हैं। Kronos ने अधिक इंजीनियर-मूल मार्ग अपनाया: ट्रेस लॉग से शुरू करें और खोज को सीमित करने के लिए उनका उपयोग करें।

वह विकल्प मायने रखता है।

जब इंजीनियर प्रोडक्शन विफलताओं को डीबग करते हैं, तो वे शायद ही कभी AI मॉडल से पूरे रिपॉजिटरी को पढ़ने के लिए कहकर शुरुआत करते हैं। वे त्रुटि को देखते हैं। वे स्टैक ट्रेस का पालन करते हैं। वे कोड के माध्यम से ग्रेप करते हैं। वे लक्षण से स्रोत की ओर बढ़ते हैं।

Kronos को उसी वृत्ति के इर्द-गिर्द डिज़ाइन किया गया था।

सिस्टम लॉग को प्रवेश बिंदु के रूप में उपयोग करता है, उस कोड को पुनर्प्राप्त करता है जो सबसे प्रासंगिक प्रतीत होता है, और केवल तभी AI मॉडल को वर्कफ़्लो में लाता है। यह मॉडल को सर्वदर्शी ओरेकल के बजाय साक्ष्यों के एक केंद्रित पैकेट से काम करने वाले समीक्षक की तरह बनाता है।

Dawood स्पष्ट थे कि बड़े पैमाने पर भरोसा किए जाने से पहले इस दृष्टिकोण को अभी भी सुधार की आवश्यकता है। लेकिन डेमो के लिए, इसने काम किया। इससे भी महत्वपूर्ण बात यह है कि इसने एक गंभीर उत्पाद वृत्ति को दर्शाया: सर्वोत्तम AI सिस्टम आँख बंद करके इंजीनियरिंग वर्कफ़्लो को प्रतिस्थापित नहीं करते हैं। वे सीखते हैं कि इंजीनियर पहले से ही समस्याओं को कैसे हल करते हैं।

Enter Pro के साथ ऑब्जर्वेबिलिटी स्टैक का निर्माण

Kronos को उन उपकरणों पर काम करना था जिनका टीम ने पहले गहराई से उपयोग नहीं किया था।

Grafana। Prometheus। Loki। डैशबोर्ड। लॉग। मेट्रिक्स। अलर्ट।

एक हैकाथॉन टीम के लिए, वास्तविक उत्पाद के काम शुरू होने से पहले समझने के लिए यह बहुत सारा बुनियादी ढांचा है।

यही वह जगह है जहाँ Enter Pro WhyVenv के लिए उपयोगी बन गया।

टीम ने अनुसंधान, विचार सुधार और डीबगिंग के लिए पूरी परियोजना के दौरान Enter Pro का उपयोग किया। Dawood और उनके साथियों ने इसका उपयोग ऑब्जर्वेबिलिटी स्टैक को समझने, यह पता लगाने के लिए किया कि घटक एक साथ कैसे फिट होते हैं, और जब सिस्टम उम्मीद के मुताबिक व्यवहार नहीं कर रहा था तो एकीकरण के मुद्दों से आगे बढ़ने के लिए किया।

एक क्षण अलग था।

टीम इस बात पर अटकी हुई थी कि उनके डेटा अलर्ट सही तरीके से क्यों नहीं आ रहे थे। उन्होंने अन्य AI मॉडलों की कोशिश की थी, लेकिन Dawood को लगा कि उनमें से कुछ टीम द्वारा इसे पहले ही ठीक कर दिए जाने के बाद भी उसी बिंदु के चक्कर काट रहे थे।

जब उन्होंने Enter Pro को आज़माया, तो इसने उन्हें वास्तविक कारण की अधिक सीधे पहचान करने में मदद की।

यह उस तरह का क्षण है जो एक बिल्ड स्प्रिंट में मायने रखता है। कोई पॉलिश किया हुआ डेमो उत्तर नहीं। कोई सामान्य सुझाव नहीं। एक वास्तविक अवरोधक के माध्यम से एक ठोस धक्का।

WhyVenv के लिए, Enter Pro केवल कोड उत्पन्न करने का स्थान नहीं था। यह अपरिचित प्रणालियों के माध्यम से इतनी तेज़ी से तर्क करने का एक तरीका था कि निर्माण जारी रखा जा सके।

फोकस के दो दिन

Dawood ने टीम द्वारा गंभीर विकास शुरू करने से पहले ही परियोजना की योजना बना ली थी।

वे जानते थे कि वे क्या बनाना चाहते हैं। उन्होंने बुनियादी वास्तुकला के बारे में सोच लिया था। उन्हें इस बात का मोटा अंदाजा था कि काम को कैसे विभाजित किया जाना चाहिए।

फिर वास्तविक हैकाथॉन की लय ने कब्जा कर लिया।

पहला दिन केवल कोड का नहीं था। टीम ने एक साथ समय बिताया, बात की, मज़ाक किया और अपनी पकड़ बनाई। वास्तविक निर्माण उसके बाद आया: एक केंद्रित स्प्रिंट जहाँ उन्होंने काम को विभाजित किया, अपरिचित टुकड़ों पर शोध किया, मुख्य प्रवाह को लागू किया, और उत्पाद को तब तक परिष्कृत किया जब तक कि वह एक साथ न आ जाए।

वास्तुकला सरल शुरू हुई:

क्रैश रिपोर्ट -> प्रासंगिक कोड -> LLM निदान -> समस्या या समाधान।

फिर जैसे-जैसे टीम ने निर्माण किया, प्रत्येक भाग अधिक स्पष्ट होता गया।

वह सादगी ही इस बात का हिस्सा है कि क्यों Kronos सम्मोहक है। यह एजेंटिक सॉफ़्टवेयर के एक जटिल सिद्धांत के साथ शुरू नहीं होता है। यह एक वर्कफ़्लो के साथ शुरू होता है जिसे हर ऑन-कॉल इंजीनियर समझता है: कुछ टूट गया, कारण ढूंढें, तय करें कि आगे क्या करना है।

Kronos AI एजेंटों के बारे में क्या सुझाव देता है

Kronos कोडबेस के बगल में बैठा चैटबॉट नहीं है।

यह एक वर्कफ़्लो एजेंट के करीब है: एक प्रणाली जो वास्तविक दुनिया से एक संकेत प्राप्त करती है, सही सबूत इकट्ठा करती है, केवल वहीं तर्क मांगती है जहाँ तर्क उपयोगी है, और फिर परिणाम को उन उपकरणों में भेजती है जिनका इंजीनियर पहले से उपयोग करते हैं।

वह अंतर मायने रखता है।

Dawood AI प्रणालियों के आसपास लागत और नियंत्रण समस्याओं के प्रति संवेदनशील हैं। साक्षात्कार में, उन्होंने टोकन उपयोग, महंगे मॉडल कॉल, और एजेंट को सब कुछ संभालने न देने के महत्व के बारे में बात की जब नियतात्मक बैकएंड तर्क काम के हिस्से को अधिक कुशलता से कर सकता है।

2026 में AI के साथ निर्माण करने वाले किसी व्यक्ति के लिए यह एक परिपक्व वृत्ति है।

AI एजेंटों का भविष्य केवल मजबूत मॉडलों का उपयोग करने के बारे में नहीं होगा। यह यह जानने के बारे में भी होगा कि उनका उपयोग कब नहीं करना है। कौन से हिस्से कोड होने चाहिए? कौन से हिस्से पुनर्प्राप्ति होने चाहिए? कौन से हिस्से मॉडल तर्क होने चाहिए? कौन से हिस्से मानव समीक्षा के अधीन रहने चाहिए?

Kronos, एक हैकाथॉन परियोजना के रूप में भी, उस प्रश्न की ओर इशारा करता है।

आगे क्या आता है

उत्पादन के लिए तैयार होने से पहले परियोजना के पास अभी भी उत्तर देने के लिए प्रश्न हैं:

पुनर्प्राप्ति दृष्टिकोण बड़े कोडबेस में कितनी अच्छी तरह स्केल करता है?
गंभीरता और स्वायत्तता को कैसे कैलिब्रेट किया जाना चाहिए?
एक एजेंट को समाधान का प्रयास करने के बजाय समस्या कब खोलनी चाहिए?
एक मॉडल के लिए वास्तविक घटना का निदान करने के लिए कितना संदर्भ पर्याप्त है?
उत्पादन तक कुछ भी पहुँचने से पहले मनुष्यों को क्या अनुमोदित करना चाहिए?

ये छोटे प्रश्न नहीं हैं। ये बिल्कुल वही प्रश्न हैं जो Kronos को ध्यान देने योग्य बनाते हैं।

क्योंकि प्रोडक्शन की घटनाएं खत्म नहीं होने वाली हैं। एकमात्र सवाल यह है कि क्या हर प्रतिक्रिया को मैन्युअल घबराहट के साथ शुरू होना चाहिए।

Kronos एक अलग पहले कदम की कल्पना करता है: एक जहाँ विफलता को देखने वाली प्रणाली इसे समझना भी शुरू कर सकती है।

यही वह चीज़ है जिसका समर्थन करने के लिए Enter मौजूद है।

केवल तेज़ कोड नहीं। एक वास्तविक दर्द बिंदु से एक कार्यशील उत्पाद तक तेज़ गति।

और WhyVenv के लिए, वह गति एक दर्दनाक इंजीनियरिंग पैटर्न को Quackathon की विजेता परियोजनाओं में से एक में बदलने के लिए पर्याप्त थी।

अन्वेषण करें Kronos।

यह कहानी हमारी Quackathon Builder Series का हिस्सा है, जहाँ हम एक समय में एक परियोजना पर जाकर यह समझते हैं कि निर्माताओं ने Enter Pro के साथ क्या बनाया, उन्होंने इसे क्यों बनाया, और उनका काम हमें AI-संचालित सॉफ़्टवेयर निर्माण के भविष्य के बारे में क्या बताता है। बने रहें।