खामियों से भरा टॉवर, vibe sickness, और vibe bobsled

 (dustycloud.org)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जैसे-जैसे LLM से बने कोड को इंसान खुद समझे बिना फिर उसी LLM से उसका अर्थ समझवाकर development करने का तरीका फैल रहा है, पहले अलग माने जाने वाले agent engineering और vibe coding के बीच की रेखा तेजी से धुंधली हो रही है
  • vibe bobsled उस तय रास्ते को दर्शाता है जो autocomplete से code generation, review छोड़ने और फिर prompt लिखना छोड़ने तक जाता है; और generation speed का जितना ज़्यादा उपयोग होता है, programmer की मूल भूमिका—थ्योरी बनाना और review करना—उतनी ही दूर होती जाती है
  • Pvote प्रयोग में security experts ने जगह पहले से जानते हुए भी 100 lines of code को लगभग 20 घंटे review किया, फिर भी तीन bugs में से कठिन bug नहीं ढूंढ पाए; इससे यह दिखता है कि इंसान बड़े पैमाने पर LLM output को पूरी तरह review कर लेंगे, यह मान लेना अव्यावहारिक है
  • समझे बिना बने code और outputs restaurant posters, customer support chatbots, age verification code, और open source issues·PR तक फैलते हुए vibe sickness फैला रहे हैं; tools का उपयोग न करने वाले लोग भी दूसरों के generated output को review करते-करते प्रभावित होते हैं
  • generative AI समस्या ढूंढने में उपयोगी हो सकता है, लेकिन generation में खास तौर पर कमजोर है; और भले ही दुनिया को ऐसे systems से बदला जा रहा हो जिन्हें कोई समझ नहीं पाता, इंसानों को बेहतर माहौल खुद बनाने की अपनी क्षमता नहीं छोड़नी चाहिए

समझ में न आने वाले कोड का टॉवर

  • The Tower Keeps Rising यह देखता है कि जिन स्थितियों को पहले टीम के लोगों को आपस में बात करके सुलझाना पड़ता था, वहाँ अब agents की मदद से लगातार प्रगति की जा सकती है
    • Armin ने इसे न अच्छा कहा, न बुरा, और न ही इसे टिकाऊ स्थिति बताकर समर्थन किया
    • लेकिन वह vibe coding कंपनी चलाते हुए इस रुझान को आगे बढ़ाने वाली स्थिति में हैं
  • vibe coding systems लगातार code और abstractions की परतें चढ़ाते-चढ़ाते आखिरकार ऐसी स्थिति तक पहुँच सकते हैं जहाँ कोई भी इंसान codebase को समझ न सके
    • इंसान जिन हिस्सों को नहीं समझ पाते, उन्हें भी LLM फिर से interpret कर देता है, इसलिए development जारी रखा जा सकता है—यह एक नया operating model बन रहा है
  • इसका समर्थन करने वाले पक्ष में भी यह स्वीकार किया जा रहा है कि अंतिम पड़ाव ऐसा हो सकता है जहाँ इंसान system को न समझे, और उस स्थिति को भविष्य के development तरीके के रूप में स्वीकार करने का बदलाव दिख रहा है

agent engineering और vibe coding की सीमा का टूटना

  • Simon Willison ने शुरू में agentic engineering को vibe coding से साफ़ अलग माना था
    • मार्च 2025 की पोस्ट में उन्होंने यह सिद्धांत रखा कि production-quality AI-assisted programming में repository में commit होने वाले हर code को पढ़कर किसी और को ठीक से समझा सकना चाहिए
    • उनका भेद यह था कि अगर LLM ने code लिखा हो, लेकिन इंसान उसे review करे, अच्छी तरह test करे, और उसका काम समझा सके, तो वह vibe coding नहीं बल्कि software development है
  • करीब एक साल बाद Vibe coding and agentic engineering are getting closer than I’d like में उन्होंने कहा कि coding agents की reliability बढ़ने के साथ अब production code की भी हर line review नहीं की जा रही
    • उन्हें भरोसा है कि Claude Code SQL query चलाकर JSON लौटाने वाला API endpoint सही बनाएगा और tests व documentation भी जोड़ देगा
    • साथ ही, review न किए गए code को production में इस्तेमाल करना जिम्मेदाराना है या नहीं, इस पर उन्हें अपराधबोध और संदेह महसूस होता है
  • इन दोनों स्थितियों के बीच का अंतर सिर्फ एक साल से थोड़ा ज़्यादा है
  • agent engineering को बेहतर उपयोग-पद्धति मानने की धारणा व्यापक हुई है, लेकिन असल उपयोगकर्ता—खुद Simon सहित—vibe coding की ओर खिंचते दिखते हैं

