GitHub Copilot तुमच्या डेटाबेस डिझाइनचा नाश करत आहे

तुम्ही ४७ टेबल्स असलेल्या Rails schema कडे पाहत आहात. त्यातील संबंध (relationships) एखाद्या स्पॅगेटीसारखे गुंतागुंतीचे वाटत आहेत. तुम्हाला शुक्रवारपर्यंत एक नवीन फीचर हवे आहे. तुम्ही तो schema Copilot मध्ये पेस्ट करता आणि मायग्रेशनसाठी (migration) विचारता.

AI तुम्हाला असा कोड देते जो योग्य वाटतो. तुम्ही तो शिप (ship) करता. तीन आठवड्यांनंतर, एका circular dependency मुळे तुमचा checkout flow क्रॅश होतो.

ही Copilot ची चूक नाही. हे 'Context Composting' आहे.

तुम्ही तुमचा डेटाबेस अशा प्रकारे डिझाइन करत आहात जो AI एका सिंगल प्रॉम्प्टमध्ये समजू शकेल. तुम्ही तो तुमच्या ॲप्लिकेशनच्या गरजांसाठी (requirements) डिझाइन करत नाही आहात.

Qiita वरील एका जपानी डेव्हलपरने टीम्स AI चा वापर कशा प्रकारे करतात यातील फरक नोंदवला आहे. अनेक पाश्चात्य डेव्हलपर्स AI ला कमी कॉन्टेक्स्ट देऊन टोकन्स वाचवण्याचा प्रयत्न करतात. ते लहान प्रॉम्प्ट्स आणि छोट्या तुकड्यांचा (chunks) वापर करतात.

काही जपानी टीम्स कॉन्टेक्स्टला एक 'architectural asset' मानतात. ते AI साठी स्केफोल्डिंग (scaffolding) म्हणून schema documentation चा वापर करतात. मॉडेलला बिझनेस रूल्स (business rules) आणि स्टेट ट्रान्झिशन्स (state transitions) समजतील अशा पद्धतीने ते विशेषतः कमेंट्स लिहितात.

यामुळे एक सापळा तयार होतो.

मी एका स्टार्टअपला "Copilot-first" डिझाइन फिलॉसॉफी स्वीकारताना पाहिले. त्यांनी संबंध (relationships) सोपे केले आणि फक्त AI ला ते सहज स्कॅन करता यावेत म्हणून इंडेक्स (indexes) जोडले.

त्याचे परिणाम वाईट होते:

  • AI गुंतागुंतीचे असोसिएशन (associations) हाताळू शकले नाही, त्यामुळे त्यांच्याकडे ३०% जास्त टेबल्स झाले.
  • क्वेरी परफॉर्मन्स (Query performance) कमी झाला.
  • ॲनालिटिकल क्वेरीज (Analytical queries) ४०% मंदावल्या.

त्यांनी AI च्या वाचनीयतेसाठी (readability) ऑप्टिमाइझ केले आणि मानवी कामगिरीचा (human performance) बळी दिला.

AI ला तुमचे आर्किटेक्चर ठरवू देऊ नका. संतुलन राखण्यासाठी या पायऱ्या फॉलो करा:

  • निर्णय दोनदा डॉक्युमेंट करा. एक व्हर्जन AI साठी आणि दुसरे व्हर्जन मानवांसाठी "का" (why) स्पष्ट करणारे लिहा.
  • दर आठवड्याला एक AI मायग्रेशन मॅन्युअली (manually) तपासा. प्रत्येक फॉरेन की (foreign key) आणि इंडेक्सचा मागोवा घ्या.
  • तुमच्या AI सीलिंगचा (ceiling) मागोवा घ्या. AI फेल होण्यापूर्वी तुम्ही एका सेशनमध्ये किती टेबल्सबद्दल तर्क करू शकता, याची नोंद ठेवा.
  • दर तिमाहीला schema ऑडिट करा. AI शिवाय एखादा मानवी आर्किटेक्ट या पद्धतीने डिझाइन करेल का, असा प्रश्न स्वतःला विचारा.

AI साठी डिझाइन करण्याचा दबाव वाढत जाईल. फ्रेमवर्क्स "AI-optimized" पॅटर्न रिलीज करतील.

सर्वोत्तम डेव्हलपर्स ते नसतील जे AI ला विरोध करतात. तर ते असतील जे त्यांचे आर्किटेक्चरल विचार इतके तीक्ष्ण ठेवतील की AI त्यांना चुकीच्या मार्गावर नेल्यास ते ओळखू शकतील.

तुमच्या टीमने AI कॉन्टेक्स्टभोवती आर्किटेक्चर डिझाइन करायला सुरुवात केली आहे का? जेव्हा ते प्रोडक्शनमध्ये (production) आले, तेव्हा त्याची किंमत काय होती?

Source: https://dev.to/xu_xu_b2179aa8fc958d531d1/github-copilot-is-rewriting-how-you-think-about-database-design-and-not-in-a-good-way-1691

Optional learning community: https://t.me/GyaanSetuAi