आपके एजेंटों की डिज़ाइन प्रक्रिया 90% खत्म हो चुकी है

AAI LABS
Computing/SoftwareSmall Business/StartupsManagementInternet Technology

Transcript

00:00:00पुराने बिल्ड प्रोसेस में एक ऐसी लेयर होती थी जो अब अस्तित्व में नहीं है।
00:00:03और ज्यादातर टीमों को यह समझ नहीं आया है कि इसे किससे बदला जाए, इसलिए वे अब भी
00:00:06पुरानी प्रक्रिया को ही आदतवश चला रहे हैं।
00:00:08इस हफ्ते, जेनी वेन ने लेनी के पॉडकास्ट पर एक इंटरव्यू पब्लिश किया।
00:00:11वह एंथ्रोपिक में क्लॉड के लिए हेड ऑफ डिज़ाइन हैं, और उससे पहले वह फिग्मा में
00:00:16डिज़ाइन डायरेक्टर थीं।
00:00:17एपिसोड में, उन्होंने बताया कि कैसे डिज़ाइन प्रोसेस अब खत्म हो चुका है और वास्तव में
00:00:21इसकी जगह क्या ले रहा है।
00:00:22तो हम विश्लेषण करेंगे कि क्या बदला, क्यों बदला, और फिर उस सटीक प्रक्रिया को
00:00:26देखेंगे जिसने इसकी जगह ली है।
00:00:27यह समझने के लिए कि इसकी जगह क्या आया, आपको यह समझना होगा कि यह क्यों मौजूद था।
00:00:31पुरानी प्रक्रिया में, आप पहले आवश्यकताएं तय करते थे, फिर एक डिज़ाइनर उन्हें
00:00:35फिग्मा में ले जाकर एक मॉक-अप बनाता था कि ऐप कैसा दिखना चाहिए।
00:00:38वह फिग्मा फ़ाइल ही हैंड-ऑफ़ डॉक्यूमेंट थी कि कोई क्या चाहता था और क्या बना।
00:00:43फिर एक फ्रंट-एंड इंजीनियर उस फ़ाइल को कोड में बदल देता था।
00:00:46इसी बीच, बैक-एंड इंजीनियर समानांतर में काम कर रहा होता था, क्योंकि API स्पेसिफिकेशन
00:00:51पहले ही तय हो जाते थे, ताकि दोनों पक्ष एक साथ काम कर सकें और अंत में सब जुड़ जाए।
00:00:55जेनी इसे एक ऐसी प्रक्रिया बताती हैं जिसे डिज़ाइनर एक रस्म की तरह मानते थे।
00:00:58यह पूरी इंडस्ट्री में एक मानक था।
00:01:00यह बदलाव क्यों हो रहा है, इसे समझाने वाले ज्यादातर लोग वह असली वजह भूल गए जिसके लिए यह शुरू हुआ था।
00:01:05साइमन विलिसन, जो इस क्षेत्र के सबसे लोकप्रिय तकनीकी ब्लॉगों में से एक लिखते हैं,
00:01:09उन्होंने जनवरी में जेनी की बर्लिन टॉक के बारे में लिखा और वह इनसाइट दी जो उनकी टॉक
00:01:14इशारा तो करती है पर सीधे नहीं कहती।
00:01:16AI के साथ निर्माण करने से गलत चीज़ बनाने की लागत काफी कम हो जाती है।
00:01:19AI से पहले, एक गलत दिशा का मतलब था इंजीनियरिंग के महीनों का समय बर्बाद होना।
00:01:23फ्रंट-एंड में एक छोटी सी गलती का मतलब लागू करने के दौरान 10 गुना काम बढ़ जाना था।
00:01:27इसलिए टीमें हर कदम को सही ठहराती थीं।
00:01:28रिसर्च, पर्सोना, यूजर जर्नी, वायरफ्रेम, स्पेसिफिकेशन डॉक्यूमेंट।
00:01:33यह सब बड़े पैमाने पर गलत चीज़ बनाने से बचने का एक सुरक्षा कवच था।
00:01:36तो वास्तव में प्रक्रिया में क्या बदला?
00:01:38सबसे पहले इंजीनियरिंग की गति बदली।
00:01:40और यह इतनी तेज़ी से बदली कि ज्यादातर लोग इसे समझ भी नहीं पाए।
00:01:42जेनी ने कहा कि कुछ साल पहले, एक डिज़ाइनर के रूप में उनका 60 से 70% समय मॉकिंग और प्रोटोटाइपिंग में बीतता था।
00:01:48अब यह 30 से 40% है।
00:01:49उन्होंने अलग तरह से काम करने का फैसला नहीं किया था।
00:01:51उनके आसपास के इंजीनियरों ने समानांतर में कई एजेंटों का उपयोग करना शुरू कर दिया और अचानक
00:01:55इंजीनियरिंग अब बाधा नहीं रह गई।
00:01:58इंजीनियरिंग पहले बदली और डिज़ाइन को उसका अनुसरण करने के लिए मजबूर होना पड़ा।
00:02:00विज़न की समय-सीमा भी बदल गई।
00:02:02डिज़ाइन पहले 2 से 5 साल का विज़न तैयार करता था।
00:02:04अब टेक्नोलॉजी इतनी तेज़ी से आगे बढ़ रही है कि 3 से 6 महीने का दायरा ही वास्तविक है।
00:02:09और अब यह ज़रूरी नहीं कि कोई प्रेजेंटेशन डेक हो।
00:02:11अब यह एक प्रोटोटाइप होता है जो लोगों को एक दिशा दिखाता है।
00:02:13यही बात ट्रांसलेशन (अनुवाद) वाले चरण के साथ भी हुई।
00:02:15जब कोई एजेंट रिक्वायरमेंट डॉक्यूमेंट लेकर एक चालू इंटरफेस बना सकता है, तो किसी
00:02:19ट्रांसलेशन लेयर की ज़रूरत नहीं होती।
00:02:20एजेंट खुद कोड लिखता है।
00:02:22अनुवाद करने के लिए कोई फिग्मा फ़ाइल नहीं होती क्योंकि फिग्मा फ़ाइल की ज़रूरत ही नहीं पड़ती।
00:02:25साथ ही, अगर आप हमारे कंटेंट का आनंद ले रहे हैं, तो हाइप बटन दबाने पर विचार करें क्योंकि यह हमें
00:02:29ऐसा और कंटेंट बनाने और अधिक लोगों तक पहुँचने में मदद करता है।
00:02:33जब हमें क्लाइंट का काम मिलता है, तो हमें यही सटीक बदलाव करना पड़ता है।
00:02:36अब डिज़ाइन प्रोसेस बदल गया है, लेकिन जो हिस्सा नहीं बदला वह है 'रिक्वायरमेंट' (आवश्यकताएं)।
00:02:40गलत आवश्यकताएं पूरे निर्माण को बर्बाद कर देती हैं।
00:02:42और ज्यादातर टीमें सीधे स्पेसिफिकेशन पर कूद जाती हैं।
00:02:44यह गलत क्रम है।
00:02:45जब आप प्रोटोटाइप बना रहे हों, तो आपको टेक स्टैक या API स्पेक की ज़रूरत नहीं होती।
00:02:48आपको बस इतना जानने की ज़रूरत है कि कुछ ऐसा बनाया जाए जो असली प्रोडक्ट जैसा दिखे और महसूस हो
00:02:52ताकि आप इसे किसी के सामने रख सकें और 'हाँ' या 'ना' में जवाब पा सकें।
00:02:56इसलिए प्रोटोटाइप को छूने से पहले, 'एक्टर्स' (पात्रों) से शुरू करें।
00:02:58एक्टर वह व्यक्ति है जो सिस्टम के साथ इंटरैक्ट करता है।
00:03:01एक विशिष्ट लक्ष्य वाला एक विशिष्ट व्यक्ति।
00:03:03लेकिन इसका उपयोग कौन करता है, यही तय करता है कि इसे क्या करने की ज़रूरत है।
00:03:06अगर आपके पास कोई कंटेंट सबमिट करने वाला है और कोई उसे अप्रूव करने वाला है, तो वे
00:03:10दो अलग-अलग स्क्रीन वाले दो अलग-अलग इंटरफेस होंगे।
00:03:12फिर देखें कि व्यूज़ कहाँ अलग होते हैं।
00:03:13ज्यादातर प्रोडक्ट्स में, एक ही URL पर दो अलग-अलग एक्टर्स जाते हैं और पूरी तरह से
00:03:18अलग चीज़ें देखते हैं।
00:03:19एडमिन को एक मैनेजमेंट पैनल दिखता है।
00:03:21एक सामान्य यूजर को अपना डैशबोर्ड दिखता है।
00:03:22आखिरी चीज़ है 'कन्स्ट्रेंट्स' (सीमाएं)।
00:03:24एजेंट को यह मत बताओ कि कौन से टूल्स इस्तेमाल करने हैं।
00:03:26उसे यह बताओ कि वह क्या नहीं कर सकता और उसकी लागत कितनी नहीं हो सकती।
00:03:28इससे बाद में तकनीकी फैसले लेना भी काफी आसान हो जाएगा।
00:03:32अब हमने उन सभी विशिष्ट नियमों को इस 'Create PRD' प्रॉम्प्ट में लागू कर दिया है, जो मूल रूप से
00:03:37आपका इंटरव्यू लेता है, एक PRD इंटरव्यूअर की तरह काम करता है, और नियमों के अनुसार आपसे
00:03:42कई अलग-अलग सवाल पूछता है।
00:03:44और अंत में, आपको एक PRD मार्कडाउन फ़ाइल मिलती है, जिसका उपयोग प्रक्रिया के
00:03:48बाद के चरणों में किया जाएगा।
00:03:49वह PRD फ़ाइल ही वह आधार है जिस पर बाकी सब कुछ बनता है।
00:03:52तो अगला कदम इसे फ्रंट-एंड के स्ट्रक्चर में बदलना है।
00:03:55इसके लिए, हम इस 'लेयर प्रॉम्प्ट' का उपयोग करते हैं, जो अनिवार्य रूप से एजेंट को PRD देखने के लिए कहता है,
00:04:00जो कि सभी तकनीकी आवश्यकताओं वाला पूरा PRD नहीं है, और दो चीज़ें तैयार करने को कहता है।
00:04:04यह उन पेजों और मॉडल्स को बनाने के लिए कहता है जो आपके प्रोटोटाइप के साथ होंगे और
00:04:08फिर यूजर फ्लो।
00:04:09अब, ज़ाहिर है कि स्ट्रक्चर के लिए पेज और मॉडल्स महत्वपूर्ण हैं ताकि एजेंट को फ्रंट एंड में
00:04:14जो भी लागू करना है, वह पहले से प्लान किया जा सके।
00:04:17हमने काम करने से पहले प्लानिंग करने के बारे में और एजेंट व कॉन्टेक्स्ट विंडो के लिए इसके
00:04:21महत्व पर बात करना जारी रखा है, इसलिए हमें उसमें गहराई से जाने की ज़रूरत नहीं है।
00:04:24लेकिन यूजर फ्लो के साथ, प्रत्येक एक्टर के कार्यों को परिभाषित करना महत्वपूर्ण है।
00:04:28चूंकि हम पहले से ही फीचर्स के बजाय एक्टर्स पर ध्यान केंद्रित कर रहे हैं, इसलिए
00:04:32यूजर फ्लो को परिभाषित करना भी महत्वपूर्ण है ताकि एजेंट सही इंटरैक्शन
00:04:36स्टेट्स और पूरे UI प्रोटोटाइप के लिए सही नेविगेशन लागू कर सके।
00:04:40तो हमें दो फ़ाइलें मिलती हैं जहाँ architecture.md में वे पेज, मॉडल और यूजर फ्लो
00:04:45होते हैं जिनकी हमने चर्चा की।
00:04:46उसके बाद, हमने इसे एक Next.js ऐप इंस्टॉल करने के लिए कहा क्योंकि हम आमतौर पर
00:04:50इसी टेक स्टैक का उपयोग करते हैं, सुपबेस के साथ Next.js।
00:04:53और वास्तव में इसने यह परिणाम दिया।
00:04:55कुल मिलाकर, डिज़ाइन बहुत अच्छा लग रहा है, लेकिन इसका एक खास कारण है।
00:04:58साथ ही, पहले इसका ज़िक्र नहीं किया गया था, लेकिन यह बिल्ड चैनलों,
00:05:03प्रोडक्ट्स और कोर्सेस वाला एक कम्युनिटी प्लेटफॉर्म था।
00:05:04इसमें मूल रूप से दो एक्टर्स हैं, मेंबर और क्रिएटर, जहाँ क्रिएटर के पास
00:05:08सभी एडमिनिस्ट्रेटिव फंक्शन्स हैं जैसे चैनल बनाना, प्रोडक्ट जोड़ना
00:05:12या कोर्स अपलोड करना, और साथ ही अलग-अलग आंकड़े देखना।
00:05:15हमारी राय में, बनाए गए पहले प्रोटोटाइप के हिसाब से डिज़ाइन वाकई शानदार लग रहा है।
00:05:19लेकिन UX उतना अच्छा नहीं है क्योंकि सामान्य तौर पर हम ऐसा डैशबोर्ड नहीं चाहते।
00:05:23और यही असल बात है।
00:05:24इस तरह के सुधार में पहले दिन लगते थे, यहाँ इसमें कुछ ही मिनट लगते हैं।
00:05:27क्योंकि AI इन बदलावों को बहुत तेज़ी से कर सकता है।
00:05:30और चूंकि यहाँ कोई बैक एंड नहीं है, इसलिए इसे उन अतिरिक्त चीज़ों से नहीं जूझना पड़ता,
00:05:34यह सिर्फ एक फ्रंट एंड प्रोटोटाइप है।
00:05:36आमतौर पर AI इतने अच्छे दिखने वाले वेबसाइट और इंटरफेस नहीं बनाता।
00:05:40और इसके अच्छे दिखने का कारण यह है कि हम इस 'जनरल पर्पस फ्रंट एंड
00:05:44स्किल' का उपयोग करते हैं जिसे एंथ्रोपिक ने अपने एक ब्लॉग में दिया था।
00:05:46हम अपना UI लागू करने से पहले इसका उपयोग करने की अत्यधिक सलाह देते हैं।
00:05:50बस इसे एक स्लैश कमांड या स्किल के रूप में सेव कर लें ताकि आपका एजेंट इसका उपयोग कर सके।
00:05:53अब अगर आप किसी क्लाइंट के लिए काम कर रहे हैं, तो आपको बस उन्हें यह प्रोटोटाइप दिखाना है,
00:05:57जो मॉक डेटा के साथ फंक्शनलिटी के मामले में पूरी तरह से काम कर रहा है, क्योंकि यह
00:06:01अभी डेटाबेस तैयार नहीं करेगा।
00:06:02आप इसे अपने क्लाइंट को दिखा सकते हैं, उनकी मंजूरी ले सकते हैं और यदि नहीं, तो बदलाव करके
00:06:06बाकी निर्माण के साथ आगे बढ़ सकते हैं।
00:06:08ये टास्क लिस्ट उन कारणों में से एक हैं जिनकी वजह से अब हम इन एजेंटों से पूरी तरह से
00:06:12काम करने वाले प्रोटोटाइप बनाने के लिए कह सकते हैं।
00:06:14यह इन टास्क लिस्ट, टास्क पर्सिस्टेंस और सब कुछ
00:06:17स्ट्रक्चर्ड होने के कारण संभव है।
00:06:18इसीलिए वह architecture.md फ़ाइल बनाना बहुत महत्वपूर्ण था क्योंकि यह
00:06:23एजेंट को एक पूरी तरह से ऑप्टिमाइज्ड टास्क लिस्ट बनाने की अनुमति देता है ताकि वह भ्रमित न हो।
00:06:28उसके बाद हम बैक एंड इम्प्लीमेंटेशन की ओर बढ़ते हैं।
00:06:30अब सामान्य तौर पर दो चीज़ें हैं जो आप कर सकते हैं।
00:06:32आप Next.js रख सकते हैं, फ्रंट एंड को Next.js में अलग रख सकते हैं और फिर
00:06:36बैक एंड को एक अलग पायथन सर्विस के रूप में लागू कर सकते हैं।
00:06:39लेकिन यह इस पर निर्भर करता है कि आप किस तरह के एप्लिकेशन पर काम कर रहे हैं।
00:06:42आप लोग जो ज्यादातर प्रोजेक्ट बनाएंगे, उनके लिए Next.js ठीक रहेगा।
00:06:46आपको अलग पायथन बैक एंड की ज़रूरत तब होती है जब आपको उन व्यापक लाइब्रेरीज़ की ज़रूरत हो
00:06:50जो Next.js में उपलब्ध नहीं हैं या यदि आपको अपनी साइट या इसके कार्यों को ऑप्टिमाइज करने के लिए
00:06:55गंभीर बैकग्राउंड जॉब ऑर्केस्ट्रेशन की आवश्यकता है।
00:06:57उस स्थिति में, आपको एक अलग बैक एंड की आवश्यकता हो सकती है।
00:06:59वरना Next.js बैक एंड ही वह सब है जिसकी आपको ज़रूरत होगी।
00:07:03बैक एंड को छूने से पहले, हमें यह जानना होगा कि फ्रंट एंड को उससे वास्तव में क्या चाहिए।
00:07:07तो हमने एजेंट से फ्रंट एंड कोड, PRD और आर्किटेक्चर फ़ाइल को देखने और एक
00:07:11API स्पेसिफिकेशन लिखने को कहा।
00:07:12उसके बाद, हमने इसे पूरा सुपबेस स्कीमा बनाने के लिए इन तीन दस्तावेजों का उपयोग करने को कहा क्योंकि
00:07:17हम फ्रंट एंड के रूप में सुपबेस और Next.js का उपयोग कर रहे हैं।
00:07:20इसे मूल रूप से वे स्कीमा बनाने की ज़रूरत है जो ऐप के डेटा को स्टोर करेंगे।
00:07:25सामान्य तौर पर यदि आप अपने एजेंट से पूछते हैं, तो वह आपसे कहेगा कि डेटाबेस से अपनी API कीज़
00:07:28लाएँ और टेबल बनाने के लिए मैन्युअल रूप से SQL क्वेरी पेस्ट करें।
00:07:33लेकिन इसके बजाय, आपको सुपबेस MCP का उपयोग करना चाहिए।
00:07:36आप जिस भी सर्विस के साथ काम कर रहे हैं, उसके लिए हमेशा MCP का उपयोग करने की कोशिश करें क्योंकि यह
00:07:40बहुत सारी चीज़ों को ऑटोमेट कर देता है।
00:07:41उदाहरण के लिए, हमें यहाँ प्रोजेक्ट्स को देखने की ज़रूरत भी नहीं पड़ी।
00:07:43इसने स्वचालित रूप से प्रोजेक्ट बनाया, स्कीमा के लिए क्वेरी चलाई और स्वचालित रूप से
00:07:48माइग्रेशन भी कर दिया।
00:07:49तो हमें मूल रूप से कुछ भी नहीं करना पड़ा।
00:07:51डेटाबेस सेटअप होने के बाद, आप फ्रंट एंड को डेटाबेस से जोड़ेंगे।
00:07:55अब फिर से, यहाँ एक स्पष्ट अंतर है।
00:07:57आपको बैक एंड को डेटाबेस से जोड़ने की ज़रूरत नहीं है क्योंकि यह पहले से ही
00:08:00फ्रंट एंड में एकीकृत है।
00:08:01फ्रंट एंड सीधे डेटाबेस से बात करता है, जिससे इंटीग्रेशन और कुल जटिलता
00:08:06काफी कम हो जाती है।
00:08:07अब हम वास्तव में इस वीडियो के लिए वार्प (warp) के साथ पार्टनरशिप में हैं और उन्होंने हाल ही में OZ जारी किया है, जो
00:08:11विभिन्न क्लाउड एजेंटों के लिए एक ऑर्केस्ट्रेशन प्लेटफॉर्म है।
00:08:14ये क्लाउड एजेंट उन कामों के लिए काम के हैं जिन्हें आप बस सौंपना चाहते हैं और आप जानते हैं कि
00:08:19एजेंट उन्हें अपने दम पर पूरा करने में सक्षम होगा।
00:08:21तो अब तक, एजेंट ने फ्रंट एंड को डेटाबेस से जोड़ दिया था और ऐप मूल रूप से
00:08:26उसके अनुसार काम कर रहा था।
00:08:27लेकिन पेमेंट प्रोसेसिंग, नए नोटिफिकेशन, रेट लिमिटिंग, या एनालिटिक्स
00:08:32जैसी चीज़ें जोड़ने के लिए, हमें एक समर्पित बैकएंड API लेयर की ज़रूरत है ताकि हम उन सबको एकीकृत कर सकें।
00:08:37उसके लिए, हमने OZ का उपयोग करके एक एनवायरनमेंट बनाया और एक क्लाउड एजेंट चलाया, जिससे
00:08:41उस समर्पित बैकएंड लेयर को बनाने के लिए कहा गया।
00:08:43और करीब 15 मिनट के बाद, काम पूरा हो गया और सब कुछ तैयार था।
00:08:47इसे वास्तव में चालू करने और यूजर्स को स्वीकार करना शुरू करने के लिए, अब बस
00:08:51गूगल ऑथेंटिकेशन, स्ट्राइप इंटीग्रेशन और कुछ छोटी बारीकियों को ठीक करना बाकी था।
00:08:56अब आपने पूरी प्रक्रिया देख ली है और प्रॉम्प्ट्स स्क्रीन पर ही रहे हैं।
00:09:00लेकिन अगर आप इन सभी प्रॉम्प्ट्स को एक स्टेप-बाय-स्टेप वर्कफ्लो के रूप में चाहते हैं जिसे आप अपने
00:09:04प्रोजेक्ट्स के लिए फॉलो कर सकें, तो हम उसे AI Labs Pro में डाल रहे हैं।
00:09:06जो लोग नहीं जानते, उनके लिए यह हमारी कम्युनिटी है जहाँ आपको रेडी-टू-यूज़ टेम्पलेट्स मिलते हैं जिन्हें
00:09:10आप इस वीडियो और पिछले सभी वीडियो के लिए सीधे अपने प्रोजेक्ट्स में प्लग कर सकते हैं।
00:09:14अगर आपको हमारे काम में वैल्यू मिली है और आप चैनल को सपोर्ट करना चाहते हैं, तो यह
00:09:18ऐसा करने का सबसे अच्छा तरीका है।
00:09:19लिंक डिस्क्रिप्शन में है।
00:09:20इसी के साथ हम इस वीडियो के अंत में पहुँच गए हैं।
00:09:22अगर आप चैनल को सपोर्ट करना चाहते हैं और हमें इस तरह के वीडियो बनाने में मदद करना चाहते हैं, तो
00:09:26आप नीचे दिए गए सुपर थैंक्स बटन का उपयोग करके ऐसा कर सकते हैं।
00:09:28हमेशा की तरह, देखने के लिए धन्यवाद और मैं आपसे अगले वीडियो में मिलूँगा।

