वाइब कोडिंग, ऑटोमेशन, और MCP

वाइब कोडिंग = AI को आउटसोर्स करना

वाइब कोडिंग मूल रूप से AI को प्रोग्राम डेवलपमेंट आउटसोर्स करने जैसा है।

अगर आउटसोर्स डेवलपमेंट के अनुभव को पीछे मुड़कर देखें, तो अच्छे क्लाइंट आम तौर पर ये काम अच्छी तरह करते हैं।

1. मेरी समस्या हल करने के लिए काम को स्पष्ट रूप से परिभाषित करना
2. उसे डेवलपर अच्छी तरह समझ सके, इसके लिए प्रभावी communication करना
3. प्रोग्राम को अच्छी तरह बनाने के लिए resources देना
4. बने हुए प्रोग्राम की जाँच करना कि क्या वह इरादे के अनुसार काम को सही तरह से संभाल रहा है
5. इस प्रक्रिया में जो खुद नहीं जानते, उसे डेवलपर से सीखना ताकि धीरे-धीरे खुद भी कर सकें

अगर इसे वाइब कोडर के नज़रिए से देखें, तो

1. PRD और user flow को define करना
2. अच्छे prompts और निर्देशों (Cursor Rules आदि) का इस्तेमाल करना
3. इरादे से भटके हिस्सों को पकड़ना और automated tests चलाना
4. इस प्रक्रिया में AI के साथ ping-pong करते हुए सीखना

तो फिर 3 क्या है? इसे प्रोग्राम के दो पहलुओं से समझा जा सकता है।

• पहला, प्रोग्राम को कहीं न कहीं चलना तो होगा। → execution और deployment environment तय करना
• दूसरा, प्रोग्राम मूल रूप से 'input को process करके output देने' वाला code का समूह है। → data और API उपलब्ध कराना

प्रोग्राम को चलना चाहिए

• डेवलपमेंट आउटसोर्सिंग में डेवलपर की ज़िम्मेदारी आम तौर पर code implementation तक होती है, और deployment व operations की ज़िम्मेदारी क्लाइंट की होती है।
  • इसके बदले डेवलपर क्लाइंट को यह गाइड देता है कि वह इस प्रोग्राम को कैसे चला सकता है।
• आउटसोर्सिंग क्लाइंट के रूप में अगर आप AI को code चलाने और deploy करने का environment बता दें, तो वह बहुत अच्छी तरह काम करता है.
  • खासकर अगर वह code web browser पर चलने वाला हो, तो और भी ज्यादा।
• पहले 'regex से Markdown दस्तावेज़ की कुछ syntax हटाने' जैसे बहुत छोटे scripts भी non-developers के लिए चलाना या deploy करना आसान नहीं था।
• अब Claude Artifacts, Gemini Canvas जैसी चीज़ों से अपना छोटा प्रोग्राम तुरंत बनाकर चलाया जा सकता है। अगर दूसरों को भी इस्तेमाल करने देना हो, तो Lovable में बनाकर deploy किया जा सकता है, और यह सब लगभग तुरंत और मुफ्त में संभव है।
• वाइब कोडिंग का मतलब यह नहीं कि ज़रूरी तौर पर कोई 'app' ही बनाना पड़े। अगर वह ऐसा प्रोग्राम है जो मेरी समस्या हल करे और दोहराए जाने वाले काम कम करे, तो वह app हो, script हो, GPTs हो या prompt — सब ठीक है।

प्रोग्राम को और उपयोगी बनाने वाले API

• लेकिन छोटे प्रोग्रामों की अपनी सीमाएँ होती हैं।
  • Markdown remover में न DB जुड़ा है, न API, न LLM।
  • इसलिए text input भी user को खुद देना पड़ता है, और output text भी user को खुद copy करके कहीं और चिपकाना पड़ता है।
• अगर user का उद्देश्य 'Notion में लिखे हुए लेख को साफ़-सुथरा करके SNS पर पोस्ट करना' हो, तो?
  • input: सिर्फ Notion page link डालना
  • processing: लाया गया लेख LLM में डालकर SNS के हिसाब से summarize करना और Markdown syntax हटाना
  • output: लेख को review करके approve करने पर उसे अपने SNS account पर अपने-आप पोस्ट कर देना
