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

 (silly.business)
14 पॉइंट द्वारा GN⁺ 2026-03-11 | 2 टिप्पणियां | 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 एक न थकने वाली मशीन बनाए रखे?"

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

2 टिप्पणियां

 
GN⁺ 2026-03-11
Hacker News की राय

  • मुझे लगता है कि सबसे आसान तरीका यह है कि LLM अपनी टिप्पणियाँ खुद छोड़े
    ऐसा करने पर जब LLM बाद में कोड दोबारा पढ़ेगा, तो वह अपनी ही टिप्पणियों का सहारा ले सकेगा, और वे एक तरह की just-in-time memory की तरह काम करेंगी
    <summary> में सारांश, <remarks> में कारण और संदर्भ, और <params> में सीमाएँ लिखवाई जाएँ, जबकि inline comments को न्यूनतम रखा जाए
    इससे PR review के समय LLM की सोचने की प्रक्रिया को सीधे <remarks> में देखा जा सकता है, इसलिए जहाँ उसने इरादे से अलग समझा हो उसे आसानी से पकड़ा जा सकता है

    • मेरे अनुभव में LLM द्वारा जोड़ी गई टिप्पणियाँ बहुत ज़्यादा लंबी और बचकानी होती हैं
      अंत में वे उसके अपने context को बेकार की जानकारी से प्रदूषित कर देती हैं, जिससे समझने की क्षमता और गिरती है
      अभी यह इंसानी स्तर की literacy से काफ़ी दूर है
    • इंसानों को LLM की टिप्पणियाँ अक्सर शोर और अनावश्यक जानकारी जैसी लगती हैं
      लेकिन जब LLM वही कोड दोबारा पढ़ता है, तो अक्सर वही चीज़ें उसके लिए अटकने वाले बिंदु होती हैं, इसलिए यह उल्टा क़ीमती जानकारी भी हो सकती है
    • इंसान को याद रहता है कि कोड क्यों लिखा गया था, लेकिन LLM का context window सीमित होता है, इसलिए ऐसी जानकारी जल्दी गायब हो जाती है
      इसलिए ऐसी टिप्पणियाँ उस स्मृति को सुरक्षित रखने का काम करती हैं
    • यह देखकर लगता है कि एजेंट द्वारा लिखी गई टिप्पणियों पर हस्ताक्षर होने चाहिए ताकि उन्हें अलग पहचाना जा सके

  • मुझे लगता है कि programming languages इसलिए बनीं क्योंकि natural language में अस्पष्टता होती है
    इसलिए code comments भी अंततः अस्पष्ट हो जाते हैं, और क्योंकि वे execute नहीं होते, वे जल्दी पुराने पड़ जाते हैं
    LLM कोड अनुवाद में मज़बूत है, लेकिन natural language prompts को कोड में बदलना अभी भी मुश्किल लगता है
    अच्छा कोड इरादे को स्पष्ट रूप से व्यक्त करना चाहिए, और बहुत ज़्यादा comments इस बात का संकेत भी हो सकते हैं कि कोड की गुणवत्ता कमज़ोर है

    • अगर सिर्फ अच्छा कोड ही काफ़ी होता, तो दस्तावेज़ पढ़ने के बजाय सिर्फ source code देखना पर्याप्त होता
      लेकिन अच्छा software अच्छे documentation को भी शामिल करता है
      literate programming implementation details से ज़्यादा explanation-केंद्रित लेखन है
    • जैसे legal writing style बनने का कारण था, वैसे ही prompts जितने अधिक विशिष्ट हों उतने प्रभावी होते हैं
      कोड में ‘कैसे’ को संकीर्ण रूप से परिभाषित किया जाता है, लेकिन natural language ‘क्या’ पर केंद्रित होकर बात कर सकती है, जिससे LLM को बेहतर तरीक़े सुझाने की गुंजाइश मिलती है
    • कोड और दस्तावेज़ परस्पर error-correcting code की तरह साथ काम करने चाहिए
      त्रुटियों को पहचानने और सुधारने के लिए जानकारी में कुछ redundancy होनी चाहिए
    • programming languages भी पूरी तरह स्पष्ट नहीं होतीं
      वे बस व्याख्या की आज़ादी को सीमित करने वाले नियम बनाती हैं
      कभी-कभी रूपक या अस्पष्टता ही ज़्यादा उपयुक्त अभिव्यक्ति होती है
    • मैं LLM से literate programming नहीं करवाता, लेकिन उससे trade-offs समझाने को कहता हूँ
      अगर example code और documentation को template की तरह दे दिया जाए, तो hallucination कम हो जाती है

  • इस पर शोध है कि literate programming शैली की टिप्पणियाँ इंसानों को कोड समझने में मदद करती हैं
    Google के शोधकर्ताओं ने यह परखा कि क्या LLM ऐसी टिप्पणियों को अपडेट कर सकता है, और क्या उससे इंसानी समझ बेहतर होती है
    निष्कर्ष यह था कि इरादे को समझाने वाली block-level comments सबसे प्रभावी हैं
    (संदर्भ: 2024 arXiv paper "Natural Language Outlines for Code")

  • हाल की एक दिलचस्प बात यह है कि पहले लोग इंसानों के लिए README या architecture documents लिखने में आलस करते थे
    लेकिन अब अगर कहा जाए कि यह LLM के लिए है, तो लोग कहीं ज़्यादा उत्साह से करते हैं

    • इंसान दस्तावेज़ लगभग पढ़ते ही नहीं, और ज़रूरत पड़ने पर ही सवाल पूछते हैं
      लेकिन LLM हर काम में दस्तावेज़ों को देखता है, इसलिए documentation की motivation कहीं ज़्यादा मज़बूत हो जाती है
    • पहले जिन आदतों को ‘engineering hygiene’ कहकर नज़रअंदाज़ कर दिया जाता था, वे अब एजेंटों को बड़ा फ़ायदा देती हैं
      commit messages, ADR जैसे रिकॉर्ड इंसान भले न पढ़ें, LLM सब पढ़ता है
      आख़िरकार ये आदतें नए मानव साथियों की onboarding में भी मदद करती हैं
    • मैंने पहले एक बात सुनी थी
      जो लोग कंप्यूटर से बात करना सीखते-सीखते इंसानों से बात करना भूल गए, वे graduation के बाद और पीछे रह गए
    • दस्तावेज़ कोड की तुलना में ज़्यादा तेज़ी से सड़ते हैं
      क्योंकि कोड के चलने के लिए दस्तावेज़ की शुद्धता ज़रूरी नहीं होती
      इसलिए कई बार दस्तावेज़ से बेहतर सीधे कोड को देखना लगता है
    • शायद यह आदत manager के नज़रिए से शुरू से ही ज़्यादा स्वाभाविक रही होगी

  • मेरी नज़र में हल्का-फुल्का literate programming और convention-driven languages का मेल एजेंट युग के लिए अच्छा है
    Go जैसी भाषाएँ, जिनमें तेज़ compilation और स्पष्ट style guides हों, बेहतर लगती हैं
    अगर एजेंट से कोड लिखवाते समय उसे Google Go Style Guide देखने को कहा जाए, तो काफ़ी अच्छे नतीजे मिलते हैं

    • Go एक ऐसी भाषा है जिसमें style guide और patterns काफ़ी मज़बूत हैं, इसलिए यह LLM के लिए अच्छी बैठती है
      (संदर्भ: Rob Pike से जुड़ा एक प्रसंग)

  • LLM एक language model है, इसलिए स्पष्ट लेखन में निवेश करना बहुत फ़ायदेमंद है
    भले पूरी तरह literate programming न हो, फिर भी अच्छे names, docstring, type signatures, और “क्यों” समझाने वाली टिप्पणियाँ महत्वपूर्ण हैं
    आख़िरकार असली बात यह है कि इंसानों और LLM दोनों के लिए communication patterns बनाए जाएँ

    • ज़रूरत docstring और literate programming के बीच के किसी मध्य बिंदु की है
      file·directory·project स्तर की ऊपरी संरचना समझाने वाले दस्तावेज़ ख़ास तौर पर महत्वपूर्ण हैं
      लेकिन ऐसी अवधारणाएँ कई files में फैली होती हैं, इसलिए कहाँ लिखें और document-code synchronization कैसे रखें, यह हमेशा समस्या रहती है
    • मुझे लगता है कि Notebook खुद literate programming का एक रूप है

  • पिछले 10 साल में मैंने लगभग सारा कोड literate programming तरीके से लिखा है
    मैंने nbdev बनाया ताकि notebook-आधारित तरीके से कोड, दस्तावेज़ और tests को साथ संभाला जा सके
    हाल में मैंने LLM-इंटीग्रेटेड Solveit नाम का एक टूल बनाया है, जिसे पूरी कंपनी में इस्तेमाल किया जा रहा है
    (Solveit लिंक)
    literate programming प्रोग्रामिंग के बाहर के कामों में भी उपयोगी है

    • लेकिन Solveit नाम बहुत आम है, इसलिए search में ढूँढना मुश्किल है, और उसका परिचय वीडियो बहुत लंबा है
      छोटा demo या screenshots जोड़ दिए जाएँ तो अच्छा होगा

  • LLM की मदद से टिप्पणियों और कोड के बीच असंगति को अपने-आप पहचानने का विचार दिलचस्प है
    दस्तावेज़ समय के साथ निश्चित रूप से कोड से अलग हो जाते हैं, और अगर इसे अपने-आप पकड़ा जा सके तो यह बहुत क़ीमती होगा
    इस पर startup भी बनाया जा सकता है

    • 2023 के बाद से इस क्षेत्र में 10 से ज़्यादा startups आ चुके हैं (लिखने वाला एक technical writer है)
    • यह एक पुराना आइडिया है जिस पर मैंने भी सोचा था: हर directory·module·class·function पर DocString/JSDoc अनिवार्य करने वाली व्यवस्था
      बदलाव की शुरुआत document PR से हो, और फिर developer उसे कोड में लागू करे
      review के दौरान दस्तावेज़ और कोड को साथ-साथ दिखाया जाए ताकि सत्यापन हो सके
      और documents के बीच links से context navigation भी संभव हो
    • Promptless.ai जैसे मिलते-जुलते startups पहले से मौजूद हैं
    • AI को CI से जोड़कर नियमित रूप से document-code mismatch या architecture drift भी पकड़ी जा सकती है
      उदाहरण: GitHub gh-aw, Continue.dev
    • लेकिन यह सवाल भी है: “क्या बस AI से यह नहीं पूछ सकते कि कोड क्या करता है?”

  • test code और production code की जोड़ीदार संरचना accounting की double-entry bookkeeping जैसी उपयोगी है
    tests कोड के इरादे को समझाते हैं, और कोड tests के अर्थ को पूरा करता है
    review के समय अगर एक तरफ़ से बात साफ़ न हो, तो दूसरी तरफ़ देखा जा सकता है
    कमी यह है कि कोड की मात्रा बढ़ती है, लेकिन readability में सुधार उसके लायक़ है

  • मैंने भी हाल में intent-based coding पर लिखा था, और यह चर्चा उससे जुड़ती है
    (ब्लॉग लिंक)
    यह महत्वपूर्ण है कि codebase को अलग-अलग रूपों में पढ़ने लायक़ बनाया जा सके
    आगे चलकर non-programmers भी कोड के और क़रीब आएँगे, और natural language का समावेश उनकी उत्पादकता और सीखने दोनों में बहुत मदद करेगा
 
xguru 2026-03-11

Wikipedia - साहित्यिक प्रोग्रामिंग

साहित्यिक प्रोग्रामिंग (literate programming) प्रोग्रामिंग methodology का एक रूप है, जिसमें प्रोग्रामिंग करते समय कंप्यूटर द्वारा compile किए जा सकने वाले code बनाने से अधिक, इंसानों के लिए आसानी से समझ आने वाला code बनाने पर ज़ोर दिया जाता है। दूसरे शब्दों में, इसका उद्देश्य ऐसा प्रोग्रामिंग करना है जैसे किसी दस्तावेज़ को इस तरह लिखा जाए कि लोग उसे पढ़कर समझ सकें। लक्ष्य यह है कि 'प्रोग्रामिंग को इस तरह पढ़ा जा सके मानो कोई साहित्यिक कृति पढ़ी जा रही हो', इसलिए इसका नाम 'साहित्यिक प्रोग्रामिंग' रखा गया।