Key Takeaway

AI एजेंटों के युग में, पारंपरिक फिग्मा-आधारित डिज़ाइन रस्मों की जगह अब तेज़ प्रोटोटाइपिंग और एक्टर-केंद्रित विकास ने ले ली है, जिससे इंजीनियरिंग अब कोई बाधा नहीं रही।

Highlights

पुरानी डिज़ाइन प्रक्रिया अब समाप्त हो चुकी है क्योंकि AI ने गलत चीज़ बनाने की लागत को काफी कम कर दिया है।

डिज़ाइनर अब अपना 60-70% समय मॉकिंग में बिताने के बजाय केवल 30-40% समय ही इस पर खर्च कर रहे हैं।

प्रोटोटाइप बनाने से पहले 'एक्टर्स' (उपयोगकर्ताओं) और उनकी विशिष्ट भूमिकाओं को परिभाषित करना सबसे महत्वपूर्ण कदम है।

एजेंटों को टूल के बजाय 'कन्स्ट्रेंट्स' (सीमाएं) बताना अधिक प्रभावी होता है ताकि वे बेहतर तकनीकी निर्णय ले सकें।

Supabase MCP जैसे टूल्स का उपयोग करके डेटाबेस सेटअप और माइग्रेशन को पूरी तरह से ऑटोमेट किया जा सकता है।

