जब AI अधिक कोड लिख रहा है, तब भी हमें उसे समझने की आवश्यकता क्यों है

मैंने AI की सहायता से ऐसा उत्पाद बनाया जो लोगों को कोड समझने में मदद करता है।

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

मैंने लगभग जुलाई 2025 में FiboCode बनाना शुरू किया। उस समय Vibe Coding तेज़ी से बढ़ रहा था और हर कोई AI से कोड लिखने तथा software development की लागत घटाने की बात कर रहा था। मेरे मन में स्वाभाविक रूप से एक विचार आया:

यदि AI लोगों को कोड लिखने में मदद कर सकता है, तो क्या वह उन्हें कोड समझने में भी मदद कर सकता है?

कोड लिखने की लागत लगातार घट रही है, लेकिन किसी अपरिचित project को समझना अब भी कठिन है। वर्षों पुराने codebase में जटिल directory structure, module dependencies, historical design decisions और अनेक conventions हों तो यह और कठिन हो जाता है। अक्सर केवल यह जानने में बहुत समय लगता है कि शुरुआत कहाँ से करें।

FiboCode उसी सरल विचार से शुरू हुआ: AI से code analysis कराकर संबंधित documents और relationship diagrams बनाना, फिर code, documents और diagrams के बीच जाना संभव करना।

उस समय वह केवल code analysis tool था।

बाद में code के बारे में प्रश्न पूछना आसान बनाने के लिए मैंने एक सरल Agent जोड़ा। पढ़ने का अनुभव सुधारने के लिए Monaco Editor integrate किया। Editor आने पर code navigation, symbol references और language diagnostics भी आवश्यक लगे, इसलिए LSP support जोड़ा।

पढ़ना संभव हुआ तो editing स्वाभाविक अगला कदम था।

जब FiboCode code बदलने लगा, मैंने सोचना शुरू किया कि Agent केवल खुली हुई कुछ files से निर्णय लेने के बजाय पूरे project को वास्तव में कैसे समझे। धीरे-धीरे MCP और Skills जोड़े, ताकि AI को design conventions, architectural context और project history भी मिल सके।

फिर मुझे एहसास हुआ कि कई developers Claude और Codex जैसे Agent CLI के साथ पहले ही सहज हैं। शायद उन्हें एक और built-in Agent नहीं, बल्कि Agent के काम के परिणामों की समीक्षा के लिए बनाया गया interface चाहिए।

इसलिए FiboCode में terminal और Agent CLI output के लिए विशेष सुधार जोड़े गए, ताकि terminal के file references, code changes और execution steps को code, documents और relationship diagrams से जोड़ा जा सके।

इस प्रकार एक सरल code analysis module धीरे-धीरे बढ़कर अधिक जटिल system बन गया।

मैं अपना बनाया project भूलने लगा

AI-assisted programming वास्तव में सुविधाजनक है।

शुरुआती models आज जितने सक्षम नहीं थे, फिर भी मैं उनके generated code की कई बार सावधानी से समीक्षा करता था। मैं देखता था कि modules कैसे बाँटे गए, data कैसे बहता है और architecture उस तरह क्यों design हुआ।

Development के दौरान project में कई refactorings हुईं। कुछ बहुत बड़ी थीं, लेकिन उस समय design details से परिचित होने के कारण अंततः किसी ने project नहीं तोड़ा।

फिर models अधिक सक्षम हुए, code generation तेज़ हुई और codebase तेजी से बढ़ने लगा।

धीरे-धीरे मैंने देखा कि केवल एक-दो सप्ताह पहले review किए code की design details भी याद नहीं रहतीं।

शुरू में इससे थोड़ा डर लगा।

यह मेरा अपना project था। हर feature मुझसे आया था, फिर भी मैं याद नहीं रख पा रहा था कि हर module उस तरह क्यों design हुआ या हर logic कैसे काम करती है।

