OpenAI पर एक पुनरावलोकन

 (calv.info)
27 पॉइंट द्वारा GN⁺ 2025-07-16 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • लेखक ने मई 2024 में जॉइन करने के बाद लगभग 1 साल OpenAI में काम किया और फिर इस्तीफा दिया, और आंतरिक संस्कृति व वास्तविक कामकाजी माहौल के बारे में ईमानदारी से लिखा है
  • अत्यंत तेज़ वृद्धि (1,000→3,000 लोग) के बीच आंतरिक प्रक्रियाएँ, संगठन, संस्कृति और काम करने के तरीके तेज़ी से बदल रहे हैं
  • बॉटम-अप/मेरिटोक्रेसी संस्कृति, Slack-केंद्रित अनोखा सहयोग, ऊँची execution क्षमता, नेतृत्व की स्पष्ट मौजूदगी और तेज़ दिशा-परिवर्तन, तथा 'कोड ही जवाब है' वाला रवैया संगठन में गहराई तक समाया हुआ है
  • टीम-स्तरीय संस्कृति, काम की गति और संगठनात्मक लचीलापन बहुत मजबूत हैं; शोधकर्ताओं को 'मिनी मैनेजर' जैसी स्वायत्तता मिलती है, और समानांतर प्रोजेक्ट व आंतरिक आइडिया-प्रयोग अक्सर होते रहते हैं
  • OpenAI को बाहरी निगाह और मीडिया की गहन निगरानी, वास्तविक सुरक्षा/गोपनीयता, और AGI/consumer service को लेकर मिशन-भावना व तनाव—इन सबको साथ लेकर चलने वाला महत्वाकांक्षी और गंभीर संगठन बताया गया है

परिचय और व्यक्तिगत पृष्ठभूमि

  • मई 2024 में जॉइन किया था और हाल ही में OpenAI छोड़ा है
  • इस लेख के माध्यम से OpenAI में महसूस की गई वास्तविक संस्कृति और अपना निजी दृष्टिकोण साझा करना चाहता/चाहती हूँ
  • इसमें कोई आंतरिक गोपनीय जानकारी नहीं है; बल्कि ऐतिहासिक रूप से रोचक एक संगठन की वर्तमान झलक और एक कर्मचारी के छोटे-से दृष्टिकोण से देखे गए अनुभव शामिल हैं
  • नौकरी छोड़ने के फैसले में व्यक्तिगत द्वंद्व था, लेकिन startup founder से बड़े संगठन के कर्मचारी में बदलाव के साथ आने वाली नई ताजगी की चाह भी थी
  • AGI बनाने की प्रक्रिया में शामिल होने का अनुभव और Codex लॉन्च में सीधे योगदान देना बेहद अर्थपूर्ण रहा

संगठन संस्कृति

  • जॉइन करते समय कंपनी में 1,000 लोग थे, और 1 साल बाद 3,000 पार हो गए—यह असामान्य रूप से तेज़ वृद्धि का अनुभव था
  • तेज़ विस्तार के कारण communication, reporting structure, product launch, और organizational management में तरह-तरह की समस्याएँ पैदा हुईं
  • लगभग पूरा communication और काम Slack-केंद्रित है, email लगभग इस्तेमाल नहीं होता
  • हर टीम की संस्कृति और गति अलग है; research, application, GTM(Go-To-Market) आदि की समय-धारा भी अलग चलती है
  • वास्तविक बॉटम-अप और meritocracy बहुत मजबूत है; researcher और developer व्यक्ति-स्तर पर प्रयोग और निर्णय को आगे बढ़ाते हैं
  • performance-आधारित, skill-first संगठन संस्कृति में राजनीतिक क्षमता से अधिक execution और ideas मायने रखते हैं
  • किसी औपचारिक roadmap के बिना, अच्छे ideas के इर्द-गिर्द टीमें स्वाभाविक रूप से बनती हैं और तेज़ी से दिशा बदलती हैं
  • नेतृत्व execution (doing the right thing) और बदलाव के प्रति agility को महत्व देता है
  • आंतरिक रूप से duplicate development और parallel experiments बहुत होते हैं; कई prototypes स्वाभाविक रूप से बनते रहते हैं, और यह सचमुच 'कोड से चलने वाला संगठन' है
  • नेता political skill से अधिक वास्तविक idea execution क्षमता को महत्व देते हैं
  • शोधकर्ता "मिनी management" की तरह अपने-अपने स्तर पर सक्रिय होकर समस्याएँ सुलझाने में डूबे रहते हैं
  • कुशल research managers और PMs का प्रभाव बहुत बड़ा है
  • ChatGPT के EMs बेहद भरोसेमंद बताए गए हैं, जो अच्छे लोगों को hire करके उन्हें autonomy देते हैं
  • दिशा बदलने की गति बहुत तेज़ है, और निर्णय के तुरंत बाद अमल शुरू हो जाता है