Next.js और Supabase का संयोजन अधिकांश एप्लिकेशनों के लिए पर्याप्त है, जिससे बैकएंड की जटिलता कम हो जाती है।

Timeline

डिज़ाइन प्रक्रिया में बदलाव और उसका कारण

वीडियो की शुरुआत पुरानी सॉफ़्टवेयर निर्माण प्रक्रिया के विश्लेषण से होती है जिसे जेनी वेन ने एक 'रस्म' बताया है। पहले फिग्मा फाइलों का उपयोग हैंड-ऑफ़ डॉक्यूमेंट के रूप में किया जाता था ताकि इंजीनियरिंग की भारी लागत से बचा जा सके। AI के आगमन के साथ, गलतियाँ करने की कीमत कम हो गई है, जिससे सुरक्षा कवच के रूप में इस्तेमाल होने वाले लंबे शोध और वायरफ्रेम की ज़रूरत कम हो गई है। साइमन विलिसन का उदाहरण देते हुए लेखक बताते हैं कि अब सुरक्षा के बजाय गति पर ध्यान केंद्रित किया जा रहा है। यह खंड स्पष्ट करता है कि क्यों पारंपरिक डिज़ाइन लेयर अब अस्तित्व में नहीं है।

इंजीनियरिंग की गति और नया विज़न

