GitHub Copilot ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ವಿನ್ಯಾಸವನ್ನು ಹಾಳುಮಾಡುತ್ತಿದೆ

ನೀವು 47 ಟೇಬಲ್‌ಗಳಿರುವ ಒಂದು Rails schema ಅನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ. ಅದರ ಸಂಬಂಧಗಳು (relationships) ಗೋಜಲಿನಂತೆ ಕಾಣಿಸುತ್ತಿವೆ. ಶುಕ್ರವಾರದೊಳಗೆ ನಿಮಗೆ ಹೊಸ ಫೀಚರ್ ಬೇಕಾಗಿದೆ. ನೀವು ಆ schema ಅನ್ನು Copilot ಗೆ ಪೇಸ್ಟ್ ಮಾಡಿ ಒಂದು migration ಕೇಳುತ್ತೀರಿ.

AI ನಿಮಗೆ ಸರಿಯಾಗಿ ಕಾಣುವ ಕೋಡ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ನೀವು ಅದನ್ನು ಶಿಪ್ (ship) ಮಾಡುತ್ತೀರಿ. ಮೂರು ವಾರಗಳ ನಂತರ, ಒಂದು circular dependency ನಿಮ್ಮ checkout flow ಅನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡುತ್ತದೆ.

ಇದು Copilot ನ ವೈಫಲ್ಯವಲ್ಲ. ಇದು Context Composting.

ನೀವು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು AI ಒಂದು ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ರೀತಿಯಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತಿದ್ದೀರಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅಗತ್ಯತೆಗಳಿಗಾಗಿ ನೀವು ಅದನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತಿಲ್ಲ.

Qiita ನಲ್ಲಿರುವ ಒಬ್ಬ ಜಪಾನೀಸ್ ಡೆವಲಪರ್, ತಂಡಗಳು AI ಅನ್ನು ಬಳಸುವ ರೀತಿಯಲ್ಲಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಿದ್ದಾರೆ. ಅನೇಕ ಪಶ್ಚಿಮದ ಡೆವಲಪರ್‌ಗಳು AI ಗೆ ಕಡಿಮೆ context ನೀಡುವ ಮೂಲಕ ಟೋಕನ್‌ಗಳನ್ನು ಉಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಅವರು ಚಿಕ್ಕ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಸಣ್ಣ ತುಣುಕುಗಳನ್ನು ಬಳಸುತ್ತಾರೆ.

ಕೆಲವು ಜಪಾನೀಸ್ ತಂಡಗಳು context ಅನ್ನು ಒಂದು ವಾಸ್ತುಶಿಲ್ಪದ ಆಸ್ತಿ (architectural asset) ಎಂದು ಪರಿಗಣಿಸುತ್ತವೆ. ಅವರು AI ಗಾಗಿ scaffolding ಆಗಿ schema documentation ಅನ್ನು ಬಳಸುತ್ತಾರೆ. ಮಾಡೆಲ್ ವ್ಯವಹಾರದ ನಿಯಮಗಳು (business rules) ಮತ್ತು state transitions ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಂತೆ ಅವರು ವಿಶೇಷವಾಗಿ ಕಾಮೆಂಟ್‌ಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ.

ಇದು ಒಂದು ಬಲೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಒಂದು ಸ್ಟಾರ್ಟ್‌ಅಪ್ "Copilot-first" ವಿನ್ಯಾಸದ ತತ್ವವನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿರುವುದನ್ನು ನಾನು ನೋಡಿದೆ. AI ಸುಲಭವಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಬಲ್ಲದು ಎಂಬ ಕಾರಣಕ್ಕೆ ಅವರು ಸಂಬಂಧಗಳನ್ನು ಸರಳಗೊಳಿಸಿದರು ಮತ್ತು indexes ಅನ್ನು ಸೇರಿಸಿದರು.

ಇದರ ಪರಿಣಾಮ ಕೆಟ್ಟದಾಗಿತ್ತು:

  • AI ಸಂಕೀರ್ಣ ಸಂಬಂಧಗಳನ್ನು (complex associations) ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗದ ಕಾರಣ ಅವರಲ್ಲಿ 30% ಹೆಚ್ಚು ಟೇಬಲ್‌ಗಳಿದ್ದವು.
  • Query performance ಕುಸಿಯಿತು.
  • Analytical queries 40% ನಿಧಾನವಾದವು.

ಅವರು AI ಓದುವಿಕೆಗೆ (readability) ಆದ್ಯತೆ ನೀಡಿದರು ಮತ್ತು ಮಾನವನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು (human performance) ಬಲಿಗೊಟ್ಟರು.

AI ನಿಮ್ಮ architecture ಅನ್ನು ನಿರ್ಧರಿಸಲು ಬಿಡಬೇಡಿ. ಸಮತೋಲನವನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಈ ಹಂತಗಳನ್ನು ಅನುಸರಿಸಿ:

  • ನಿರ್ಧಾರಗಳನ್ನು ಎರಡು ಬಾರಿ ದಾಖಲಿಸಿ. ಒಂದು AI ಗಾಗಿ ಮತ್ತು ಇನ್ನೊಂದು ಮನುಷ್ಯರಿಗೆ "ಏಕೆ" ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಆವೃತ್ತಿಯನ್ನು ಬರೆಯಿರಿ.
  • ಪ್ರತಿ ವಾರ ಒಂದು AI migration ಅನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ಪರಿಶೀಲಿಸಿ. ಪ್ರತಿಯೊಂದು foreign key ಮತ್ತು index ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿ (trace).
  • ನಿಮ್ಮ AI ceiling ಅನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. AI ವಿಫಲವಾಗುವ ಮೊದಲು ಒಂದು ಸೆಷನ್‌ನಲ್ಲಿ ನೀವು ಎಷ್ಟು ಟೇಬಲ್‌ಗಳ ಬಗ್ಗೆ ವಿವೇಚಿಸಬಹುದು ಎಂಬುದನ್ನು ಗಮನಿಸಿ.
  • ಪ್ರತಿ ಮೂರು ತಿಂಗಳಿಗೊಮ್ಮೆ schema audit ಮಾಡಿ. AI ಇಲ್ಲದಿದ್ದರೆ ಒಬ್ಬ ಮಾನವ ವಾಸ್ತುಶಿಲ್ಪಿ (human architect) ಇದನ್ನೇ ರೀತಿ ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತಿದ್ದರೇ ಎಂದು ಕೇಳಿ.

AI ಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸುವ ಒತ್ತಡ ಹೆಚ್ಚಾಗುತ್ತದೆ. Frameworkಗಳು "AI-optimized" ಪ್ಯಾಟರ್ನ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತವೆ.

ಅತ್ಯುತ್ತಮ ಡೆವಲಪರ್‌ಗಳು AI ಅನ್ನು ವಿರೋಧಿಸುವವರಲ್ಲ. ಬದಲಾಗಿ, AI ಯಾವಾಗ ತಪ್ಪು ದಾರಿಗೆ ಎಳೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಪತ್ತೆಹಚ್ಚುವಷ್ಟು ತಮ್ಮ architectural ಆಲೋಚನಾ ಶಕ್ತಿಯನ್ನು ಚುರುಕಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುವವರೇ ನಿಜವಾದ ಅತ್ಯುತ್ತಮ ಡೆವಲಪರ್‌ಗಳು.

ನಿಮ್ಮ ತಂಡವು AI context ಅನ್ನು ಆಧರಿಸಿ architecture ವಿನ್ಯಾಸಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆಯೇ? ಅದು production ಗೆ ಬಂದಾಗ ಅದರ ಬೆಲೆ (cost) ಏನಾಯಿತು?

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