काम करने का तरीका और माहौल

  • Slack channels और permission structure जटिल हैं, और सारा communication Slack पर ही होता है
  • research team/PM/EM(Engineering Manager) जैसी भूमिकाएँ अपने-अपने तरीके से काम करती हैं, और टीमों के बीच आना-जाना तथा सहयोग बहुत लचीला है
  • बाहरी security और media exposure को लेकर बहुत संवेदनशीलता है, इसलिए performance/revenue जैसी आंतरिक जानकारी बहुत सख्ती से नियंत्रित की जाती है
  • वास्तविक सदस्य 'सही काम' करने की प्रेरणा से काम करते हैं, और वे उतने cynical नहीं हैं जितना बाहर से लोग सोचते हैं
  • OpenAI को कई subcultures के मिश्रण वाले 'Los Alamos (परमाणु अनुसंधान प्रयोगशाला) + विशाल consumer service' प्रकार के संगठन के रूप में तुलना की गई है
  • AI के लाभों को व्यापक रूप से वितरित करना महत्वपूर्ण माना जाता है; cutting-edge models को सिर्फ enterprise तक सीमित नहीं रखा जाता, बल्कि API/ChatGPT के ज़रिए आम लोगों के लिए भी उपलब्ध कराया जाता है

सुरक्षा और आंतरिक नीतियाँ

  • AI safety मुद्दों पर वास्तव में अंदर काफी लोग और संसाधन लगाए गए हैं
  • व्यवहार में hate speech, misuse, political bias, prompt injection, self-harm जैसी वास्तविक जोखिमों पर अधिक काम होता है
  • सैद्धांतिक जोखिम (जैसे intelligence explosion, power-seeking) पर कुछ लोग समर्पित रूप से काम करते हैं, लेकिन यह मुख्यधारा नहीं है
  • safety से जुड़ा शोध और सिस्टम का बड़ा हिस्सा बाहर सार्वजनिक नहीं किया जाता