इस भाग में बताया गया है कि कैसे इंजीनियरिंग की गति ने डिज़ाइन को अपने पीछे चलने के लिए मजबूर किया है। एंथ्रोपिक की जेनी वेन के अनुसार, डिज़ाइनरों का प्रोटोटाइपिंग समय आधा हो गया है क्योंकि इंजीनियर अब समानांतर में एजेंटों का उपयोग कर रहे हैं। अब 2 से 5 साल के लंबे विज़न के बजाय केवल 3 से 6 महीने का वास्तविक दायरा ही प्रासंगिक रह गया है। फिग्मा जैसी ट्रांसलेशन लेयर्स की अब आवश्यकता नहीं है क्योंकि एजेंट सीधे आवश्यकताओं से कोड लिख सकते हैं। यह बदलाव तकनीकी विकास की तीव्र गति को दर्शाता है जिसने पुराने मानकों को बदल दिया है।

नई प्रक्रिया: एक्टर्स और कन्स्ट्रेंट्स

लेखक नई डिज़ाइन प्रक्रिया के मुख्य स्तंभों के रूप में 'एक्टर्स', 'व्यूज़' और 'कन्स्ट्रेंट्स' पर चर्चा करते हैं। सबसे पहले यह पहचानना ज़रूरी है कि सिस्टम का उपयोग कौन करेगा, जैसे कि एडमिन या सामान्य यूजर, क्योंकि यही इंटरफेस को परिभाषित करता है। विभिन्न उपयोगकर्ताओं के लिए अलग-अलग डैशबोर्ड और यूआरएल अनुभव होने चाहिए ताकि कार्यक्षमता सटीक रहे। एजेंटों को यह निर्देश देना कि वे क्या 'नहीं' कर सकते, उन्हें स्वतंत्र रूप से बेहतर समाधान खोजने में मदद करता है। यह खंड सिखाता है कि सीधे स्पेसिफिकेशन पर कूदने के बजाय सही क्रम में काम करना क्यों आवश्यक है।

