एजेंट युग में literate programming पर फिर से विचार किया जाना चाहिए

 (silly.business)
14 पॉइंट द्वारा GN⁺ 2026-03-11 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • कोड और natural language विवरण को एक ही narrative में पिरोने वाला Literate Programming कोड और विवरण—दोनों को साथ-साथ बनाए रखने के बोझ की वजह से व्यापक रूप से इस्तेमाल नहीं हो पाया, लेकिन AI coding agents इस मुख्य मेहनत को हटा सकते हैं
  • Emacs Org Mode के org-babel के ज़रिए multi-language literate programming संभव है, लेकिन बड़े प्रोजेक्ट्स में source code extraction (tangling) प्रक्रिया की झंझट इसकी सीमा बन जाती है
  • अगर एजेंट को Org file-आधारित runbook लिखने के लिए कहा जाए, तो एक ऐसा workflow संभव है जिसमें विवरण में intent समझाया जाता है, code blocks को interactive तरीके से चलाया जाता है, और results को दस्तावेज़ में सहेजा जाता है
  • क्योंकि एजेंट विवरण और कोड के बीच synchronization और tangling को अपने आप संभालता है, इसलिए कोड बदलने पर विवरण फिर से लिखने की मेहनत खत्म हो जाती है, और LLM की सबसे मजबूत क्षमता—translation और summarization—का उपयोग होता है
  • जिस प्रवाह में engineer की भूमिका कोड लिखने से कोड पढ़ने पर केंद्रित हो रही है, उसमें एजेंट द्वारा maintained narrative codebase की उपयोगिता एक अहम सवाल बनकर उभरती है

Literate Programming की अवधारणा और सीमाएँ

  • Literate Programming वह विचार है जिसमें कोड और natural language विवरण को मिलाकर ऐसा बनाया जाता है कि बिना पूर्व ज्ञान वाला पाठक भी codebase को एक narrative की तरह पढ़कर उसके काम करने के तरीके को समझ सके
  • यह आकर्षक विचार है, लेकिन व्यवहार में कोड और विवरण जैसी दो समानांतर narratives को बनाए रखने का बोझ पैदा होता है, और यही इसके अपनाए जाने की मूल बाधा रही है
  • व्यवहार में इसका सबसे आम रूप data science समुदाय के Jupyter notebooks हैं, जहाँ विवरण, computation और results एक साथ web browser में दिखाई देते हैं

Emacs Org Mode और Literate Programming

  • Emacs Org Mode org-babel package के माध्यम से multi-language literate programming को support करता है, और किसी भी language को चलाकर उसके results को दस्तावेज़ में capture किया जा सकता है
    • लेकिन यह तरीका अब भी केवल कुछ उत्साही users तक सीमित niche pattern है
  • अगर बड़े software projects में Org files को source of truth की तरह इस्तेमाल किया जाए, तो source code लगभग compiled output बन जाता है, और हर edit के बाद कोड को extract करके ("tangle") सही जगह रखना पड़ता है
    • इसे automate किया जा सकता है, लेकिन user या agent अगर असली source को सीधे edit कर दें, तो अगली tangle के समय overwrite होने की समस्या आसानी से आ सकती है

एजेंट से पहले के उपयोग पैटर्न

  • personal configuration की bookkeeping में literate programming का इस्तेमाल पर्याप्त उपयोगी रहा, इसलिए LLM आने से पहले भी इस विचार को छोड़ा नहीं गया
  • Org Mode का manual testing और note-taking के लिए उपयोग: command line की जगह editor में commands लिखना और चलाना, फिर हर step सही होने तक उन्हें edit करना, और results को वहीं सहेजना
    • "अगर note-taking और test execution को जोड़ दिया जाए, तो testing पूरी होने तक notes मुफ़्त में तैयार हो जाते हैं"

एजेंट के साथ नया workflow

  • Claude, Kimi जैसे coding agents Org Mode syntax को अच्छी तरह समझते हैं, और Org एक forgiving markup language है जिसे LLM बहुत अच्छे से संभालते हैं
    • Org Mode का बहुत विस्तृत syntax इंसानों के लिए भले कमी हो, लेकिन language models के लिए यह समस्या नहीं है
  • feature testing के समय एजेंट से Org runbook लिखने को कहा जाए, तो:
    • विवरण हर step के intent पर model की reflection को समेटता है
    • review के बाद code blocks को एक-एक करके या पूरे script की तरह interactive रूप से चलाया जा सकता है
    • results को Jupyter notebook की तरह कोड के नीचे सहेजा जाता है
  • विवरण को edit करके model से code update कराया जा सकता है, या code को edit करके model से उसका अर्थ विवरण में शामिल कराया जा सकता है, या एजेंट दोनों को एक साथ बदल सकता है
    • इससे समानांतर narratives को बनाए रखने की समस्या खत्म हो जाती है

एजेंट जो मुख्य मेहनत हटाते हैं

  • अगर tangling का काम एजेंट को दे दिया जाए, तो code extraction की समस्या भी हल हो जाती है
  • AGENTS.md file के ज़रिए एजेंट को यह निर्देश दिया जा सकता है कि Org Mode files को source of truth माने, हमेशा विवरण लिखे, और execution से पहले tangle करे
    • एजेंट यह सब काम कुशलता से कर सकता है, और कोड बदलने के बाद विवरण फिर से लिखने से कभी नहीं थकता
  • literate programming के व्यापक न होने की जो मूल अतिरिक्त मेहनत थी, उसे एजेंट हटा देते हैं, और यह LLM की सबसे मजबूत translation और summarization क्षमता का उपयोग है

अपेक्षित लाभ

  • codebase को अलग-अलग formats में export करके आसानी से पढ़ा जा सकता है
    • अगर engineer की मुख्य भूमिका लिखने से पढ़ने की ओर शिफ्ट हो रही है, तो यह खास तौर पर महत्वपूर्ण है
  • यह डेटा से साबित नहीं है, लेकिन यह अनुमान है कि हर code block के intent को समझाने वाला narrative जब कोड के साथ context में दिखाई देता है, तो generate होने वाले code की quality भी बेहतर हो सकती है
  • अब तक इसे बड़े, गंभीर codebase में नहीं आज़माया गया है; फिलहाल इसका उपयोग testing और manual process documentation workflow में हो रहा है

Org Mode की सीमाएँ और विकल्प

  • Org format का Emacs के साथ गहरा integration एक सीमा है, और लंबे समय से यह मान्यता रही है कि Org को Emacs के बाहर भी आना चाहिए
  • Markdown को विकल्प के रूप में सुझाना अच्छा लगेगा, लेकिन Markdown में metadata शामिल करने की क्षमता कमज़ोर है
    • Org Mode का Properties concept दस्तावेज़ को Emacs Lisp के ज़रिए programmatically manipulate करने योग्य बनाता है, और अब LLM उस दस्तावेज़ के लिए विशेष custom features को file variables section में Emacs Lisp के रूप में लिख सकता है
    • Markdown में Org Mode के header arguments जैसी सुविधा नहीं है, जिससे code blocks की execution details (कहाँ चलाना है, remote machine आदि) तय की जा सकें
  • उत्साह पैदा करने वाली चीज़ Emacs का विशेष implementation नहीं, बल्कि विचार स्वयं है

मुख्य प्रश्न

  • "क्या एजेंटों के माध्यम से ऐसा बड़ा codebase रखना व्यावहारिक हो सकता है जिसे narrative की तरह पढ़ा जा सके, और जहाँ कोड बदलाव और विवरण का synchronization एक न थकने वाली मशीन बनाए रखे?"

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.