• तेज़ response time और generality छोड़ने की कीमत पर, यह उस काम में user का बहुत समय और ऊर्जा बचा सकता था। यानी किसी खास उद्देश्य के लिए यह और अधिक 'उपयोगी' हो जाता।
• आखिरकार, किसी प्रोग्राम की उपयोगिता इस बात पर निर्भर करती है कि input/processing/output के स्तर पर वह user के हाथ से होने वाला काम कितना कम करता है।
  • input को automate करना
  • processing को और जटिल बनाना
  • output को automate करना
• सामान्य प्रोग्रामों में API के ज़रिए (यानी दूसरे प्रोग्रामों से जुड़कर) input/output automation और अधिक उन्नत processing संभव होती है।
  • input: Notion की permission लेकर Notion API call करके page content लाना
  • processing: LLM API में system prompt के साथ Notion page content डालकर SNS के अनुरूप response लेना
  • output: Threads की permission लेकर SNS API call करके पोस्ट publish करना
• लेकिन इस तरह बनाना skilled developers के लिए भी हमेशा बहुत आसान नहीं होता। खासकर क्योंकि permissions और authorization का काम जटिल होता है।
• क्या इसे और आसान बनाया जा सकता है?

मुश्किल API integration की जगह लेने वाले automation tools और MCP

• Zapier, Make जैसे automation tools का उपयोग करें, तो API integration सीधे खुद नहीं करना पड़ता।
  • उदाहरण: Notion DB में नया item आए → ChatGPT चलाओ → फिर Instagram पर upload करने वाला Zap
• आम तौर पर Instagram posting API call करने के लिए एक dedicated app बनाना पड़ता है और approval भी लेना पड़ता है।
• Zapier या Make में Instagram upload के लिए app पहले से बना हुआ है, और permission लेकर data भेजने-लेने का flow भी पहले से implemented है। इसलिए permissions की जटिलता मुझे खुद नहीं संभालनी पड़ती।
• लेकिन कुछ लोगों के लिए इस तरह 'यह, फिर वह' वाला flow बनाना भी मुश्किल और झंझटभरा लग सकता है। ऐसे लोगों को LLM chatbot से ही सब कुछ करने देने वाली चीज़ें MCP/A2A जैसी हैं।
• जैसे सामान्य प्रोग्राम API के ज़रिए साधारण logic से आगे बढ़ सकते हैं, वैसे ही LLM chatbot नाम का प्रोग्राम भी MCP के ज़रिए दूसरे प्रोग्रामों से जुड़कर साधारण(?) text/image/voice output से कहीं अधिक काम कर सकता है।
  • यानी Claude में 'मेरे Notion page को खींचकर summarize करो, फिर Instagram पर पोस्ट कर दो' संभव हो जाता है।
• बेशक, इसके लिए सही MCP servers (Notion, Instagram) को MCP client (Claude) से जोड़ना होगा।
  • MCP server की सबसे बड़ी भूमिका tools के माध्यम से API को proxy की तरह call करना है; Notion के लिए आधिकारिक MCP server पहले से है, लेकिन Instagram के लिए नहीं।
  • तब Claude Instagram API को कैसे call करेगा?
• यहीं Zapier फिर सामने आता है। Zapier या Make द्वारा दिए गए MCP server के ज़रिए Instagram upload संभव हो जाता है।
• यानी LLM chatbot में (जहाँ पहले से बहुत सारे integrations मौजूद हैं) automation tools को MCP के रूप में जोड़ दिया जाए, तो वह बेहद शक्तिशाली हो जाता है।

MCP की क्षमता और सीमाएँ

• लेकिन इसे देखकर यह भी लग सकता है कि फिर MCP की ज़रूरत ही क्या है।
  • क्योंकि आज chatbot + MCP से जो ज़्यादातर काम किए जा सकते हैं, वे लगभग सभी automation tools से भी किए जा सकते हैं।
• फिर भी लेखक को लगता है कि MCP की क्षमता तीन कारणों से बहुत बड़ी है।
  1. सुविधाजनक interface (क्या ऐसा chatbot assistant जो सब कुछ खुद संभाल ले, अंतिम रूप वाला प्रोग्राम नहीं होगा?)
  2. sensitive कामों में user intervention अधिक सुविधाजनक है
  3. file system control, browser control जैसी local PC पर होने वाली चीज़ों को भी automate किया जा सकता है, और resources, prompt templates जैसी अधिक जानकारी भी दी जा सकती है
