💻 computer science

Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

यह शोध पत्र Cadre प्रस्तुत करता है, जो एक संदर्भ-जागरूक ढांचा (context-aware framework) है जो लक्षित पैच उत्पन्न करने के लिए एक संदर्भ-जागरूक निर्भरता ग्राफ (Context-aware Dependency Graph - CDG) का निर्माण करने हेतु स्टैटिक एनालिसिस का लाभ उठाता है ताकि Dockerfile ड्रिफ्ट को प्रभावी ढंग से ठीक किया जा सके, और यह नए पेश किए गए 1,040 वास्तविक-विश्व ड्रिफ्ट उदाहरणों के $D^3$ बेंचमार्क पर मौजूदा नियम-आधारित और LLM-आधारित बेसलाइन से बेहतर प्रदर्शन करता है।

मूल लेखक: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

प्रकाशित 2026-07-15

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आप अपने गैरेज में एक रोबोट बना रहे हैं। आपने एक बेहतरीन निर्देश पुस्तिका (Dockerfile) लिखी है जो आपके रोबोट को बताती है कि उसे कौन से पुर्जे उठाने हैं, उन्हें कहाँ रखना है और उन्हें कैसे जोड़ना है। लेकिन फिर, आप रोबोट के दिमाग को अपग्रेड करने का फैसला करते हैं (source code) और कुछ तार बदल देते हैं। आप नए पुर्जों के अनुसार निर्देश पुस्तिका को अपडेट करना भूल जाते हैं।

अब, जब आप रोबोट बनाने की कोशिश करते हैं, तो वह लड़खड़ाता है और बंद हो जाता है। निर्देश पुस्तिका व्याकरण के लिहाज से "टूटी" नहीं है; शब्द सही हैं। लेकिन निर्देश पुस्तिका वास्तविकता से दूर (drift) हो गई है। यह एक ऐसे पुर्जे को पकड़ने की कोशिश कर रही है जो अब मौजूद नहीं है या एक ऐसे उपकरण का उपयोग करने की कोशिश कर रही है जिसे बदल दिया गया है। सॉफ्टवेयर की दुनिया में, इसे Dockerfile drift कहा जाता है, और यह कंप्यूटरों को चुपचाप विफल कर देता है, जिससे डेवलपर्स कई दिनों तक सिर खुजलाते रह जाते हैं।

पुराना तरीका: अंधेरे में अनुमान लगाना

पिछले टूल्स ने इसे केवल मैनुअल और एरर मैसेज को पढ़कर ठीक करने की कोशिश की। यह कार के इंजन को ठीक करने के लिए केवल "चेक इंजन" लाइट और ओनर मैनुअल को देखने जैसा है, बिना बोनट खोलकर यह देखे कि असली तार कहाँ हैं।

कुछ टूल्स ने कठोर नियमों (जैसे चेकलिस्ट) का उपयोग किया, जबकि अन्य सुपर-स्मार्ट AI (लार्ज लैंग्वेज मॉडल्स) का उपयोग करके सुधार का अनुमान लगाने लगे। लेकिन समस्या यह थी: ये AI टूल्स सूचनाओं में डूब रहे थे। उन्हें पूरे गैरेज के साथ—हर एक पेंच, हर पुराना मैनुअल और कबाड़ का हर डिब्बा—एरर मैसेज के साथ थमा दिया गया था। AI इस शोर से इतना अभिभूत हो गया कि या तो उसने हार मान ली या उसने एक पागलपन भरा समाधान बताया जो काम नहीं आया। वास्तव में, हर बैच की 41 से 58 समस्याओं में से, इन AI टूल्स ने कोई भी उत्तर देने में विफलता दिखाई क्योंकि "निर्देश सूची" इतनी लंबी थी कि वे उसे पढ़ ही नहीं सके।

नया नायक: Cadre (जासूस)

यहाँ Cadre आता है, एक नया फ्रेमवर्क जो एक शानदार जासूस की तरह काम करता है। लेखक, चेंगजी वांग और उनकी टीम ने महसूस किया कि रोबोट को ठीक करने का रहस्य जासूस को और अधिक चीजें पढ़ने के लिए देना नहीं है, बल्कि उन्हें सही नक्शा देना है।