डेवलपमेंट वातावरण और तकनीक

  • विशाल mono-repo और Python-केंद्रित stack, साथ में कुछ Rust/Golang; style guide लगभग enforce नहीं होती
    • Google से आए अनुभवी लोगों द्वारा डिज़ाइन किए गए बड़े सिस्टम और नए PhD द्वारा लिखे गए Jupyter notebook—दोनों साथ मौजूद हैं
    • FastAPI-केंद्रित API और Pydantic data validation का उपयोग विशेष रूप से नज़र आता है
  • पूरा infrastructure Azure पर चलता है
    • भरोसेमंद services काफ़ी सीमित हैं, जैसे Azure Kubernetes Service, CosmosDB, BlobStore
    • IAM स्तर और कुछ services, AWS की तुलना में कमजोर मानी गईं, इसलिए in-house development की प्रवृत्ति है
  • Meta(पूर्व Facebook) से आए इंजीनियरों की बड़ी आमद
    • infrastructure sensibility और codebase का माहौल शुरुआती Meta/Instagram जैसा लगता है
    • उदाहरण: TAO का पुनर्निर्माण, auth system integration जैसी in-house system development आम है
  • duplicate code, tools/queue management library, बड़े backend monolith का प्रबंधन जैसी तेज़ी से बढ़ते संगठन की स्थायी समस्याएँ महसूस होती हैं; CI की speed/stability से जुड़ी दिक्कतें भी हैं
  • chat messages और conversation structure कोड के कई हिस्सों में गहराई से समाए हुए हैं, और अलग-अलग products में बार-बार उपयोग होते हैं
  • 'Code wins': किसी केंद्रीय planning committee के बिना, जो टीम वास्तव में काम करके code shipping करती है, वही standard बनाती है
    • निर्णय का अधिकार उसी टीम के पास होता है जो वह काम सीधे करती है, यानी code-आधारित skill और execution को बढ़त मिलती है

consumer brand और business दृष्टिकोण

  • Consumer brand का विशाल पैमाना: मुख्य metrics टीम-स्तर पर नहीं, बल्कि individual user subscription के आधार पर चलाए जाते हैं
    • product growth और traffic को 'Pro subscribers की संख्या' जैसे consumer metrics से मापा जाता है, जो B2B पृष्ठभूमि वाले लेखक के लिए एक नया अनुभव था
  • model training और experiments छोटे स्तर से शुरू होकर, सफल होने पर बड़े distributed systems engineering तक फैलते हैं
  • GPU cost का हिस्सा बहुत भारी है; छोटी-सी feature के लिए भी विशाल GPU resources चाहिए होते हैं
    • GPU usage estimation और benchmarking: ज़रूरी latency/token count जैसे user experience मानकों से उल्टी गणना की जाती है
  • बड़े Python codebase को चलाने का व्यावहारिक कौशल: जैसे-जैसे developers बढ़ते हैं, basic functioning, testing, और misuse prevention के लिए तरह-तरह के guardrails चाहिए होते हैं

टीम संचालन और नेतृत्व

  • नेतृत्व बहुत visible और hands-on है, और सभी executives Slack पर अक्सर चर्चाओं में शामिल होते हैं
  • टीम mobility और collaboration बहुत तेज़ है; दूसरी टीम के अनुरोध पर भी तुरंत मदद के लिए लोग लगा दिए जाते हैं, बिना इंतज़ार या औपचारिक प्रक्रिया के
  • कंपनी swag भी बहुत कम है, और भीतर सीमित बिक्री के रूप में ही दिया जाता है

Codex लॉन्च का अनुभव

  • पिछले 3 महीनों में Codex लॉन्च करियर का बड़ा हाइलाइट रहा
  • नवंबर 2024 में 2025 के भीतर coding agent लॉन्च करने का लक्ष्य तय हुआ, और फरवरी 2025 तक आंतरिक टूल तैयार होने लगे; साथ ही बाज़ार प्रतिस्पर्धा की गति का दबाव भी महसूस हुआ
  • Codex लॉन्च के लिए टीमों को मिलाकर सिर्फ 7 हफ्तों में एक पूर्ण coding agent बनाकर लॉन्च किया गया, यानी बहुत कम समय में प्रभावशाली product तैयार कर दिया गया
    • वास्तव में देर रात तक काम, weekend work, और नवजात बच्चे की देखभाल के साथ YC जैसे दिनों की याद लौट आई
    • container runtime, repo optimization, custom model fine-tuning, git integration, internet access जैसी कई सुविधाएँ तेज़ी से जोड़ी गईं
    • टीम में 8 senior engineers, 4 researchers, 2 designers, 2 GTM, 1 PM—यानी वरिष्ठ लोगों की छोटी लेकिन बेहद सक्षम टीम थी
  • लॉन्च से एक दिन पहले, खुद deployment जैसे अंतिम कामों पर फोकस किया गया
  • लॉन्च के दिन traffic का विस्फोट हुआ, और सिर्फ ChatGPT sidebar में दिखने भर से ही तुरंत बड़े पैमाने पर उपयोगकर्ता आ गए
  • Codex ने asynchronous agent मॉडल अपनाया (user-agent messages → work → PR results return)
    • यह एक स्वतंत्र execution environment में user request को संभालकर collaborator की तरह PR result लौटाता है
    • अभी भी model performance को लेकर भरोसा और सीमाएँ—दोनों साथ मौजूद हैं
    • multi-task execution और बड़े codebase को समझने की क्षमता में Codex की अलग पहचान है
  • लॉन्च के 53 दिनों के भीतर 630,000 PR बनाए गए, यानी प्रति engineer 78,000 से अधिक PR के बराबर जबरदस्त impact पैदा हुआ

