ऑटोमैटिक प्रोग्रामिंग

• AI सहायता का उपयोग करके सॉफ्टवेयर लिखने की प्रक्रिया को antirez ने ‘Automatic Programming’ के रूप में परिभाषित किया है, और उनका अनुमान है कि यह जल्द ही सॉफ्टवेयर लिखने का मानक बन जाएगा
• एक ही LLM का उपयोग करने पर भी मानवीय अंतर्ज्ञान, डिज़ाइन और लगातार दिशा-संशोधन के आधार पर परिणाम बहुत अलग हो सकते हैं
• Vibe coding वह तरीका है जिसमें बिना गहरी समझ के काम AI पर छोड़ दिया जाता है, जबकि ऑटोमैटिक प्रोग्रामिंग डेवलपर की स्पष्ट vision और control को आधार मानती है
• AI द्वारा जनरेट किया गया कोड भी मनुष्यों द्वारा संचित pretraining data और निर्णय पर आधारित होता है, और उसके परिणाम का स्वामित्व डेवलपर के पास होता है
• प्रोग्रामिंग लगातार अधिक automated होती जा रही है, लेकिन ideas और vision अभी भी मनुष्यों का क्षेत्र बने हुए हैं

---

Automatic Programming की अवधारणा की परिभाषा

• AI सहायता के साथ सॉफ्टवेयर लिखने की प्रक्रिया को ऑटोमैटिक प्रोग्रामिंग (Automatic Programming) नाम दिया गया है
• यह तरीका जल्द ही सॉफ्टवेयर लिखने की standard process बन जाएगा

Vibe coding से अंतर

• Vibe coding वह तरीका है जिसमें प्रक्रिया में लगभग बिल्कुल भाग लिए बिना AI से सॉफ्टवेयर बनवाया जाता है
  • यदि आप अपनी इच्छा को बहुत सामान्य शब्दों में समझाते हैं, तो LLM अपने training data और उस execution के विशेष sampling के आधार पर स्वाभाविक रूप से उभरने वाला पहला idea/design/code बना देता है
  • Vibe coder ज़्यादा से ज़्यादा यह बता पाता है कि क्या काम नहीं कर रहा या क्या उम्मीद से अलग है
• ऑटोमैटिक प्रोग्रामिंग उच्च गुणवत्ता का लक्ष्य रखती है और निर्माता की software vision का कड़ाई से पालन करती है
  • यह vision बहु-स्तरीय होती है: किसी खास काम को ठीक-ठीक कैसे करना है, से लेकर किसी विशेष function को कैसे लिखना है, यह AI को सीधे निर्देश देने तक
  • क्या करना है यह भी एक मुख्य तत्व है

मानवीय तत्व का महत्व

• एक ही LLM होने पर भी, प्रक्रिया का नेतृत्व करने वाले व्यक्ति का अंतर्ज्ञान, डिज़ाइन, लगातार दिशा-संशोधन और सॉफ्टवेयर के बारे में विचार परिणाम को बहुत बदल देता है
• "Claude ने इस सॉफ्टवेयर को vibe coding से बना दिया" जैसी अभिव्यक्ति उचित नहीं है
• यदि आप यह समझते हुए कि क्या हो रहा है, वास्तव में सॉफ्टवेयर बना रहे हैं, तो वह आपके द्वारा बनाया जा रहा सॉफ्टवेयर है

कोड स्वामित्व पर दृष्टिकोण

• pretraining data, भले ही LLM केवल उसी से नहीं सीखता हो (RL की भी बड़ी भूमिका है), फिर भी मनुष्यों द्वारा निर्मित है
  • इसलिए यह किसी और चीज़ का appropriation नहीं है
• AI-जनित कोड को "हमारा" कहा जा सकता है, और ऐसा कहने का अधिकार भी है
• pretraining एक सामूहिक उपहार है, जो अनेक व्यक्तियों को वे काम करने देता है जो वे अकेले कभी नहीं कर सकते थे
  • यह कुछ हद तक किसी तरह सामूहिक चेतना से जुड़े होने जैसा है
• ऑटोमैटिक प्रोग्रामिंग से जनरेट किया गया कोड आपका कोड, आपका output, आपका product है, और इस पर गर्व किया जा सकता है

Redis का उदाहरण

