यह कैसे काम करता है
कोड ही मापदंड है। मॉडल ड्राफ्ट बनाता है। इंसान निर्णय लेता है।
Language models refactoring patterns में अच्छे हैं लेकिन counting में कमजोर, इसलिए हर step सही tool से किया जाता है। हर step audit trail में लिखा जाता है।
- 01
संग्रह करें
Parsers कोड, OSGi configs, dispatcher, indexes और आपके BPA report को पढ़ते हैं।
निर्धारितकेवल कोड से किया जाता है: एक ही इनपुट हमेशा एक ही परिणाम देता है। - 02
वर्गीकरण करें
हर finding को file और line के साथ एक Cloud Service pattern से मैप किया जाता है।
निर्धारितकेवल कोड से किया जाता है: एक ही इनपुट हमेशा एक ही परिणाम देता है। - 03
योजना बनाएं
हमारा private model risk को rank करता है और हर pattern के लिए change का draft तैयार करता है।
हमारे सर्वर पर AIहमारे अपने सर्वर पर मॉडल द्वारा किया जाता है, फिर किसी व्यक्ति को दिखने से पहले कोड द्वारा जाँचा जाता है। - 04
Refactor
छोटे pull requests, एक समय में एक pattern, notes और tests के साथ।
हमारे सर्वर पर AIहमारे अपने सर्वर पर मॉडल द्वारा किया जाता है, फिर किसी व्यक्ति को दिखने से पहले कोड द्वारा जाँचा जाता है। - 05
समीक्षा
एक senior AEM engineer हर pull request को approve करता है। आपकी टीम merge करती है।
मानवनामित व्यक्ति अनुमोदन करता है; इसके बिना कुछ भी मर्ज नहीं होता। - 06
सत्यापित करें
Cloud Manager build, AEM Analyser और parity checks; सभी steps log किए जाते हैं।
निर्धारितकेवल कोड से किया जाता है: एक ही इनपुट हमेशा एक ही परिणाम देता है।
Step by step
हर stage पर क्या होता है
Fact sheet सबसे पहले आती है और सिर्फ code द्वारा बनाई जाती है। Model सिर्फ fact sheet में मौजूद चीज़ों पर काम करता है, और बिना इंसान की approval के कुछ भी आपकी main branch तक नहीं पहुँचता।
संग्रह करें
Parsers आपके repository, OSGi configurations, dispatcher files, package filters, Oak indexes, आपके BPA report और content statistics को पढ़ते हैं। आउटपुट एक fact sheet है: हर finding के साथ file, line और rule। कोई model शामिल नहीं है, इसलिए inventory पूर्ण और repeatable है।
वर्गीकरण करें
हर finding को open rule set (33 code rules और 31 BPA codes) से एक Cloud Service pattern से मैच किया जाता है, जिसमें document किया गया fix, automatable होने की डिग्री और planning hours शामिल हैं।
योजना बनाएं
हर pattern के लिए, हमारे अपने server पर model target (Cloud Service या Edge Delivery block), risk, और यह कि इसे mechanically fix किया जा सकता है या नहीं, सुझाव देता है। यह केवल fact sheet में मौजूद items के बारे में सोचता है, इसलिए यह findings नहीं बना सकता।
Refactor
5 कोडमॉड्स बिना किसी AI के मैकेनिकल रीराइट्स लागू करते हैं। उन पैटर्न को मॉडल द्वारा रीराइट किया जाता है जिन्हें निर्णय की आवश्यकता होती है, और उन्हें किसी व्यक्ति द्वारा देखे जाने से पहले डिटर्मिनिस्टिक चेक्स पास करने होंगे। जहां Adobe के अपने माइग्रेशन टूल्स किसी पैटर्न को कवर करते हैं, वहां उनका उपयोग किया जाता है।
समीक्षा
एक वरिष्ठ AEM इंजीनियर हर पुल रिक्वेस्ट की समीक्षा और स्वीकृति करता है, और आपकी टीम मर्ज करती है। रिजेक्शन और एडिट्स फीडबैक के रूप में वापस दिए जाते हैं ताकि अगला बदलाव बेहतर हो।
सत्यापित करें
Cloud Manager build और code quality gates, AEM Analyser, generated regression tests, मुख्य पेजों की visual comparisons और URLs, redirects और metadata का SEO parity check।
AI कहाँ चलता है
आपका code हमारे operate किए जाने वाले models के साथ रहता है
Client code उन AI models द्वारा process किया जाता है जो हमारे operate किए जाने वाले servers पर चलते हैं। इसे third-party AI services को भेजा नहीं जाता।
- Default रूप से Private। Routing rule code में enforce किया जाता है: client code वाले tasks external AI service पर नहीं जा सकते।
- External models सिर्फ consent के साथ। यदि किसी task के लिए Anthropic's Claude जैसे external model का लाभ हो, तो हम पहले पूछते हैं और सिर्फ आपकी written consent के साथ, audit log में record करके, उसे उपयोग करते हैं।
- इंसान देखने से पहले जाँच हो जाती है। हर AI rewrite को deterministic checks से pass करना होता है, जैसे कि कोई imports invented न हों।
- हर step record किया जाता है। Model calls, check results और approvals को hash-chained log में append किया जाता है। किसी entry को edit या delete करने से chain टूट जाता है, इसलिए आप साबित कर सकते हैं कि किसने क्या approve किया और किस model ने हर change produce किया।
Limits
जो चीज़ें हम automate नहीं करते
कुछ काम ऐसे लोगों की ज़रूरत होता है जो आपके बिज़नेस को जानते हैं। ये काम इंजीनियर्स और आपके टीम के साथ रहते हैं।
सुरक्षा और इंटीग्रेशन डिज़ाइन
अन्य सिस्टम के साथ ऑथेंटिकेशन, सुरक्षा और इंटीग्रेशन इंजीनियर्स द्वारा डिज़ाइन किए जाते हैं, जनरेटेड नहीं।
प्रोडक्ट निर्णय
AEM Communities को बदलना या साइट को Edge Delivery Services पर ले जाना आपके टीम द्वारा पोर्टल में लिए गए निर्णय हैं।
आपके मुख्य ब्रांच में मर्ज करना
हर pull request किसी नामित इंजीनियर द्वारा स्वीकृत होता है, और आपकी टीम इसे मर्ज करती है।
फैक्ट शीट से शुरू करें
रेडीनेस स्कैन आपके ब्राउज़र में एक प्रारंभिक फैक्ट शीट देता है: हर फाइंडिंग के साथ फाइल, लाइन, फिक्स और प्रयास। साइन-अप नहीं, और कुछ अपलोड नहीं होता।