निष्कर्ष और सीख

  • बड़े संगठन में काम करने को लेकर डर था, लेकिन पीछे मुड़कर देखें तो यह सबसे अच्छे फैसलों में से एक निकला और सीखने-विकास का बड़ा अवसर बना
  • जिन लक्ष्यों की उम्मीद थी—model training की समझ, बेहतरीन साथियों के साथ काम, और प्रभावशाली product launch—वे सब हासिल हुए
  • बड़े Python codebase को संभालने का अनुभव, और वास्तविक GPU benchmarking/capacity estimation जैसी चीज़ें सीधे सीखने को मिलीं
  • अगर आप startup founder हैं या करियर को लेकर सोच रहे हैं, तो और अधिक आक्रामक रूप से चुनौती लेने या किसी बड़े research lab से जुड़ने पर विचार करने का यह अच्छा समय हो सकता है
  • AGI की दौड़ में तीन बड़े घोड़े—OpenAI, Anthropic, Google—अलग-अलग तरीके अपना रहे हैं, और इनमें से किसी एक जगह काम करने का अनुभव दृष्टि को व्यापक बना सकता है
  • OpenAI का अनुभव, एक founder और engineer—दोनों रूपों में, जीवन के सबसे अच्छे चुनावों में से एक माना गया है

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

2 टिप्पणियां

 
brainer 2025-07-17

https://hi.news.hada.io/topic?id=21081 यह लेख याद रह गया है।
 
