Vibe coding की पूजा पागलपन है

 (bramcohen.com)
33 पॉइंट द्वारा GN⁺ 23 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Claude के source code leak की घटना ने यह उजागर किया कि "vibe coding" में अंधविश्वास वास्तविक project quality को कितना नुकसान पहुंचा सकता है
  • vibe coding का सिद्धांत यह मानता है कि code के अंदर बिल्कुल नहीं देखना चाहिए, लेकिन यह महज़ एक अंधविश्वास है; व्यवहार में plan files, skills, rules जैसी मानवीय structural design अनिवार्य रूप से साथ होती है
  • AI वास्तव में code duplication और technical debt की सफाई जैसे कामों में बहुत अच्छा है, लेकिन इसका लाभ उठाने के लिए इंसानों को खुद code देखना, समस्याएँ समझना और उन्हें AI को समझाना पड़ता है
  • AI बहुत कम ही अपने आप यह पहचानता है कि "यहाँ spaghetti code है, इसे साफ़ करना चाहिए"; जब इंसान पहले दिशा और context देते हैं, तब बेहतर quality के नतीजे मिलते हैं
  • "खराब software डेवलपर की पसंद है" इस वाक्य की तरह, quality में गिरावट AI नहीं बल्कि निर्णय लेने का परिणाम है
  • यानी, software quality में गिरावट AI की गलती नहीं है, बल्कि डेवलपर के अपने चुने हुए फैसलों का परिणाम है

Claude source code leak और vibe coding की समस्या

  • Claude का source code leak हुआ, और code quality खराब होने की वजह से बहुत लोगों ने उसका मज़ाक उड़ाया
  • इस समस्या के कारण के रूप में dogfooding की अति, यानी अपने ही product को अत्यधिक अंधविश्वास के साथ इस्तेमाल करने वाली संस्कृति, को जिम्मेदार ठहराया गया
  • dogfooding अपने आप में अच्छा विचार है, लेकिन यह किसी भी तार्किक सीमा से आगे बढ़कर cult जैसी गतिविधि में बदल सकता है

vibe coding की असलियत

  • vibe coding एक ऐसा तरीका है जिसका सिद्धांत है कि code के भीतर कोई योगदान नहीं करना, बल्कि उसे देखना तक नहीं
  • लेकिन शुद्ध vibe coding एक मिथक है — व्यवहार में plan files (to-do lists), skills, rules जैसे इंसानों द्वारा बनाए गए framework ज़रूर मौजूद होते हैं, और इस संरचना के बिना AI बहुत खराब प्रदर्शन करता है
  • code अंग्रेज़ी में लिखा होता है, इसलिए कोई भी उसे पढ़ सकता है, फिर भी "अंदर देखना cheating है" जैसी सोच के कारण डेवलपर खुद जाँच करने से इनकार करते हैं
  • वास्तव में जब एक इंसान ने code देखा, तो पाया गया कि agents और tools के बीच बड़े पैमाने पर duplication मौजूद था; यह ऐसी समस्या थी जिसे कोई भी थोड़ी देर देखकर आसानी से समझ सकता था

AI और technical debt की सफाई

  • software projects अक्सर technical debt के साथ शुरू होते हैं, और पहले कभी-कभी केवल उसे साफ़ करने में ही 1 साल लग जाता था
  • AI का उपयोग करके यह सफाई कुछ हफ्तों में पूरी की जा सकती है, या नए features के विकास के साथ-साथ इसे धीरे-धीरे कम किया जा सकता है
  • AI code cleanup में बहुत अच्छा है, लेकिन अपने आप समस्याएँ पहचानने की क्षमता कमज़ोर है — जब इंसान उसे बताते हैं कि "यहाँ spaghetti code है" और guide करते हैं, तब अच्छे नतीजे मिलते हैं

AI का सही उपयोग — conversation-based approach

  • duplication की समस्या हल करने के सही तरीके के रूप में ये steps दिए गए हैं:
    • agents और tools दोनों से संबंधित items की list बनाना
    • examples देखकर तय करना कि हर item agent है या tool
    • पूरे criteria पर चर्चा करना और general guidelines बनाना
    • सभी items का audit करने के बाद गलत classification को ठीक करना
    • जो items दोनों तरफ मौजूद हों, उनकी दोनों versions की समीक्षा करके उन्हें एक में merge करना
  • Ask mode इसी प्रक्रिया के लिए है; examples को साथ देखकर, और जब AI ज़रूरत से ज़्यादा सहमत होने लगे तो उसकी गलतियाँ तुरंत ठीक करना, यही इसका मुख्य हिस्सा है
  • पर्याप्त बातचीत के बाद ऐसा लग सकता है कि AI ने one-shot जैसा result दिया है, लेकिन वास्तव में उसके पीछे पहले से इंसान के साथ बहुत अधिक interaction होता है
  • Claude टीम इस प्रक्रिया के बिना dogfooding को चरम तक ले गई है, और code के अंदर थोड़ी देर देखकर समस्या समझाने की न्यूनतम कोशिश तक से इनकार कर रही है

वास्तविक उपयोग के उदाहरण

  • अपने workflow का उदाहरण: बातचीत शुरू करते समय "इस codebase में unreachable code का audit करें" या "यह function आँखों को चुभ रहा है" जैसा कहकर शुरुआत करना
  • जब तक कोई actionable दिशा न मिल जाए, बातचीत जारी रखना, क्या करना है यह समझाना, और AI के बेवकूफी भरी बातें बंद करने तक चर्चा करते रहना
  • उसके बाद plan बनाना और build चलाना, यही रोज़मर्रा का तरीका है

software quality चुनाव का प्रश्न है

  • AI का उपयोग करने का मतलब यह नहीं कि खराब quality के software को स्वीकार ही करना पड़े
  • AI की मदद के बिना, बहुत ज़्यादा पैसे लेने वाले डेवलपर्स द्वारा बनाई गई libraries भी खराब quality की हो सकती हैं
  • खराब software अपने खुद के फैसलों का नतीजा है, और इसके लिए जिम्मेदारी लेनी चाहिए तथा बेहतर quality की कोशिश करनी चाहिए

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

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.