AI युग के नए डेवलपर पैटर्न

• AI को सिर्फ एक साधारण टूल नहीं, बल्कि आधारभूत तकनीक के रूप में देखने वाली डेवलपमेंट संस्कृति बन रही है
• पारंपरिक version control, dashboard, template, documentation, और secret management जैसे तरीके AI युग के अनुरूप बदल रहे हैं
  • Git को अब code की line-by-line बदलाव ट्रैकिंग से आगे बढ़ाकर prompt और test result-केंद्रित state management के रूप में फिर से समझा जा रहा है
  • एजेंट अब code के लेखक भी हैं और उपभोक्ता भी, इसलिए टूल्स को खुद फिर से डिज़ाइन करने की ज़रूरत बढ़ रही है
  • Dashboard और UI natural language-आधारित interface में बदल रहे हैं, और ऐसे रूप में विकसित हो रहे हैं जिन्हें इंसान और AI agent साथ मिलकर इस्तेमाल करें
  • Documentation इंसानों और AI दोनों के लिए knowledge base में बदल रही है, और उसे agent द्वारा समझे जा सकने वाले format में फिर से व्यवस्थित किया जा रहा है

1. AI-Native Git: AI एजेंटों के लिए version management की पुनर्परिभाषा

• Git मूल रूप से इंसानों द्वारा सीधे लिखे गए code के line-level change history को ट्रैक करने के लिए डिज़ाइन किया गया था
  • लेकिन जब AI code का बड़ा हिस्सा अपने-आप generate और modify करता है, तब ऐसी सूक्ष्म ट्रैकिंग का महत्व कम हो जाता है
  • डेवलपर अब बदलाव की सूची से ज़्यादा अंतिम व्यवहार की उपयुक्तता पर ध्यान देते हैं, जैसे test pass हुआ या नहीं, सिस्टम सही चला या नहीं
  • SHA यह तो बताता है कि बदलाव हुआ, लेकिन उसमें बदलाव क्यों हुआ या वह बदलाव वैध है या नहीं जैसी जानकारी नहीं होती
  • खासकर बड़े बदलावों या auto-generated code के मामले में, डेवलपर अक्सर हर diff को अलग-अलग review नहीं करते
• AI-first workflow में नीचे दिए गए तत्वों का संयोजन अधिक उपयोगी unit बन जाता है
  • prompt: वह input जिसने code generation को निर्देशित किया
  • test: अपेक्षित व्यवहार की पुष्टि करने वाला test
  • spec और constraints जैसी डिज़ाइन आवश्यकताएँ
  • इन्हें एक versionable bundle मानकर manage और track किया जाता है
• इसे एक कदम आगे बढ़ाएँ तो Agent-Driven workflow में Source of Truth prompt, data schema, API contract, और architectural intent की ओर upstream खिसक सकता है
  • नतीजतन code को compiled artifact की तरह देखा जाएगा, यानी source नहीं बल्कि इन inputs का byproduct
  • Git तब code workspace नहीं, बल्कि artifact log की तरह काम करेगा
    • किसने, किस model का इस्तेमाल कर, किस prompt से code बनाया
    • कौन से test pass हुए
    • और किन हिस्सों की human review ज़रूरत है, जैसी metadata भी साथ रखी जाएगी
• Change history में prompt, उद्देश्य, संबंधित test, और इस्तेमाल किए गए model की जानकारी शामिल होगी
  • Diamond जैसे AI reviewer tools के साथ integration से automated review flow संभव होगा
  • agent-generated code और human-managed protected zones को अलग तरह से संभालने वाली संरचना सहित, और भी समृद्ध metadata को layer किया जा सकेगा
• AI-Native Git workflow की कल्पना करें तो
  • ऐसा नया Git dashboard उभर सकता है जिसमें prompt, उनसे जुड़े change flow, test results, सक्रिय agent की जानकारी, और bundle information एक साथ दिखाई दे

2. Dashboards → Synthesis: dynamic AI-आधारित interface की ओर विकास

• कई वर्षों तक dashboard ने observability systems, analytics tools, और cloud console (जैसे AWS) जैसे जटिल systems के साथ interaction के मुख्य interface की भूमिका निभाई है
  • लेकिन बहुत ज़्यादा controls, charts, tabs आदि के कारण UX overload पैदा हुआ, और information exploration व action के बीच users का भटक जाना आसान हो गया
  • खासकर non-experts या कई teams के collaboration वाले माहौल में, ऐसे dashboard को डराने वाले और अप्रभावी tools के रूप में देखा जा सकता है
  • users को अक्सर यह पता होता है कि वे क्या हासिल करना चाहते हैं, लेकिन कहाँ देखना है या कौन-सा filter लगाना है, यह नहीं पता होता
