जुलाई 2026 में, AI प्रोग्रामिंग क्षेत्र में एक बड़ा बदलाव हुआ। पीटर स्टीनबर्गर ने X प्लेटफॉर्म पर घोषणा की कि साइक्लिक इंजीनियरिंग का युग समाप्त हो गया है, जिससे उद्योग को ग्राफ (Graph) इंजीनियरिंग की ओर ले जाया गया। साइक्लिक इंजीनियरिंग, जेफ्री हंटले की राल्फ विधि से उत्पन्न हुई, जिसमें AI एजेंट को लक्ष्य प्राप्त करने तक निरंतर चलाकर संदर्भ खिड़की सीमा को दूर किया जाता था। 2026 के अप्रैल से मई तक, Codex, Claude Code आदि उपकरणों ने Goal फीचर को लॉन्च किया, जिससे साइक्लिक का उत्पादीकरण हुआ। वर्तमान में, उद्योग संगठनात्मक ग्राफ और कार्य ग्राफ के सह-डिज़ाइन पर आधारित अधिक जटिल ग्राफ इंजीनियरिंग का पता लगा रहा है।

लेखक, स्रोत: वेची ग्रुप InfoQ (ID: infoqchina)

क्या हम अभी भी चक्र पर चर्चा कर रहे हैं, या हम ग्राफ पर चले गए हैं?

18 जुलाई, 2026 को, पीटर स्टीनबर्गर ने X प्लेटफॉर्म पर इस एक वाक्य के साथ, साइक्लिक इंजीनियरिंग के युग के अंत की घोषणा की। यह पोस्ट प्रकाशित होने के दो दिनों में 260 लाख ब्राउज़ किया गया।

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

दो पोस्टों ने, जिनकी कुल देखी गई दर्जनों 1.1 करोड़ से अधिक हैं, AI प्रोग्रामिंग क्षेत्र में सबसे अधिक चर्चित चर्चा को अगले स्तर पर ले गए।

The Rise of Cycles

पिछले महीने, "लूप इंजीनियरिंग" एआई प्रोग्रामिंग के क्षेत्र में एक लोकप्रिय अवधारणा बन गया।

लेकिन इसकी वास्तविक उत्पत्ति एक साल पहले तक जाती है। 2025 के जुलाई में, सॉफ्टवेयर इंजीनियर जेफ्री हंटले ने एक ऐसी विधि प्रस्तावित की जिसे उन्होंने "Ralph" कहा—एक सरल Bash लूप, जिससे Claude को लक्ष्य प्राप्त होने तक बार-बार कार्य करने के लिए प्रेरित किया जाता है:

जब तक :; do cat PROMPT.md | claude-code ; done

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

इस संदर्भ में, रॉल्फ विधि इस प्रकार कार्य करती है:

• एक लक्ष्य निर्धारित करें, फिर लक्ष्य प्राप्त होने तक Agent को निरंतर चलाएं या पुनः चलाएं।
• पहले से पूर्ण किए गए कार्य को फ़ाइल सिस्टम में संकुचित रूप में स्थायी रूप से सहेजें, उदाहरण के लिए लॉग या अद्यतन योजना के रूप में।
• एजेंट को नए संदर्भ के साथ शुरू करें ताकि "संदर्भ दूषित होने" को कम से कम किया जा सके।
• जब आवश्यक हो, तो प्रत्येक एजेंट को "सामान्य योजना" जोड़ने या संशोधित करने की अनुमति दें।

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

लूप की लोकप्रियता के पीछे एंथ्रोपिक और ओपनएआई के कुछ मुख्य डेवलपर्स भी हैं। शुरुआत में, एंथ्रोपिक के डेवलपर कॉन्फ्रेंस में, क्लॉड कोड के निर्माता बोरिस चेर्नी ने कहा: "अब मैं क्लॉड को निर्देश नहीं देता। मैं कुछ लूप चला रहा हूँ, जो क्लॉड को निर्देश देते हैं और अगला कदम क्या होना चाहिए, यह निर्णय लेते हैं। मेरा काम लूप लिखना है।"

इसके बाद, पीटर स्टेनबर्गर ने भी एक पोस्ट करके डेवलपर्स को बुलाया कि वे प्रोग्रामिंग एजेंट को सीधे प्रॉम्प्ट न करें: "महीने में एक बार याद दिलाता हूँ: आपको अब सीधे प्रोग्रामिंग एजेंट को प्रॉम्प्ट नहीं करना चाहिए। आपको ऐसे साइकिल डिज़ाइन करने चाहिए जो एजेंट को प्रॉम्प्ट कर सकें।"

