पिछले साल मेरी LinkedIn feed की एक अपनी ही शैली थी। कोई program manager या कोई "delivery lead" या जिसके headline में Agile लिखा हो, वह AI के किसी function लिखने का screenshot post करता, साथ में एक line जोड़ता जैसे "और कहते थे यह नौकरी safe है, बस code करना सीख लो" और वही काम करने वालों से चार सौ likes बटोर लेता। इशारा हमेशा यही होता कि engineering का typing वाला हिस्सा ही engineering था, और अब जब एक model type कर सकता है, typing वाला तबक़ा ख़त्म।
मुझे लगता है उन्होंने org chart उल्टा पढ़ लिया। और मुझे ख़ुशी है कि अब उन्हें पता चल रहा है
अब वह बात जो feed के उस तरफ़ कोई खुलकर नहीं कहता। AI building के load-bearing हिस्से में बहुत अच्छा नहीं है, यानी यह तय करना कि system को करना क्या चाहिए, यह जानना कि पिछली तीन कोशिशें क्यों fail हुईं, और यह बता पाना कि model ने अभी पूरे आत्मविश्वास से तुम्हें कोई टूटी हुई चीज़ कब पकड़ा दी। दूसरे हिस्से में यह सचमुच, शर्मिंदा कर देने वाली हद तक अच्छा है। status rollup। वे release notes जिन्हें कोई नहीं पढ़ता। वह feature catalog जो हफ़्ते भर में बासी हो जाता है। वह test plan जो ज़्यादातर acceptance criteria का ही दोबारा format किया रूप है। वह weekly update जो उस standup का सार है जो उस Slack thread का सार था। AI को इसी काम से जूझना नहीं पड़ता। यही वह काम है जिसके लिए AI पैदा हुआ था।
तो देखो कौन कहाँ बैठा है। यह सहायक परत, जान-बूझकर, वही हिस्से करने को है जो engineers नहीं करना चाहते थे। project tracker update रखो। updates के लिए लोगों के पीछे पड़ो। engineer के दो वाक्यों को VP के लिए एक paragraph में बदलो। engineer के paragraph को VP के लिए दो वाक्यों में बदलो। doc maintain रखो। वह meeting चलाओ जहाँ हर कोई वही कहता है जो उसने कल लिखकर कहा था। मैं इस पर कोई कठोरता नहीं कर रहा। ये काम असली थे और उबाऊ थे और किसी को तो करने थे, यही पूरी वजह है कि इन roles को funding मिली। दिक़्क़त यह है कि "दूसरों के बनाए inputs का एक साफ़ summary बनाना" ठीक उसी आकार का है जो एक language model सबसे अच्छा करता है, और "inputs बनाना" वह हिस्सा है जो यह अब भी अकेले नहीं कर सकता।
और अब वह असमानता जिसे obsolescence वाले posters छोड़ गए। AI को ढंग से इस्तेमाल करने के लिए तुम्हें उसे जाँच पाना आना चाहिए। तुम्हें diff पढ़कर पता होना चाहिए कि वह ग़लत है। तुम्हें generate हुई migration देखकर भाँपना आना चाहिए कि उसमें कोई rollback नहीं है। builder के पास यह पहले से है। यही वह skill है जिसने उसे builder बनाया। दूसरी तरफ़, coordination परत को इसी साफ़ समझ के साथ रखा गया था कि उन्हें code पढ़ने की ज़रूरत नहीं होगी, और अब जो tool उन्हें बचाने वाला है वह ऐसा output बनाता है जिस पर सिर्फ़ वही भरोसा कर सकता है जो code पढ़ सके। उनके हाथ में chainsaw थमा दिया गया और उसका manual उस भाषा में है जिसे न सीखने का उन्हें भरोसा दिलाया गया था।
एक अच्छा program manager status-update मशीन नहीं होता।
हाँ, मुझे पता है। पर अपने करियर में अब तक मिले ~40 में से शायद 2 ऐसे थे। 38 तो पक्के status-update मशीनें थीं। असली काम, जिसके पैसे देना सही है, वह है यह जज करना कि क्या काटा जाए, launch खिसकने पर राजनीतिक ढाल बनना, यह जानना कि किस executive का "छोटा-सा सवाल" दरअसल धमकी है, और एक-दूसरे से नफ़रत करने वाली छह teams को एक तारीख़ पर राज़ी कराना। AI इनमें से कुछ नहीं करता। यह कमरे में इल्ज़ाम अपने सिर नहीं ले सकता। यह तय नहीं कर सकता कि तकनीकी रूप से सही sequencing ही राजनीतिक रूप से आत्मघाती है। पूरे काम को "Confluence page गरम रखने" तक घटा देना coder की सबसे पुरानी कल्पना है और इस role के सबसे बेहतरीन लोगों के बारे में यह हमेशा ग़लत रही है। मुझे पता है।
judgment-और-ढाल वाला काम कभी पूरी headcount नहीं था। उन सचमुच अच्छे program managers में से हर एक के नीचे लोगों की एक परत थी जिनका असली दिन यही था, artifact maintenance, rollup, catalog, वह deck जो deck को ही दोबारा कहता था।
"engineers ख़त्म" वाली भीड़ ने इसे उल्टा समझ लिया क्योंकि उन्होंने यह गड़बड़ा दिया कि value कौन पैदा करता है और उसे पैदा करने का सबसे ज़्यादा शोर कौन मचाता है। जो इंसान एक अच्छे जवाब को एक आत्मविश्वास से भरे ग़लत जवाब से अलग बता सकता है, AI उसी इंसान को ज़्यादा value वाला बनाता है, कम नहीं। वह इंसान आम तौर पर building कर रहा था। वह शायद ही कभी screenshot post करने वाला होता था।