• नई पीढ़ी के AI models इस समस्या का समाधान देने की संभावना दिखाते हैं
  • वे dashboard को एक fixed canvas नहीं, बल्कि खोज और interaction के लिए एक space के रूप में फिर से परिभाषित कर सकते हैं
• LLM निम्न तरीकों से users की मदद कर सकता है:
  • “इस API की rate limit setting कहाँ बदलूँ?” जैसे control location discovery
  • “पिछले 24 घंटों में staging environment की सभी services में आए error trends का summary दो” जैसे integrated data summary
  • “मेरे business context के आधार पर इस quarter में किन metrics पर ध्यान देना चाहिए?” जैसे hidden insight suggestions
• अभी भी Assistant UI जैसी तकनीकें agents को React components को tool की तरह इस्तेमाल करने में सक्षम बनाती हैं
  • जैसे content dynamic और personalized हो गया है, वैसे ही UI खुद भी user intent के अनुसार reconfigure होकर conversational रूप में विकसित हो रहा है
  • static dashboard जल्द ही पुराने दौर की चीज़ माने जा सकते हैं
  • उदाहरण:
    • user कहे, “पिछले weekend Europe में हुई anomalies दिखाओ,” तो filter को manually छेड़े बिना summarized logs और trends अपने-आप मिल जाएँ
    • “पिछले हफ्ते NPS score क्यों गिरा?” जैसे सवाल पर AI survey sentiment analysis, product deployment correlation analysis, और diagnostic summary तक दे सके
• और व्यापक दृष्टि से देखें तो, अगर agent software के consumer बनते हैं, तो ‘dashboard’ की अवधारणा को भी फिर से डिज़ाइन करना होगा
  • उदाहरण के लिए, dashboard Agent Experience के लिए optimized view render कर सकता है
    • ऐसा structured और programmatically accessible interface दे सकता है जो system state को समझने, निर्णय लेने और action करने में मदद करे
  • नतीजतन human users के लिए UI और agents के लिए UI साथ मौजूद रहने वाली dual-interface structure बन सकती है
    • दोनों UI एक ही state share करेंगे, लेकिन consumption pattern के अनुसार उनकी रचना अलग होगी
• agent पारंपरिक alert, cron job, और condition-based automation की भूमिका को बदलते हुए, कहीं अधिक context और flexibility वाले executor बनेंगे
• उदाहरण:
  • पारंपरिक: if error rate > threshold then send alert
  • agent-आधारित: “error rate बढ़ रही है। इसका कारण यह service है, प्रभावित components ये हैं, और recommended actions निम्न हैं”
• इस तरह dashboard सिर्फ देखने की जगह नहीं रहेगा, बल्कि इंसानों और AI के सहयोग, synthesis, और action execution का space बनकर पुनर्परिभाषित होगा

3. दस्तावेज़ tool, index, और interactive knowledge base के संयोजन में विकसित हो रहे हैं

• डेवलपर्स के documentation उपयोग करने का तरीका बदल रहा है
  • पहले लोग table of contents के अनुसार पढ़ते थे या ऊपर से नीचे तक spec पढ़ते थे, लेकिन अब “पहले सवाल पूछने का तरीका” सामान्य हो गया है
  • “मुझे यह spec पढ़नी है” की जगह “जानकारी को मेरी ज़रूरत के हिसाब से फिर से व्यवस्थित करके दिखाओ” जैसी सोच उभर रही है
  • यह बदलाव documentation के रूप को भी प्रभावित कर रहा है, और वह static HTML या Markdown नहीं, बल्कि index, embedding, और tool-aware agent से समर्थित interactive knowledge system में बदल रही है
• इसी वजह से Mintlify जैसे tools सामने आ रहे हैं
  • Mintlify documentation को semantic search योग्य database के रूप में संगठित करता है, और साथ ही विभिन्न platforms पर agent के context source के रूप में इस्तेमाल होता है
    • उदाहरण: AI IDE, VS Code extension, terminal agent आदि में Mintlify docs real-time reference material के रूप में उपयोग की जाती हैं
  • इसकी वजह यह है कि code generation agent latest documentation को context के रूप में इस्तेमाल करते हैं