समय के साथ समझ आया कि शायद इसे स्वीकार करना ही होगा।

यह अब शुरुआत वाला छोटा project नहीं था। पर्याप्त जटिल system में कोई भी हर implementation detail याद नहीं रख सकता। वास्तव में महत्वपूर्ण शायद हर line को दिमाग में रखना नहीं, बल्कि यह जानना है कि system का core कहाँ है, modules कैसे सहयोग करते हैं, किन हिस्सों को सुरक्षित रूप से AI को सौंपा जा सकता है और किन्हें ध्यान से समझना आवश्यक है।

मुझे चयन करना सीखना था।

विशाल code में critical paths खोजने, system की व्यापक mental picture बनाने और फिर AI को अधिक सटीक requirements व constraints देने थे।

इस दृष्टि से FiboCode मुझे FiboCode बनाने में भी मदद कर रहा था।

मैंने AI से product विकसित किया; product अधिक उपयोगी हुआ; फिर उसने स्वयं को अधिक तेज़ी से समझने और सुधारने में मेरी मदद की। यह positive feedback loop बहुत रोमांचक था और इतने लंबे समय तक काम जारी रखने का महत्वपूर्ण कारण था।

लेकिन उत्साह के अलावा मैं अक्सर स्वयं से पूछता था:

इस development process में मेरे लिए क्या बचा था?

जब मैंने अपनी अधिक से अधिक सोच AI को सौंप दी

लंबे समय में धीरे-धीरे मेरी एक आदत बन गई।

जब भी कोई requirement होती, पहले AI को देता।

जब भी कोई problem होती, पहले AI से जाँच करवाता।

Solution आने पर मैं verify करता। Verification fail होने पर result वापस देकर फिर analysis और fix माँगता।

कभी पूरा दिन AI को requirements बताने, bug की current state समझाने और test results वापस देने में निकल जाता।

लगता था कि लगभग सारा कठिन बौद्धिक काम AI कर रहा है, जबकि मेरी भूमिका requirements तय करने और results लौटाने तक सीमित हो गई है।

उस समय मुझे गहराई से लगा:

जैसे मेरे पास अब अधिक मूल्य नहीं बचा।

लेकिन काम जारी रखने पर पता चला कि यह पूरी तरह सही नहीं था।

AI के साथ development में मुझे ऐसी technologies मिलीं जिन्हें पहले पढ़ना नहीं चुनता, और कई implementation approaches दिखीं। Concrete implementation से पहले design और architecture को जानबूझकर देखने लगा।

कुछ tasks में तुरंत समझ जाता कि scope छोटा है और AI सीधे पूरा कर सकता है।

लेकिन जब task कई modules में जाता या project की core structure को प्रभावित करता, तुरंत पता चलता कि वह सरल नहीं है। AI केवल वर्तमान requirement देख सकता है, historical design का कारण या indirect impact नहीं जान सकता।

ऐसा code भी था जिसे AI लिख सके तब भी मुझे लगभग पूरी तरह समझना था, क्योंकि वहाँ गलती के परिणाम नियंत्रित करना कठिन होता।

मैंने हर implementation detail समझने पर ज़ोर देना छोड़ दिया, लेकिन system boundaries, dependencies, risks और changes के प्रति अधिक संवेदनशील हो गया।

शायद मानव कार्य समाप्त नहीं हुआ; वह केवल बदल रहा है।

पहले हम स्वयं code implement करके system समझते थे।

भविष्य में शायद repetitive implementation पर कम प्रयास और architecture, process, constraints, verification व long-term evolution पर अधिक ध्यान देंगे।

AI इसे लिख सकता है, इसका अर्थ यह नहीं कि हम भरोसा कर सकते हैं

मैं नहीं जानता कि भविष्य में AI सचमुच human experts की जगह लेकर सारा programming work कर पाएगा या नहीं।

यह निश्चित रूप से technical question है, लेकिन मेरे विचार में trust का question भी है।