उनका बड़ा विचार सरल है: संरचना (Structure), मात्रा (Volume) से अधिक महत्वपूर्ण है। यह जानना कि कौन सा विशिष्ट तार किस विशिष्ट पेंच से जुड़ता है, हजारों असंबंधित टेक्स्ट को पढ़ने की तुलना में बहुत अधिक महत्वपूर्ण है।

Cadre तीन जादुई चरणों में यह करता है:

द कॉन्टेक्स्ट प्रोफाइलर (समय यात्री): किसी भी चीज़ को ठीक करने की कोशिश करने से पहले, Cadre पूरी निर्माण प्रक्रिया का चरण-दर-चरण अनुकरण (simulate) करता है। यह देखता है कि कौन सी फाइलें कॉपी की जा रही हैं, कौन से वेरिएबल्स सेट किए जा रहे हैं, और किन टूल्स को कॉल किया जा रहा है। यह हर क्षण प्रोजेक्ट की "अवस्था" (state) का एक मानसिक मॉडल बनाता है।
द CDG (डिपेंडेंसी मैप): उस सिमुलेशन का उपयोग करके, Cadere एक कॉन्टेक्स्ट-अवेयर डिपेंडेंसी ग्राफ (CDG) बनाता है। इसे अपने सॉफ्टवेयर के लिए एक सबवे मैप की तरह समझें। यह दिखाता है कि "FROM" निर्देश (बेस) कैसे "COPY" निर्देश (पुर्जे) से जुड़ता है और अंत में "RUN" निर्देश (असेंबली) से जुड़ता है। यदि कोई फ़ाइल बदलती है, तो मैप दिखाता है कि कौन से निर्देश उस पर ठोकर खाएंगे।
द टू-स्टेप फिक्स (स्मार्ट फिल्टर): AI पर पूरा गैरेज डालने के बजाय, Cadre पहले AI से एक स्मार्ट सवाल पूछता है: "इस मैप और एरर के आधार पर, आपको वास्तव में किन विशिष्ट फाइलों को देखने की आवश्यकता है?"
- चरण 1: AI केवल प्रासंगिक फाइलों (मुख्य फाइलों) को चुनता है।
- चरण 2: AI केवल उन फाइलों को पढ़ता है और सुधार लिखता है।

यह AI के "दिमाग" को ओवरफ्लो होने से रोकता है। जहाँ अन्य तरीके 41-58 मामलों में पैच बनाने में विफल रहे क्योंकि प्रॉम्प्ट बहुत बड़ा था, वहीं Cadre ने अपने हर प्रयास के लिए एक पैच तैयार किया।

परिणाम: क्या यह काम करता है?

टीम ने 1,040 वास्तविक दुनिया के उदाहरणों पर Cadre का परीक्षण किया जिन्हें उन्होंने GitHub के इतिहास से निकाला था (एक डेटासेट जिसे उन्होंने 𝐷3 कहा)। ये नकली समस्याएं नहीं थीं; ये वास्तविक सॉफ़्टवेयर प्रोजेक्ट्स में हुई वास्तविक विफलताएं थीं, जिनमें उन्हें दोबारा उत्पन्न करने के लिए सटीक सेटिंग्स भी शामिल थीं।

यहाँ Cadre का मुकाबला हुआ:

Cadre ने समस्याओं के 35.22% को ठीक किया।
सबसे अच्छे पिछले AI मेथड (बिना इस स्मार्ट मैपिंग के) ने 28.48% को ठीक किया।
पुराने नियम-आधारित चेकलिस्ट मेथड ने केवल 9.34% को ठीक किया।

इसका मतलब है कि Cadre अपने सबसे अच्छे AI प्रतिद्वंद्वी से 1.24 गुना बेहतर है और पुराने नियम-आधारित टूल्स से लगभग 3 गुना बेहतर है।