• इससे documentation के उद्देश्य में ही बदलाव आ रहा है
  • अब documentation सिर्फ human readers को जानकारी देने के लिए नहीं, बल्कि agent consumers के लिए structured रूप में डिज़ाइन की जानी चाहिए
  • इस नई dynamic में documentation AI agents के लिए usage guide की भूमिका निभाने लगती है
  • यह सिर्फ content exposure नहीं, बल्कि system का सही उपयोग कैसे किया जाए, इसे समझाने वाला format है

4. template से generation तक: create-react-app की जगह vibe coding

• पहले किसी प्रोजेक्ट की शुरुआत करने के लिए create-react-app, next init, rails new जैसे static templates चुनना आम बात थी
  • ऐसे templates एक consistent app structure देते थे, लेकिन developer की मंशा या stack के हिसाब से customize करना मुश्किल था, और framework के defaults का पालन करना पड़ता था
  • नतीजतन, default setup से बाहर निकलने के लिए काफ़ी manual refactoring करनी पड़ती थी
• अब यह प्रवाह Replit, Same.dev, Loveable, Chef by Convex, Bolt जैसे text-to-app platforms और Cursor जैसे AI IDE के आने से बदल रहा है
  • उदाहरण के लिए, developer अगर “Supabase, Clerk, Stripe के साथ TypeScript API server” जैसा विवरण दे, तो AI कुछ ही सेकंड में एक customized project अपने-आप configure कर देता है
  • तैयार हुआ starter कोई सामान्य template नहीं होता, बल्कि developer की मंशा और stack के लिए optimized structure में बनाया जाता है
• यह बदलाव ecosystem की distribution structure को भी बदल रहा है
  • पहले की तरह कुछ frameworks ecosystem के केंद्र में रहने के बजाय, विभिन्न tools और architectures के मेल से बने customized generation flows फैल रहे हैं
  • अब मूल बात framework चुनने से ज़्यादा यह बताना है कि ‘आप क्या बनाना चाहते हैं’
  • कोई developer Next.js और tRPC का combination चुने, और दूसरा Vite और React, तब भी दोनों के लिए तुरंत runnable project generate किया जा सकता है
• बेशक, standard stack के अपने फ़ायदे भी हैं:
  • team productivity में सुधार, onboarding efficiency, debugging में आसानी आदि
  • लेकिन frameworks के बीच refactoring सिर्फ़ तकनीकी समस्या नहीं है, बल्कि product, infrastructure और organizational capability से भी जुड़ी होती है
• असली turning point यह है कि framework बदलने की लागत कम हो गई है
  • AI agents अब project की मंशा समझकर large-scale refactoring को semi-automated तरीके से कर सकते हैं
  • इससे experiment करना आसान होता है, और शुरुआती चरण में अलग-अलग stacks आज़माने या वापस लौटने की गुंजाइश बनती है
• नतीजतन, framework का चुनाव reversible decision बनता जा रहा है
  • उदाहरण: Next.js से शुरुआत करके बाद में Remix + Vite पर जाना, और agent पूरा refactoring संभाल ले
• framework lock-in कम हो रहा है, और opinionated stack भी अब बिना झिझक आज़माए जा सकते हैं

5. .env से आगे: agent-केंद्रित environment में secret management

• कई दशकों तक .env files developers के लिए API keys, database URLs, service tokens जैसे secrets को लोकल में आसानी से manage करने का बुनियादी तरीका रही हैं
  • यह तरीका सरल, portable और developer-friendly है, लेकिन जब AI IDE या agents code लिखें, services deploy करें और environments coordinate करें, तब समस्याएँ पैदा होती हैं
  • यानी, यह स्पष्ट नहीं रह जाता कि .env file का मालिक वास्तव में कौन है
• इस समस्या को हल करने के लिए नए रुझान उभर रहे हैं
  • उदाहरण के लिए, नए MCP spec में OAuth 2.1 आधारित authentication framework शामिल है
  • यह structure संकेत देता है कि AI agents को raw secrets की जगह scope-based, revocable tokens दिए जाएँ
  • उदाहरण: agent को पूरी AWS key देने के बजाय, “S3 पर file upload” जैसी सीमित action की अनुमति देने वाला short-lived credential दिया जाए
