AI आपके लिए काम करने वाला प्रोडक्ट नहीं बनाता, वह अब भी आपका काम है

 (weeraman.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI कुछ ही मिनटों में UI और database के साथ prototype बना देता है, लेकिन पहले working version से production-grade product तक की दूरी कम नहीं करता
  • वास्तविक product में scalability, error handling, observability, security, authentication, data structure जैसे ऐसे सवाल बचे रहते हैं जहाँ syntax लिखने से ज़्यादा engineering judgment चाहिए
  • computer science की असली अहमियत code production से ज़्यादा सिस्टम के behavior और failure के कारण समझने वाले mental model में है; यही समझ inefficient query या race condition पकड़ने में मदद करती है
  • requirements को mechanical तरीके से code में बदलने वाले काम की मांग घटेगी, लेकिन skilled engineer repetitive काम AI को देकर expertise मांगने वाली समस्याओं पर ध्यान केंद्रित कर कहीं तेज़ी से काम कर सकते हैं
  • अगर AI को understanding के बदले इस्तेमाल करेंगे, तो टूटे हुए सिस्टम को ठीक करना, बढ़ाना या handoff करना मुश्किल होगा; इसलिए पहले fundamentals सीखें, फिर AI tools का इस्तेमाल करें

Prototype और product के बीच की खाई

  • अगर आप natural language में idea समझाएँ, तो कुछ ही मिनटों में UI और database वाला, इच्छित feature करने वाला काम करने योग्य prototype मिल सकता है
  • लेकिन laptop पर चलने वाला prototype वास्तविक environment में कई समस्याएँ दिखा सकता है
    • वह load नहीं झेल पाता और उसमें error handling भी नहीं होती
    • API token लीक हो सकता है
    • demo के लिए बना data model दूसरे user को जोड़ते ही टूट सकता है
    • authentication unverified assumptions पर टिका हो सकता है और security भी संदिग्ध हो सकती है
  • deployment के चरण में पहुँचते ही 'यह चलता है' और 'यह तैयार है' के बीच का बड़ा production gap सामने आता है

मुश्किल काम code लिखने के बाद भी रहता है

  • software engineer पहले भी कुछ चीज़ें जल्दी चला सकते थे, और असली समय उसके बाद वाले हिस्से में लगता था
    • ऐसा system design जो scale बढ़ने पर भी टिके
    • जब user unexpected path से आए तो exception handling
    • failure दिखाने वाली observability बनाना
    • ऐसे data architecture फ़ैसले जो 3 साल बाद पछतावा कम करें
  • AI ने पहले working version तक पहुँचने का समय बहुत घटाया है, लेकिन उस version से production-grade system तक जाने की दूरी कम नहीं की
  • request-response-result का तेज़ चक्र यह भ्रम दे सकता है कि बाकी development process भी compress हो गया है, लेकिन software की कठिन समस्याएँ शुरू से syntax लिखना नहीं थीं
  • क्या बनाना है, उसे कैसे structure करना है, क्या टालना है और कब मना करना है—यह judgment ही prototype और production system में फर्क करती है

Computer science अब भी क्यों ज़रूरी है

  • AI-generated code तक आसान पहुँच के बाद, नए entrants में यह सवाल बढ़ा है कि algorithm, data structure, operating system और theory को सालों तक पढ़ना क्या अब भी ज़रूरी है
  • computer science education की value सिर्फ code लिखने की क्षमता में नहीं है; यह ऐसे mental model बनाती है जिनसे समझ आता है कि system कैसे काम करता है, कैसे fail होता है, और क्यों वह नतीजा आता है
  • यही आधार होना चाहिए ताकि AI द्वारा generate किए गए code की संभावित विफलताओं को पहचाना जा सके
    • 5 करोड़ rows वाली table पर full table scan कराने वाली query
    • concurrent load में race condition पैदा करने वाली cache strategy
    • जो current requirement तो हल कर दे, लेकिन अगले problem को बहुत कठिन बना दे, ऐसा architecture
  • fundamentals के बिना आप model के judgment पर पूरी तरह निर्भर हो जाते हैं
    • model judgment नहीं, pattern matching के आधार पर ऐसा code उत्साह से बनाता है जिसे वह आपकी मंशा के अनुरूप मानता है
    • generated code सही और conventional दिख सकता है, फिर भी production में fail हो सकता है
    • अगर समस्या पहचानने की समझ न हो, तो diagnosis में कई दिन लग सकते हैं
  • अब जबकि understanding और output के बीच की दूरी घट गई है, यह computer science सीखने का अच्छा समय है; distributed systems को सही तरह समझने वाला छात्र 10 साल पहले की तुलना में बहुत कम समय में उन्हें बना सकता है

Automate होने वाले काम और बढ़ती productivity

  • requirements को लाइन-दर-लाइन implementation में बदलने वाले mechanical coding tasks की demand वास्तव में घट रही है, और यह क्षेत्र automate हो रहा है
  • productivity distribution का निचला हिस्सा compress हो रहा है, जबकि ऊपर की सीमा फैल रही है
    • modern AI tools इस्तेमाल करने वाला skilled engineer 5 साल पहले कल्पना करना मुश्किल था, ऐसी speed से काम कर सकता है
    • कठिन समस्याएँ गायब नहीं हुईं; बस समय और ध्यान खाने वाले mechanical कामों का बड़ा हिस्सा अब संभल रहा है
    • इससे बचा समय उन कामों में लगाया जा सकता है जहाँ असली expertise चाहिए
  • पीछे वही engineer रह जाएगा जो AI इस्तेमाल करना नहीं जानता ऐसा नहीं, बल्कि वह जो AI को understanding के विकल्प की तरह इस्तेमाल करता है
    • वह vibe coding से ऐसे system बनाता है जिन पर वह खुद reason नहीं कर सकता
    • वह failure ठीक नहीं कर पाता या बढ़ चुके system को scale नहीं कर पाता
    • वह maintenance करने वाले engineer को अपनी बनाई चीज़ समझा नहीं पाता

ऊँचे abstraction level पर काम करना

  • ज़रूरी बदलाव सिर्फ नए tools अपनाना नहीं है, बल्कि fundamentals में जड़ें बनाए रखते हुए और ऊँचे abstraction level पर काम करना है
  • जो engineer AI को deep knowledge के विकल्प की जगह amplifier की तरह इस्तेमाल करते हैं, वे अपने peers से तेज़ी से आगे निकल सकते हैं
    • वे समझते हैं कि model से क्या generate करवाना है
    • वे generated code को वैसे ही critically देखते हैं जैसे junior engineer के pull request को review करते समय देखते हैं
    • वे सिर्फ feature description नहीं देते, बल्कि architecture के नज़रिये से बातचीत करते हैं
    • वे तय कर सकते हैं कि model के सुझाव का विरोध कब करना चाहिए
  • यह पुरानी skills को नई capability से बदलना नहीं है, बल्कि पुरानी skills को नए environment में लागू करके बहुत अधिक leverage हासिल करना है
  • prototype के बाद भी वास्तविक engineering judgment की ज़रूरत रहती है, और यही क्षमता भरोसेमंद software ship करने वाले developer और सिर्फ demo ship करने वाले developer में फर्क करती है
  • सीखने का क्रम पहले fundamentals, फिर AI tools होना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की रायें

  • मैं अपने side project में कई महीनों तक LLM से लिखवाया गया code फेंकने की सोच रहा हूँ। design specs सावधानी से लिखने और मौजूदा codebase पर काम करने के बावजूद, अलग-अलग बदलाव logical दिखते थे, लेकिन कुल मिलाकर कई हिस्से बारीक तरीक़े से mismatch होते हुए एक जटिल ढेर बन गया
    reports या papers में भी हर section ठीक-ठाक लगता है, लेकिन पूरा document अजीब महसूस होता है। इंसान detailed कामों में धीमा हो सकता है, लेकिन लगता है LLM के लिए अभी असंभव higher-level reasoning कर लेता है। defect बताने पर वह “पूरी तरह सही” कहता है, लेकिन खुद review करते समय उसे ढूँढ नहीं पाता
    common JS framework, Tailwind, ORM से simple CRUD app बनाना पर्याप्त रूप से संभव होगा, लेकिन पहले भी SaaS templates खरीदे जा सकते थे, और अच्छी तरह बनाया गया hand-crafted boilerplate vibe coding के नतीजों से बेहतर होने की संभावना ज़्यादा है

    • पूरी तरह autonomous programming की बजाय LLM-assisted programming का इस्तेमाल बढ़ता जा रहा है। Opus जैसे models अच्छे design को समझने से ज़्यादा goal पूरा होने तक बदलाव करते रहते हैं, और अक्सर ऐसा code व बहुत ज़्यादा research work छोड़ जाते हैं जिसे इंसान को साफ़ करना पड़ता है
      दूसरों के PR में भी अक्सर देखता हूँ कि prompt की समस्या सतही तौर पर हल हो जाती है, लेकिन implementation long-term maintenance के लिए कठिन होता है। इसलिए implementation steps और design मैं खुद तय करता हूँ, और छोटे open-source models या Claude 4.5·4.6 के साथ step-by-step काम करता हूँ। API exploration और boilerplate writing तेज़ हो जाती है, इसलिए manual work से कई गुना तेज़ रहते हुए भी knowledge degrade नहीं होती और codebase खराब नहीं होता
    • कई बार complex और over-engineered solution में फँसने के बाद टहलने या कुछ और करने पर simple solution समझ आया है। LLM सब कुछ तुरंत process कर देता है, जिससे reflection करने, dead end पहचानने और अगले काम से conflicts पर सोचने का समय छिन जाता है
    • मेरा side project भी अब ऐसा हो गया है कि code को पूरी तरह समझकर सुरक्षित रूप से खुद modify करना कठिन है, लेकिन मुझे लगता है अब इसकी ज़रूरत नहीं रही। लगभग 20 साल तक सुंदर code लिखा है, अब productivity और output पर focus करना चाहता हूँ, और जब तक Codex spaghetti code समझता है, personal projects या छोटे indie developers के लिए यह ठीक है
      AI, machine language के ऊपर high-level languages की तरह, tech stack पर जोड़ी गई एक नई layer है, इसलिए छोड़ना सीखना होगा
    • असली value code से ज़्यादा वहाँ तक पहुँचने में मिली learning में थी। संघर्ष की प्रक्रिया में actual requirements और technical challenges बार-बार सामने आते हैं, लेकिन AI उस प्रक्रिया को bypass करके ऐसा दिखाता है मानो goal सतही तौर पर हासिल हो गया हो
      इसका मतलब यह नहीं कि AI बेकार है; requirements और final validation पर ज़्यादा गहराई से सोचना चाहिए और यह भरोसा कम करना चाहिए कि process अपने-आप valuable result सुनिश्चित करेगी
    • नए family calendar project में AI की speed का फायदा उठाकर user experience issues refine कर रहा हूँ। features बनाकर कुछ दिनों तक खुद इस्तेमाल करता हूँ, फिर जो पसंद नहीं आता उसे ठीक करता हूँ, और इसी process को दोहराते हुए v1 features पूरा करने का लक्ष्य है
      colors या लंबा-चौड़ा और अनावश्यक रूप से flashy business logic पसंद नहीं है, लेकिन अभी महत्वपूर्ण बात यह है कि husband-wife इसे वास्तव में उपयोगी पाते हैं या नहीं, और परिणाम positive हैं। बाद में UI को अपनी पसंद से फिर design करूँगा, backend requirements finalize करूँगा, और maintenance व scaling आसान हो इसलिए शुरुआत से rewrite करूँगा
      Claude family prototyping और requirements discovery में बेहतरीन है, और बाद में ठीक से फिर बनाने की प्रक्रिया को आसान बना देती है

  • एक simple validation criterion यह है कि पिछले 12·24·36 महीनों में आपने कोई बेहतरीन नया product या existing product में बड़ा improvement सचमुच देखा है या नहीं। मैंने जो बेहतरीन नए products इस्तेमाल किए हैं, वे सिर्फ पसंदीदा LLMs हैं, और वे labs उल्टा और ज़्यादा लोगों को hire कर रहे हैं
    अगर 12 महीने बाद भी improvement नहीं होता, तो मुझे लगता है कि “फरवरी 2027 में ही LLM काफी अच्छे हुए हैं, इसलिए अभी evaluate नहीं किया जा सकता” वाली दलील फिर दोहराई जाएगी

    • Claude Code का web version और VS Code version अभी भी bugs से भरे हैं या नहीं, यह भी अच्छा benchmark है। लगभग हर agent loop टूट जाता है और forced refresh की ज़रूरत पड़ती है, और कभी-कभी उससे भी समस्या हल नहीं होती। Anthropic के पास practically unlimited LLM budget और unreleased models भी हैं
    • मैं LLM को सर्वशक्तिमान मानने वाला नहीं हूँ और उन्हें controlled तरीके से इस्तेमाल करता हूँ, लेकिन हाल की automatic vulnerability discovery दिलचस्प progress है। Chrome ने जून के एक महीने में पिछले 2 साल से ज़्यादा bugs fix किए
      https://news.ycombinator.com/item?id=49120097
      नवीनतम Apple security updates और जून Android security bulletin ने भी भारी संख्या में vulnerabilities fix कीं। इनमें से काफ़ी C/C++ जैसी unsafe languages से आईं, लेकिन clearly defined और कम deviation वाली transformation tasks में LLM मजबूत होते हैं, इसलिए Rust जैसी safe languages में port करने में भी useful हैं
    • project launch speed पहले जैसी ही है, लेकिन AI tools की वजह से output कहीं ज़्यादा polished और feature-rich हो गया है। पहले सिर्फ happy path चलाकर launch कर देते थे, लेकिन अब cancellation, account export, privacy policy और पूरे mobile·web apps तक बिना बड़े effort के दे सकते हैं
    • कुछ developer communities को ही देखें तो इन tools के आने के बाद नए products की संख्या तीन गुना हो गई है। सभी released software और AI usage को track करने वाली कोई list भी नहीं है, ऐसे में सिर्फ इसलिए कि आपने खुद improvement नहीं देखा, यह मान लेना कि वह मौजूद नहीं है, अजीब है
      medical field में भी products की संख्या तेज़ी से बढ़ी है; quality अलग-अलग है, लेकिन यह कहना कि कोई result नहीं निकला, objectively गलत है
    • मेरा मानना है कि practical use पिछले साल के अंत से शुरू हुआ, लेकिन हाल में hobby software में साफ़ तौर पर तेज़ बढ़ोतरी हुई है। यह कितना अच्छी तरह maintain होगा, अलग बात है

  • जब product चलने लगे, तो “review करो कि codebase production-ready है या नहीं, और क्या यह 1 million dollars में बेचने के standard को पूरा करता है” कहकर देखना चाहिए। तब AI दिखा देगा कि वह पहले जिस level का दावा कर रहा था, उसके कहीं पास भी नहीं पहुँचा, और यह ‘million-dollar prompt’ बन जाएगा जो बताता है कि आप कितने धोखे में थे

    • मैंने Hacker News की दो posts देखीं और दोनों में top comments थे कि “AI code नहीं लिख सकता और जल्द collapse हो जाएगा।” जो लोग सालों से रोज़ इन tools को सफलतापूर्वक इस्तेमाल कर रहे हैं, उन्हें लगातार mirage बताने की बात समझना मुश्किल है
    • बहुत खराब codebases भी कई बार 1 million dollars से ज़्यादा में बिके हैं
    • तो फिर सोचता हूँ Oracle Database कितने million dollars में बिकना चाहिए
      https://news.ycombinator.com/item?id=18442941
    • problem fix करने को कहकर वही सवाल फिर पूछें, तो fixes के बाद भी वह फिर मिलती-जुलती criticism देगा
    • यह सोचने लायक है कि OpenClaw कितने में बिका था

  • LLM को दो तरीकों से इस्तेमाल करके देखा। पहला, Opus 4.6 और Node backend के साथ, लोगों के क्रम के अनुसार Slack चैनल में notification भेजने वाला plugin और Google Meet के प्रतिभागी-वार बोलने का timer vibe coding से बनाया। यह internal tool है, इसलिए implementation को अच्छी तरह न समझने पर भी GCP पर बिना समस्या चलता है, और प्रति व्यक्ति महीने के 20 डॉलर वाले Slack tool का खर्च घटाकर पूरे system के लिए महीने के 0.07 डॉलर infrastructure cost कर दिया
    यह एक ही बार में नहीं बना; detailed planning, step-by-step execution और tests जोड़ने की प्रक्रिया से गुजरा। दूसरा, लंबे समय तक चलने वाले product में team architecture design और review करती है, detailed JIRA tickets बनाती है और फिर उन्हें Opus को देती है। Model implementation plan बनाता है और engineer की approval के बाद ही coding करता है
    तेज MVP या proof of concept के लिए पहला तरीका अच्छा है, लेकिन long-term product हो तो MVP को छोड़कर scalability और साफ architecture को शुरू से plan करना चाहिए और LLM को coding worker की तरह इस्तेमाल करना चाहिए। LLM अभी उस architecture और clean code के फैसले में कमजोर है जिसे इंसान लंबे समय तक maintain कर सकें

    • One-off, low-risk app की vibe coding के लिए यह शानदार था, लेकिन विशाल legacy codebase में इसी तरीके से feature implement करना पूरी तरह nightmare बन गया

  • कसौटी यह है कि AI output को consume करना enjoyable है या नहीं। लेख, video, voice, restaurant menu, clothing photos, documents, airport control, ads—कुछ भी enjoyable नहीं है; LLM को बेहतर search engine या Q&A tool के रूप में valuable माना जा सकता है

    • बहुत से consumers quality की परवाह नहीं करते, जब तक वह minimum standard पूरा करके काम कर जाए। Appliances, software और fast food में भी यही हुआ था
      अगर AI आखिरकार उस standard को पूरा कर लेता है, तो generated output handmade चीजों पर dominate करेगा, और इंसानों द्वारा बनाए गए products और services शायद आज के handicrafts की तरह बहुत ज्यादा कीमत पर ही मिलेंगे
    • हो सकता है अच्छे AI outputs का हम पहले से ही, उन्हें पहचाने बिना, लगातार आनंद ले रहे हों। खराब one-off generated output किसी को पसंद नहीं आता
    • लोग हर महीने कुल मिलाकर अरबों डॉलर खर्च कर रहे हैं, यह देखकर कहा जा सकता है कि वे वास्तव में इसे पसंद करते हैं
    • AI output को सिर्फ raw material की तरह मानता हूं, mass customers को सीधे देने वाले finished product की तरह नहीं
    • समस्या AI होने में नहीं, बल्कि low quality में है। अगर output अच्छी तरह बना हो तो AI होना स्पष्ट होने पर भी लोग उसे पसंद करते हैं

  • दूसरी कंपनियों की vibe coding के नतीजों को साफ करके realistic systems में बदलने का काम बहुत बढ़ेगा। अलग-अलग projects की value भले कम हो जाए, संख्या बढ़ेगी, और बिना मदद के उनके ठीक से काम करने की संभावना कम होगी
    जिस company में software engineer नहीं है, वह Claude Code से अपने main business से बाहर का काम कर रही थी, लेकिन कहा कि वह चाहती है कि employee code से छेड़छाड़ करने के बजाय वही काम करे जिसके लिए उसे hire किया गया था
    Custom बनाना आसान होने से one-size-fits-all products बेचना मुश्किल होगा, लेकिन असली custom result deliver करने में अभी भी बहुत काम लगेगा। जिसने खुद build किया हो और उस domain का ज्ञान भी रखता हो, उसे दोगुना फायदा होगा
    लोगों को आम तौर पर पता नहीं होता कि उन्हें क्या चाहिए, इसलिए जरूरतों का पता लगाकर उन्हें उपलब्ध कराने वाली consulting की मूल प्रकृति वही रहेगी; software सस्ता होने से बस अधिक customers लिए जा सकेंगे

    • यह स्पष्ट नहीं है कि वह employee कौन है जिसे code नहीं छूना चाहिए

  • लेख का basic logic flawed है। Prototype बनाने के बाद अगर करने के लिए काम बचता है, तो वह काम भी जारी रखा जा सकता है। ऐसा लगता है कि यह AI use को चार-line prompt से एक बार में generate करने के बराबर मानता है, और fundamental insight से ज्यादा बिना आलोचना की self-justification जैसा दिखता है

    • यह मेरे उस अनुभव से बिल्कुल मेल खाता है जिसमें test coverage कम थी, requirements uncertain थीं और deployment तरीका non-standard था। happy path से बाहर जाते ही यह production को तोड़ देने वाली खराब assumptions करने लगता है, और सबसे smart models भी ऐसे environment के लिए suitable architecture तक नहीं पहुंचते

  • Engineering background न होने पर भी यह intuitively सही लगा, और card game बनाते समय कई बार अनुभव हुआ। शुरुआत में सब ठीक बना, लेकिन standard 52-card library लेने के कारण special event cards जोड़ना संभव नहीं था, और card objects पर आधारित flexible data model चाहिए था
    शुरू से बता दें तो शायद यह solve कर सकता है, लेकिन अगर software को disposable मानें और skilled engineer की तरह implementation पर गहराई से न सोचें, तो ऐसी requirement सूझती ही नहीं। AI-generated writing और code की समस्या यह है कि वे creation process में निहित सोच को छीन लेते हैं
    हालांकि हर software को scalability, speed और maintainability की जरूरत नहीं होती। करोड़ों users के infrastructure और apps को जरूरत है, लेकिन family meal planning app को Google के हजारों employees की allergy settings तक support करने की जरूरत नहीं
    AI software को घर के खाने जैसे tools में बदलने देता है। घर का खाना perfect cuisine होना जरूरी नहीं; परिवार का पेट भर दे और किसी के लिए मेहनत का gift बन जाए, इतना काफी है

  • अगर product सिर्फ एक request से बन जाता, तो outsourcing companies बहुत पहले product companies पर dominate कर चुकी होतीं। Product development का बड़ा हिस्सा शुरुआती prototype/MVP के बाद की iterations में होता है
    सिर्फ technology नहीं, problem को लंबे समय तक खंगालकर pain के root cause को समझना और user experience तथा technology दोनों तरफ से solve करना पड़ता है। पहले भी outsourcing company को product “prompt” किया जा सकता था, लेकिन customers से वर्षों बात करके expertise बनाने वाली product companies को पैसे देने की वजह यही थी

  • लेख के title को discussion बेहतर तरीके से summarize करने के लिए The Prototype Isn't the Product होना चाहिए। AI से “mostly works” enough वाले disposable prototypes और personal apps हैरान करने वाली तेजी से बनाए जा सकते हैं, लेकिन quality और maintenance अहम हों तो software engineering अभी भी कठिन और धीमी है
    चमकदार vibe coding demos बहुत हैं, लेकिन बड़े legacy codebase या रोजमर्रा के non-flashy professional work में AI कितना useful रहा, इस पर चर्चा कम है
    Vibe-coded 3D game prototype रुक जाए तो रविवार सुबह 6 बजे phone नहीं आता, लेकिन अभी update किए गए 24/7 operating system में bug आ जाए तो phone जरूर आएगा