AI युग में नए प्रोडक्ट-इंजीनियरिंग वर्कफ़्लो पर एक फ़्रंटएंड इंजीनियर का नज़रिया
एक ऐसा आँकड़ा जिसका कोई तुक नहीं बनना चाहिए
12 दिन। दो लोग: एक प्रोडक्ट डिज़ाइनर और एक फ़्रंटएंड इंजीनियर। एक पूरी प्लेटफ़ॉर्म रीबिल्ड।
कोई प्रोटोटाइप नहीं। कोई MVP नहीं। एक प्रोडक्शन एप्लिकेशन का पूरा प्रतिस्थापन, जिसकी परिणति एक ऐसे PR में हुई जिसने 26,000 लाइन का पुराना कोड हटा दिया। हर पेज, हर रूट, हर इंटरैक्शन, शून्य से दोबारा बनाया गया और असली यूज़र्स तक शिप किया गया।
किसी भी पारंपरिक प्रोडक्ट डेवलपमेंट वर्कफ़्लो में, यह समय-सीमा बेतुकी है। इस दायरे का कोई प्रोजेक्ट आम तौर पर महीनों लेता: Figma में हफ़्तों की डिज़ाइन खोज, हितधारकों की समीक्षा के कई दौर, एक हैंडऑफ़ समारोह, स्प्रिंट प्लानिंग, और फिर पिक्सल-परफ़ेक्ट इम्प्लीमेंटेशन की धीमी मेहनत। यहाँ जो हुआ वह मूल रूप से अलग था। इसलिए नहीं कि हमने ज़्यादा मेहनत की, बल्कि इसलिए कि हमारे साथ काम करने का तरीका बदल गया।
यह कहानी है कि कैसे हमने VM0 में Zero प्लेटफ़ॉर्म शिप किया, और इसने मुझे प्रोडक्ट-इंजीनियरिंग सहयोग के भविष्य के बारे में क्या सिखाया।
पुरानी रुकावट
हर फ़्रंटएंड इंजीनियर पारंपरिक पाइपलाइन जानता है:
- डिज़ाइनर Figma में मॉकअप बनाता है
- डिज़ाइन समीक्षा, पुनरावृत्ति, मंज़ूरी
- स्पेसिंग, रंग, ब्रेकपॉइंट के साथ एनोटेट किए गए स्पेक
- इंजीनियर विज़ुअल स्पेक को कोड में अनुवादित करता है
- आगे-पीछे: "क्या तुम इसे 4px बाईं ओर खिसका सकते हो?"
- आख़िरकार, API परत को जोड़ना
- इंटीग्रेशन टेस्टिंग, और आगे-पीछे
रुकावट कभी किसी एक कदम में नहीं थी। यह कदमों के बीच की खाई में थी: इंतज़ार, अनुवाद में हुई हानि, संदर्भ बदलना। किसी इंटरैक्शन का डिज़ाइनर का मानसिक मॉडल, एक बार जब किसी स्थिर Figma फ़्रेम में सपाट हो जाता है और रेडलाइन से एनोटेट किया जाता है, तो इंजीनियर की मेज़ पर पहले से ही ख़राब होकर पहुँचता है। इंजीनियर वही दोबारा बनाता है जो डिज़ाइनर ने कल्पना की थी, लेकिन वह अनिवार्य रूप से एक हानिकारक नकल होती है।
हम इस घर्षण के इतने आदी हो चुके थे कि हमने इसे देखना ही बंद कर दिया था। यह तो बस "चीज़ें कैसे काम करती हैं" था।
प्रयोग: अगर डिज़ाइनर ही कोड शिप करे तो?
5 मार्च, 2026 को, हमारी प्रोडक्ट डिज़ाइनर Ming ने PR #3685 खोला: feat(platform): add zero app with shell, pages and polish। इसने काम करने वाले React कोड की 4,146 लाइनें जोड़ीं।
कोई Figma फ़ाइल नहीं। कोई डिज़ाइन टोकन एक्सपोर्ट नहीं। एक चलता हुआ एप्लिकेशन।
PR में एक पूरा ऐप शेल था: साइडबार नेविगेशन, रूटिंग संरचना, चैट, शेड्यूल, एक्टिविटी, टीम मैनेजमेंट, और सेटिंग्स के लिए पेज स्केलेटन, सब हमारे डिज़ाइन सिस्टम से स्टाइल किए हुए, सब ब्राउज़र में रेंडर होते हुए। डेटा नकली था, पर UI असली था। आप npm run dev चला सकते थे और हर पेज पर क्लिक कर सकते थे।
Ming ने यह कोड पारंपरिक अर्थ में शून्य से नहीं लिखा। उन्होंने अपनी डिज़ाइन दृष्टि को सीधे React कंपोनेंट में अनुवादित करने के लिए AI कोडिंग टूल का इस्तेमाल किया (पहले Cursor, बाद में Claude Code)। AI ने यांत्रिक अनुवाद संभाला (JSX संरचना, CSS गुण, कंपोनेंट संयोजन), जबकि Ming ने वे विज़ुअल और इंटरैक्शन फ़ैसले निर्देशित किए जो कोई AI नहीं ले सकता: लेआउट की लय, जानकारी का पदानुक्रम, ट्रांज़िशन का एहसास।
अगले चार दिनों में, तीन और PR उतरे:
| तारीख़ | PR | Ming ने क्या शिप किया |
|---|---|---|
| 5 मार्च | #3685 | ऐप शेल, साइडबार, सभी पेज स्केलेटन (+4,146 लाइनें) |
| 6 मार्च | #3825 | शेड्यूल पेज, UI पॉलिश (+2,650 लाइनें) |
| 9 मार्च | #3993 | ऑनबोर्डिंग फ़्लो, Slack कॉन्फ़िग डायलॉग (+1,146 लाइनें) |
| 9 मार्च | #4050 | About पेज, फ़्लोटिंग नेव कार्ड |
9 मार्च तक, हमारे नए प्लेटफ़ॉर्म की पूरी फ़्रंटएंड सतह चलते हुए कोड के रूप में मौजूद थी। हर वह पेज जो आप आख़िरकार प्रोडक्शन में देखते, एक डेव एनवायरनमेंट में पहले से ही क्लिक करने योग्य था। बस वह अभी तक कुछ असली नहीं कर रहा था।
यहीं मेरी एंट्री हुई।
मेरा नया काम: आत्मा डालना
जब मैंने 9 मार्च को कोडबेस खोला, तो मेरे सामने किसी सपाट डिज़ाइन को कोड में अनुवादित करने की वह सामान्य चुनौती नहीं थी। कोड पहले से ही वहाँ था। मेरा काम था हर नकली चीज़ को हकीकत से बदलना, हर खूबसूरती से डिज़ाइन की गई सतह को नीचे के जीवंत, साँस लेते बैकएंड से जोड़ना।
इसने मेरे काम को एक मूलभूत तरीके से बदल दिया। पिक्सल के बारे में सोचने के बजाय, मैं डेटा फ़्लो के बारे में सोच रहा था। "क्या यह मॉकअप से मेल खाता है?" पूछने के बजाय, मैं पूछ रहा था "इस पेज को किस API कॉल की ज़रूरत है, और जब यह नाकाम हो तो क्या होता है?"
मेरा पहला हफ़्ता ऐसा दिखता था:
दिन 1 (9 मार्च): Auth और org स्विचिंग। मैंने Ming के शेल को Clerk ऑथेंटिकेशन से जोड़ा, क्रॉस-डोमेन रीडायरेक्ट जोड़े, और org स्विचर को सचमुच org बदलने लायक बनाया। दो PR, दोनों उसी दिन मर्ज हुए।
दिन 2 (10 मार्च): Connectors और schedule। मैंने नकली कनेक्टर ग्रिड को असली API डेटा से बदला, schedule टैब को असल cron जॉब से जोड़ा, और instructions एडिटर को बैकएंड से जोड़ा। चार PR।
दिन 3 (11 मार्च): बड़ा वायरिंग दिन। Team पेज को असली सब-एजेंट डेटा मिला (+3,271 लाइनें)। Activity पेज को असली लॉग मिले। और सबसे क़ीमती बात: chat पेज असल एजेंट रन पाइपलाइन से जुड़ गया, जिसने डेमो कोड की ~1,200 लाइनों को एक काम करने वाले AI बातचीत इंटरफ़ेस से बदल दिया। उसी दिन, मैंने FeatureSwitchKey.Zero पेश किया, एक फ़ीचर फ़्लैग जिसने हमें पुराने और नए प्लेटफ़ॉर्म को साथ-साथ चलाने दिया।
दिन 4-5 (12-13 मार्च): फ़ाइल अटैचमेंट, सेशन मैनेजमेंट, मल्टी-एजेंट चैट, सेटिंग्स पर्सिस्टेंस। हर वह पेज जो Ming ने बनाया था, अब असली काम कर रहा था।
लय लगभग संगीतमय थी। हर सुबह मैं Ming के स्कैफ़ोल्ड से एक पेज चुनता, उसकी कंपोनेंट संरचना का अध्ययन करता, पहचानता कि उसे किस डेटा की उम्मीद है, API इंटीग्रेशन बनाता, एरर स्थितियाँ संभालता, और पुश करता। दोपहर तक, एक और पेज जीवित हो जाता।
फ़ीचर स्विच: समानांतर दुनियाएँ
FeatureSwitchKey.Zero फ़ीचर फ़्लैग अपने अलग ज़िक्र का हक़दार है, क्योंकि यही वह चीज़ है जिसने इस माइग्रेशन को लापरवाह के बजाय सुरक्षित बनाया।
11 मार्च से, हमारा प्रोडक्शन ऐप दो पूरे UI समानांतर में चला रहा था। पुराने सिस्टम पर यूज़र्स पुराने रूट देखते। नए सिस्टम पर आंतरिक परीक्षक Zero देखते। हर वह पेज जिसे मैं जोड़ता, उसे किसी एक यूज़र के वर्कफ़्लो को जोखिम में डाले बिना प्रोडक्शन संदर्भ में परखा जा सकता था।
यह क्रांतिकारी नहीं है। फ़ीचर फ़्लैग एक मानक चलन है। लेकिन फ़ीचर फ़्लैग और डिज़ाइन-एज़-कोड वर्कफ़्लो के संयोजन ने कुछ ख़ास बनाया: हम नए प्लेटफ़ॉर्म के पूरे UX को मान्य कर सकते थे (क्योंकि Ming ने एक पूरा, ब्राउज़ करने योग्य UI बनाया था) जबकि हर पेज को धीरे-धीरे कार्यात्मक बनाते जाते (क्योंकि मैं उन्हें एक-एक करके जोड़ रहा था)। किसी भी मोड़ पर, अगर कुछ गड़बड़ होती, तो हम स्विच को वापस पलट सकते थे।
कुछ भी गड़बड़ नहीं हुआ।
दिन 12: बड़ा स्विच
17 मार्च को, मैंने PR #5095 खोला: refactor: remove all non-zero platform pages and feature flag।
डिफ़: +456 लाइनें, -26,041 लाइनें।
पहले: पुराना VM0 Platform। टेबल, रन ID, और कच्चा सेशन डेटा।
बाद में: नया Zero। पिन किए गए एजेंट और यूज़ केस कार्ड के साथ एक संवादात्मक AI वर्कस्पेस।
एक ही मर्ज में, हर पुराना रूट हटा दिया गया। फ़ीचर फ़्लैग हटा दिया गया। Zero अब कोई विकल्प नहीं था; यह एकमात्र मोड था। एक फ़ॉलो-अप PR (#5155) ने /zero URL प्रीफ़िक्स पूरी तरह हटा दिया: जो /zero/chat था वह बस /chat बन गया।
मैंने यह कटौती करने में आत्मविश्वास क्यों महसूस किया? क्योंकि:
- हर पेज फ़ीचर फ़्लैग के तहत कम से कम 5 दिनों से चल रहा था
- हर API इंटीग्रेशन प्रोडक्शन डेटा के विरुद्ध परखा जा चुका था
- पुराना और नया सिस्टम एक ही बैकएंड साझा करते थे। यह एक फ़्रंटएंड स्वैप था, कोई डेटा माइग्रेशन नहीं
- नए सिस्टम पर हमारे असली यूज़र्स थे जो पूरे दौरान फ़ीडबैक दे रहे थे
26,000 लाइनें चिंता के साथ नहीं हटाई गईं। वे राहत के साथ हटाई गईं।
पैटर्न दोहराता है
मुझे सबसे ज़्यादा हैरानी माइग्रेशन से नहीं हुई। हैरानी इस बात से हुई कि जो वर्कफ़्लो हमने खोजा था वह हर अगले फ़ीचर के लिए हमारा डिफ़ॉल्ट मोड बन गया। Ming AI सहायता से UI शेल बनाती हैं, मैं लॉजिक जोड़ता हूँ और आर्किटेक्चर का विस्तार करता हूँ। वही डिज़ाइन-एज़-कोड पैटर्न, फ़ीचर के पैमाने पर:
अनुमति प्रणाली (19 मार्च → 7 अप्रैल)
Ming ने PR #5467 शिप किया, Sheet कंपोनेंट और टॉगल कंट्रोल के साथ एक अनुमति ड्रॉअर UI। तीन कमिट, साफ़ UI।
मैंने उसी PR में 13 कमिट जोड़े: firewall_access_requests के लिए डेटाबेस माइग्रेशन, API एंडपॉइंट, इंटीग्रेशन टेस्ट, लिंट फ़िक्स। फिर अगले दो हफ़्तों में, 10+ फ़ॉलो-अप PR ने पूरी अनुमति परत बनाई: अप्रूवल कार्ड का रीडिज़ाइन, एक्सेस अनुरोधों के लिए Slack नोटिफ़िकेशन, अनुमति समस्याओं की पहचान के लिए CLI doctor कमांड, और आख़िरकार पूरे कोडबेस में पूरी अवधारणा का नाम "firewall" से बदलकर "permission" करना।
Ming का ड्रॉअर बीज था। अनुमति प्रणाली पेड़ थी।
शेड्यूल प्रणाली (23 मार्च → 13 अप्रैल)
Ming ने शेड्यूल विवरण रूट और कैलेंडर UX डिज़ाइन किया (#6155)। साफ़ UI काम के तीन कमिट।
मैंने 14 कमिट जोड़े: ऑटो-जनरेशन के साथ विवरण एडिटिंग, नोटिफ़िकेशन के लिए Slack चैनल चयन, बिना सहेजे बदलावों के पुष्टि डायलॉग, कैलेंडर/लिस्ट व्यू का एकीकरण, और व्यापक टेस्ट। फिर 15+ फ़ॉलो-अप PR ने इसे रन इतिहास, टाइमज़ोन हैंडलिंग, और cron एक्सप्रेशन सपोर्ट के साथ एक पूरी आवर्ती कार्य प्रणाली में विस्तारित किया।
Telegram इंटीग्रेशन (27 अप्रैल → 28 अप्रैल)
इस मुक़ाम तक, पैटर्न इतना अभ्यस्त हो चुका था कि हमने एक पूरा प्लेटफ़ॉर्म इंटीग्रेशन 48 घंटों में शिप कर दिया। Ming ने Settings UI (#11196) और Onboarding फ़्लो (#11399) बनाया। मैंने मल्टी-बॉट API, मैसेज भेजना/प्राप्त करना, फ़ाइल अपलोड/डाउनलोड, समृद्ध मैसेज संदर्भ, Ably रियल-टाइम अपडेट, और E2E टेस्ट बनाए। अगले दिन, यह सभी यूज़र्स के लिए चालू कर दिया गया।
AI कहाँ फ़िट बैठता है
मैं यहाँ AI की भूमिका के बारे में सटीक रहना चाहता हूँ, क्योंकि इसे बढ़ा-चढ़ाकर या कम करके आँकना आसान है।
AI ने डिज़ाइनर को कोड करने में सक्षम बनाया। Ming एक प्रोडक्ट डिज़ाइनर हैं, सॉफ़्टवेयर इंजीनियर नहीं। वे लेआउट, पदानुक्रम, और इंटरैक्शन में सोचती हैं, React हुक और TypeScript जेनेरिक्स में नहीं। AI टूल (Cursor, फिर Claude Code) ने डिज़ाइन इरादे से काम करने वाले कोड तक के यांत्रिक अनुवाद को संभालकर उस खाई को पाटा। Ming ने निर्देश दिया; AI ने टाइप किया। नतीजा ऐसा कोड था जिसे एक डिज़ाइनर ने रचा पर एक इंजीनियर उस पर निर्माण कर सका।
AI ने समीक्षा लूप को तेज़ किया। सहयोगी PR पर, मेरा AI एजेंट Ming के कोड की समीक्षा करता, मुद्दों को प्राथमिकता के अनुसार वर्गीकृत करता (P0/P1/P2), और सीधे फ़िक्स कमिट पुश करता। PR #5060 ने 38 मिनट में पाँच समीक्षा दौर पूरे किए। PR #5467 ने 20 मिनट में तीन दौर पूरे किए। यह "AI द्वारा कोड समीक्षा की जगह लेना" नहीं है। मैं अब भी हर बदलाव पढ़ता हूँ। पर लिंट समस्याओं, गुम प्रकारों, और टेस्ट खाइयों को पहचानने का यांत्रिक काम स्वचालित हो गया।
AI ने डिज़ाइन के फ़ैसले नहीं लिए। हर पेज की सूचना संरचना, इंटरैक्शन पैटर्न, विज़ुअल पदानुक्रम: ये Ming की प्रोडक्ट सहज-बुद्धि से आए, जो यूज़र रिसर्च और डोमेन विशेषज्ञता से सूचित थी। AI एक सेटिंग्स पेज तैयार कर सकता है, पर यह तय नहीं कर सकता कि क्या टॉगल होना चाहिए बनाम ड्रॉपडाउन, या कब किसी पुष्टि डायलॉग की ज़रूरत है बनाम कब वह घर्षण है।
AI ने आर्किटेक्चर के फ़ैसले नहीं लिए। समानांतर परिनियोजन के लिए फ़ीचर फ़्लैग इस्तेमाल करने का चुनाव, API परत पृथक्करण रणनीति, पेजों को एक साथ के बजाय धीरे-धीरे जोड़ने का फ़ैसला: ये इंजीनियरिंग के निर्णय थे। AI ने मुझे कोड तेज़ी से लिखने में मदद की, पर अनुक्रम और जोखिम प्रबंधन इंसानी थे।
ईमानदार सारांश: AI ने डिज़ाइन और इंजीनियरिंग के बीच की अनुवाद परत को ख़त्म कर दिया। इसने किसी भी अनुशासन की जगह नहीं ली; इसने उनके बीच की खाई हटा दी।
मेरी भूमिका के बारे में क्या बदला
तीन महीने तक इस वर्कफ़्लो में रहने के बाद, मैं एक फ़्रंटएंड इंजीनियर के रूप में अपनी भूमिका को अलग नज़र से देखता हूँ।
मैं अब कोई विज़ुअल अनुवादक नहीं हूँ। एक Figma फ़ाइल पाने और स्पेसिंग मानों को मिलाने में घंटों बिताने के दिन ख़त्म हो गए। इसलिए नहीं कि मैं इसमें तेज़ हूँ, बल्कि इसलिए कि यह अब मेरा काम ही नहीं है। डिज़ाइनर का इरादा कोड के रूप में आता है, कोड की किसी तस्वीर के रूप में नहीं।
मैं एक आर्किटेक्चर विस्तारक हूँ। मेरा मुख्य मूल्य किसी काम करने वाली UI सतह को लेकर उसके नीचे की अदृश्य अवसंरचना बनाना है: API इंटीग्रेशन, डेटा मान्यकरण, एरर हैंडलिंग, अनुमति जाँच, रियल-टाइम अपडेट, टेस्ट। ज़्यादातर सहयोगी PR का अनुपात पूरी कहानी कहता है। Ming UI के 3 कमिट देती हैं, मैं बाकी सब के 13 कमिट देता हूँ।
मैं एक गुणवत्ता द्वारपाल हूँ। AI-सहायता प्राप्त समीक्षा लूप के साथ, मैं पहले से कहीं बड़ी सतह पर कोड गुणवत्ता बनाए रख सकता हूँ। स्वचालित समीक्षा यांत्रिक मुद्दे पकड़ती है; मैं आर्किटेक्चरल चिंताओं, किनारे के मामलों, और यह सुनिश्चित करने पर ध्यान देता हूँ कि फ़ीचर वाकई शुरू से अंत तक काम करे।
मैं एक डिलीवरी रणनीतिकार हूँ। फ़ीचर फ़्लैग, क्रमिक वायरिंग, समानांतर परिनियोजन: कोई फ़ीचर कोड से प्रोडक्शन तक कैसे जाता है इसका अनुक्रम अब मेरे काम का एक मुख्य हिस्सा है, कोई बाद की सोच नहीं।
आँकड़े
तीन महीने। दो लोग। पूरे दौरान AI-सहायता प्राप्त।
- 914 मर्ज किए गए PR (679 मेरे, 235 Ming के)
- पहले स्कैफ़ोल्ड से पूरे प्लेटफ़ॉर्म प्रतिस्थापन तक 12 दिन
- एक पूरे Telegram इंटीग्रेशन के लिए 48 घंटे (हमारा सबसे तेज़ फ़ीचर)
- एक ही आत्मविश्वासी मर्ज में हटाई गई 26,000 लाइनें
- मेरे 88% PR और Ming के 66% PR AI सह-लेखकत्व रखते हैं
ये भाग-दौड़ के आँकड़े नहीं हैं। हम दोनों में से किसी ने न वीकेंड पर काम किया न रात भर जागे। यह तेज़ी मृत समय को ख़त्म करने से आती है: हैंडऑफ़ मीटिंग, स्पेक की गलतफ़हमियाँ, "क्या तुम इसे 4px खिसका सकते हो" वाली आगे-पीछे। जब डिज़ाइन इरादा सीधे कोड में बहता है, और इंजीनियरिंग उसी कोड को वहीं विस्तारित करती है, तो बस कम बर्बादी होती है।
टीमों के लिए इसका क्या मतलब है
मैं यह दावा नहीं कर रहा कि हर टीम को इस तरह काम करना चाहिए। यह वर्कफ़्लो हमारे विशिष्ट संदर्भ से उभरा: एक छोटी टीम, एक ग्रीनफ़ील्ड रीबिल्ड का अवसर, और सक्षम AI कोडिंग टूल्स तक जल्दी पहुँच। आपके नतीजे अलग होंगे।
लेकिन मुझे विश्वास है कि अंतर्निहित बदलाव सार्वभौमिक है: डिज़ाइन और इंजीनियरिंग के बीच की सीमा घुल रही है, और AI ही वह विलायक है। जैसे-जैसे AI टूल इरादे को कोड में अनुवादित करने में बेहतर होंगे, अधिक डिज़ाइनर सीधे कोड शिप करेंगे। जैसे-जैसे ऐसा होगा, इंजीनियर अनुवाद पर कम और आर्किटेक्चर, गुणवत्ता, और डिलीवरी पर ज़्यादा समय बिताएँगे।
फ़्रंटएंड इंजीनियर का काम ख़त्म नहीं हो रहा। यह अपना आकार बदल रहा है। और ईमानदारी से? नया आकार ज़्यादा दिलचस्प है।
Yuma VM0 में एक फ़्रंटएंड इंजीनियर हैं, जहाँ वे Zero को संचालित करने वाला प्लेटफ़ॉर्म बनाते हैं, जो एक AI एजेंट ऑपरेटिंग सिस्टम है। उन्होंने जितना स्वीकार करना चाहेंगे उससे कहीं ज़्यादा पुराना कोड बड़े पैमाने पर हटाया है।
