4 पॉइंट द्वारा GN⁺ 2026-01-17 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • इस चेतावनी के साथ कि "AI मानव technical writers की जगह ले सकता है" इस विश्वास में भर्ती रोकना या लोगों को निकालना एक गंभीर गलती है
  • AI द्वारा तैयार किया गया documentation न तो बुद्धिमत्ता रखता है, न सहानुभूति, और यह product truth और context को समेट न पाने वाला एक खाली खोल भर है
  • technical writer user empathy, information gathering, और clear communication के जरिए product को समझने योग्य बनाने वाले मुख्य लोग हैं
  • AI-assisted tools और policies को जोड़ने वाला ‘augmented technical writing’ productivity बढ़ाने का एक व्यावहारिक विकल्प है
  • AI शोर बनाता है, लेकिन इंसान signal बनाते हैं - technical writers की वापसी और पुनर्नियुक्ति की अपील

technical writers की जगह AI पर निर्भरता की समस्या

  • AI की वजह से technical writers (Technical Writer) को निकालने या भर्ती न करने का फैसला बड़ी गलती है
    • केवल AI-लिखित documentation पर निर्भर रहने से expert oversight और context understanding से रहित नतीजे मिलते हैं
    • documentation का बोझ developers पर डालना documentation की असली प्रकृति को गलत समझना है
  • technical documentation सिर्फ एक output नहीं, बल्कि product truth को समेटने वाला एक मुख्य घटक है
    • software कभी पूरी तरह complete, self-evident, या simple नहीं होता, इसलिए documentation के बिना वह उपयोग योग्य नहीं होता
    • technical writers information gathering, clear expression, और user-centered narration के जरिए product को लोगों से जोड़ते हैं

AI-generated documentation की सीमाएँ

  • AI द्वारा तैयार documentation में बुद्धिमत्ता नहीं होती और उसमें vision की कमी होती है
    • करोड़ों tokens पर training के बाद भी यह documentation strategy बनाना, structure करना, और reuse के लिए design करना नहीं कर सकता
    • यह exception cases, subtle boundaries, और अधूरेपन के तनाव को पकड़ नहीं पाता, इसलिए सामग्री खोखली रहती है
  • कानूनी जिम्मेदारी AI पर नहीं, इंसानों पर ही रहती है
    • गलत निर्देशों से नुकसान होने पर जिम्मेदारी managers या company पर ही आती है
    • AI model को न तो निकाला जा सकता है, न अदालत में खड़ा किया जा सकता है, इसलिए जिम्मेदारी से बचना संभव नहीं
  • AI को documentation बनाने के लिए पहले से मौजूद high-quality context चाहिए
    • RAG, Cursor rules, Claude Skills जैसी चीजें सभी technical writing की निरंतरता हैं
    • writers को निकाल देने पर वह आधारभूत data ही खत्म हो जाता है जिससे AI सीखता है

technical writers और AI के सहयोग की संभावना

  • AI tools और training उपलब्ध कराई जाए तो technical writers की productivity काफी बढ़ सकती है
    • AI policies के जरिए quality को सुरक्षित रखते हुए AI के साथ सहयोग करने वाला future-ready documentation environment बनाया जा सकता है
    • पहले से ही कुछ technical writers AI का उपयोग करके writing, editing, और publishing को automate कर रहे हैं
  • AWS CEO Matt Garman ने भी इंसानों को replace करने के बजाय assist करने वाली productivity improvement को स्वीकार किया है
  • companies को technical writers के साथ मिलकर AI strategy बनाने और experiment करने के लिए समय और resources देने चाहिए
    • technical writers के पास पहले से सीमित resources में efficiency अधिकतम करने की क्षमता होती है
    • सही tools और अवसर दिए जाएँ तो वे AI का उपयोग documentation quality बेहतर करने में कर सकते हैं