vibe bobsled

  • bobsled एक ऐसा खेल है जिसमें बर्फीले track पर बहुत तेज़ नीचे आया जाता है, लेकिन दिशा चुनने की गुंजाइश लगभग नहीं होती
    • खिलाड़ी आपस में कौशल की प्रतिस्पर्धा कर सकते हैं और रोमांच महसूस कर सकते हैं, लेकिन सवारी कर रहा व्यक्ति यात्रा को बहुत नहीं चुनता
  • vibe bobsled में LLM वाहन है और उपयोगकर्ता यात्री
    • उपयोगकर्ता को जितना लगता है, वास्तविक नियंत्रण उससे कहीं कम होता है; यह सिर्फ फिसलन भरी ढलान नहीं, बल्कि पहले से तय यात्रा के ज़्यादा करीब है
  • developer आगे के चरणों से गुजरते हुए code production प्रक्रिया से खुद को हटाता जाता है
    • पहले वह सोचता है कि इसे सिर्फ advanced autocomplete की तरह इस्तेमाल करेगा
    • फिर idea exploration के लिए agent चलाता है, लेकिन कहता है कि code खुद लिखेगा
    • उसके बाद agent code generate करता है, लेकिन वह कसम खाता है कि हर result review करेगा
    • जल्द ही वह code लगभग review करना छोड़ देता है और मानने लगता है कि agent शायद उससे बेहतर developer है
    • अंत में वह “अब coding नहीं करता” से आगे बढ़कर “अब prompts भी नहीं लिखता” वाले चरण तक पहुँच सकता है
  • हर चरण LLM पर आधारित trust-based code production की ओर बढ़ने की प्रक्रिया है, जहाँ मान लिया जाता है कि LLM अपने काम को समझता है और उसे अच्छी तरह कर लेगा

generation speed और review की टक्कर

  • coding में धीमा हिस्सा generation नहीं बल्कि थ्योरी बनाना और review है, और जो नतीजे ऊपर से सही लगें लेकिन गलत हों, उन्हें debug करना और समझना बहुत कठिन होता है
  • LLM की सबसे शक्तिशाली विशेषता generation speed है, इसलिए अगर इंसान हर output review करे तो उस speed का पूरा लाभ उठाना मुश्किल होता है
  • दूसरी ओर, थ्योरी बनाना और review करना programmer की सबसे महत्वपूर्ण भूमिका है; इसलिए LLM की ताकत को जितना अधिकतम किया जाए, उतना ही इस मूल भूमिका से टकराव पैदा होता है
  • Ka-Ping Yee के पेपर Building Reliable Voting Machine Software में software verification को कठिन बनाने वाले चार कारण बताए गए हैं
    • components की संख्या
    • जटिल interactions
    • व्यापक impact
    • nonlinearity
  • ये चारों समस्याएँ LLM के code generation तरीके से और बदतर हो सकती हैं

Pvote bug review प्रयोग

  • Ka-Ping Yee और David Wagner ने model voting machine Pvote में ऐसे तीन bugs डाले—आसान, मध्यम और कठिन—जिनका दुरुपयोग करके चुनाव परिणाम बदले जा सकते थे
  • तीनों bugs Navigator.py की lines 11~109 के 100-line क्षेत्र में रखे गए थे
    • यह program logic के हिसाब से दिलचस्प हिस्सा था और reviewers के सीमित समय को देखते हुए चुना गया था
    • reviewers को यह बताया गया कि किस हिस्से को देखना है, लेकिन bugs कितने हैं यह नहीं बताया गया
  • तीसरे दिन review के नतीजे इस प्रकार थे
    • Python में बहुत निपुण Dan Sandler ने लगभग 70 मिनट में आसान और मध्यम bug खोज लिए
    • Yoshi Kohno और Mark Miller ने लगभग 4 घंटे बाद आसान bug ढूंढा
    • कठिन bug किसी को नहीं मिला
  • चौथे दिन Ian Goldberg ने लगभग 2 घंटे में आसान bug ढूंढ लिया, लेकिन बाकी bugs नहीं मिले
  • कुशल security experts को जगह पहले से मालूम थी, फिर भी कुल लगभग 20 reviewer-hours लगाने के बाद भी वे तीनों bugs नहीं ढूंढ पाए
  • बाद में bugs की पुष्टि करने के बाद Mark S. Miller इस बात से हैरान थे कि सबने माना कि वे सभी साफ़-साफ़ bugs थे और उन्हें मिल जाना चाहिए था
  • अगर शीर्ष स्तर के programmers भी 100 lines में निश्चित रूप से मौजूद bugs चूक सकते हैं, तो इंसानों के लिए LLM के विशाल output को review करना संभालना बहुत कठिन है
    • अंततः उपयोगकर्ता review छोड़ देता है और code production प्रक्रिया से खुद को चरणबद्ध तरीके से हटा देता है

