Vibe Coding
यह क्यों मायने रखता है
गहन अध्ययन
Karpathy का original description deliberately provocative था: उन्होंने typing के बजाय voice input, diffs पढ़े बिना हर suggested change पर "accept all" press करने और errors गायब होने तक error messages model में paste करके bugs ठीक करने की बात की। Provocation हटाएँ तो workflow simple है — describe, generate, run, react — जिसमें human author के बजाय product manager और tester होता है। 2025 में इसे viable बनाने वाली बात AI का code लिख पाना नहीं थी — AI कोडिंग असिस्टेंट वर्षों से ऐसा कर रहे थे — बल्कि underlying बड़ा भाषा मॉडल का उस loop के many turns में पूरे small project को साथ रखने लायक अच्छा होना था। Months में term tech circles से पूरी तरह बाहर निकला, mainstream media और Collins Dictionary की word-of-the-year shortlist पर दिखाई दिया, तथा software कौन बना सकता है उसमें real shift का default shorthand बन गया।
इसे संभव बनाने वाले Tools
Coding assistants में agent modes आने पर vibe coding practical हुई। एक समय में एक line complete करने के बजाय Cursor, GitHub Copilot और Windsurf जैसे tools अब कई files साथ edit, नई create, shell commands run, program execute, output read तथा iterate कर सकते हैं — ठीक वही loop जिसे vibe coder delegate करना चाहता है। Long कॉन्टेक्स्ट विंडो model को single time में small project जितना code याद रखने देती हैं, और better instruction following का अर्थ intent का loose description आम तौर पर runnable चीज़ बनाता है। Devin जैसे अधिक autonomous tools same idea आगे बढ़ाते हैं, task description लेकर minimal supervision में extended periods तक काम करके।
Vibe Coding कहाँ चमकती है
Sweet spot useful लेकिन disposable software है: weekend projects, personal tools, one-off data scripts, prototypes, demos और internal dashboards। Karpathy की अपनी framing throwaway weekend projects थी — ऐसी चीज़ें जिन्हें हाथ से लिखने की जहमत कभी न उठाते क्योंकि effort payoff से अधिक था। Non-programmers के लिए appeal और direct है: teacher, marketer या small-business owner small app describe करके afternoon में working version पा सकता है, ऐसी चीज़ जिसके लिए पहले developer hire या code सीखना पड़ता। Experienced engineers same mode boilerplate, migrations तथा glue code में इस्तेमाल करते हैं, जहाँ solution का shape obvious है और हर line पढ़ना कम value जोड़ता है। इन सभी cases में subtle bug की cost low है, इसलिए review step skip करना rational trade है।
Review और Security Debt
Risks same choice का flip side हैं। Model library functions हैलूसिनेशन कर सकता है, deprecated APIs चुन या authentication गलत wire कर सकता है, और कोई diff न पढ़े तो mistakes ship होती हैं। AI सुरक्षा researchers ने बार-बार पाया है कि AI-generated code meaningful rate पर vulnerabilities — injection flaws, missing authorization checks तथा hard-coded secrets — रखता है, और 2025 में ऐसे incidents की series आई जहाँ जल्दी vibe-coded apps ने production में user data या API keys expose किए। Slower, structural cost भी है: किसी के पूरी तरह न समझे codebase को debug करना कठिन है, और model की context window से आगे बढ़ने पर AI भी inconsistent changes करने लगता है। Critics इसके worst output को स्लॉप label में रखते हैं — code जो plausible दिखता, mostly काम करता और quietly rot होता है।
यह AI-Assisted Coding जैसा नहीं है
एक आम गलतफ़हमी है कि vibe coding किसी भी AI-assisted programming का नया नाम भर है। ऐसा नहीं है। Term specifically review step surrender करने को refer करता है: model ने code लिखा लेकिन आपने पढ़ा, समझा और responsibility ली तो वह better tooling के साथ ordinary AI-assisted development है — distinction जिसे Simon Willison जैसे writers ने early तथा sharply खींचा। Flip-side गलतफ़हमी है कि human कुछ contribute नहीं करता। व्यवहार में good vibe coding skill है: intent precisely describe करना, next क्या माँगना जानना और output गलत लगे तो पहचानना, सभी मायने रखते हैं, इसीलिए discipline प्रॉम्प्ट इंजीनियरिंग तथा context engineering से overlap करती है।
Professionals इसे वास्तव में कैसे इस्तेमाल करते हैं
अधिकतर working teams blended pattern पर पहुँचती हैं। Prototype vibe-coded होता है — fast, disposable और अच्छा demo होने से judged — तथा production के लिए destined हर चीज़ normal review से गुजरती है, tests तथा CI उस safety net की तरह जो हर line upfront पढ़ने की जगह लेता है। Common boundary risk है: internal tools तथा scripts fair game हैं, जबकि authentication, payments और user data छूने वाली हर चीज़ को human scrutiny मिलती है, चाहे उसे कैसे लिखा गया हो। Senior developers style से सबसे अधिक निकालते हैं, क्योंकि instincts wrong-looking output जल्दी पकड़ते हैं; बहुत जल्दी इस पर निर्भर juniors ऐसा code ship करने का risk लेते हैं जिसे explain या fix नहीं कर सकते। Generated code को fast लेकिन careless junior colleague की pull request जैसा मानना — useful, welcome और unread कभी merge नहीं — वह mental model है जिस पर कई teams converge हुई हैं।