लेकिन असली जादू तब होता है जब समस्या "पुरानी (stale)" हो जाती है। कल्पना कीजिए कि एक टूटा हुआ बिल्ड जिसे पांच या छह अपडेट के बाद भी ठीक नहीं किया गया। हाल के कोड परिवर्तन मूल त्रुटि से पूरी तरह से असंबंधित लग सकते हैं। अधिकांश टूल्स भ्रमित हो जाते हैं और हार मान लेते हैं। लेकिन क्योंकि Cadre CDG मैप का उपयोग करता है, यह टूटे हुए तार को उसके मूल तक ट्रैक कर सकता है, भले ही वह इतिहास में कहीं भी गहरा दबा हो। पांच या अधिक अपडेट दूर होने पर भी, Cadre ने 25.9% समस्याओं को ठीक किया, जबकि अगले सबसे अच्छे टूल ने केवल 19.7% ही प्रबंधित किया। यह अंतर और भी बढ़ गया क्योंकि समस्याएं जितनी पुरानी हुईं, मैप उतना ही मजबूत संकेत साबित हुआ।

यह क्या नहीं है

यह जानना महत्वपूर्ण है कि Cadre क्या नहीं है। यह हर चीज़ को ठीक करने वाली जादुई छड़ी नहीं है।

यह उन समस्याओं को ठीक नहीं कर सकता जो इंटरनेट डाउन होने या सर्वर में डिस्क स्पेस खत्म होने के कारण होती हैं।
यह वास्तविक कोड लॉजिक (जैसे प्रोग्राम के भीतर गणितीय त्रुटि) के भीतर के बग को ठीक नहीं कर सकता; यह केवल बिल्ड निर्देशों को ठीक करता है।
लगभग 65% मामलों में जहाँ यह विफल हुआ, समस्या एक जटिल बिल्ड-टूल बाधा थी जिसे केवल मैनुअल बदलकर हल नहीं किया जा सकता था (जैसे कि किसी प्राइवेट रजिस्ट्री में गायब पैकेज)।

निष्कर्ष

लेखक सुझाव देते हैं कि सॉफ्टवेयर रखरखाव के भविष्य के लिए, हमें केवल AI को अधिक डेटा देने के बजाय उसे निर्भरताओं (dependencies) की संरचना को समझने के लिए सिखाने की आवश्यकता है। फाइलों और निर्देशों के बीच संबंध का एक मैप बनाकर, Cadre ने सिद्ध किया कि थोड़ा सा स्मार्ट कॉन्टेक्स्ट बहुत काम आता है। यह पूरी लाइब्रेरी को पढ़ने के बारे में नहीं है; यह यह जानने के बारे में है कि बिल्कुल कौन सा पन्ना पलटना है।

1,040 वास्तविक दुनिया के ड्रिफ्ट्स का सारा कोड और डेटासेट किसी के भी द्वारा जांच के लिए खुला है, यह सुनिश्चित करता है कि यह केवल एक सिद्धांत नहीं है, बल्कि वास्तविक, पुनरुत्पादक साक्ष्य पर बना एक टूल है।

तकनीकी सारांश: ड्रिफ्ट पर नियंत्रण: सॉफ्टवेयर विकास के दौरान Dockerfile ड्रिफ्ट का संदर्भ-जागरूक सुधार (Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution)

1. समस्या की परिभाषा: Dockerfile ड्रिफ्ट

आधुनिक सॉफ्टवेयर विकास निरंतर एकीकरण और निरंतर परिनियोजन (CI/CD) पाइपलाइनों पर बहुत अधिक निर्भर करता है, जहाँ Docker दोहराने योग्य बिल्ड वातावरण सुनिश्चित करने के लिए एक मानक के रूप में कार्य करता है। हालाँकि, एक महत्वपूर्ण समस्या जिसे Dockerfile ड्रिफ्ट कहा जाता है, इस विश्वसनीयता को कम करती है। ड्रिफ्ट तब होता है जब एक Dockerfile एप्लिकेशन के सोर्स कोड में किए गए परिवर्तनों को आत्मसात करने में विफल रहता है, जिससे बिल्ड स्क्रिप्ट और विकसित होते रिपॉजिटरी स्टेट के बीच विसंगति पैदा हो जाती है। सिंटैक्स त्रुटियों के विपरीत, यह एक आंतरिक सह-विकास (co-evolution) की समस्या है जहाँ सुधार की जानकारी उसी रिपॉजिटरी के भीतर मौजूद होती है जिसने विफलता उत्पन्न की है।

