ಪರಿಶೀಲನಾ ವೆಚ್ಚವೇ ನಿಜವಾದ AI ಕೋಡಿಂಗ್ ವೆಚ್ಚ

ಕೋಡಿಂಗ್‌ಗಾಗಿ AI ಮಾಡೆಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವಾಗ ನಾನು ಒಂದು ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತಿದ್ದೆ.

ಈ ಕೆಲಸಕ್ಕೆ ಯಾವ ಮಾಡೆಲ್ ಸಾಕಷ್ಟು ಬಲವಾಗಿದೆ?

ಆ ಪ್ರಶ್ನೆ ಸರಿಯಾಗಿದೆ. ಆದರೆ ಅದು ಈಗ ನನ್ನ ಮೊದಲ ಪ್ರಶ್ನೆಯಲ್ಲ.

ಉತ್ತಮವಾದ ಪ್ರಶ್ನೆಯೆಂದರೆ: ನಾನು ಫಲಿತಾಂಶವನ್ನು ಎಷ್ಟು ವೇಗವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದು?

ಈ ಮನೋಭಾವವು ನೀವು ಕಡಿಮೆ ವೆಚ್ಚದ ಮಾಡೆಲ್‌ಗಳನ್ನು ಬಳಸುವ ರೀತಿಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಅವುಗಳನ್ನು ದೊಡ್ಡ ಮಾಡೆಲ್‌ಗಳ ದುರ್ಬಲ ಆವೃತ್ತಿಗಳೆಂದು ನೋಡಬೇಡಿ. ಬದಲಾಗಿ, ಕಡಿಮೆ ಪರಿಶೀಲನಾ ಅವಧಿಯಿರುವ ಕೆಲಸಗಳಿಗಾಗಿ ಕೆಲಸಗಾರರಂತೆ ನೋಡಿ.

ಕೆಲವು ಕೆಲಸಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಗ್ಗವಾಗಿದೆ ಏಕೆಂದರೆ ನೀವು ಫಲಿತಾಂಶಗಳನ್ನು ತಕ್ಷಣವೇ ನೋಡಬಹುದು.

• README ಕ್ಲೀನಪ್ • ಬಳಕೆಯ ಉದಾಹರಣೆಗಳು (Usage examples) • ಕೋಡ್ ಕಾಮೆಂಟ್‌ಗಳು (Code comments) • ಚೇಂಜ್‌ಲಾಗ್ ನೋಟ್ಸ್ (Changelog notes) • ಸಣ್ಣ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು • ಇಶ್ಯೂ ಟೆಂಪ್ಲೇಟ್‌ಗಳು (Issue templates)

ಒಂದು ಮಾಡೆಲ್ ಕೆಟ್ಟ README ಪ್ಯಾರಾಗ್ರಾಫ್ ಬರೆದರೆ, ನೀವು ಅದನ್ನು ನೋಡಬಹುದು. ನೀವು ಆ ಕೆಟ್ಟ ಭಾಗವನ್ನು ಅಳಿಸಿಹಾಕಬಹುದು. ಆ ತಪ್ಪು ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡಬಹುದು, ಆದರೆ ಅದಕ್ಕೆ ನಿಮಗೆ ಯಾವುದೇ ವೆಚ್ಚವಾಗುವುದಿಲ್ಲ. ಕಡಿಮೆ ವೆಚ್ಚದ ಮಾಡೆಲ್‌ಗಳಿಗೆ ಇದು ಅತ್ಯುತ್ತಮ ಬಳಕೆ.

ಮುಂದಿನ ವರ್ಗವೆಂದರೆ ಪರೀಕ್ಷಿಸಬಹುದಾದ ಕೆಲಸ (testable work).

ನೀವು ನಿರೀಕ್ಷಿತ ವರ್ತನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಮತ್ತು ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ರನ್ ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ, ಮೊದಲ ಡ್ರಾಫ್ಟ್‌ಗಾಗಿ ಅಗ್ಗದ ಮಾಡೆಲ್ ಬಳಸಿ. ನೀವು ಮಾಡೆಲ್‌ಗೆ ಸ್ಪಷ್ಟವಾದ ಮಿತಿಗಳನ್ನು ನೀಡಬೇಕು.

ಹೀಗೆ ಹೇಳಬೇಡಿ: ಈ ಹೆಲ್ಪರ್ (helper) ಗೆ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಸೇರಿಸಿ.

ಹೀಗೆ ಹೇಳಿ: ಖಾಲಿ ಇನ್‌ಪುಟ್ (empty input), ನಲ್ ಇನ್‌ಪುಟ್ (null input), ಡೂಪ್ಲಿಕೇಟ್ ವ್ಯಾಲ್ಯೂಗಳು, ಅಮಾನ್ಯ ಕಾನ್ಫಿಗರೇಶನ್ (invalid config), ಡಿಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಸಾಮಾನ್ಯ ಇನ್‌ಪುಟ್‌ಗಾಗಿ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಸೇರಿಸಿ. ರನ್‌ಟೈಮ್ ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಡಿ.

ಇದು ಮಾಡೆಲ್ ಅನ್ನು ಪರಿಶೀಲನಾ ಚೌಕಟ್ಟಿನೊಳಗೆ ಕೆಲಸ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ.

ಕೆಲವು ಕೆಲಸಗಳಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಟೆಸ್ಟ್‌ಗಳ ಕೊರತೆಯಿರುತ್ತದೆ ಆದರೆ ಸ್ಪಷ್ಟವಾದ ಮ್ಯಾನುಯಲ್ ಪರಿಶೀಲನೆಗೆ ಅವಕಾಶವಿರುತ್ತದೆ.