एक दिन AI स्वतंत्र रूप से अत्यंत जटिल system बना सके, तब भी यह नहीं कि हम उस पर बिना शर्त भरोसा करेंगे।

System अप्रत्याशित व्यवहार करे तो क्या हम जानेंगे कि क्यों?

क्या हम error locate कर पाएँगे?

क्या fix verify कर पाएँगे?

क्या कोई दूसरा व्यक्ति उसे संभाल पाएगा?

System गंभीर नुकसान करे तो उत्तरदायी कौन होगा?

ये प्रश्न model accuracy को 99% से 99.9% करने मात्र से पूरी तरह हल नहीं होते।

कम जोखिम और आसानी से बदली जाने वाली applications में हम अधिक black box सह सकते हैं। Function काम करे और development पर्याप्त तेज़ हो तो हर detail की चिंता आवश्यक नहीं।

लेकिन operating systems और databases जैसे foundational software, या finance, electricity और समाज पर बड़ा प्रभाव डालने वाले systems में ऐसा black box स्वीकारना कठिन है जिसे समझा, audit या hand over न किया जा सके।

इन systems को अब भी बनाए रखने के लिए लोगों की आवश्यकता है।

उन्हें हर line स्वयं नहीं लिखनी, लेकिन किसी को मोटे तौर पर पता होना चाहिए कि system कैसे काम करता है, critical risks कहाँ हैं और समस्या आने पर जाँच कहाँ से शुरू करनी है।

इसीलिए मेरा विश्वास बढ़ता गया कि AI programming के बढ़ने से code understanding समाप्त नहीं होगी।

वह केवल दूसरा रूप लेगी।

पहले code लिखने के लिए उसे समझना आवश्यक था।

भविष्य में AI द्वारा बनाए systems को verify, maintain, take over और evolve करने के लिए code समझना आवश्यक हो सकता है।

गायब होते entry-level tasks

Code understanding का एक और महत्व है।

AI repetitive implementation और basic tasks पर आधारित कुछ entry-level roles घटा रहा है। Jobs स्वयं न भी मिटें, तो नए लोगों को मिलने वाला बहुत सा काम पहले AI से automate हो रहा है।

यह newcomers के लिए अनुकूल नहीं है।

Engineer के बढ़ने का पारंपरिक रास्ता सरल tasks से शुरू होता है: bug ठीक करना, छोटा code section पढ़ना, छोटा feature पूरा करना, फिर धीरे-धीरे अधिक जटिल modules और system design में भाग लेना।

इन महत्वहीन दिखने वाले tasks से newcomers वास्तविक projects की समझ धीरे-धीरे बनाते हैं।

लेकिन अब AI ये foundational tasks सीधे पूरा कर सकता है।

जब newcomers को प्रशिक्षित करने के entry points कम होंगे, तो भविष्य के senior engineers कहाँ से आएँगे?

यह FiboCode बनाने का एक और कारण था।

मैं स्वयं भी profession में नया हूँ। पहली बार complex legacy codebase सामने आया तो अक्सर पूरी तरह असहाय महसूस किया।

बहुत सारी files और directories थीं। Services एक-दूसरे को call करतीं, types, interfaces और configuration अलग जगहों पर बिखरे थे। पता था कि उत्तर code में कहीं है, पर यह नहीं कि शुरुआत कहाँ से करें, क्या महत्वपूर्ण है और क्या केवल implementation detail।

अक्सर असली कठिनाई किसी line को समझना नहीं, बल्कि पूरा map न होना था।

मैं हमेशा ऐसा tool चाहता था जो पहले पूरे project की structure analyze करके बताए कि core modules कहाँ हैं, code कैसे जुड़ा है और change किन क्षेत्रों को प्रभावित कर सकता है।

तब newcomers को किसी के step-by-step मार्गदर्शन पर पूरी तरह निर्भर नहीं रहना पड़ता, न ही अपरिचित codebases में बार-बार टटोलना पड़ता।

