एक साथी लेख में हमने दिखाया कि AI एजेंट स्किल्स फ्रंट-एंड आउटपुट को एक ब्लाइंड टेस्ट में मापने योग्य रूप से अधिक सुंदर बना सकती हैं। यह लेख कहानी का दूसरा भाग है — वह जिसे अधिकांश "AI ने हमारे कोड को बेहतर बनाया" पोस्ट छोड़ देती हैं: जहां स्किल्स ने मदद नहीं की, उनकी लागत क्या रही, और हम कैसे जानते हैं कि यह अंतर असली है। यदि आप यह तय कर रहे हैं कि एजेंट स्किल्स में निवेश करें या नहीं, तो कमियां उतनी ही मायने रखती हैं जितने फायदे।
हमने आठ स्किल्स बनाईं और उन्हें दो अलग-अलग तरीकों से परखा। सबसे महत्वपूर्ण परिणाम यह है कि आठ स्किल्स एक चीज़ नहीं हैं — वे साफ़-साफ़ दो प्रकारों में बंट जाती हैं जो विपरीत तरीकों से व्यवहार करती हैं।
दो प्रकार की स्किल्स
"एजेंट स्किल्स" को एक ही लीवर मानने का लालच होता है। वे ऐसी नहीं हैं।
ज्ञान स्किल्स (इनमें से सात)
ये यह एनकोड करती हैं कि अच्छा फ्रंट-एंड क्या होता है: CSS आर्किटेक्चर, एक डिज़ाइन सिस्टम, रिस्पॉन्सिव लेआउट, सिमेंटिक HTML और एक्सेसिबिलिटी, एनिमेशन, आधुनिक CSS और ब्राउज़र समर्थन, और परफॉर्मेंस। ये संदर्भ सामग्री हैं जिन्हें एजेंट मांग पर लोड करता है।
एक प्रक्रिया स्किल
आठवीं, "Visual Polish," यह एनकोड करती है कि एक डिज़ाइनर कैसे काम करता है: बनाओ, इसे एक असली ब्राउज़र में रेंडर करो, इसका स्क्रीनशॉट लो, एक रूब्रिक के मुकाबले इसकी आलोचना करो, सबसे कमज़ोर चीज़ों को ठीक करो, और दोहराओ — साथ ही एक जांची-परखी डिज़ाइन-सिस्टम एसेट लाइब्रेरी और एक सख्त "definition of done।" यह एजेंट के व्यवहार को बदलती है, न कि केवल उसके ज्ञान को।
यह अंतर नीचे दिए गए हर परिणाम को समझाने वाला निकला।
हमने इसे कैसे मापा
दो मूल्यांकन, प्रत्येक में एक ही कार्य की तुलना स्किल्स के साथ बनाम बिना सहायता (कोई स्किल्स नहीं) की गई:
- शुद्धता मूल्यांकन (Correctness eval) — सात बिल्ड कार्य, वस्तुनिष्ठ जांचों द्वारा ग्रेड किए गए: क्या यह रिलेटिव यूनिट्स, सिमेंटिक HTML, एक्सेसिबल फ़ोकस स्टेट्स, em-आधारित ब्रेकपॉइंट्स, नेटिव लेज़ी-लोडिंग, इत्यादि का उपयोग करता है।
- गुणवत्ता मूल्यांकन (Quality eval) — दो नए कार्य (एक प्राइसिंग सेक्शन, एक फाइनेंस लैंडिंग पेज), ब्लाइंड तरीके से आंके गए: एक स्वतंत्र समीक्षक ने केवल रेंडर किए गए स्क्रीनशॉट्स को स्कोर किया, नहीं जानता था कि कौन-सा कौन-सा है, और लेबल यादृच्छिक कर दिए गए थे ताकि यह पैटर्न न पहचान सके।
आंकड़े
| माप | स्किल्स के साथ | बिना सहायता | निष्कर्ष |
|---|---|---|---|
| शुद्धता पास दर | ~90% | ~95% | वस्तुतः बराबरी |
| ब्लाइंड गुणवत्ता — कार्य 1 | जीता (उच्च विश्वास) | हारा | विशिष्टता 9 बनाम 3 |
| ब्लाइंड गुणवत्ता — कार्य 2 | जीता (उच्च विश्वास) | हारा | विशिष्टता 8 बनाम 3 |
| प्रति कार्य समय | +~33% | आधार रेखा | स्किल्स की लागत अधिक |
| प्रति कार्य टोकन | +~24% | आधार रेखा | स्किल्स की लागत अधिक |
उन दोनों खंडों को एक साथ पढ़ें और पूरी कहानी सामने आ जाती है: शुद्धता पर, स्किल्स और बिना-स्किल्स बराबरी पर रहते हैं; कारीगरी पर, स्किल्स निर्णायक रूप से जीतती हैं — लेकिन लागत अधिक होती है।
जहां स्किल्स जीतती हैं (फायदे)
1. कारीगरी और सौंदर्य — निर्णायक जीत
प्रक्रिया स्किल के साथ, आउटपुट पहचानने योग्य "जेनेरिक AI डिफ़ॉल्ट" से सचमुच आर्ट-डायरेक्टेड बन गया — और उच्च विश्वास पर दोनों कार्यों में एक ब्लाइंड तुलना जीती। समीक्षक ने, बिना यह जाने कि कौन-सा डिज़ाइन कौन-सा है, स्वतंत्र रूप से बिना-सहायता वाले संस्करणों के संकेतक बताए: गहरा बैंगनी ग्रेडिएंट और ग्रेडिएंट हेडलाइन टेक्स्ट।
"एक आर्ट-डायरेक्टेड है और स्पष्ट रूप से कस्टम-डिज़ाइन किया गया है — इंस्पिरेशन-बोर्ड जैसी सामग्री। दूसरा एक साथ दो सबसे बड़े जेनेरिक-AI संकेतकों पर टिका है। अंतर स्पष्ट है, मामूली नहीं।"
2. यह असली दोषों को पकड़ती है
क्योंकि प्रक्रिया स्किल एजेंट को रेंडर करने और देखने के लिए मजबूर करती है, इसने दो प्रोडक्शन-ग्रेड बग पकड़े जिन्हें एक कोड रिव्यू ने चूक दिया था: ऐसी सामग्री जो JavaScript के बिना अदृश्य थी, और एक लेआउट जो मोबाइल पर क्षैतिज रूप से ओवरफ़्लो हो रहा था। एक वन-शॉट जनरेशन ने इनमें से किसी को भी शिप नहीं किया — क्योंकि किसी ने इसे परिणाम देखने पर मजबूर नहीं किया।
3. यह आपकी परंपराओं को हर बार लागू करती है
स्किल्स भरोसेमंद तरीके से प्रोजेक्ट-विशिष्ट निर्णयों को इंजेक्ट करती हैं जिन्हें कोई मॉडल डिफ़ॉल्ट रूप से नहीं चुनेगा: एक सुसंगत साइज़िंग रणनीति, em-आधारित मीडिया क्वेरीज़, असली ब्राउज़र-समर्थन डेटा द्वारा नियंत्रित आधुनिक CSS, reduced-motion सुरक्षा, और लेयर्ड (न कि फ्लैट) शैडो। सैकड़ों रन में यह निरंतरता स्वयं एक डिलिवरेबल है।
जहां वे नहीं जीततीं (कमियां)
ईमानदार हिस्सा। ये असली हैं और इनके आसपास योजना बनाने लायक हैं।
ज्ञान स्किल्स एक मजबूत मॉडल को मुश्किल से हराती हैं
एक फ्रंटियर मॉडल पहले से ही रिलेटिव यूनिट्स, सिमेंटिक HTML, और एक्सेसिबिलिटी की मूल बातें जानता है। इसलिए शुद्धता मूल्यांकन पर, सात ज्ञान स्किल्स अनिवार्य रूप से बिना-सहायता वाले मॉडल के साथ बराबरी पर रहीं — और एक कार्य पर ग्रेडर ने उन्हें थोड़ा कम भी स्कोर किया। उनका मूल्य निरंतरता और कमज़ोर या सस्ते मॉडलों की मदद करना है, न कि किसी शीर्ष-स्तरीय मॉडल पर कच्ची बढ़त।
उनकी लागत अधिक होती है
स्किल्ड रन ने ज्ञान कार्यों पर लगभग 24% अधिक टोकन और 33% अधिक समय का उपयोग किया; पूरा रेंडर-और-दोहराओ लूप और भी भारी है (एक-दो के बजाय दर्जनों बिल्ड-और-जांच चरण)। आप गुणवत्ता को कंप्यूट से खरीद रहे हैं — जब गुणवत्ता मायने रखती है तब सार्थक, और जब काम "सही कोड, तेज़ी से" हो तब बेकार।
सबसे बेहतर लीवर को एक ब्राउज़र की ज़रूरत होती है
प्रक्रिया स्किल की महाशक्ति एक असली ब्राउज़र में रेंडर करना है। बिना ब्राउज़र वाले वातावरण में, यह एक ज्ञान स्किल में घट जाती है और सबसे बड़ा लाभ गायब हो जाता है। टूलचेन की योजना उसी अनुसार बनाएं।
गुणवत्ता को सस्ते में मापना कठिन है
हमारी वस्तुनिष्ठ शुद्धता जांचें गुणवत्ता आंकने में खराब थीं — उन्होंने ज़्यादातर दोनों संस्करणों को पास कर दिया, और डिज़ाइन कार्य पर फ़ॉल्स नेगेटिव उत्पन्न किए। वास्तविक गुणवत्ता मूल्यांकन के लिए एक मानव-शैली के ब्लाइंड न्यायाधीश की ज़रूरत थी। और हमारा गुणवत्ता मूल्यांकन छोटा था: दो कार्य, एक समीक्षक। विश्वसनीय, लेकिन अभी सांख्यिकीय रूप से मज़बूत नहीं।
वह अंतर्दृष्टि जो इसे जोड़ती है
एक वाक्य इसे पकड़ लेता है:
"शुद्धता हल हो गई है। कारीगरी नहीं। सक्षम और असाधारण फ्रंट-एंड के बीच का अंतर वह ज्ञान नहीं है जो मॉडल में कमी है — यह पुनरावृत्ति के माध्यम से लागू किया गया स्वाद है, और जेनेरिक डिफ़ॉल्ट को शिप करने से इनकार है।"
यही कारण है कि अधिक ज्ञान जोड़ने से मुश्किल से फर्क पड़ा, जबकि एक प्रक्रिया जोड़ने — रेंडर करो, आलोचना करो, परिष्कृत करो, शिप किए गए स्वाद के मुकाबले — ने इसमें बहुत फर्क डाला। एक टेक्स्ट निर्देश किसी वन-शॉट को पिक्सेल-परफेक्ट नहीं बना सकता। एक स्किल जो एजेंट को अपने ही काम को देखने और उसे ठीक करने पर मजबूर करती है, बना सकती है।
टीमों के लिए इसका क्या अर्थ है
- एक मजबूत मॉडल से शुद्धता में बढ़त की उम्मीद न करें। यदि आपका मूल्यांकन केवल शुद्धता की जांच करता है, तो स्किल्स बेकार लगेंगी — क्योंकि आप उस चीज़ को माप रहे हैं जो मॉडल पहले से करता है।
- प्रक्रिया में निवेश करें, केवल प्रॉम्प्ट में नहीं। टिकाऊ फायदे उन सत्यापन लूपों से आते हैं जिन्हें एजेंट को चलाना होता है, न कि लंबी निर्देश फ़ाइलों से।
- स्वाद शिप करें, सिद्धांत नहीं। जांचे-परखे, दृढ़ राय वाले डिफ़ॉल्ट हर बार अमूर्त सलाह को हरा देते हैं।
- गुणवत्ता को उस तरह मापें जैसे उपयोगकर्ता इसे अनुभव करते हैं — इसे रेंडर करो, इसे देखो, ब्लाइंड तुलना करो। बूलियन जांचें सुंदरता नहीं देख सकतीं।
- इसके लिए बजट रखें। गुणवत्तापूर्ण आउटपुट में अधिक टोकन और समय लगता है; इसे वहां खर्च करें जहां गुणवत्ता ही मुद्दा है।
सिफारिशें: कमियों को पाटना
ये निष्कर्ष एक ठोस टू-डू सूची की ओर इशारा करते हैं — हमारे अपने स्किल सूट के लिए और किसी भी टीम के लिए जो एक बना रही है:
- ब्लाइंड मूल्यांकन को बड़ा करें। दो कार्य और एक समीक्षक दिशा साबित करते हैं, परिमाण नहीं। पेज प्रकारों में दस से अधिक कार्यों तक विस्तार करें, एक दूसरा AI न्यायाधीश जोड़ें, और कम से कम एक मानव समीक्षक शामिल करें। एक अकेले निर्णय के बजाय जीत दर और विश्वास को ट्रैक करें।
- ट्रिगरिंग को ट्यून करें, केवल सामग्री को नहीं। एक स्किल जो सक्रिय नहीं होती वह बेकार है, और एक जो गलत कार्य पर सक्रिय होती है वह और भी बुरी है। एक स्वचालित विवरण-अनुकूलन पास चलाएं ताकि प्रत्येक स्किल तब सक्रिय हो जब उसे होना चाहिए और तब शांत रहे जब नहीं होना चाहिए।
- प्रक्रिया स्किल को शालीनता से घटने दें। जब कोई ब्राउज़र उपलब्ध न हो, तो इसे यह पहचानना चाहिए और यह मानने के बजाय कि यह रेंडर कर सकती है, अपने ज्ञान और चेकलिस्ट पर वापस लौटना चाहिए — ताकि यह अपने सबसे बड़े लीवर को कभी चुपचाप न खोए।
- ओवरलैप करते ज्ञान को समेकित करें। आठ स्किल्स में कुछ दोहराई गई सतह होती है — आधुनिक CSS, रिस्पॉन्सिवनेस, और परफॉर्मेंस एक ही ज़मीन को छूते हैं। तीक्ष्ण सीमाओं का अर्थ है प्लेटफ़ॉर्म के आगे बढ़ने पर कम रखरखाव।
- इरादे के अनुसार रूट करें। जब गुणवत्ता लक्ष्य हो तब भारी रेंडर-और-दोहराओ लूप का उपयोग करें; "सही कोड, तेज़ी से" के लिए इसे छोड़ दें। सबसे बड़ी बर्बादी एक फेंक देने वाले आंतरिक टूल के लिए कारीगरी-स्तर का कंप्यूट चुकाना है।
- एक कमज़ोर मॉडल पर फिर से मापें। ज्ञान स्किल्स को वहां अधिक मदद करनी चाहिए जहां आधार मॉडल कम सक्षम हो; इसकी पुष्टि करने से लागत-संवेदनशील तैनातियों के लिए उनके असली मूल्य की मात्रा तय होती है।
SplatDev इसे कैसे लागू करता है
यही वह काम है जो हम ग्राहकों के लिए करते हैं: केवल एक कोडबेस पर AI को इंगित करना नहीं, बल्कि उन स्किल्स, गार्डरेल्स, और सत्यापन लूपों की इंजीनियरिंग करना जो इसके आउटपुट को भरोसेमंद रूप से उत्कृष्ट बनाते हैं — और फिर परिणाम को मान लेने के बजाय ईमानदार मूल्यांकन के साथ साबित करना। हम केवल गति नहीं, गुणवत्ता मापते हैं, और हम आपको बताते हैं कि फायदे कहां हैं और कहां नहीं।
ऐसा AI चाहते हैं जो ऐसा काम शिप करे जिसे आप किसी पोर्टफोलियो में रखें — और उसकी सीमाओं का एक ईमानदार लेखा-जोखा?
SplatDev से संपर्क करें — AI के साथ बेहतर बनाएं
या हमें ईमेल करें [email protected] पर