• CLI ಔಟ್‌ಪುಟ್ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ • ಕಾನ್ಫಿಗರೇಶನ್ ಉದಾಹರಣೆಗಳು • ಮೈಗ್ರೇಶನ್ ಡ್ರೈ ರನ್ ನೋಟ್ಸ್ • ಸಣ್ಣ ಡೇಟಾ ಕನ್ವರ್ಷನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು

ಇವುಗಳಿಗಾಗಿ, ಮಾಡೆಲ್ ಅನ್ನು ಇವುಗಳನ್ನು ಸೇರಿಸಲು ಕೇಳಿ:

  • ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ರನ್ ಮಾಡುವುದು
  • ಯಾವ ಇನ್‌ಪುಟ್ ಬಳಸಬೇಕು
  • ಯಾವ ಔಟ್‌ಪುಟ್ ನಿರೀಕ್ಷಿಸಬೇಕು
  • ಯಾವ ಎಡ್ಜ್ ಕೇಸ್‌ಗಳನ್ನು (edge cases) ಪರಿಶೀಲಿಸಬೇಕು

ಒಂದು ಮಾಡೆಲ್ ತನ್ನ ಕೆಲಸವನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸಬೇಕೆಂದು ವಿವರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಆ ಕೋಡ್ ಅನ್ನು ನಂಬಬೇಡಿ.

ಸಣ್ಣ ರಿಫ್ಯಾಕ್ಟರ್‌ಗಳು (refactors) ಅಪಾಯಕಾರಿ. ಒಂದು ಡಿಫ್ (diff) ಚಿಕ್ಕದಾಗಿ ಮತ್ತು ಸ್ವಚ್ಛವಾಗಿ ಕಾಣಿಸಬಹುದು. ಆದರೆ ಅದು ಯಾವುದೋ ಗುಪ್ತ ಹಾದಿಯಲ್ಲಿ, ಡಿಫಾಲ್ಟ್ ವ್ಯಾಲ್ಯೂ ಅಥವಾ ಪರ್ಮಿಷನ್ ಚೆಕ್‌ನಲ್ಲಿ ವರ್ತನೆಯನ್ನು ಬದಲಾಯಿಸಬಹುದು.

ಈ ಕೆಳಗಿನವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಕೆಲಸವಾದಾಗ ನಿಮ್ಮ ಅಪಾಯದ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸಿ:

  • ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗಳು (Fallbacks)
  • ಡಿಫಾಲ್ಟ್‌ಗಳು (Defaults)
  • ರೂಟಿಂಗ್ (Routing)
  • ಪರ್ಮಿಷನ್‌ಗಳು (Permissions)
  • ಬಿಲ್ಲಿಂಗ್ (Billing)
  • ರೇಟ್ ಲಿಮಿಟ್‌ಗಳು (Rate limits)
  • ಮೈಗ್ರೇಷನ್‌ಗಳು (Migrations)
  • ಬ್ಯಾಕ್‌ವರ್ಡ್ಸ್ ಕಾಂಪ್ಯಾಟಿಬಿಲಿಟಿ (Backwards compatibility)

ಇಂತಹ ತಪ್ಪುಗಳನ್ನು ಸಾಮಾನ್ಯ ಕೋಡ್ ರಿವ್ಯೂನಲ್ಲಿ ನೋಡುವುದು ಕಷ್ಟ. ಇವುಗಳಿಗೆ ಆಳವಾದ ಸಂದರ್ಭದ (context) ಅಗತ್ಯವಿದೆ.

ನಿಮ್ಮ ಕೆಲಸವನ್ನು ಪರಿಶೀಲನಾ ವೆಚ್ಚದ ಆಧಾರದ ಮೇಲೆ ವಿಂಗಡಿಸಿ:

  • ಕಡಿಮೆ ಪರಿಶೀಲನಾ ವೆಚ್ಚ: ಡ್ರಾಫ್ಟ್ ಮಾಡಲು ಕಡಿಮೆ ವೆಚ್ಚದ ಮಾಡೆಲ್ ಬಳಸಿ.
  • ಮಧ್ಯಮ ಪರಿಶೀಲನಾ ವೆಚ್ಚ: ಕಡಿಮೆ ವೆಚ್ಚದ ಮಾಡೆಲ್ ಬಳಸಿ, ನಂತರ ಮನುಷ್ಯರು ತಿದ್ದುಪಡಿ ಮಾಡಿ.
  • ಹೆಚ್ಚಿನ ಪರಿಶೀಲನಾ ವೆಚ್ಚ: ಟೆಸ್ಟ್‌ಗಳು ಮತ್ತು ಮನುಷ್ಯರ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ ಬಲವಾದ ಮಾಡೆಲ್ ಬಳಸಿ.

ಗಾತ್ರ ಮುಖ್ಯವಲ್ಲ. ಪರಿಶೀಲಿಸುವುದು ಕಷ್ಟವಾಗಿದ್ದರೆ ಸಣ್ಣ ಕೆಲಸವೂ ದುಬಾರಿಯಾಗುತ್ತದೆ.

AI ಕೋಡಿಂಗ್‌ನ ದುಬಾರಿ ಭಾಗವು ಜನರೇಷನ್ (generation) ಅಲ್ಲ. ಅದು ನಂಬಿಕೆ (trust).

Source: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354

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