AI psychosis और vibe sickness

  • “AI psychosis” शब्द का इस्तेमाल अक्सर generative AI से पैदा हुए खराब व्यवहार या नतीजों के लिए व्यापक रूप से होता है, लेकिन मूल अर्थ में यह उस स्थिति के करीब था जहाँ उपयोगकर्ता अत्यधिक सकारात्मक chatbots के साथ बातचीत करते हुए वास्तविक psychosis जैसी भ्रमपूर्ण वास्तविकता-विच्छेद अवस्था में पहुँच जाते हैं
  • clinical psychosis नहीं, बल्कि generative AI से पैदा हुई व्यापक बेचैनी के लिए vibe sickness ज़्यादा उपयुक्त शब्द है
  • Glyph की PyCon US 2026 प्रतिक्रिया में ये स्थितियाँ एक साथ दिखती हैं
    • व्यापक vibe sickness
    • open source की बड़े पैमाने की sustainability crisis
    • low-quality security PR की बाढ़
    • आपसी समझ के लिए आशा, ऊर्जा और प्रयास, और काम के प्रति आभार

रोज़मर्रा और open source में फैलते outputs

  • लोग low-quality generated output यानी slop की शिकायत करते हैं, लेकिन generative AI उपयोगकर्ता अपने खुद के output को slop नहीं कहते
  • ऊपर से ठीक दिखने वाले लेकिन समझ में न आने वाले outputs रोज़मर्रा की कई जगहों पर दिखाई देते हैं
    • मुश्किल से समझ आने वाले design वाले स्थानीय restaurant posters
    • उपयोगकर्ताओं को परेशान करने वाले customer support chatbots
    • age verification code
    • open source projects में जमा किए जाने वाले low-quality issues और PR
  • ये tools कुछ कामों में उपयोगी हैं, और समस्या खोजने के मामले में इन्हें अलग तरह से आंका जा सकता है
  • लेकिन “genAI” नाम जिस generation पर ज़ोर देता है, वही दरअसल tools का सबसे कमजोर हिस्सा है
    • समस्या सिर्फ output quality की नहीं, बल्कि यह भी है कि system के निर्माण, संरचना और maintenance का तरीका किसी को समझ नहीं आता

generative AI से बचना मुश्किल होता जा रहा माहौल

  • भले ही आप generative AI का सीधे उपयोग न करें, सहकर्मी या open source contributors ऐसे generated outputs “contribution” के रूप में भेज सकते हैं जिन्हें वे खुद भी नहीं समझते
    • reviewer को यह सोचकर हिचकना पड़ सकता है कि LLM-generated होने के बारे में पूछना कहीं असभ्य तो नहीं होगा
    • issues या PR का जवाब देते समय वह agents के साथ परोक्ष रूप से interact करता है और अनजाने में vibe coding workflow का हिस्सा बन जाता है
  • Glyph ने LLM वाले हर software को ठुकराने की कोशिश की तुलना इस बात से की कि जैसे leaded gasoline के विरोध में लोग तब तक साँस रोक लें जब तक सब उसका उपयोग बंद न कर दें
    • व्यवहार में कुछ हद तक इसे स्वीकार करना पड़ सकता है, और कोई अपनी निजी ethical line तय भी करे, तब भी इसका मतलब generative AI वाले माहौल के लिए उत्साह या समर्थन नहीं है
  • uncanny valley वास्तविक दुनिया पर कब्ज़ा करती जा रही है, और ऐसे systems पुरानी दुनिया की जगह ले रहे हैं जिन्हें कोई समझ नहीं पाता
  • इस स्थिति से उबरने की कीमत क्या होगी, यह अभी साफ़ नहीं है; और जो projects मौजूदा generative AI में भाग न लेने का चुनाव करते हैं, वे सम्मान के योग्य हैं

