हम फिर से Dreamweaver वाली गलती कर रहे हैं
AI डिज़ाइन को फिर से कोड की कमान सौंप रहा है।
बीस वर्षों तक, हमने इन भूमिकाओं को अलग करने के लिए काम किया। डिज़ाइनर्स ने डिज़ाइन किया। डेवलपर्स ने निर्माण किया। एक इंसान ने सेतु (bridge) के रूप में काम किया।
AI इसे बदल देता है। आप एक मॉडल को डिज़ाइन फ़ाइल की ओर निर्देशित करते हैं और वह कंपोनेंट्स (components) जनरेट कर देता है। डिज़ाइन फिर से कोड को संचालित करने लगता है।
यह कुशल लगता है, लेकिन इसमें एक जोखिम है।
पुराने Dreamweaver के दिनों में, एक इंसान बीच में बैठा होता था। वह व्यक्ति गुणवत्ता (quality) सुनिश्चित करता था। AI के साथ, डिज़ाइन सीधे कोड में चला जाता है और ड्राइवर की सीट पर कोई नहीं होता।
दो बातें हैं जिन्हें आपको समझना चाहिए:
- डिज़ाइन फ़ाइलें, डिज़ाइन सिस्टम नहीं होती हैं। एक फ़ाइल का मूल्यांकन इस आधार पर किया जाता है कि वह कैसी दिखती है। एक सिस्टम का मूल्यांकन उसके पुन: उपयोग (reuse), स्थायित्व (durability) और अवस्थाओं (states) के आधार पर किया जाता है। AI इस अंतर को धुंधला कर देता है।
- AI स्टैटिक साइट्स (static sites) के लिए बेहतरीन है। यदि आपको केवल एक स्नैपशॉट की आवश्यकता है, तो इसका उपयोग करें। समस्या तब शुरू होती है जब आप एक पुन: प्रयोज्य (reusable) सिस्टम बनाते हैं, जैसे कि एक कस्टम CMS या डायनेमिक UI।
असली विफलता बारीकियों में होती है।
टीमें अक्सर Figma वेरिएबल नामों के आधार पर कोड पाइपलाइन बनाती हैं। नामकरण (Naming) एक डिज़ाइन विकल्प है, लेकिन AI इसे एक कठोर अनुबंध (rigid contract) में बदल देता है। यदि कोई डिज़ाइनर एक वेरिएबल का नाम बदलता है, तो पूरी पाइपलाइन टूट जाती है।
एक डिज़ाइन एक स्टैटिक स्नैपशॉट है। यह एक अवस्था में एक स्क्रीन दिखाता है। यह निम्नलिखित को नहीं दिखाता है:
- लोडिंग या एरर स्टेट्स (error states)।
- कंटेंट-संचालित बनाम फिक्स्ड लेआउट्स (fixed layouts)।
- एक CMS डेटा कैसे फीड करता है।
वह संदर्भ (context) एक डेवलपर के दिमाग में होता है, डिज़ाइन फ़ाइल में नहीं।
उद्योग के दिग्गज इसे ठीक करने की कोशिश कर रहे हैं। Google ने AI को अधिक संरचना देने के लिए DESIGN.md जारी किया है। Fixel जैसे टूल Figma के विरुद्ध कोड को वैलिडेट करके डिज़ाइन ड्रिफ्ट (design drift) को पकड़ने में मदद करते हैं।
लेकिन बेहतरीन टूल्स की भी सीमाएं होती हैं। वे पिक्सेल या टोकन निकाल सकते हैं, लेकिन वे आर्किटेक्चरल निर्णय नहीं ले सकते। वे यह तय नहीं कर सकते कि किसी मौजूदा कंपोनेंट का पुन: उपयोग करना है या नया बनाना है।
भविष्य डिज़ाइन द्वारा कोड को संचालित करने के बारे में नहीं है। यह एक मध्य मार्ग (middle ground) के बारे में है।
मेरा मानना है कि इस मध्य मार्ग के लिए आवश्यक है:
- बिल्ड टाइम पर टाइप्ड CSS इनपुट्स (Typed CSS inputs)।
- AI द्वारा यह प्रस्तावित करना कि डिज़ाइन आपके मौजूदा सिस्टम से कैसे मैप होते हैं।
- व्यवहार और अर्थ पर अंतिम निर्णय लेने के लिए UX इंजीनियर्स।
AI डिज़ाइनर्स को कोड की गुणवत्ता के लिए अधिक जिम्मेदार बनाता है। क्योंकि डिज़ाइन ही कोड बन जाता है, इसलिए अनुवाद की निगरानी (gatekeep) करने के लिए कोई नहीं बचता।
हमें UX इंजीनियर को इस प्रक्रिया से बाहर नहीं करना चाहिए। हमें ऐसे लोगों की आवश्यकता है जो डिज़ाइन और सिस्टम के बीच मैपिंग और अनुबंध (contract) की जिम्मेदारी संभाल सकें।
आप यह कैसे तय करते हैं कि AI क्या प्रस्तावित करता है और क्या निर्णय लेना आपका काम है?
स्रोत: https://dev.to/slafleche/were-making-the-dreamweaver-mistake-again-on-purpose-this-time-ema