ड्रिफ्ट गलत फ़ाइल पथों, बेमेल एनवायरनमेंट वेरिएबल्स, पुराने डिपेंडेंसी स्पेसिफिकेशन, या प्लेटफॉर्म परिवर्तनों के रूप में प्रकट होता है। ये विफलताएं स्वचालित रूप से मरम्मत करना विशेष रूप से कठिन है क्योंकि तीन मुख्य चुनौतियाँ हैं:

C1 (संदर्भ निष्कर्षण - Context Extraction): बिल्ड स्टेट (वर्किंग डायरेक्टरी, एनवायरनमेंट वेरिएबल्स, फ़ाइल सेट) पिछले निर्देशों के संचयी निष्पादन द्वारा निर्धारित होता है, न कि केवल Dockerfile के टेक्स्ट द्वारा। मौजूदा नियम-आधारित और LLM-आधारित विधियाँ अक्सर Dockerfile को अलग-थलग मानती हैं, और इन गतिशील अंतःक्रियाओं को मॉडल करने में विफल रहती हैं।
C2 (क्रॉस-इंस्ट्रक्शन डिपेंडेंसीज़ - Cross-Instruction Dependencies): निर्देश अक्सर पूर्ववर्ती चरणों द्वारा निर्मित आर्टिफ़ैक्ट्स पर गैर-स्पष्ट तरीकों से निर्भर करते हैं (उदाहरण के लिए, एक RUN कमांड उन फ़ाइलों पर कार्य करता है जो पिछले COPY या ARG द्वारा पेश की गई थीं)। ये निर्भरताएँ अकेले में सिंटैक्स के माध्यम से दृश्यमान नहीं होती हैं।
C3 (मूल कारणों का पता लगाना - Locating Root Causes): एरर लॉग अक्सर विफल होने वाले निर्देश की ओर संकेत करते हैं लेकिन शायद ही कभी मूल कारण की पहचान करते हैं, जो कि पिछले कमिट में पेश किए गए कोड परिवर्तन से उत्पन्न हो सकता है।

2. कार्यप्रणाली: Cadre फ्रेमवर्क

लेखक Cadre प्रस्तावित करते हैं, जो एक संदर्भ-जागरूक (context-aware) फ्रेमवर्क है जिसे बिल्ड संदर्भ को स्पष्ट रूप से मॉडल करके Dockerfile ड्रिफ्ट को ठीक करने के लिए डिज़ाइन किया गया है। केंद्रीय डिज़ाइन अंतर्दृष्टि यह है कि संदर्भ की मात्रा से अधिक संदर्भ की संरचना सुधार की गुणवत्ता निर्धारित करती है। Cadre इन तीन चुनौतियों को चार एकीकृत चरणों के माध्यम से संबोधित करता है:

2.1 Dockerfile ड्रिफ्ट एक्सट्रैक्टर (DodeX)

यथार्थवादी बेंचमार्क की कमी को दूर करने के लिए, लेखकों ने DodeX विकसित किया है, जो GitHub Actions CI लॉग से वास्तविक दुनिया के ड्रिफ्ट इंस्टेंस निकालने वाला एक पाइपलाइन है। स्टैटिक स्नैपशॉट डेटासेट के विपरीत, DodeX पूर्ण बिल्ड कॉन्फ़िगरेशन कैप्चर करता है, जिसमें डायनेमिक बिल्ड आर्गुमेंट्स, टारगेट प्लेटफॉर्म और विफलता को ट्रिगर करने वाले सटीक कोड-चेंज डिफ शामिल हैं। यह सुनिश्चित करता है कि प्रत्येक निकाला गया इंस्टेंस स्थानीय रूप से पुनरुत्पादित (reproducible) है।

2.2 इंस्ट्रक्शन-लेवल कॉन्टेक्स्ट प्रोफाइलर

C1 को हल करने के लिए, Cadre Docker बिल्ड प्रक्रिया का एक स्टेटफुल सिमुलेशन करता है। यह Dockerfile के प्रत्येक निर्देश के माध्यम से यात्रा करता है, और एक कॉन्टेक्स्ट स्टेट ( $\sigma$ ) बनाए रखता है जो ट्रैक करता है:

वर्तमान वर्किंग डायरेक्टरी ( $\delta$ )।
रिजोल्व किए गए एनवायरनमेंट वेरिएबल्स ( $\varepsilon$ )।
कंटेनर में मौजूद फ़ाइलों का सेट ( $\Phi$ )।