• एक और रुझान है local secret brokers का उभरना
  • यह लोकल में या app के साथ-साथ चलने वाली ऐसी service होती है, जो agent और sensitive secrets के बीच मध्यस्थ का काम करती है
  • agent .env तक सीधे पहुँचने या secrets hardcode करने के बजाय, किसी विशेष task request पर broker real time में निर्णय लेकर अनुमति देता है
    • उदाहरण: “staging पर deploy करो” या “Sentry को logs भेजो” जैसी requests
    • broker इन्हें just-in-time तरीके से संभालता है, और हर access का audit trail रखा जा सकता है
• यह तरीका secret access को file system से हटाकर API-आधारित permission model में बदल देता है
  • नतीजतन, secret management .env configuration से आगे बढ़कर OAuth-आधारित access control structure में विकसित हो रहा है

6. accessibility को universal interface बनाना: LLM के नज़रिए से apps

• हाल के दिनों में Granola, Highlight जैसे apps macOS accessibility permissions माँगते हैं, लेकिन इसका उद्देश्य पारंपरिक disability support नहीं, बल्कि AI agents को UI देखने और उससे interact करने देना है
  • इसे अस्थायी hack नहीं, बल्कि एक ज़्यादा बुनियादी interface shift का संकेत माना जा सकता है
• accessibility APIs मूल रूप से visual या motor disabilities वाले users की digital accessibility सुधारने के लिए बनाई गई थीं
  • लेकिन इन्हीं APIs का विस्तार करके AI agents के लिए universal interface layer बनाया जा सकता है
  • pixel position पर click करने या DOM scraping करने के बजाय, assistive technologies की तरह apps को semantic तरीके से देखा और चलाया जा सकता है
  • accessibility tree पहले से ही buttons, headings, input fields जैसे structured UI elements expose करती है
  • इसमें intent, role, affordance जैसी metadata जोड़ दी जाए, तो agents उद्देश्य और context के हिसाब से कहीं अधिक सटीक control कर सकते हैं
• यह दिशा आगे चलकर इन capabilities तक फैल सकती है:
  • Context extraction: accessibility/semantic APIs के ज़रिए स्क्रीन पर दिख रहे elements, interactable items और user की मौजूदा activity को query करने का तरीका
  • Intentful execution: कई API calls को manually जोड़ने के बजाय, “cart में item जोड़ो और सबसे तेज़ delivery चुनो” जैसे high-level goals declare करना, और backend उनका execution flow तैयार करे
  • Fallback UI for LLMs: accessibility features ऐसे apps के लिए भी backup interface दे सकती हैं जिनके पास public API नहीं है, ताकि agents उन्हें उपयोग कर सकें
    • developers visual UI या DOM के अलावा, agent द्वारा पहचाने जा सकने वाले render surface को structured annotation या accessibility-centric components के रूप में define कर सकते हैं
• सार यह है कि accessibility APIs अब सिर्फ़ इंसानों के लिए नहीं, बल्कि AI और systems के बीच interaction की एक मुख्य interface layer बनती जा रही हैं

7. asynchronous agent tasks का उभार

• जैसे-जैसे डेवलपर्स code writing agents के साथ स्वाभाविक रूप से सहयोग करने लगे हैं, asynchronous workflow की ओर बदलाव तेज़ हो रहा है
  • एजेंट background में parallel काम करते हैं, और एक निश्चित स्तर तक पहुँचने पर परिणाम रिपोर्ट करते हैं
  • यह interaction धीरे-धीरे pair programming से ज़्यादा task orchestration के करीब होता जा रहा है
  • यानी, डेवलपर लक्ष्य बताता है, एजेंट उसे पूरा करता है, और बाद में उसकी जाँच की जाती है
• महत्वपूर्ण बात यह है कि यह सिर्फ काम का बोझ कम नहीं करता, बल्कि सहयोग को ही संक्षिप्त कर देता है
  • उदाहरण के लिए, किसी दूसरी टीम से config file update, error triage, या component refactoring का अनुरोध करने के बजाय,
    डेवलपर सीधे एजेंट को intent बताकर उसे background में process करने का निर्देश दे सकता है
  • पहले इसके लिए synchronous meetings, cross-functional handoff, और लंबे review cycle की ज़रूरत होती थी,
    अब request → generate → validate का loop स्वाभाविक रूप से बन रहा है