पूर्व Google इंजीनियर एडी ओसमैनी ने बाद में “लूप इंजीनियरिंग” शीर्षक से एक लेख भी लिखा, जिसमें उन्होंने इसे इस प्रकार सारांशित किया: “लूप इंजीनियरिंग का अर्थ है कि आप स्वयं Agent को प्रॉम्प्ट करने की स्थिति से बाहर निकलकर, एक ऐसा सिस्टम डिज़ाइन करें जो आपके लिए यह काम कर दे।”

अवधारणा मिल गई, नाम मिल गया, और बुनियादी ढांचा भी तेजी से आगे बढ़ गया।

2026 के अप्रैल से मई के बीच, कोडेक्स, क्लॉड कोड और हर्मेस ने क्रमशः /goal कमांड लॉन्च किया, जिससे हाथ से लिखे गए लूप को एक ही कमांड में प्रोडक्टाइज़ किया जा सके।

राल्फ द्वारा व्यापक रूप से शुरू किए जाने के लगभग छह महीने बाद, कोडेक्स ने गोल फीचर जारी किया

Codex दस्तावेज़ में लिखा है: "लक्ष्य Codex में स्थायी लक्ष्य होते हैं, जो एक संवाद थ्रेड को बहुत सारी बातचीत के दौरान एक स्पष्ट परिणाम की ओर ले जाने में मदद करते हैं। लक्ष्य Codex को एक पूरा होने की शर्त प्रदान करते हैं: कौन सी स्थिति सत्य होनी चाहिए, सफलता की जांच कैसे की जाए, और कौन सी सीमाएँ हमेशा बनी रहनी चाहिए।"

दस्तावेज़ विशेष रूप से उल्लेख करता है: "सामान्य प्रॉम्प्ट का अर्थ है: अगला कार्य करें। गोल का अर्थ है: तब तक काम जारी रखें, जब तक यह परिणाम सत्य न हो जाए।"

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

उदाहरण के लिए: "चेकआउट बेंचमार्क में p95 लेटेंसी को 120 मिलीसेकंड से कम करें, जबकि सही परीक्षण सूट हमेशा पास हो।"

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

गोल्स फीचर की आर्किटेक्चर

डेवलपर्स चक्र का उपयोग कैसे करते हैं

तो डेवलपर वास्तव में लूप का उपयोग क्या कर रहे हैं? समुदाय की प्रतिक्रिया के अनुसार, सबसे सामान्य स्थिति अभी भी कुछ नियमित कार्यों को संभालना है।

लेकिन चक्रीय क्षमता इससे अधिक है। वास्तविक रूप से चक्रीय इंजीनियरिंग का मूल्य उन अधिक जटिल, निरंतर इटरेशन की आवश्यकता वाली लंबी अवधि की कार्यों में प्रकट होता है।

जैसे कि बड़े पैमाने पर कोड माइग्रेशन पूरा करना। स्टार्टअप के संस्थापक राफेल मेंडिओला को एक React ऐप को React Native में बदलना था। पारंपरिक तरीका एक बड़ा Epic बनाना और फिर 50 से 100 टिकट में विभाजित करना था, जिससे बस बुनियादी ढांचा तैयार करना ही डरावना लगता था।

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

अगला स्टॉप: Graph

पीटर के ट्वीट की समस्या वास्तव में एक विकास के मार्ग की ओर इशारा करती है।

एक साल पहले, प्रॉम्प्ट इंजीनियरिंग मुख्य कौशल थी। 2025 से 2026 की शुरुआत तक, ध्यान चक्रों के डिजाइन पर स्थानांतरित हो गया। और अब, पीटर जिस ओर इशारा कर रहे हैं, वह और भी आगे है: कई चक्रों से बने ग्राफ का डिजाइन—जिसमें प्रत्येक एजेंट अपना चक्र चलाता है और निर्भरता के माध्यम से एक-दूसरे से जुड़ा होता है।

इस ट्वीट के चर्चा थ्रेड में सबसे उत्कृष्ट प्रतिक्रिया Luis Catacora की है: "साइकिल में बहुत अधिक त्रुटि सहनशीलता होती है। ग्राफ आपको यह स्वीकार करने के लिए मजबूर कर देगा कि वर्कफ्लो में कितने हिस्से अभी तक वास्तव में मॉडल नहीं किए गए हैं।"

यह वाक्य इन दोनों पैटर्न के बीच के अंतर को दर्शाता है। लूप आपको आर्किटेक्चर डिज़ाइन को स्थगित करने की अनुमति देता है: पहले एक एजेंट को सभी कार्य सौंप दें, जब तक कि वह इसे संभालने में असमर्थ न हो जाए। दूसरी ओर, ग्राफ आपसे पूरी संरचना की पूर्व-घोषणा मांगता है—कौन क्या जिम्मेदार है, कौन से कार्य किन कार्यों पर निर्भर हैं, और किसी शाखा के विफल होने पर क्या करना है। लूप निर्णय को स्थगित करता है, जबकि ग्राफ निर्णय पूर्व-लेता है।