पुनर्नियुक्ति और सोच में बदलाव की अपील

  • यह गलत धारणा छोड़नी होगी कि AI ने इंसानी भूमिका को पूरी तरह replace कर दिया है
    • technical writing सिर्फ शब्दों का जोड़ नहीं, बल्कि expert interviews, product understanding, और context interpretation का काम है
  • technical writers कोई विलासिता नहीं, बल्कि जरूरी लोग हैं, जो product को वास्तव में उपयोग योग्य बनाने वाले अनुवादक की भूमिका निभाते हैं
    • उनके बिना product खुद को समझा नहीं पाता या गलत जानकारी देता है
  • अंत में यह निष्कर्ष दिया गया है कि AI अनंत शोर बना सकता है, लेकिन इंसान अर्थपूर्ण signal बनाते हैं
    • निकाले गए Technical Writer को वापस बुलाने और साथ काम करने की अपील की गई है

2 टिप्पणियां

 
coremaker 2026-01-19

मुद्दा AI बनाम इंसान का नहीं है,

बल्कि यह है कि क्या कोई "यूज़र के प्रति सहानुभूति, जानकारी जुटाना, और स्पष्ट तरीके से संप्रेषित" कर सकता है या नहीं।

 
GN⁺ 2026-01-17
Hacker News की राय
  • मैं पेशेवर रूप से डॉक्यूमेंटेशन लिखने का काम करता/करती हूँ
    लेकिन मेरा असली काम देखना, सुनना और समझना है
    अच्छा लिखने के लिए पाठक की बेचैनी और उलझन को गहराई से समझना पड़ता है
    जब भी मैं किसी विदेशी public transport system का अनुभव करता/करती हूँ, स्थानीय transit guide को सुधार देता/देती हूँ
    पाठक की जगह खुद उलझन महसूस करके मैं लेखन को बेहतर बनाता/बनाती हूँ
    सहानुभूति ही मेरे काम को चलाने वाला इंजन है
    मैंने वर्षों तक लोगों के साथ भरोसेमंद रिश्ते बनाकर जानकारी जुटाने की infrastructure खड़ी की है
    AI सिर्फ वही संभालता है जो पहले से दर्ज है, लेकिन मैं खुद दुनिया में जाकर सवाल पूछता/पूछती हूँ
    मैंने immigration office के अनुभव इकट्ठा करने का एक tool बनाया और वकीलों व विशेषज्ञों के सैकड़ों इंटरव्यू किए
    AI डेटा पर निर्भर है, लेकिन मैं अपना डेटा खुद ढूँढकर लाता/लाती हूँ
    यह मानना कि AI इस काम की जगह ले सकता है, इस पेशे के बारे में अपमानजनक गलतफ़हमी है

    • आजकल कई industries में monopoly इतनी बढ़ गई है कि quality मायने ही नहीं रखती
      public transport documentation बुरी हो जाए तो revenue तुरंत कम नहीं होता
      लेकिन technical writer को निकालते ही budget तुरंत घट जाता है
      software में भी यही बात है — entry barrier इतने ऊँचे हैं कि “यह खराब है, मैं इससे बेहतर बना लूँगा/लूँगी” कहना मुश्किल हो गया है
    • coding भी बिल्कुल ऐसी ही है
      code वह documentation है जिसे computer पढ़ता है
      computer के पास common sense नहीं होता, इसलिए सारी समझ programmer पर निर्भर करती है
      सिर्फ इसलिए कि LLM व्याकरण के हिसाब से सही वाक्य बना देता है, इसका मतलब यह नहीं कि वह अच्छी documentation लिखता है
      उसी तरह, सिर्फ इसलिए कि वह compile होने वाला code बना दे, इसका मतलब यह नहीं कि वह उपयोगकर्ता की ज़रूरत का program बना रहा है
    • मैं इस बात से पूरी तरह सहमत हूँ
      मैं यही बात “तकनीक में आत्मा होनी चाहिए” कहकर व्यक्त करता/करती हूँ
      technical documentation, UI, product — सबमें मानवीय संवेदना घुली होनी चाहिए, तभी उनकी कीमत बनती है
    • आपकी लिखावट स्पष्ट अभिव्यक्ति का वह स्तर दिखाती है जिसकी नकल AI करना चाहता है लेकिन कभी पहुँच नहीं सकता
      AI का इंसानों को replace करने का सपना अपमानजनक है
      हम हर चीज़ रिकॉर्ड नहीं करते — जो बातें सबसे ज़्यादा obvious होती हैं, वही अक्सर लिखी नहीं जातीं, लेकिन AI को वही डेटा चाहिए होता है
    • इतनी अच्छी तरह लिखे गए लेख के लिए धन्यवाद। बात का सार यही है
  • मैं उस कंपनी में काम नहीं करता/करती जिसने technical writers को निकाला, लेकिन हमारी कंपनी ने भी वही देखा है
    writers जब AI पर निर्भर हो गए तो नतीजा भयानक था, और वे खुद से लगभग कुछ लिख ही नहीं पा रहे थे
    बाज़ार में अच्छे technical writer ढूँढना मुश्किल है, और अच्छा portfolio होने पर भी कई लोग असल में बेहद खराब निकलते हैं
    आखिरकार documentation developers पर डाल दी जाती है — लेकिन developers इसे अपने career का हिस्सा बनाना नहीं चाहते
    किसी ऐसे writer को निकाल देना जो आधा-अधूरा ही सही पर ठीक-ठाक काम करता हो, business को नुकसान पहुँचाने जैसा है
    AI README या config जैसे स्थिर pattern वाले data पर अच्छा काम करता है, लेकिन product documentation जैसे unique content पर कमजोर पड़ता है

  • कुछ तरह की documentation AI अच्छी बना लेता है — वह जिसे कोई पढ़ता नहीं, सिर्फ compliance के लिए होती है
    ऐसे दस्तावेज़ CPU जैसे बुनियादी terms तो define करते हैं, लेकिन असल में ज़रूरी domain terms छोड़ देते हैं
    इनमें ऐसे references भरे होते हैं जिन तक पहुँचा नहीं जा सकता, code से मेल न खाने वाले UML, पुराने signatures, और बेतरतीब screenshots
    format भी पूरी तरह असंगत होता है, इसलिए ऐसी documentation उदास QA manager के अलावा कोई नहीं पढ़ता

    • मैंने LLM से README generate कराया था, और वह देखने में अच्छा व पढ़ने में आसान था
      लेकिन अगर आप बहुत सारे ठोस examples दें तो AI ज़्यादा अच्छी मदद करता है
    • फिर भी ऐसी documentation को दूसरे LLM ही पढ़ेंगे /s
  • सबसे अच्छे technical writer सिर्फ product की documentation नहीं करते
    वे असली user की तरह व्यवहार करके usability issues खोज लेते हैं
    उनमें engineers के साथ 1:1 interview करके ज़रूरी जानकारी निकलवाने की क्षमता होती है
    AI यह भूमिका अच्छी तरह नहीं निभा पाता

    • इस तरह का feedback पूरी team की भागीदारी से आना चाहिए
      internal तौर पर भी पहली बार देखे जा रहे content पर first-impression feedback बहुत महत्वपूर्ण होता है
      लेकिन कई organizations departments के बीच feedback culture को रोक देती हैं
      नतीजतन, marketing के लिए बनाई गई technical content अक्सर धुंधली और अर्थहीन हो जाती है
    • AI top-tier writers को replace करना मुश्किल पाएगा, लेकिन औसत से कम writers से बेहतर हो सकता है
      क्योंकि कई projects में documentation या तो होती ही नहीं या बहुत खराब होती है
    • बेहतरीन technical writer चुपचाप usability radar की तरह काम करते हैं
      वे जटिल workflows में समस्या सबसे पहले पहचान लेते हैं
    • बेशक, अगर technical writer यह समस्याएँ पकड़ रहा है, तो सवाल उठता है कि PM क्या कर रहा था
    • technical writer की भूमिका कई बार QA या PM से overlap भी करती है
      अक्सर उनमें Python जैसी language संभालने लायक technical समझ भी होती है
  • AI technical writers की जगह ले तो सकता है, लेकिन यह अच्छा विकल्प नहीं है
    जिन कंपनियों की documentation सबसे अच्छी होगी, वे अब भी human writers रखेंगी
    बहुत से लोग यह गलतफ़हमी पालते हैं कि “हर कोई लिख सकता है,” जबकि हक़ीक़त में ऐसा नहीं है
    (संबंधित लेख: Nobody Can Write)
    technical writers UX और testing में भी योगदान देते हैं, और API naming conventions की असंगति भी सबसे पहले वही पकड़ते हैं
    AI सहायक tool के रूप में तो काम का है, लेकिन बिना editing के उसे ज्यों का त्यों जारी करना ख़तरनाक है

    • जिन बाज़ारों में quality मायने नहीं रखती, वहाँ AI replacement और तेज़ी से होगा
      संबंधित चर्चा के लिए यह टिप्पणी देखें
    • “अच्छी documentation? माफ़ कीजिए, मैं सिर्फ ‘थोड़ी-बहुत काम की’ चीज़ ही दे सकता हूँ” वाला meme याद आता है
    • फिर भी अगर वह पूरी तरह कोई documentation न होने से बेहतर है, तो AI की भूमिका अर्थपूर्ण है
  • सबसे अच्छे technical writer मानवविज्ञानी की तरह product team, engineers और users के बीच पुल बनाते हैं
    इसी नज़रिए की वजह से product खुद बेहतर होता है

    • मैं भी FAANG में काम करता/करती हूँ, और इन दिनों technical writers निकाले जा रहे हैं
      documentation developers पर धकेल दी जाती है, और बस इतना कहा जाता है कि “AI से कर लो”
      क्या यही वह वादों वाला भविष्य है, इस पर संदेह होता है
    • AI पहले से मौजूद insights को synthesis करने में मदद कर सकता है,
      लेकिन लोगों के बीच मौजूद सांस्कृतिक दूरी को महसूस करने की संवेदना उसमें नहीं है
  • मैं 2026 में अपनी writing और communication skills को और बेहतर बनाना चाहता/चाहती हूँ
    ऐसी skills को आसानी से replace नहीं किया जा सकता
    इन्हें खुद सीखने से सोचने का तरीका बदलता है, और जीवन के दूसरे हिस्सों में भी मदद मिलती है
    इंसानी skill upgrade का गायब हो जाना ही असली नुकसान है

    • सही बात, खुद सीखो तो पढ़ना भी कम उबाऊ लगता है
      LLM की एकरस writing style से जल्दी ऊब हो जाती है
      लंबी अवधि में देखें तो speed gains शायद skill loss की भरपाई न कर पाएँ
  • शुरू में title देखकर मैं उलझ गया/गई था/थी
    मुझे लगा यह “AI इस्तेमाल करते पकड़े जाने पर निकाले गए writer के नाम पत्र” है
    पूरा लेख भाषा के स्तर पर इतना अस्पष्ट लगा कि उल्टा human writer पर भरोसा कम हो गया
    मैंने भी English literature और CS में पढ़ाई की है, PhD students को writing सिखाई है,
    और अब कंपनी की documentation खुद संभालता/संभालती हूँ

    • लेकिन इन दिनों AI replacement पर इतने लेख आ रहे हैं कि,
      दूसरी व्याख्या (“AI से replace किए गए writer को”) ज़्यादा स्वाभाविक लगती है
  • insurance companies को देखकर सीखने लायक बात है
    वे AI से वैध claims ठुकराने के कारण खोजती हैं
    और अदालत में “software bug” कहकर ज़िम्मेदारी से बच निकलती हैं
    उम्मीद है कि यह बहाना standard न बन जाए

  • क्या हमें यह मानकर चलना चाहिए कि LLM आगे भी बेहतर होते रहेंगे?
    बहुत से लेख मान लेते हैं कि आज की सीमाएँ हमेशा बनी रहेंगी
    प्रगति की संभावना को नज़रअंदाज़ करना मुझे दूरदर्शिता की कमी जैसा लगता है

    • “कौन सुधार की उम्मीद करता है” यह सवाल ज़्यादा अहम है
      उम्मीद का स्तर हर व्यक्ति में अलग होता है
    • LLM असल में product इस्तेमाल करके यह समझ ही नहीं पाता कि उसकी व्याख्या गलत है