• Redis में तकनीकी रूप से चकित कर देने वाली बहुत-सी चीज़ें नहीं हैं
  • शुरुआती चरण में यह बस मूल डेटा संरचनाओं और networking code का एक संयोजन था, जिसे कोई भी सक्षम systems programmer लिख सकता था
• फिर भी यह बेहद उपयोगी सॉफ्टवेयर बना, क्योंकि इसके भीतर idea और vision निहित थे

निष्कर्ष

• प्रोग्रामिंग अब automated हो चुकी है, लेकिन vision अभी automated नहीं हुआ है

[GN⁺]

Hacker News की राय

• इंडस्ट्री में 30+ साल के करियर के बाद, हाल में मैं spec-driven development में गहराई से डूबा हुआ हूँ
  Claude Code और GPT-5.2(CoPilot) का उपयोग करके requirements बनाता हूँ, और कई बार self-review दोहराते हुए spec को निखारता हूँ
  तैयार spec से Claude Code implementation plan और code लिख देता है, और 20 मिनट के भीतर मुख्य features तैयार हो जाते हैं
  इससे पुराने defense industry दौर का waterfall model याद आता है, लेकिन AI की वजह से अब कहीं तेज़ और अधिक refined “augmented cascade” approach संभव लगती है

  • waterfall के ठीक से काम करने के लिए long-term perspective चाहिए और spec लिखने वाला और developer एक ही होना चाहिए
    agile उन कंपनियों की survival strategy थी जहाँ ये शर्तें संभव नहीं थीं और उन्हें जल्दी product ship करना पड़ता था
  • मुझे भी लगता है कि programming का भविष्य spec-centric होगा
    क्या देखने लायक कोई public spec examples हैं? जैसे पिछली पीढ़ी John Carmack के Quake code का सम्मान करती थी, वैसे अगली पीढ़ी शायद बेहतरीन specs की प्रशंसा करेगी
  • spec कितना भी सूक्ष्म क्यों न हो, वास्तविकता से टकराव से बचना मुश्किल है
    इंसान हर complexity और exception case पहले से नहीं देख सकता। असल में बनाते समय हमेशा कुछ न कुछ “ये तो सोचा ही नहीं था” निकलता है
  • agile बदलती requirements वाले environment में धीरे-धीरे सही दिशा खोजने का तरीका है
    अगर requirements पहले से स्पष्ट हैं, तो इसकी खास ज़रूरत नहीं
  • यह approach आखिरकार Design by Contract concept का आधुनिक रूपांतरण लगती है
    फर्क बस इतना है कि sub-team की जगह LLM का उपयोग हो रहा है
    संबंधित संदर्भ: Design by Contract (Goodreads), मूल PDF

• “pre-training मानवता का collective gift है” इस अभिव्यक्ति से सहमत नहीं हूँ
  अगर वह चोरी की गई चीज़ है, तो वह gift नहीं है
  LLM द्वारा बनाया गया code भी अगर मैं ज़िम्मेदारी लेकर maintain करता हूँ, तो मैं उसे अपना code मानता हूँ
  समस्या तब होती है जब लेखक ज़िम्मेदारी से बचता है

  • “चोरी किया हुआ gift” जैसी अभिव्यक्ति पर instinctive rejection महसूस हुआ
  • ज्ञान चोरी नहीं किया जा सकता। जैसे हम यह नहीं कहते कि किसी ने mathematics चुरा ली, वैसे ही ज्ञान का साझा होना ही मानव प्रगति का मूल है

• Claude Code और Opus 4.5 का उपयोग करते हुए मैं भी इसी तरह के निष्कर्ष पर पहुँचा हूँ
  मैं इसे “zen coding” कहता हूँ। codebase को एक Zen garden की तरह संभालते हुए, spec को बारीकी से design करता हूँ और हर line review करता हूँ
  AI को designer नहीं बल्कि tool की तरह काम करना चाहिए
  जिन लोगों के पास स्पष्ट spec होती है, वे AI से कहीं बेहतर quality का code निकलवा सकते हैं
  Vibe coding सहज प्रयोग है, और Zen coding कारीगर की साधना