महत्वपूर्ण रूप से, प्रोफाइलर 11 प्रमुख इकोसिस्टम (जैसे Go, Python, npm, Maven) के लिए बिल्ड-सिस्टम-जागरूक पार्सर्स का उपयोग करता है। RUN कमांड को अपारदर्शी स्ट्रिंग्स के रूप में मानने के बजाय, ये पार्सर्स अंतर्निहित फ़ाइल निर्भरताओं का अनुमान लगाते हैं (जैसे, यह अनुमान लगाना कि go build के लिए go.mod और डायरेक्टरी में सभी *.go फ़ाइलों की आवश्यकता है)। यह एक इंस्ट्रक्शन कॉन्टेक्स्ट मैप (ICM) उत्पन्न करता है जो प्रत्येक निर्देश को उसके सटीक बिल्ड-टाइम स्टेट से जोड़ता है।

2.3 कॉन्टेक्स्ट-अवेयर डिपेंडेंसी ग्राफ (CDG)

C2 को हल करने के लिए, ICM को एक कॉन्टेक्स्ट-अवेयर डिपेंडेंसी ग्राफ (CDG) में परिवर्तित किया जाता है, जो एक निर्देशित अचक्रीय ग्राफ (directed acyclcyclic graph - $G = (V, E)$ ) है जो इंटर-इंस्ट्रक्शन निर्भरताओं को स्पष्ट बनाता है:

वर्टेक्स (Vertices): इसमें इंस्ट्रक्शन नोड्स ( $V_I$ ) और फ़ाइल नोड्स ( $V_F$ ) शामिल हैं।
एजेस (Edges): इसमें अनुक्रमिक एजेस ( $E_S$ ) शामिल हैं जो कंट्रोल फ्लो का प्रतिनिधित्व करती हैं और डेटाफ्लो एजेस ( $E_D$ ) शामिल हैं जो फ़ाइलों और निर्देशों के बीच "रीड-फ्रॉम" (read-from) निर्भरता का प्रतिनिधित्व करती हैं।
यह ग्राफ विफलता के प्रसार पथों (failure propagation paths) को ट्रैक करने की अनुमति देता है, जिससे यह पहचानना संभव होता है कि एक सोर्स फ़ाइल (जैसे, go.mod) में परिवर्तन कैसे एक मध्यवर्ती COPY या ARG चरणों के माध्यम से एक विशिष्ट RUN निर्देश को अमान्य कर देता है।

2.4 कॉन्टेक्स्ट-रिफाइंड रिपेयर वर्कफ़्लो

C3 को हल करने और टोकन सीमाओं को प्रबंधित करने के लिए, Cadre सिंगल-शॉट प्रॉम्प्ट के बजाय एक दो-चरणीय एजेंटिक वर्कफ़्लो का उपयोग करता है:

कॉन्टेक्स्ट इंक्वायरी (Context Inquiry): LLM को एरर लॉग, कोड डिफ और CDG का एक छँटा हुआ (pruned) संस्करण प्रस्तुत किया जाता है। इसे मरम्मत के लिए आवश्यक न्यूनतम प्रासंगिक फ़ाइलों और grep कीवर्ड्स को चुनने के लिए कहा जाता है। यह चरण फ़ाइल सामग्री लोड करने से पहले अप्रासंगिक संदर्भ को फ़िल्टर करता है।
रिपेयर जनरेशन (Repair Generation): सिस्टम केवल चयनित फ़ाइलों को प्राप्त करता है और एक लक्षित पैच उत्पन्न करता है।
यह दृष्टिकोण प्रॉम्प्ट ओवरफ्लो (जो प्रतिस्पर्धी LLM विधियों का एक सामान्य विफलता मोड है) को रोकता है और सुनिश्चित करता है कि मॉडल केवल कारण-संबंधी साक्ष्यों पर ध्यान केंद्रित करे।

3. प्रमुख योगदान