• एजेंट के साथ interaction करने के तरीके भी फैल रहे हैं
  • सिर्फ IDE या CLI में prompt डालने के अलावा, अब ये तरीके भी संभव हैं:
    • Slack message से काम का अनुरोध
    • Figma mockup पर comment लिखना
    • code diff या PR में inline comments जोड़ना (जैसे: Graphite review assistant)
    • deployed app preview पर feedback जोड़ना
    • voice या call-based interface के ज़रिए बदलावों को मौखिक रूप से समझाना
• यह बदलाव एजेंटों को पूरे development lifecycle में मौजूद बना रहा है
  • वे सिर्फ code writing तक सीमित नहीं हैं, बल्कि design interpretation, feedback incorporation, और पूरे platform में bug triage भी कर रहे हैं
  • डेवलपर orchestrator की भूमिका निभाता है, जो तय करता है कि कौन-से work thread चलाने, हटाने या merge करने हैं
• यह प्रवाह अंततः इस संभावना की ओर इशारा करता है कि agent-based work thread एक नए ‘Git branch’ कॉन्सेप्ट के रूप में स्थापित हो सकते हैं
  • अब यह static code fork नहीं, बल्कि purpose-driven dynamic threads होंगे, जो asynchronous रूप से चलते हैं और पूरा होने पर integrate हो जाते हैं

8. MCP: सार्वभौमिक मानक के और एक कदम करीब पहुँचा Model Context Protocol

• हाल ही में MCP पर एक गहन विश्लेषण लेख प्रकाशित होने के बाद, MCP adoption की रफ़्तार तेज़ हुई है
• OpenAI ने आधिकारिक रूप से MCP अपनाया है, कई नए features spec में merge किए गए हैं,
  और अधिक से अधिक tool makers MCP को agents और वास्तविक दुनिया के बीच के default interface के रूप में स्वीकार कर रहे हैं
• MCP मूल रूप से दो महत्वपूर्ण समस्याएँ हल करता है:
  • ज़रूरी context उपलब्ध कराता है ताकि LLM ऐसे काम भी कर सके जिनसे वह पहली बार सामना कर रहा हो
  • N×M तरह की custom integration को हटाकर, ऐसी संरचना देता है जिसमें tools standard interface (server) expose करते हैं और सभी agents (clients) उनका उपयोग कर सकते हैं
• आगे MCP adoption और बढ़ने की उम्मीद है,
  और अगर remote MCP तथा de-facto MCP registry उभरते हैं,
  तो कई apps डिफ़ॉल्ट रूप से MCP interface के साथ लॉन्च हो सकते हैं
• जैसे पहले API ने SaaS tools को जोड़ने और workflow बनाने में मदद की थी,
  वैसे ही MCP AI agents के लिए interoperable building blocks का ecosystem बना सकता है
• MCP client को embed करने वाले platforms सिर्फ “AI-enabled” नहीं रहेंगे,
  बल्कि agent-accessible capability network से सीधे जुड़ी ecosystem का हिस्सा बन जाएँगे
• MCP के client और server केवल logical concepts हैं, वे भौतिक रूप से अलग नहीं होते
  • इसका मतलब है कि कोई भी MCP client server बन सकता है, और इसका उलटा भी संभव है
  • इससे उच्च स्तर की composability खुलती है:
    • उदाहरण: कोई coding agent client के रूप में GitHub issues ला सकता है, और साथ ही server के रूप में दूसरे agents को test coverage या code analysis results दे सकता है
• MCP tools और agents के organic interaction वाले ecosystem के लिए मूल interface layer के रूप में स्थापित हो रहा है

9. Abstracted primitives: हर AI agent को चाहिए authentication, payments, storage

• जैसे-जैसे vibe coding agents अधिक शक्तिशाली होते जा रहे हैं, एक बात साफ़ हो रही है:
  agents बहुत सारा code बना सकते हैं, लेकिन उस code को जुड़ने के लिए एक भरोसेमंद foundation चाहिए
• जैसे human developers payments के लिए Stripe, authentication के लिए Clerk, और database के लिए Supabase पर निर्भर करते हैं,
  वैसे ही agents को भी भरोसेमंद और composable service primitives चाहिए
• ये services स्पष्ट API boundaries, उपयोग में आसान SDKs, और उचित default settings देती हैं,
  और धीरे-धीरे agent runtime interface की भूमिका निभाने लगती हैं
