Seeing AGI (8): इंसानी भूमिका का नया जन्म
मैं हाल ही में San Francisco में Delight Spark में गया था, और वहाँ हुई एक बातचीत इवेंट खत्म होने के बाद भी मेरे ज़हन में रही। बात AI organizations की थी।
अपने पिछले सात Seeing AGI लेखों में मैंने AGI के आगमन, vibe working, और multi-agent systems पर लिखा है। लेकिन एक सवाल जो बार-बार लौट आता है वो ज़्यादा सीधा है: कंपनी के अंदर इंसान की भूमिका का क्या होगा? AI org chart को नए सिरे से लिखने से पहले, वह इंसान को नए सिरे से लिखता है।
बहुत-सी कंपनियाँ अब भी AI को उन्हीं लोगों के लिए, उन्हीं नौकरियों के लिए एक software upgrade की तरह देखती हैं। यह नज़रिया ही गलत है। AI सिर्फ़ काम को तेज़ नहीं कर रहा। यह बदल रहा है कि कौन क्या करता है, context का मालिक कौन है, और judgment किस तरह से हाथ बदलता है।
हर technology wave इंसान की भूमिका बदलती है
जब लोगों के सामने कोई breakthrough technology आती है, तो वे आम तौर पर मान लेते हैं कि उनकी नौकरी बिल्कुल वैसी ही रहेगी, बस तेज़ हो जाएगी। इतिहास हमें दिखाता है कि यह एक भ्रम है।
कागज़ पर बना org chart आम तौर पर सबसे पहले नहीं बदलता। सबसे पहले बदलता है यह कि इंसान दिनभर क्या करते हैं, किस पर निर्भर हैं, किसको रिपोर्ट करते हैं, और system असल में किस तरह की judgment को इनाम देता है।
तो अगर हमें AI को सही ढंग से समझना है, तो सिर्फ़ यह नहीं पूछना चाहिए कि models क्या कर सकते हैं। यह भी पूछना चाहिए कि पिछली technology waves ने काम के स्वरूप के साथ क्या किया।
बिजली ने सिर्फ़ factory को आधुनिक नहीं बनाया। उसने अंदर के लोगों को भी बदल दिया।
Electrification से जुड़ा मशहूर सबक सिर्फ़ यह नहीं है कि बिजली ताकतवर थी। बात यह है कि adoption की पहली लहर अपेक्षाओं पर खरी नहीं उतरी क्योंकि factories ने पुराना layout वैसे का वैसे रखा। मालिकों ने steam engines की जगह dynamos लगा दिए, लेकिन वही केंद्रीकृत power logic, वही line shafts, वही belts, और वही production geometry बनी रही।
असली छलाँग बाद में आई, जब factories ने unit drive अपनाया — हर मशीन के स्तर पर अलग electric motors। उस मोड़ पर पूरी इमारत ही बदल सकती थी। Single-story layouts आसान हो गए। मशीनों को अब किसी एक mechanical spine के इर्द-गिर्द जमाने की मजबूरी नहीं रही। Workflow को speed, safety और specialization के हिसाब से नए सिरे से डिज़ाइन किया जा सकता था।
और जैसे ही factory बदली, उसके साथ इंसानी भूमिकाएँ भी बदल गईं। केंद्रीय engine rooms, shaft-driven layouts, और एकल power source के इर्द-गिर्द बनी maintenance — इन सबकी पुरानी logic धीरे-धीरे फीकी पड़ने लगी। उसकी जगह electricians, electrical engineers, factory planners, और एक नए तरह के operations management की ज़रूरत खड़ी हो गई। Paul David ने लिखा था कि बड़े पैमाने के electrification के लिए "अनुभवी factory architects और electrical engineers का एक cadre" खड़ा करना पड़ा था। बात ठीक यही है। नया power source सिर्फ़ पुराने workers को तेज़ नहीं बनाता। वह नए specialists, नए reporting relationships, और नई operating logic को जन्म देता है।
Computers ने सिर्फ़ offices को automate नहीं किया। उन्होंने एकदम नई information roles खड़ी कर दीं।
Computer युग ने कुछ ऐसा ही किया। Computerization से पहले, बड़ी संस्थाएँ clerks, typists, filing staff, bookkeepers, और machine operators की कई परतों के सहारे information को हाथ से इधर-उधर पहुँचाती थीं। फिर आए data-processing departments, keypunch operators, programmers, systems analysts, और बाद में database administrators और IT managers।
कुछ भूमिकाएँ सिकुड़ गईं। कुछ कहीं से नहीं प्रकट हो गईं। Punch card युग में keypunch operator एक पहचानने लायक पेशा बना और फिर direct computing फैलने के साथ धीरे-धीरे लुप्त हो गया। ठीक उसी समय systems analyst एक नई पुल-भूमिका के तौर पर उभरा — कोई जो business को समझ सके, system डिज़ाइन कर सके, programmers के लिए diagrams तैयार कर सके, और management की ज़रूरतों को technical structure में अनुवाद कर सके। यह role केवल एक ऐसी दुनिया में मायने रखता है जहाँ software कंपनी की सोच का हिस्सा बन जाता है।
इससे reporting lines भी बदलीं। एक बार जब information systems operations के केंद्र में आ गए, तो कंपनियों ने MIS और IT organizations, project management की परतें, systems teams, और बाद में enterprise software functions बनाए। Authority अब सिर्फ़ physical operations से नहीं, बल्कि information architecture के ज़रिए ज़्यादा बहने लगी।
Software ने आधुनिक product organization को जन्म दिया।
फिर software युग ने एक और परत जोड़ दी। जैसे-जैसे software complexity बढ़ती गई, organization फिर से बँट गया। Product management business, users, और engineering के बीच की खाई भरने के लिए उभरा। Software में प्रोडक्ट को सिर्फ़ बेचना काफ़ी नहीं था। किसी को तय करना था कि क्या बनाना है, user scenarios को अनुवाद करना था, और पूरे cycle में engineering के पास रहना था।
UX और interaction design तब परिपक्व हुए जब personal computing और बाद में web ने usability को आर्थिक रूप से अनिवार्य बना दिया। Quality assurance एक अलग function बन गया क्योंकि testing अब programmer के दिमाग़ के अंदर नहीं रह सकती थी। बाद में Agile और DevOps ने इन रेखाओं को फिर से धुँधला किया, testers को cycle में पहले लाया, और quality को एक साझा ज़िम्मेदारी बना दिया।
तो PM, Designer, Developer, और Tester वाला structure कोई प्रकृति का दिया हुआ ढाँचा नहीं था। वह software engineering के पिछले युग का था। यह इंसानी संवाद की सीमाओं, बँटे हुए ज्ञान, manual coding, और धीमे feedback loops का एक तार्किक जवाब था।
पुरानी assembly line एक अलग दुनिया के लिए बनी थी
एक बार जब आप यह इतिहास साफ़ देख लेते हैं, तो आज का software org chart उतना स्थायी नहीं लगता जितना ज़्यादातर लोग सोचते हैं। यह बस technological reorganizations की एक लंबी श्रृंखला की ताज़ा परत है।
पुरानी software दुनिया में किसी project को एक इंच भी आगे बढ़ाने के लिए specialized functions की एक मोटी परत चाहिए थी। Reporting logic आम तौर पर workflow की ही नक़ल करती थी: product requirements बनाता था, design उन्हें अनुवाद करती थी, engineering उन्हें लागू करती थी, QA उन्हें validate करती थी, और management इन silos के बीच handoffs को coordinate करती थी।
ज़रा सोचिए, एक PM पहले क्या करता था: वह हफ़्तों तक 20 पन्नों के विशाल specification documents लिखता था ताकि उन्हें "दीवार के पार फेंक" सके। Designer फिर हफ़्तों तक उस spec को mockups में बदलने के लिए हाथ से pixels खिसकाता था। Developer उन mockups को लेकर महीनों तक boilerplate code टाइप करता था। आख़िर में Tester हफ़्तों तक misalignments और bugs ढूँढता था।
यह structure तब समझ में आता था जब हर step को अलग tools के साथ अलग specialist को करना पड़ता था, और उनके बीच transitions महँगी थीं। Handoffs सिर्फ़ नौकरशाही नहीं थे। यह वह तरीक़ा था जिससे system ख़ुद को complexity से बचाता था।
लेकिन जब एक AI agent code generate करने, UI draft करने, test cases बनाने, और iteration को मिनटों में सिकोड़ने में मदद कर सकता है, तो वही structure ख़ुद के ख़िलाफ़ काम करने लगता है। Handoff safety mechanism से सीधा drag बन जाता है।
आज का ज़्यादातर "AI transformation" अभी भी यहीं फँसा हुआ है। कंपनियाँ PM को AI writing tool, Designer को AI design tool, और Developer को AI coding tool थमा देती हैं, लेकिन वही reporting lines और वही division of labor क़ायम रहता है। यह नए power source को पुरानी मशीन से जोड़ने जैसा है।
इसलिए मेरा मानना है कि इस कहानी का पहला हिस्सा बहुत मायने रखता है। AI काम को नए सिरे से जमाने वाली पहली technology नहीं है। लेकिन शायद यह पहली ऐसी technology है जो यह काम इतनी रफ़्तार से करती है, और साथ ही इतनी सारी knowledge roles को execution के एक ही पल में समेट लेती है।
Genspark के अंदर मैं क्या देख रहा हूँ
Genspark के अंदर मैं उस इतिहास की अगली परत real time में लिखी जाती हुई देख रहा हूँ। हम अब क़रीब 70 लोगों का organization हैं। हमारा structure बेरहमी से flat है।
हम projects को विशाल, बहु-विषयक departments से नहीं चलाते। हमारे ज़्यादातर projects महज़ 1 से 3 लोगों के agile pods चलाते हैं। चूँकि workflow सिकोड़ा हुआ है, लोग value creation की पूरी श्रृंखला के बहुत क़रीब रहकर काम करते हैं।
यह पहले दिन से शुरू होता है। नए employees को संकीर्ण roles में छिपाकर नहीं रखा जाता, और न ही उन्हें महीनेभर documentation पढ़ने पर मजबूर किया जाता है। उन्हें फ़ौरन front lines पर धकेला जाता है। हम नियमित रूप से देखते हैं कि लोग अपने पहले ही हफ़्ते में असली, complex functionality ship कर रहे होते हैं। यहाँ तक कि वे team members भी features launch कर रहे हैं जिन्होंने हमारे साथ जुड़ने से पहले कभी एक भी line of code नहीं लिखी थी।
पिछले युग में यह बात लापरवाह या नामुमकिन लगती। इस युग में यह baseline है। महत्वाकांक्षी लोग यहाँ फलते-फूलते हैं क्योंकि अब वे एक ही डिब्बे में बंद नहीं हैं।
भूमिकाएँ असल में कैसे बदल रही हैं
जब workflow इतनी आक्रामकता से सिकुड़ता है, तो professional roles ग़ायब नहीं होतीं। वे रूप बदलती हैं। वे ऊँची उठती हैं।
PM: Spec लिखने वाले से System Director तक
PM अब हफ़्तों तक static documents नहीं लिखता ताकि कोई और उन्हें interpret करे। वह AI से तुरंत live prototypes बनवाता है। वह system को steer करता है, real-time में logic test करता है, और सिर्फ़ requirements नहीं, अंतिम outcome का मालिक होता है।
Designer: Front-End अनुवादक से अंतिम न्यायाधीश तक
हमारा हाल ही में जारी हुआ Genspark Design इसका बेहतरीन उदाहरण है। पुरानी प्रक्रिया में Designer एक front-loaded अनुवादक था। उसे screens हाथ से बनानी पड़ती थीं, तभी कोई और कुछ बना सकता था। आज एक abstract idea से एक पूरा design से एक launched product तक का रास्ता निरंतर है।
चूँकि AI सेकंडों में दर्जनों high-fidelity functional prototypes बना सकता है, Designer की भूमिका pipeline के पिछले छोर पर चली जाती है। वह न्यायाधीश बन जाता है। वह quality bar तय करता है। वह taste level की रक्षा करता है। वह experience पर मुहर लगाता है। वह तय करता है कि AI के iterations में से किसमें brand के लिए सही soul है।
Developer: Code टाइपिस्ट से System Architect तक
Developer का पहला हफ़्ता अब local environments सेट करने और पुराने codebases पढ़ने का नहीं है। वह shipping के बारे में है। वे boilerplate टाइप करने में कम और logic architect करने, agents को guide करने, और उन गहरे, structural problems को सुलझाने में ज़्यादा समय लगाते हैं जो AI को अभी दिख नहीं रहे।
Tester: Manual Gatekeeper से Agent Infrastructure Engineer तक
AI-native workflow में हर कोई अपने ही feature का tester बन जाता है। जो person feature बना रहा है, वही cases generate कर रहा है, edge conditions check कर रहा है, experience को validate कर रहा है, और तय कर रहा है कि यह ship के लिए तैयार है या नहीं। Testing अब chain के अंत में एक अलग gate की तरह नहीं बैठती। यह authorship का ही हिस्सा बन जाती है।
इसका यह मतलब नहीं कि traditional tester ग़ायब हो जाता है। वह role एक स्तर ऊपर चली जाती है। यह एक infrastructure role बन जाती है। हर screen को बाद में हाथ से check करने के बजाय, यह person यह सुनिश्चित करने में मदद करता है कि एक बार जब features टीम भर में ship हो जाएँ, तो system production में स्थिर, observable, और भरोसेमंद रहे।
इस मायने में नया tester quality के लिए एक infrastructure engineer की तरह दिखता है। वे frameworks, guardrails, monitoring, evaluation loops, और release logic बनाते हैं जो पूरे organization को ज़्यादा भरोसेमंद बनाते हैं। वे ऐसी infrastructure भी बनाने में मदद करते हैं जो ज़्यादा agent-friendly हो, ताकि AI testing, debugging, और निरंतर सुधार में बेहतर ढंग से हिस्सा ले सके।
हर discipline में रुझान बिल्कुल एक-सा है: judgment अब handoff से कहीं ज़्यादा ज़रूरी होती जा रही है। Context ownership संकीर्ण specialization से ज़्यादा क़ीमती होती जा रही है।
CEO: Chief Executive Officer से Chief Context Officer तक
एक बार जब आप देख लेते हैं कि AI roles को कितनी गहराई से recombine कर रहा है, तो आप PMs, Designers, Developers, और Testers पर रुक नहीं सकते। CEO भी नए सिरे से लिखा जा रहा है।
पुराने company model में scale CEO को काम से दूर धकेलता था। Organization बहुत specialized, बहुत बहुपरतीय, और बहुत धीमा हो जाता था। CEO का काम दूसरे लोगों के ज़रिए complexity को संभालना बन जाता था।
वह दूरी कोई व्यक्तित्व का गुण नहीं थी। यह structural थी। बहुत-सी कंपनियों में CEO अब product को सीधे छू नहीं सकता था क्योंकि काम बहुत सारे functions, meetings, और handoffs में बँट चुका था।
AI इस model को तोड़ता है। एक CEO जो सीखने को तैयार है, वह वापस काम के अंदर जा सकता है। वह product ideas explore कर सकता है, prototypes review कर सकता है, flows test कर सकता है, assumptions को challenge कर सकता है, और AI के साथ execution drive करने में भी मदद कर सकता है। इसलिए नहीं कि CEO को फिर से micromanager बन जाना चाहिए, बल्कि इसलिए कि leadership और creation के बीच की दीवार पतली होती जा रही है।
तो काम बदल जाता है। AI युग का CEO अब Chief Executive Officer से कम और Chief Context Officer से ज़्यादा दिखने लगता है। उसका काम है दिशा तय करना, judgment को साफ़ करना, decision rights को edge के क़रीब लाना, और ऐसे interfaces design करना जो छोटे pods को असली ownership के साथ चलने दें।
पुराने model में ताक़त दूरी और control से आती थी। नए model में ताक़त context, taste, स्पष्टता, और संगठन को एक system की तरह सोचने व चलने में मदद करने की क्षमता से आती है। और जब CEO बदलता है, तो organization वैसा का वैसा नहीं रह सकता। Role rewrite स्वाभाविक रूप से org rewrite बन जाता है।
नया organization सिर्फ़ flatter नहीं है। यह structurally अलग है।
मुझे नहीं लगता कि इस नई कंपनी का सही वर्णन सिर्फ़ "flat" है। Flat का मतलब है कम परतें। हम जो देख रहे हैं वह उससे कहीं गहरा बदलाव है। Organization की मूल इकाई अब function नहीं है। वह pod है।
पुराने structure में कंपनी departments के इर्द-गिर्द बनी थी। Product एक जगह बैठता था। Design दूसरी जगह। Engineering कहीं और। QA अंत में बैठती थी। Org chart handoff chain का ही आईना था।
नए structure में कंपनी छोटे, high-context pods के एक network जैसी दिखने लगती है। 1 से 3 लोगों का pod problem के क़रीब, user के क़रीब, और AI के क़रीब काम करता है। वह idea से release तक की chain का ज़्यादा हिस्सा अपने हाथ में रखता है। उसके पास ज़्यादा context होता है। वह ज़्यादा निर्णय लेता है। वह कम इंतज़ार करता है।
हज़ारों लोगों की कंपनी में इसका मतलब यह नहीं हो सकता कि एक CEO सीधे सैकड़ों pods को छू रहा है। वह scale नहीं करेगा। Scalable version है networks का network: pods को mission clusters में जोड़ा जाए, और उन्हें साझा context, साझा taste, साझा स्पष्टता, और साझा system design से एक साथ रखा जाए। Leadership परतें अब भी रहेंगी, लेकिन उनका काम बदल जाएगा। वे अब approval के bottlenecks नहीं रहेंगे। वे context routers, interface designers, और force multipliers बन जाएँगे। उस model में CEO हर pod को manage नहीं कर रहा। CEO ऐसी architecture design कर रहा है जो बहुत सारे pods को पुरानी नौकरशाही फिर से खड़ी किए बिना तालमेल के साथ चलने दे। AI-native scale ऐसा ही दिखता है: एक चपटा pyramid नहीं, एक अलग system।
जैसे ही ऐसा होता है, hierarchy मुख्य coordination mechanism नहीं रहती। Context मुख्य coordination mechanism बन जाता है। सबसे ज़रूरी सवाल अब "किसे किसे रिपोर्ट करना है?" नहीं रहता। वह बन जाता है: "context सच में किसके पास है, और उस पर action लेने का judgment किसके पास है?"
इससे यह भी बदलता है कि leadership परतें किस लिए हैं। पुरानी दुनिया में middle management का बड़ा हिस्सा functional सीमाओं के पार translate, summarize, coordinate, और information move करने के लिए मौजूद था। नई दुनिया में वे roles सिर्फ़ तभी क़ीमती रहेंगी जब वे system builders, quality reviewers, talent coaches, और cross-pod integrators में विकसित हो जाएँ। Transmission-belt manager का महत्व लगातार घटेगा।
एक वाक्य में, AI-native organization यह है: छोटे pods का एक network जिसमें high context ownership हो, AI agents का साथ हो, साझा judgment से aligned हो, और भारी hierarchy की जगह हल्के interfaces से जुड़ा हो।
कंपनी को नए सिरे से लिखने की खिड़की
अगर role rewrite से CEO rewrite होता है, और CEO rewrite से org rewrite होता है, तो यह कोई tooling upgrade नहीं है। यह company rewrite है। तो सिर्फ़ अपने AI stack को घूरना बंद कीजिए। अपने लोगों को देखिए। अपने structure को देखिए।
मुश्किल सवाल पूछिए। क्या आपके लोग अब भी संकीर्ण translation roles में फँसे हुए हैं? क्या आपके सबसे अच्छे दिमाग़ अब भी निर्णय लेने के बजाय handoffs तैयार कर रहे हैं? क्या आपका org chart अब भी पुराने PM-Designer-Developer-Tester chain के लिए बना हुआ है? क्या decision rights अब भी उन लोगों से बहुत दूर हैं जिनके पास असली context है?
AI access ख़रीदना आसान है। असली बदलाव मुश्किल है। इसका मतलब है roles को नए सिरे से डिज़ाइन करना, ownership को छोटे pods में धकेलना, infrastructure को agents के इर्द-गिर्द फिर से बनाना, और leadership को ख़ुद नए सिरे से परिभाषित करना।
इस युग के विजेता सिर्फ़ बेहतर models का इस्तेमाल नहीं करेंगे। वे तेज़ी से ख़ुद को नए सिरे से बनाएँगे। वे handoff chains की जगह pod networks रखेंगे। वे context को edge तक ले जाएँगे। वे judgment के लिए bar ऊँचा उठाएँगे।
AI सिर्फ़ tasks को नए सिरे से नहीं लिख रहा। वह कंपनी को नए सिरे से लिख रहा है। खिड़की अभी खुली है। यह ज़्यादा देर खुली नहीं रहेगी।