Cadre फ्रेमवर्क: एक नया रिपेयर फ्रेमवर्क जो इस अंतर्दृष्टि पर आधारित है कि संदर्भ की मात्रा से अधिक संदर्भ की संरचना मूल्यवान है। यह एक स्टेटफुल कॉन्टेक्स्ट प्रोफाइलर, एक डिपेंडेंसी ग्राफ और एक दो-चरणीय LLM वर्कफ़्लो को एकीकृत करता है।
DodeX और $D^3$ बेंचमार्क: DodeX का निर्माण, जो पूर्ण बिल्ड कॉन्फ़िगरेशन के साथ ड्रिफ्ट इंस्टेंस निकालने वाला एक पाइपलाइन है, और $D^3$ , पहला Dockerfile ड्रिफ्ट बेंचमार्क जहाँ सभी 1,040 इंस्टेंस मूल CI रन से सटीक मापदंडों का उपयोग करके स्थानीय रूप से पुनरुत्पादित किए जा सकते हैं।
अनुभवजन्य मूल्यांकन (Empirical Evaluation): एक व्यापक मूल्यांकन जो Cadre की तुलना नियम-आधारित बेसलाइन (Parfum), रिट्रीवल-आधारित बेसलाइन (FlakiDock), और वैनिला LLMs से करता है।

4. प्रयोगात्मक परिणाम

फ्रेमवर्क का मूल्यांकन $D^3$ बेंचमार्क पर किया गया (नेटवर्क टाइमआउट के लिए फ़िल्टरिंग के बाद 653 निष्पादन योग्य इंस्टेंस)।

मरम्मत प्रभावशीलता (Repair Effectiveness): Cadre ने 35.22% मरम्मत दर प्राप्त की, जो नियम-आधारित बेसलाइन (Parfum, 9.34%) की तुलना में 2.78 $\times$ और सर्वश्रेष्ठ LLM-आधारित बेसलाइन (Vanilla-LLM, 28.48%) की तुलना में 1.24 $\times$ बेहतर प्रदर्शन करती है।
टोकन दक्षता और मजबूती (Token Efficiency & Robustness): Cadre ने प्रॉम्ट-ओवरफ्लो विफलताओं को पूरी तरह से समाप्त कर दिया ( $|F_r| = 0$ ), जिससे 95.25% प्रॉम्प्ट 30k टोकन के नीचे रहे। इसके विपरीत, प्रतिस्पर्धी LLM विधियाँ संदर्भ सीमाओं को पार करने के कारण 41-58 मामलों में पैच जनरेट करने में विफल रहीं।
स्टेल ड्रिफ्ट मजबूती (Stale Drift Robustness): जैसे-जैसे ड्रिफ्ट इंस्टेंस "स्टेल" (कई कमिट्स के दौरान बने रहना) होते गए, केवल डिफ-आधारित दृष्टिकोणों का प्रदर्शन काफी गिर गया। 5+ कमिट की दूरी पर, Cadre ने 25.9% की सफलता दर बनाए रखी, जबकि सर्वश्रेष्ठ बेसलाइन के लिए यह 19.7% थी, जो दर्शाता है कि CDG एक संरचनात्मक सिग्नल प्रदान करता है जो कमिट की दूरी के प्रति मजबूत है।
एब्लेशन अध्ययन (Ablation Studies): CDG को हटाने से मरम्मत दर में 4.29 प्रतिशत अंक की कमी आई, जबकि दो-चरणीय वर्कफ़्लो को हटाने से 3.67 अंकों की कमी आई और प्रॉम्प्ट-ओवरफ्लो विफलताएं फिर से आ गईं। इनके घटकों को एक-दूसरे के पूरक के रूप में पाया गया।

5. महत्व और दावे

पेपर यह दावा करता है कि स्पष्ट निर्भरता मॉडलिंग (explicit dependency modeling) एक टिकाऊ मरम्मत सिग्नल है। लेखक तर्क देते हैं कि डिफ-ओनली या रिट्रीवल-आधारित विधियों की तुलना में संदर्भ-जागरूक दृष्टिकोण का लाभ तब बढ़ जाता है जब ड्रिफ्ट कमिट्स के माध्यम से पुराना (age) होता जाता है। अध्ययन सुझाव देता है कि संदर्भ-जागरूक इंफ्रास्ट्रक्चर एज कोड (IaC) रखरखाव भविष्य के टूल विकास के लिए एक उत्पादक दिशा है।

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