• उदाहरण के लिए, जब कोई SaaS app generate करने वाला tool बनाया जाता है, तो agent खुद authentication system या payment logic implement करने के बजाय,
  Clerk और Stripe का उपयोग करके तेज़ और सुरक्षित integration करता है
• जैसे-जैसे यह pattern mature होगा, services सिर्फ API देने से आगे बढ़कर यह भी expose कर सकती हैं:
  • schema: structured data definitions
  • capability metadata: किए जा सकने वाले कार्यों का specification
  • example flows: integration के तरीकों के उदाहरण
    → इससे agents अधिक स्थिर तरीके से integrate कर पाएँगे
• कुछ services तो built-in MCP server के साथ ही लॉन्च हो सकती हैं
  • उदाहरण: Clerk MCP server के ज़रिए उपलब्ध products की सूची देखना, नया pricing plan बनाना, subscription modify करना जैसी capabilities expose कर सकता है
  • agent API spec या documentation खोजने के बजाय natural language में अनुरोध करेगा,
    और MCP server permissions scope और constraints के भीतर अनुरोध को validate और process करेगा
  • उदाहरण:
    > “$49 प्रति माह का Pro plan बनाओ, और usage-based अतिरिक्त billing भी सेट कर दो”
    → Clerk का MCP server इस अनुरोध को समझकर execute करेगा
• जैसे शुरुआती web युग में rails new ने तेज़ development संभव बनाया था,
  वैसे ही agent युग में भरोसेमंद primitives (drop-in identity, payments, access control आदि) की ज़रूरत होगी
  • इन्हें इतना abstracted होना चाहिए कि agents इन्हें generation के लिए इस्तेमाल कर सकें,
  • और साथ ही app के बढ़ने के साथ scalable architecture भी देना चाहिए

निष्कर्ष

• ये 9 patterns सिर्फ मौजूदा development process पर AI चढ़ाने की बात नहीं करते, बल्कि यह दिखाते हैं कि agents, context, और intent के केंद्र में रखकर software creation का तरीका ही फिर से परिभाषित हो रहा है
• इसके साथ डेवलपर्स के पारंपरिक व्यवहार पैटर्न भी बदल रहे हैं, और इन्हें सहारा देने वाले नए toolchains और protocols (जैसे MCP) तेज़ी से उभर रहे हैं
• Git, templates, dashboards, documentation methods जैसे मौजूदा core tool layers AI के साथ मिलकर बुनियादी रूप से redesign हो रहे हैं
• इस संक्रमणकाल में, नए developer ecosystem को आकार देने वाले अगली पीढ़ी के tools और infrastructure के निर्माण और निवेश के तेज़ होने की उम्मीद है

[aa1567]

क्या सच में कोई ऐसा है जो नंबर 1 को वास्तव में करता है..?

[hhcrux]

LLM एक ही input के लिए एक जैसा output guarantee नहीं करता, तो क्या इस तरह का configuration management सच में काम करता है...
क्या मैं अभी भी इसे बहुत ही एक-आयामी तरीके से इस्तेमाल कर रहा हूँ

[beoks]

मेरी समझ के अनुसार, temperature विकल्प को 0 पर सेट करने से एक ही इनपुट के लिए एक ही आउटपुट की गारंटी मिलती है।

[fanotify]

वैसे भी कुछ महीनों बाद मॉडल खुद ही फिर बदल जाएगा, तो क्या यह बेकार नहीं हो जाएगा?

[beoks]

इसे एक तरफ भी रख दें, तो यह मान लेना ही बहुत ज़्यादा निर्णायक लगता है कि मानवीय हस्तक्षेप को बिल्कुल भी ध्यान में नहीं रखा जाएगा,
सरल संख्याएँ या संदेश बदलने जैसे मामलों में LLM की तुलना में इंसान का हस्तक्षेप ज़्यादा कुशल हो सकता है।

[nicewook]

यह गहरी अंतर्दृष्टि से भरा लेख है। वाकई, a16z कमाल है।

[ruinnel]

https://hi.news.hada.io/topic?id=21091
इसे यह लेख पढ़ने के बाद पढ़ा, तो लगा कि क्या सच में यही सही है।

[ahwjdekf]

नंबर 1 तो सचमुच किसी दुःस्वप्न जैसा है, ऐसा बदलाव जिसे मैं बिल्कुल स्वीकार नहीं करना चाहता। source code history tracking का बेमानी हो जाना।