पडताळणीचा खर्च (Verification Cost) हाच खरा AI कोडिंग खर्च आहे

कोडिंगसाठी AI मॉडेल निवडताना मी एक प्रश्न विचारायचो.

या कामासाठी कोणते मॉडेल पुरेसे सक्षम आहे?

तो प्रश्न ठीक आहे. पण आता तो माझा पहिला प्रश्न उरलेला नाही.

अधिक चांगला प्रश्न असा आहे: मी आउटपुट किती लवकर पडताळू (verify करू) शकतो?

ही मानसिकता कमी खर्चाच्या मॉडेल्सचा वापर करण्याची तुमची पद्धत बदलून टाकते. त्यांना मोठ्या मॉडेल्सची कमकुवत आवृत्ती म्हणून पाहू नका. त्याऐवजी, ज्या कामांसाठी पडताळणीचा मार्ग (verification path) छोटा आहे, अशा कामांसाठी ते 'कामगार' आहेत असे समजा.

काही कामे तपासणे स्वस्त असते कारण तुम्ही निकाल लगेच पाहू शकता.

• README cleanup • Usage examples • Code comments • Changelog notes • Small formatting scripts • Issue templates

जर मॉडेलने README चा एखादा खराब परिच्छेद लिहिला, तर तुम्हाला तो लगेच दिसतो. तुम्ही तो खराब भाग काढून टाकता. ती चूक त्रासदायक असली तरी, त्यासाठी तुमचा फारसा खर्च होत नाही. स्वस्त मॉडेल्ससाठी हा सर्वोत्तम वापर आहे.

पुढची श्रेणी म्हणजे 'टेस्ट करता येण्याजोगे काम' (testable work).

जर तुम्ही अपेक्षित वर्तन (expected behavior) परिभाषित करू शकत असाल आणि टेस्ट सूट (test suite) चालवू शकत असाल, तर पहिल्या ड्राफ्टसाठी स्वस्त मॉडेल वापरा. तुम्ही मॉडेलला स्पष्ट मर्यादा (boundaries) देणे आवश्यक आहे.

असे म्हणू नका: Add tests for this helper.

असे म्हणा: Add tests for empty input, null input, duplicate values, invalid config, default config, and normal input. Do not change runtime code.

यामुळे मॉडेलला एका पडताळणी चौकटीत (verification frame) काम करण्यास भाग पाडले जाते.

काही कामांमध्ये ऑटोमेटेड टेस्ट्स नसतात, परंतु स्पष्ट मॅन्युअल तपासणी (manual checks) करणे शक्य असते.

• CLI output formatting • Config examples • Migration dry run notes • Small data conversion scripts

यांच्यासाठी, मॉडेलला खालील गोष्टी समाविष्ट करण्यास सांगा:

  • कोड कसा चालवायचा (How to run the code)
  • कोणते इनपुट वापरावे (What input to use)
  • काय आउटपुट अपेक्षित आहे (What output to expect)
  • कोणते एज केसेस (edge cases) तपासावे

जर मॉडेल स्वतःचे काम कसे पडताळायचे हे स्पष्ट करू शकत नसेल, तर त्या कोडवर विश्वास ठेवू नका.

लहान रिफॅक्टर्स (refactors) धोकादायक असतात. 'डिफ' (diff) छोटा आणि स्वच्छ दिसू शकतो. परंतु, एखाद्या लपलेल्या मार्गात (hidden path), डिफॉल्ट व्हॅल्यूमध्ये किंवा परवानगी तपासणीमध्ये (permission check) वर्तन बदलू शकते.

जेव्हा एखादे काम खालील गोष्टींशी संबंधित असते, तेव्हा तुमचा जोखीम स्तर (risk level) वाढवा:

  • Fallbacks
  • Defaults
  • Routing
  • Permissions
  • Billing
  • Rate limits
  • Migrations
  • Backwards compatibility

या चुका मानक कोड रिव्ह्यूमध्ये (standard code review) शोधणे कठीण असते. त्यासाठी सखोल संदर्भाची (deep context) आवश्यकता असते.

तुमच्या कामाचे वर्गीकरण पडताळणी खर्चावरून (verification cost) करा:

  • कमी पडताळणी खर्च: ड्राफ्ट तयार करण्यासाठी कमी खर्चाचे मॉडेल वापरा.
  • मध्यम पडताळणी खर्च: कमी खर्चाचे मॉडेल वापरा, त्यानंतर मानवी सुधारणा (human edits) करा.
  • उच्च पडताळणी खर्च: टेस्ट्स आणि मानवी रिव्ह्यूसह शक्तिशाली मॉडेल वापरा.

आकार महत्त्वाचा नाही. जर एखादे छोटे काम पडताळणे कठीण असेल, तर ते महाग पडते.

AI कोडिंगमधील महागडा भाग जनरेशन (generation) नाही, तर तो विश्वास (trust) आहे.

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

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