गूगल के उच्च स्तरीय AI उत्पाद प्रबंधक और Awesome LLM Apps कोडबेस (जिसमें GitHub पर 1.24 लाख से अधिक सितारे हैं) के लेखक शुभम साबू ने एक अन्य विभाजन प्रस्तुत किया, जिसमें उन्होंने दो स्तरों का अंतर किया: “लंबे समय तक चलने वाला संगठनात्मक चार्ट यह निर्धारित करता है कि कौन किस क्षेत्र के लिए जिम्मेदार है और संदर्भ को बनाए रखता है; कार्य चार्ट वर्तमान में क्या करना है, उसे सबूत के आधार पर विभाजित, मिलाया, पुनः क्रमबद्ध किया जा सकता है या सीधे गायब हो सकता है।”

ग्राफ क्या है?

Loop से Agent के व्यवहार को प्रोग्राम किया जा सकता है। Graph से Agent के संगठन को प्रोग्राम किया जा सकता है।

अगला कदम डायनामिक एजेंट संगठन है: टास्क निष्पादन के दौरान, ग्राफ स्वयं की संरचना को पुनः लिखता है।

प्रेस्टन होल्म्स: कम से कम दो ग्राफ महत्वपूर्ण हैं। पहला आपके द्वारा दिखाए गए ग्राफ है, जिसमें लंबे समय तक मौजूद एजेंट शामिल हैं, जो क्षेत्रीय रक्षा की तरह, प्रत्येक एक क्षेत्र के लिए जिम्मेदार हैं। दूसरा उन कार्यों का ग्राफ है जिन्हें पूरा करना है। यह गतिशील है और लगातार बदलता रहता है।

शुभम साबू: लंबे समय तक अस्तित्व में रहने वाला "संगठन चित्र" यह निर्धारित करता है कि प्रत्येक क्षेत्र के लिए कौन जिम्मेदार है और संदर्भ को बनाए रखता है। "कार्य चित्र" यह निर्धारित करता है कि वर्तमान में कौन से कार्य पूरे किए जाने चाहिए। जब नए सबूत सामने आते हैं, तो इसे विभाजित, मिलाया, पुनः क्रमबद्ध किया जा सकता है, या सीधे गायब हो सकता है।

यह उत्पादन स्तरीय बहु-एजेंट सिस्टम की कुंजी है: वास्तव में दो ग्राफ एक साथ चल रहे हैं।

ऑर्ग ग्राफ़: "कौन क्या जिम्मेदार है" को परिभाषित करता है। यह स्थायी एजेंटों से बना होता है, जिनमें से प्रत्येक एक निश्चित क्षेत्र के लिए जिम्मेदार होता है, और उस क्षेत्र के संदर्भ, विशेषज्ञता और उपकरण अधिकारों को बनाए रखता है। ऑर्ग ग्राफ़ स्थिर होता है, जैसे किसी कंपनी की संगठनात्मक संरचना।

वर्क ग्राफ (Work Graph): "अभी क्या करना है और कार्य कैसे प्रवाहित होते हैं" इसकी परिभाषा है। यह कार्यों और नए सबूतों के साथ बदलता रहता है, जिसे विभाजित, एकीकृत, क्रम बदला जा सकता है या सीधे रद्द किया जा सकता है। वर्क ग्राफ एक रीयल-टाइम जनरेटेड प्रोजेक्ट प्लान की तरह है।

प्रेस्टन होल्म्स का भी मानना है कि दोनों आरेख महत्वपूर्ण हैं और वे अलग-अलग समय स्केल पर कार्य करते हैं। ऑर्गनाइजेशन आरेख को पूर्वनिर्धारित और तैनात किया जाता है; जॉब आरेख प्रत्येक कार्य के लिए डायनामिक रूप से उत्पन्न किए जाते हैं और कार्य पूरा होने के बाद फेंक दिए जाते हैं।

अगर चक्र Agent के व्यवहार को प्रोग्राम करने योग्य बनाते हैं, तो ग्राफ Agent संगठन को प्रोग्राम करने योग्य बनाते हैं। आगे बढ़कर, गतिशील Agent संगठन—कार्य निष्पादन के दौरान, ग्राफ स्वयं अपनी संरचना को पुनः लिखता है।

प्रॉम्प्ट लिखने से लेकर लूप डिज़ाइन करने और फिर ग्राफ़ बनाने तक, AI प्रोग्रामिंग की क्षमता का केंद्र लगातार ऊपर की ओर जा रहा है। डेवलपर्स को अब एकल एजेंट के साथ कैसे बातचीत करनी है, इसकी चिंता कम करनी पड़ रही है, और बजाय इस पर ध्यान केंद्रित करना पड़ रहा है कि एजेंट्स के बीच सहयोग संरचना कैसे डिज़ाइन की जाए।