• MCP इस्तेमाल करते समय ध्यान रखने वाली बातें भी बहुत हैं।
  • MCP को जितनी अधिक चीज़ें सौंपेंगे, security पर उतना ही अधिक ध्यान देना होगा। इसलिए local की तुलना में आधिकारिक remote MCP server ज़्यादा सुरक्षित है।
  • अगर LLM को बहुत सारे MCP tools दे दिए जाएँ, तो हो सकता है कि इच्छित tool चले ही नहीं; साथ ही tool definitions सब input tokens के रूप में जाती हैं, इसलिए LLM call की लागत और समय दोनों बढ़ते हैं।
  • LLM की अपनी randomness भी commercial services में हमेशा सावधानी से संभालनी चाहिए।
• आखिरकार, चाहे अपने प्रोग्राम में API जोड़ें, automation flow design करें, या LLM chatbot में MCP लगाएँ — इन सबका मतलब एक ही है: 'मेरा काम मेरे लिए कर दो'।
• Make, MCP जैसे keywords अचानक उभर रहे हैं, इसलिए तनाव लेने की ज़रूरत नहीं है। जो तरीका आपको सुविधाजनक लगे, उसके फायदे-नुकसान समझते हुए अपने काम को संभालने वाला प्रोग्राम बना सकते हैं।

सारांश

• वाइब कोडिंग का मतलब है प्रोग्राम डेवलपमेंट आउटसोर्सिंग AI को सौंपना।
• अगर वह मेरे काम को अच्छी तरह संभाल ले, तो web app, code snippet, prompt — सब उपयोगी प्रोग्राम हो सकते हैं।
• प्रोग्राम को और उपयोगी बनाने के लिए input/output automation और उन्नत processing हेतु API connection ज़रूरी है।
• automation tools API integration की जटिलता को अपने ऊपर ले लेते हैं।
• LLM chatbot जैसा प्रोग्राम भी MCP connection से और उपयोगी बन सकता है। खासकर automation tools द्वारा दिए गए MCP servers को जोड़ना बहुत शक्तिशाली है।
• API, automation, MCP — इनमें से सिर्फ एक ही इस्तेमाल करना ज़रूरी नहीं; इन्हें मिलाने से काम और आसान व शक्तिशाली हो जाता है (उदाहरण: Claude में सिर्फ Notion MCP जोड़ना, और Zapier में Notion to Instagram सेट करके upload automation करना)।
• फायदे-नुकसान को ध्यान में रखकर, अपने लिए उपयुक्त तरीके से, अपनी समस्या हल करने वाला प्रोग्राम (AI के साथ) बनाकर देखें।

[iolothebard]

सिर्फ vibe coding के स्तर को आउटसोर्सिंग नहीं कहा जा सकता। आउटसोर्सिंग में प्रोजेक्ट स्तर पर समीक्षा होती है, लेकिन अभी के AI coding agents के लिए उससे भी छोटे task स्तर पर समीक्षा करनी पड़ती है।

अगर यह आउटसोर्सिंग होती, तो काम सौंपकर मैं कोई और काम कर पाता… लेकिन अभी भी इन्हें बहुत बार देखना पड़ता है। होशियार हैं, लेकिन अनाड़ी junior developer जैसे…

लगता है कि जल्द ही… भले पूरी तरह आउटसोर्सिंग न हो, लेकिन शायद यह किसी छोटे development team की तरह काम कर सकें… काम निर्देशित करना, बीच-बीच में review करना, सुधारना… लेकिन अभी तो शायद वह स्तर भी नहीं आया है।

हो सकता है मेरी ही vibe कम हो, इसलिए ऐसा लग रहा हो…

[ifmkl]

https://tech.kakao.com/posts/700 यह पोस्ट देखकर मुझे लगा था कि यह Vibe Coding का एक अच्छा उदाहरण है, और संदर्भ भी कुछ वैसा ही लगता है। मैं भी आपके लिखे हुए से सहमत हूँ।

[spilist2]

आपकी वजह से एक मज़ेदार लेख पढ़ने को मिला! धन्यवाद।

[spilist2]

तो 3 क्या है? -> यह resource support की बात है.

ऊपर 1, 2, 4, 5 के रूप में numbering की थी, लेकिन Markdown में यह अपने-आप 1234 में बदल गया.