GN⁺ 2025-07-16
Hacker News राय

  • ऐसा कम ही होता है कि कोई पूर्व कर्मचारी अपने काम के अनुभव को सकारात्मक रूप में बताए। यह OpenAI के खास होने से ज़्यादा इस बात को दिखाता है कि ज़्यादातर ‘मैंने कंपनी क्यों छोड़ी’ पोस्ट असल में इस प्रवृत्ति को दर्शाती हैं कि व्यक्ति संगठन के साथ अपनी असंगति का दोष संगठन पर डालना चाहता है। इस लेख में ‘यक़ीन से परे bottom-up तरीका’ जैसी अभिव्यक्ति के पीछे यह भी हो सकता है कि कोई स्पष्ट roadmap नहीं है और किसी के पास अपने स्वामित्व वाला प्रोजेक्ट नहीं, जिससे कुछ लोग दिशाहीन हो जाते हों। इसी तरह ‘action orientation’ और ‘तुरंत direction change’ का मतलब अव्यवस्थित माहौल और असंगत executive leadership भी हो सकता है। और “OpenAI में सचमुच बहुत से नेक लोग हैं” जैसी बात अक्सर उन कंपनियों पर लागू होती है जो नैतिक रूप से जटिल फैसले लेती हैं। हर कोई खुद को अच्छा इंसान मानता है और बड़े लक्ष्य व औचित्य के सहारे अपने काम को सही ठहराता है।

    • मैं कभी भी सार्वजनिक जगह पर अपने employer की आलोचना नहीं करता। इससे मेरे करियर को नुकसान ही हो सकता है। खासकर Altman के बारे में बदले की भावना रखने की अफवाहें भी हैं, इसलिए OpenAI के मामले में दोगुनी सावधानी चाहिए। इस पोस्ट में तो यह भी कहा गया है कि OpenAI social media तक मॉनिटर करता है। यह पूर्व कर्मचारी भी शायद अपने 14 महीने के छोटे से कार्यकाल को सकारात्मक ढंग से पेश करके अपनी reputation संभालना चाहता है, और लगता है कि ऐसा रवैया भविष्य के employers को भी प्रभावित करता है।
    • किसी ने कहा था, "कंपनी में कोई खलनायक नहीं होता। बस अच्छे लोग खुद को तर्क देकर सही ठहराते हैं।" लेकिन मैं पहले casino software कंपनी में काम कर चुका हूँ, और वहाँ management में सचमुच खुलेआम खलनायक जैसे लोग थे।
    • OpenAI में नौकरी छोड़ने के बाद नकारात्मक रूप से बोलने पर पहले से दिए गए equity तक छिन सकते हैं, इसलिए सकारात्मक अनुभव साझा करना कहीं ज़्यादा आम होना स्वाभाविक है।
    • मेरी नज़र में Altman एक तरफ जनता को यह विश्वास दिलाने पर केंद्रित था कि AGI जल्द आने वाला है, और दूसरी तरफ OpenAI को एक मजबूत product company बनाने में बहुत मेहनत कर रहा था। और लगता है कि वह इसमें सफल भी रहा। कंपनी के भीतर गर्व और प्रतिस्पर्धा बहुत होगी, इसलिए संभव है कि यह पूर्व कर्मचारी कुछ राजनीतिक लड़ाइयों में हार गया हो, या उसका Codex prototype अपनाया न गया हो और उसे उससे ठेस पहुँची हो। या फिर शायद वह पहले ही पर्याप्त पैसा और जीवन अनुभव हासिल कर चुका था, इसलिए युवा प्रतिभाओं से आगे प्रतिस्पर्धा करते रहने की प्रेरणा नहीं बची।
    • ऐसा नहीं है कि पूर्व कर्मचारी हमेशा अपने अनुभव को नकारात्मक रूप में ही बताते हैं; कई बार वे उसे जरूरत से ज़्यादा सकारात्मक रूप में पेश करते हैं। जिस कंपनी में मैं था, वहाँ एक तानाशाही CEO के अधीन माहौल बेहद toxic हो गया था और बहुत लोगों ने कष्ट झेला, फिर भी भविष्य की नौकरी के लिए उन्होंने blog या LinkedIn पर प्रशंसात्मक पोस्ट लिखीं। HN पर चर्चा में आने वाली पोस्ट अक्सर उन कर्मचारियों की लगती हैं जिन्हें कंपनी से लगाव था और जो कंपनी या विभाग के पतन पर अफसोस जताते हुए लिखते हैं।

  • इस लेख में प्रभावशाली बातें ये थीं

    • प्रगति iterative है, और वहाँ bottom-up तथा merit-based culture है। management के ‘master plan’ से नहीं, बल्कि किसी की भी idea वास्तविकता बन सकती है, और ठोस execution व ideas के आधार पर leader प्रमोट होते हैं।
    • team members बिना अनुमति लिए भी पहल करके projects शुरू कर सकते हैं, इसलिए कई parallel projects स्वाभाविक रूप से बनते हैं और जिनमें सफलता की संभावना दिखती है, उन पर resources केंद्रित हो जाते हैं।
    • OpenAI के लोग इस मजबूत भावना के साथ काम करते हैं कि वे नेक इरादे से काम कर रहे हैं, और बाहरी आलोचना के बावजूद वे गंभीर जिम्मेदारी के साथ सही काम करने की कोशिश करते हैं।
    • कंपनी के products पर जनभावना का बड़ा असर पड़ता है, और वास्तव में लगता है कि कंपनी ‘Twitter के माहौल’ के अनुसार चलती है।
    • GPU लागत इतनी भारी है कि बाकी infrastructure लागत लगभग महत्वहीन लगती है। computing power सुनिश्चित करना वित्त और तकनीक दोनों की सर्वोच्च प्राथमिकता है।
    • AGI तक पहुँचने की दौड़ को OpenAI (consumer product DNA), Anthropic (enterprise DNA), और Google (infrastructure/Data DNA) के त्रिकोणीय मुकाबले के रूप में समझाया गया, यह दिलचस्प था।
    • Meta भी consumer-centric DNA वाला एक अहम प्रतिद्वंद्वी है। उपभोक्ताओं को सचमुच ‘product’ में बदलने में उसकी प्रतिनिधि भूमिका रही है।

  • Codex development marathon को पिछले 10 सालों का सबसे कठिन काम बताया गया, यह हिस्सा खास तौर पर ध्यान खींचता है। ज़्यादातर दिन रात 11 बजे से आधी रात तक काम, सुबह 5:30 बजे शिशु की देखभाल, और 7 बजे दफ्तर निकलना—ऐसी दिनचर्या थी। कुछ हफ्तों से कुछ महीनों में बड़े प्रोजेक्ट पूरे कर देने वाले इस कसे हुए उद्योग माहौल में सवाल उठता है कि क्या यह work style कर्मचारियों के लिए लंबे समय तक टिकाऊ हो सकती है।

    • अगर कोई मुझसे उस तरह के मोड में काम करने को मजबूर करे तो मैं साफ़ मना कर दूँगा, लेकिन अगर कोई प्रोजेक्ट मुझे सच में बहुत रोचक और महत्वपूर्ण लगे, तो कुछ हफ्तों या महीनों तक पूरी तरह झोंक देना मुझे ठीक लगेगा। मैं पहले से योजना भी बनाऊँगा, क्योंकि ऐसे प्रोजेक्ट के बाद पूरी ऊर्जा खत्म हो जाने का पता होता है। मेरे जैसे culture वाली community से भी लगातार motivation मिलता है।
    • जो व्यक्ति पहले से आर्थिक रूप से सुरक्षित है, उसने नवजात की देखभाल करने के बजाय 16–17 घंटे, हफ्ते के सातों दिन काम करना चुना—यह काफ़ी बड़ी बात है। अपने married partner से “बच्चे की देखभाल संभालने के लिए धन्यवाद” कहना बहुत कुछ बता देता है।
    • इस तरह का काम करने का तरीका बिल्कुल sustainable नहीं है। लेकिन अगर करियर में कभी-कभार ही ऐसा हो, तो इसे आज़माया जा सकता है, और मैं ऐसे लोगों को भी जानता हूँ जिन्हें इससे उलटे ऊर्जा मिली।
    • मैं अपने spouse पर बच्चे की देखभाल का पूरा बोझ डालने की कल्पना भी नहीं कर सकता। OP की पत्नी वाकई कमाल की हैं, और अंत में इसका ज़िक्र करना अच्छा था, लेकिन सच कहूँ तो हैरानी भी हुई।
    • लेखक ने 14 महीने में OpenAI छोड़ दिया, इससे लगता है कि ऐसा work pattern शायद burnout में बदला।

  • मुझे सच में यह जानने की उत्सुकता थी कि क्या OpenAI या दूसरी AI labs अपने आंतरिक संचालन में वास्तव में LLM को आधारभूत स्तर पर सक्रिय रूप से इस्तेमाल करती हैं—जैसे code development, internal model customization, ताज़ा जानकारी व्यवस्थित करना आदि व्यावहारिक कामों में क्या वे सचमुच पैसा और क्षमता लगा रही हैं। अफसोस कि लेख में इसका ज़िक्र नहीं था।

  • इंजीनियरों को यह महसूस करा देना कि वे ‘ईश्वर’ बना रहे हैं, शायद सर्वोच्च स्तर की marketing strategy है। मैं खुद नहीं मानता कि यह सच है, लेकिन इस विचार की संरचना ऐसी है कि इसकी आलोचना लगभग असर नहीं करती। “अगर यह सच हुआ तो?”—इस सवाल से किसी भी आपत्ति का जवाब दिया जा सकता है, और संभावित लाभ अनंत होने के कारण बहुत छोटी संभावना को भी नज़रअंदाज़ नहीं किया जा सकता। 0.00001% संभावना भी अगर अनंत reward से गुणा हो, तो expected value अनंत बनती है—कमाल की marketing है।

    • “लेकिन कहीं यह सच में सही हुआ तो?” यह सवाल LLM बनाने वाली कंपनियों की narrative का हिस्सा बनकर एक रहस्यमय तत्व जोड़ता है।

  • मैं सबसे ज़्यादा यह जानना चाहता था कि OpenAI के भीतर LLM का वास्तविक product building में कितना और किस तरह इस्तेमाल हो रहा है।

    • 53 दिनों में प्रति engineer 78,000 public pull request होने वाली बात तो लगभग मज़ाक जैसी लगी—मानो 99.99% चीज़ें LLM ने लिखी हों। लेख में workflow के बारे में जितनी जानकारी सार्वजनिक की गई, वह चौंकाने वाली थी; आम तौर पर क्या ऐसी बातें गोपनीय नहीं रखी जानी चाहिए? वैसे, 78,000 PR वाला आँकड़ा Codex engineers का नहीं, बल्कि कुल users के आधार पर था।

  • इतनी तेज़ी से बढ़ी कंपनी होने के बावजूद OpenAI में technical writers की कमी अब भी चौंकाती है। वहाँ बस इतना कहा जाता है कि documentation बेहतर हो सकती है, लेकिन Anthropic के documentation स्तर से तुलना करें तो OpenAI में साथी tech writers मिलना मुश्किल लगता है। अच्छे developer tools बनाने के लिए बेहतरीन documentation अनिवार्य है, और इसे संभालने व विकसित करने के लिए समर्पित टीम जरूरी है।

    • समस्या यह है कि management documentation की value महसूस नहीं करता। पहले DigitalOcean में industry-leading technical documentation team थी, लेकिन layoffs के दौरान सबसे पहले वही काटी गई। लगता है इसे सिर्फ लागत के रूप में देखा जाता है।

  • इस लेख में सचमुच बहुत-सी ऐसी रोचक जानकारियाँ थीं जो मैंने पहली बार सुनीं। समय निकालकर पढ़ने लायक है।

  • लेखक की इस राय पर कि “safety को अपेक्षा से अधिक महत्व दिया जाता है”, यह ध्यान में रखते हुए कि OpenAI की कई safety team leaders ने इस्तीफ़ा दिया या निकाल दिए गए, Superalignment project विफल रहा, और अन्य कर्मचारियों ने safety issues को समर्थन की कमी के साथ जोड़ा, यह कथन वास्तविकता से कटा हुआ या जानबूझकर भ्रामक लगता है।

  • “ज़्यादातर research की शुरुआत तब होती है जब researcher किसी खास समस्या से गहराई से मोहित हो जाता है”—यह बात दिलचस्प लगी। अगर यह आकलन सही है, तो यह कंपनी की Achilles’ heel बन सकती है।

    • लेकिन यह किसी एक कंपनी की समस्या नहीं, बल्कि इंसानी स्वभाव का मूल पहलू है। शीर्ष स्तर के researchers में अक्सर वह प्रवृत्ति होती है कि वे जिस क्षेत्र से सचमुच प्रेम करते हैं, उस पर बेहिसाब समय ख़ुशी से लगा देते हैं।