PRD निर्माण और आर्किटेक्चर प्लानिंग

यहाँ एक विशेष 'Create PRD' प्रॉम्प्ट का परिचय दिया गया है जो एक इंटरव्यूअर की तरह काम करता है और एक विस्तृत मार्कडाउन फ़ाइल बनाता है। इस PRD फ़ाइल का उपयोग 'लेयर प्रॉम्प्ट' के साथ किया जाता है ताकि पेजों, मॉडल्स और यूजर फ्लो का स्ट्रक्चर तैयार किया जा सके। यूजर फ्लो को परिभाषित करना इसलिए महत्वपूर्ण है ताकि एजेंट सही नेविगेशन और इंटरैक्शन स्टेट्स को समझ सके। अच्छी प्लानिंग से एजेंट के लिए कॉन्टेक्स्ट विंडो का उपयोग करना आसान हो जाता है और भ्रम की स्थिति पैदा नहीं होती। यह पूरी तरह से संरचित और अनुकूलित टास्क लिस्ट बनाने का आधार तैयार करता है।

प्रोटोटाइप विकास और UI स्किल

वीडियो में Next.js और Supabase का उपयोग करके एक कम्युनिटी प्लेटफॉर्म का प्रोटोटाइप बनाने का प्रदर्शन किया गया है। यद्यपि AI आमतौर पर खराब दिखने वाले इंटरफेस बनाता है, यहाँ एंथ्रोपिक के 'जनरल पर्पस फ्रंट एंड स्किल' का उपयोग करके शानदार डिज़ाइन प्राप्त किया गया है। यह प्रोटोटाइप मॉक डेटा के साथ पूरी तरह कार्यात्मक है जिसे क्लाइंट को दिखाकर तुरंत मंजूरी ली जा सकती है। यदि बदलाव की आवश्यकता हो, तो AI इसे कुछ ही मिनटों में कर सकता है, जो पहले करने में कई दिन लगते थे। यह प्रक्रिया दिखाती है कि कैसे बिना किसी भारी बैकएंड के एक प्रभावी फ्रंट-एंड प्रोटोटाइप जल्दी तैयार किया जा सकता है।