बेहतर भूभाग बनाने का चुनाव

  • काम या माहौल की वजह से generative AI की समस्याओं में योगदान देना पूरी तरह ठुकराना शायद संभव न हो
  • अगर कोई car driver सड़क पर साइकिल चलाने वालों पर झुंझलाए भी, तो खराब bicycle infrastructure की वजह से साइकिल उपयोगकर्ता parked cars के खुलते दरवाज़ों या अधीर drivers से खतरे में पड़ते हैं
  • गाड़ी चलाते समय आगे साइकिल दिखे तो उसके होने के लिए आभार महसूस किया जा सकता है, और यह सोचा जा सकता है कि भूभाग और infrastructure कैसे बदला जाए ताकि साइकिलें ज़्यादा सुरक्षित ढंग से शामिल हो सकें
    • ऐसे बदलाव car driving को भी आसान बनाते हैं, और परिस्थिति के अनुसार साइकिल चुनना भी आसान करते हैं
  • तकनीक द्वारा तय रास्ते के हवाले खुद को करने के बजाय, इंसान सीधे भाग लेकर बेहतर दुनिया बना सकते हैं—इस विश्वास को नहीं छोड़ना चाहिए

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs की राय

  • हाल में जिन software engineering इंडस्ट्री के बदलावों को मैं बेचैनी से देख रहा था, उन पर यह अब तक की सबसे अच्छी लिखी गई चीज़ों में से एक है

  • सिर्फ 1 साल पहले तक agentic engineering एक वांछनीय दिशा लगती थी, लेकिन असल tools के ज़्यादातर users मानने से हिचकते हैं, फिर भी लगता है कि वे vibe coding की ओर झुक रहे हैं। यह डर कि LLM मेरी skills और लगाव को बेकार बना सकता है, दो सिद्धांत तय करने के बाद काफी कम हो गया।
    पहला, फुर्सत के समय मैं LLM या coding agents का इस्तेमाल नहीं करता, और search के AI features भी ठुकरा देता हूँ। सिर्फ तब इस्तेमाल करता हूँ जब मैं खुद हल नहीं निकाल पा रहा होता और hallucination की संभावना स्वीकार करना मजबूरी हो। तकनीक से मुँह मोड़ने से दुनिया की समस्या हल नहीं होगी, लेकिन जब न मैं individual developers पर हमला कर सकता हूँ, न बड़ी कंपनियों को बदल सकता हूँ, तब कम-से-कम अपनी फुर्सत को इससे दूर रखना एक व्यावहारिक विकल्प है।
    दूसरा, ऐसे workplace में भी जहाँ AI के इस्तेमाल को बहुत बढ़ावा दिया जाता है, मैं इसे सिर्फ code review और छोटे-मोटे कामों के लिए इस्तेमाल करता हूँ। यानी codebase में सीधे मिल जाने वाली लेकिन ढूँढने में झंझट वाली चीज़ें पूछने तक सीमित रखता हूँ, और code पूरा खुद लिखता हूँ। तभी मैं उसके काम करने के तरीके को सहज रूप से समझ पाता हूँ और अपने व सहकर्मियों की अपेक्षा के स्तर पर काम कर सकता हूँ।
    LLM एक सहायक साधन के रूप में ठीक है, जो deterministic linter से छूट जाने वाली pattern-based errors पकड़ लेता है। यह बेहूदा जवाब भी देता है, लेकिन क्योंकि code मैं खुद लिखता और समझता हूँ, इसलिए इस पर आँख बंद करके भरोसा नहीं करता। अगर इंसानी review से पहले यह साफ़ logic errors और गलत assumptions छाँट दे, तो सहकर्मी ज़्यादा जटिल हिस्सों पर ध्यान दे सकते हैं, और public channels में इंसानों की जगह मशीनों को आपस में बात कराने वाली बदतमीज़ी से भी बचा जा सकता है।
    हाल ही में कंपनी ने token usage पर कड़ी सीमा लगा दी, लेकिन मेरा workflow दिन का सिर्फ 1–2 euro का है, इसलिए चिंता नहीं है। जो लोग पूरी तरह intuition पर निर्भर हो गए थे, वे शायद फिर से human reasoning इस्तेमाल करने की ज़रूरत से घबराएँ, लेकिन बाकी लोग सहकर्मियों के साथ मिलकर सीधे काम कर सकते हैं।

    • “क्या रेत में सिर छिपाने से समस्या हल हो जाएगी?” जैसी आलोचना असल किसी तीसरे व्यक्ति की नहीं, बल्कि कल्पित आलोचक की ओर से खुद से कही जाने वाली बात है। ऐसी आलोचना को ध्यान में रखकर जितना ज़्यादा चुनाव करते हैं, जीवन उतना ही खराब होता है, इसलिए मैं भी इससे बचने की कोशिश करता हूँ।
      इसमें यह आत्मपीड़क ज्ञानमीमांसा भी छिपी है कि जितनी पीड़ा हो, उतना ही सच को घूरना चाहिए। कष्टदायक जानकारी से बचना गुणहीन लग सकता है, लेकिन ध्यान सीमित होता है, इसलिए उसे उन चीज़ों पर लगाना बेहतर है जो आपको ज़्यादा खुश, अधिक संतुष्ट बनाती हैं और कल फिर आगे बढ़ने की ताकत देती हैं।
    • यह रेत में सिर छिपाने से ज़्यादा “ऑफिस का काम पसंद नहीं, इसलिए फुर्सत में ऑफिस से दूर रहता हूँ” जैसा है। अगर किसी अप्रिय चीज़ से बचा जा सकता है, तो उससे बचना तर्कसंगत है।
      जो लोग जीवन की हर चीज़ को optimize करके सबसे बेहतर बन जाने वाले काम की तरह लेते हैं, नुकसान अक्सर उन्हीं का होता है। अगर coding पसंद है तो फुर्सत में भी कीजिए, और अगर नहीं पसंद तो उसे सिर्फ पेशा बने रहने दीजिए। फुर्सत में कभी-कभी अकुशल होना भी ठीक है, वरना खाली समय दूसरी नौकरी बन जाता है और असली आराम बिल्कुल नहीं मिलता।

  • यहाँ Fawlty की spelling गलत लिखी गई है, यह बात ज़रूरत से ज़्यादा खटकती है

    • शायद यह जानबूझकर लिखा गया है, क्योंकि यह “मुसीबत खड़ी करने वाली” बाबेल की मीनार वाला शब्द-खेल लगता है

  • लेख हमेशा की तरह शानदार है, लेकिन यह पूछना कि क्या यह LLM से बना है, बदतमीज़ी होगी या नहीं—इस पर इतना सोचने की ज़रूरत नहीं लगती। अगर आपको खराब नतीजा मिला है, तो यह बात अलग है कि बनाने की प्रक्रिया में LLM इस्तेमाल हुआ या नहीं; आप साफ़ कह सकते हैं कि quality खराब है और आपको पसंद नहीं आई

    • अगर कोई अनजान नया contributor हो, तो PR की quality issues बताकर उसे सुधार की जिम्मेदारी वापस देना तर्कसंगत है। लेकिन याद पड़ता है कि Zig project ने नए contributors को लंबे समय के contributors में विकसित करने के लिए LLM नहीं बल्कि इंसानों द्वारा सीधे मार्गदर्शन देने के उद्देश्य से AI-विरोधी policy अपनाई थी।
      दूसरी ओर, सहकर्मी या ऐसे लोग जिनसे ऑनलाइन लंबे समय से संपर्क हो, उनके साथ रिश्ता बनाए रखने के लिए आप जितना हो सके उतनी कम बदतमीज़ी करना चाह सकते हैं। contribution कैसे बना, यह जानना चर्चा के लिए ज़रूरी हो सकता है, और उसका नतीजा जानबूझकर रिश्ते पर बड़ा असर भी डाल सकता है। आप बदतमीज़ लगने का जोखिम लें या मूलतः टकराव से बचते हुए संबंध बचाए रखें, यह स्वभाव पर निर्भर चुनाव है।
      मैं मूलतः टकराव से बचने वाला व्यक्ति हूँ, इसलिए उस वाक्य के पीछे की पृष्ठभूमि समझ सकता हूँ, और मूल दलील से भी खास असहमत नहीं हूँ।

  • bobsled रूपक मुझे पसंद आया। मैं इस बात से सहमत नहीं कि LLM users को ज़रूर अंत तक नीचे ही जाना पड़ेगा, लेकिन इंडस्ट्री में दिख रहे व्यवहार को यह अब तक देखे गए किसी भी रूपक से बेहतर बताता है

  • “bobsled रूपक” दरअसल एक logical fallacy है, जिसे slippery slope के नाम से बेहतर जाना जाता है। 1 साल पहले vibe coding का हिस्सा 0% था, और Simon Willison ने coding agents को सावधानी से अपनाते हुए धीरे-धीरे भरोसा बढ़ाने की प्रक्रिया कई लेखों में सार्वजनिक की थी।
    लेकिन यहाँ उसी आधार पर यह तय मान लिया गया है कि “जाना तो सिर्फ एक ही दिशा में है।” Willison और दूसरे users के पास भी पसंद और निर्णय-क्षमता है, ऐसा मानना ज़्यादा उचित है