ऐसा tool growth process की जगह नहीं ले सकता, लेकिन complex system में प्रवेश की बाधा कम कर सकता है।

जैसे-जैसे AI पुराना growth path काटता है, मैं आशा करता हूँ कि FiboCode एक नया मार्ग जोड़ सके।

हर foundation को छोड़ने वाला shortcut नहीं, बल्कि map, navigation system और ऐसा रास्ता जो newcomers को system का mental model जल्दी बनाने में मदद करे।

Code केवल वर्तमान दर्ज करता है

Development में मैंने एक और समस्या देखी।

Task सीधे AI को देकर repository स्वयं explore करने देना कभी-कभी अधूरी सोच तक ले जाता है।

AI current code देखता है, लेकिन शायद नहीं जानता कि module किसी विशेष तरीके से क्यों design हुआ या दिखने में असंबंधित files से उसका indirect connection है।

Code सामान्यतः बताता है कि system अभी कैसा है, लेकिन यह समझाना कठिन होता है कि वह ऐसा क्यों बना।

पहले मैंने यह सारी जानकारी code comments में रखने का विचार किया।

बाद में तय किया कि यह उपयुक्त नहीं।

बहुत सा design context, historical reasoning और change explanation code files को भारी करेगा तथा AI को current task से असंबंधित context देगा। Comments local logic समझाने के लिए अच्छे हैं, पर पूरे project evolution को नहीं ढो सकते।

इसलिए मैंने Fibo Skills की एक शृंखला design की।

वे project conventions, designs, implementation process और diff explanations दर्ज करके हर code change का अधिक पूर्ण trace छोड़ती हैं।

मैं चाहता हूँ कि भविष्य में AI code बदलते समय केवल current state न देखे, बल्कि यह भी समझे कि अतीत में क्या हुआ और कुछ designs क्यों बचाए गए।

Project evolution का इतिहास traceable हो तो AI project को अधिक पूरी तरह समझ सकता है।

यह भी FiboCode की एक दिशा बन गई:

पहले इसे लोगों को code समझने में मदद देने के लिए बनाया था। बाद में यह AI को code बेहतर समझाने में भी मदद करने लगा।

FiboCode आज के रूप में कैसे बढ़ा

पीछे देखने पर FiboCode को शुरुआत से आज जैसा बनने के लिए design नहीं किया गया था।

यह सरल code analysis module से शुरू हुआ। फिर documents और relationship diagrams, Agent, editor और language services आए। धीरे-धीरे code editing, terminal, MCP और Skills भी जुड़े।

मैं Agent CLI को Cursor जैसा code review अनुभव देना चाहता था, और code analysis से बने documents व relationship information को ऐसा context बनाना चाहता था जिसे AI वास्तव में उपयोग कर सके।

यह सरल module से complex system बना, और निरंतर growth की यह प्रक्रिया चुपचाप Fibonacci sequence के विस्तार जैसी थी।

FiboCode नाम और snail image भी यहीं से आए।

Snail के shell में golden spiral की mathematical beauty है।

वह बहुत तेज़ नहीं चलता, लेकिन आगे बढ़ता और विकसित होता रहता है।

FiboCode लोगों से हर code line फिर हाथ से लिखवाना नहीं चाहता, न ही AI को बाहर रखना चाहता है।

इसके विपरीत, वह स्वीकार करता है कि AI अधिक से अधिक code लिखेगा और इसी आधार पर लोगों को अपने systems समझने, verify करने, maintain करने और संभालने में सहायता देना चाहता है।

जब हर कोई तेज़ generation के पीछे है, तब भी मैं आशा करता हूँ कि हम कभी-कभी धीमे हो सकें।

यह समझने के लिए कि code उस तरह क्यों चलता है और system आज जैसा क्यों बना।

और programming की ओर पहली बार खींचने वाली खुशी को फिर खोजने के लिए।