डेटाबेस सेटअप और बैकएंड एकीकरण

डेटाबेस प्रबंधन के लिए लेखक 'Supabase MCP' के उपयोग की पुरज़ोर सलाह देते हैं क्योंकि यह SQL क्वेरी और माइग्रेशन को ऑटोमेट करता है। अधिकांश प्रोजेक्ट्स के लिए Next.js का अपना बैकएंड पर्याप्त है, लेकिन जटिल कार्यों के लिए अलग पायथन सर्विस की आवश्यकता हो सकती है। फ्रंट-एंड सीधे डेटाबेस से बात करता है, जो विकास की जटिलता को काफी कम कर देता है और एकीकरण को सरल बनाता है। डेटाबेस स्कीमा तैयार करने के लिए PRD और आर्किटेक्चर फाइलों का उपयोग किया जाता है ताकि डेटा संरचना सटीक रहे। यह तकनीकी खंड डेटा के कुशल प्रबंधन और स्वचालित माइग्रेशन पर केंद्रित है।

क्लाउड एजेंट और अंतिम ऑर्केस्ट्रेशन

अंतिम भाग में 'Warp' के 'OZ' प्लेटफॉर्म का परिचय दिया गया है जो क्लाउड एजेंटों के लिए एक ऑर्केस्ट्रेशन टूल है। इसका उपयोग पेमेंट प्रोसेसिंग और नोटिफिकेशन जैसी समर्पित बैकएंड लेयर्स को स्वतंत्र रूप से बनाने के लिए किया गया है। लेखक बताते हैं कि कैसे करीब 15 मिनट में जटिल बैकएंड कार्य पूरे हो गए और ऐप उपयोग के लिए तैयार हो गया। अंत में, AI Labs Pro कम्युनिटी और वहां उपलब्ध रेडी-टू-यूज़ टेम्पलेट्स के बारे में जानकारी दी गई है। यह खंड आधुनिक क्लाउड टूल्स और एजेंटों के माध्यम से प्रोजेक्ट को पूरा करने की अंतिम सीढ़ी को दर्शाता है।

Community Posts

View all posts