• जब “Claude ने दिया” जैसी अभिव्यक्ति सुनता हूँ, तो लगता है कि वह अभी भी draft-जैसा code होगा
  tool को दोष देने या माफ़ी माँगने के बजाय, output को बेहतर बनाना चाहिए

  • समस्या यह है कि अब architecture या code quality की ज़्यादा चिंता किए बिना भी काफ़ी दूर तक पहुँचना संभव हो गया है
  • इसलिए उल्टा expectations बढ़ानी चाहिए, और automation से vibe-coded apps की quality ऊपर ले जानी चाहिए

• “pre-training मानवता का gift है” यह अभिव्यक्ति असहज लगती है
  बहुत से open source developers नहीं चाहते थे कि उनका code LLM training में इस्तेमाल हो
  LLM द्वारा generated code में कुछ हिस्से मैंने किताबों या ब्लॉग के code से लगभग जस के तस उठाए हुए भी देखे हैं
  कम से कम स्रोत बताना नैतिक रूप से सही लगता है

  • हर development अपने पूर्वजों के कंधों पर खड़ा होता है। पूरी तरह independent creation जैसी कोई चीज़ नहीं
  • open source license और public domain कानूनी रूप से अलग हैं
    अगर GPL code से LLM को train किया गया है, तो यह व्याख्या संभव है कि उसके outputs भी GPL के तहत जारी होने चाहिए
  • रचनाकार की इच्छा के खिलाफ भी इतिहास में कई बार कृतियों का उपयोग हुआ है
    उदाहरण के लिए Kafka ने अपने manuscripts जला देने को कहा था, लेकिन आज वे साहित्य के classics हैं
  • यह पलटकर पूछा भी जाता है: “जब Quicksort implement करते हो, तो क्या Hoare को credit देते हो?”
  • intellectual property भी पूर्णतः absolute नहीं है, और ज़रूरत पड़ने पर समाज द्वारा expropriation स्वीकार किया जा सकता है

• 1950~60 के दशक का “automatic programming” वास्तव में compiler को ही कहा जाता था
  1980s के 4GL domain-specific high-level languages थे, और आज के LLM अभी natural language specs से draft generate करने के चरण में हैं
  आखिरकार इंसानों को अब भी iterative revision और design changes के ज़रिए completeness बढ़ानी पड़ती है

• हो सकता है कि हम अभी artisanal coder की आख़िरी पीढ़ी देख रहे हों
  Antirez जैसे कारीगर इंसानी सीमाओं से आगे के concepts से जूझते हैं, और Redis जैसा सरल लेकिन सुंदर software बनाते हैं
  AI इंसान की क्षमता से कहीं तेज़ code बना सकता है, लेकिन वह brush और canvas नहीं है
  नई पीढ़ी बिल्कुल अलग तरह के कारीगर बनेगी
  मुझे भी डर लगता है, लेकिन मैं इन नए tools को अपनाते हुए नई craftsmanship के युग का प्रयोग कर रहा हूँ

  • chess में भी इंसान computer को हरा नहीं सकता, फिर भी वह अब भी लोकप्रिय है
  • Antirez अब AI influencer के ज़्यादा करीब हैं, लेकिन coding फिर भी एक आनंददायक काम है
  • भले ही LLM code में मदद करे, मूल concepts और structure की समझ अब भी ज़रूरी है
    AI को अच्छी तरह इस्तेमाल करने की क्षमता बस एक अतिरिक्त skill है; पुराना ज्ञान बेकार नहीं हो जाता

• Antirez के लेख में “vibe coding और automatic programming के अंतर” को साफ़ तौर पर अलग किया गया, यह प्रभावशाली लगा
  यह वैसे ही बदलाव जैसा है जैसे architects के हाथ से drawing बनाने के युग से BIM, CAD की ओर जाना
  AI युग के developers कम coding नहीं कर रहे, बल्कि value का focus बदल गया है

• “vibe coding vs automatic coding” द्वैत नहीं बल्कि एक spectrum है
  एक ही project के भीतर approach के कई स्तर मिलाकर इस्तेमाल किए जा सकते हैं

  • LLM का output user के technical level और intent पर निर्भर करता है, इसलिए नतीजा आखिरकार user का ही माना जाना चाहिए
    अहम बात है tool का critical use करना और लगातार सुधार करते रहना
  • AI एक संगीत वाद्य की तरह है जिसे कई तरह से बजाया जा सकता है
    कुछ लोग इसे “spec strumming” कहते हैं