દરેક AI કોડિંગ એજન્ટ 'diff' આપી શકે છે. વાસ્તવિક સમસ્યા એ જાણવામાં છે કે તે diff કોઈ કેન્દ્રિત અને સુનિશ્ચિત પ્રક્રિયામાંથી આવ્યું છે—કે પછી તમારા રિપોઝિટરીમાં કરવામાં આવેલા એવા ઉતાવળા સર્ચમાંથી જે અચાનક સાચું નીકળી આવ્યું હોય. અત્યારે, મોટાભાગની ટીમો આ તફાવત પારખી શકતી નથી.
આ કોઈ ટેકનિકલ મર્યાદા નથી. આ વિઝિબિલિટી (દૃશ્યતા) ની સમસ્યા છે.
જ્યારે કોઈ એજન્ટ પ્રોડક્શન કોડની ત્રણ લાઇન લખે છે, ત્યારે બની શકે કે તેણે ત્રણ ફાઇલો વાંચી હોય અને ટેસ્ટ ચલાવ્યા હોય. અથવા બની શકે કે તેણે ચાલીસ બિનસંબંધિત ફાઇલોને સ્પર્શ કર્યો હોય, ડઝનબંધ નિષ્ફળ કમાન્ડ્સ ચલાવ્યા હોય, ડિપેન્ડન્સી ઇન્સ્ટોલેશન બગડવાને કારણે તમારા ટેસ્ટ સ્યુટને સ્કીપ કરી દીધો હોય, અને આ બધું કરવા માટે તમારી પાસેથી ચાર્જ પણ લીધો હોય. બંને કિસ્સામાં diff સમાન જ દેખાય છે. પ્રક્રિયાનો રેકોર્ડ વગર, તમે અંતિમ પરિણામની ગુણવત્તા વિશે માત્ર અંદાજ જ લગાવી શકો છો.
ચેટ લોગ્સ (Chat Logs) શા માટે રસીદો (Receipts) નથી
ઘણા ટૂલ્સ કામના પુરાવા તરીકે ચેટ ટ્રાન્સક્રિપ્ટ ઓફર કરે છે. ટ્રાન્સક્રિપ્ટ એ રસીદ નથી. તે તમારા ટેબલ પર ફેંકાયેલા સ્પેરપાર્ટ્સના બોક્સ જેવું છે. તેમાં દરેક વિચાર પ્રક્રિયા (thought loop), દરેક નિષ્ફળ પ્રયાસ, દરેક સિસ્ટમ પ્રોમ્પ્ટ અને દરેક બિનજરૂરી ટૂલ કોલ શામેલ હોય છે. જો તમારે ત્રણ લાઇનના પેચને વેલિડેટ કરવા માટે હજારો લાઇનનું સંવાદ વાંચવું પડે, તો તમારી રિવ્યુ વર્કફ્લો પહેલેથી જ બગડી ગઈ છે તેમ કહેવાય.
માનવીય ધ્યાન મર્યાદિત છે. એજન્ટનો હેતુ માનસિક મહેનત બચાવવાનો છે, હોમવર્ક આપવાનો નથી. ટ્રાન્સક્રિપ્ટ રિવ્યુઅરને ડિટેક્ટિવ બનવા માટે કહે છે. જ્યારે રસીદ એક નજરમાં જ જવાબ આપી દે છે.
એક ઉપયોગી રસીદ એ વ્યવહારુ સારાંશ છે. તે તમને જણાવે છે કે એજન્ટને શું કરવાનું કહેવામાં આવ્યું હતું, તેણે ખરેખર શું કર્યું અને તે તેના નિષ્કર્ષ પર કેવી રીતે પહોંચ્યો. તે નિષ્ફળતાને છુપાવતી નથી, પરંતુ તેને સ્પષ્ટ રીતે દર્શાવે છે.
એક સારી રસીદ કેવી દેખાવી જોઈએ
રિવ્યુ કરી શકાય તેવી રસીદ ઊંડાણપૂર્વક તપાસ કર્યા વગર ચોક્કસ પ્રશ્નોના જવાબ આપવી જોઈએ:
- કાર્ય શું હતું? ઈચ્છિત ફેરફારનું સ્પષ્ટ વર્ણન, માત્ર અસ્પષ્ટ પ્રોમ્પ્ટનું પુનરાવર્તન નહીં.
- કઈ ફાઇલો વાંચવામાં આવી હતી? જેથી તમે નક્કી કરી શકો કે એજન્ટ યોગ્ય સ્ત્રોતોમાંથી સંદર્ભ (context) મેળવી રહ્યો છે કે નહીં.
- કઈ ફાઇલો એડિટ કરવામાં આવી હતી? ફેરફારનું અંતિમ પ્રતિક (footprint).
- કયા કમાન્ડ્સ ચલાવવામાં આવ્યા હતા? બિલ્ડ સ્ટેપ્સ, લિંટર્સ, ફોર્મેટર્સ અથવા એજન્ટ દ્વારા ઉપયોગમાં લેવાયેલ કસ્ટમ સ્ક્રિપ્ટ્સ.
- કયા કમાન્ડ્સ નિષ્ફળ ગયા? માત્ર સફળતા જ નહીં. નિષ્ફળતાઓ દર્શાવે છે કે એજન્ટને ક્યાં તાત્કાલિક સુધારા કરવા પડ્યા અથવા ક્યાં તેણે પ્રયાસ છોડી દીધો.
- કયા ટેસ્ટ પાસ થયા અથવા સ્કીપ કરવામાં આવ્યા? સ્કીપ કરેલા ટેસ્ટ એ ચેતવણીનો સંકેત (red flag) છે. રસીદમાં જણાવવું જોઈએ કે તેઓ શા માટે સ્કીપ કરવામાં આવ્યા હતા.
- કુલ ખર્ચ કેટલો હતો? ટોકન્સ, API કોલ્સ અને કમ્પ્યુટ ટાઈમ. આમાં માત્ર મોડેલનો જ નહીં, પરંતુ તમારા આર્કિટેક્ચરનો ખર્ચ પણ સામેલ છે.
આ ફોર્મેટ રિવ્યુને પુરાતત્વીય ખોદકામમાંથી ઝડપી સેનિટી ચેક (sanity check) માં બદલી નાખે છે. એક સિનિયર એન્જિનિયર રસીદને ઝડપથી જોઈને એક મિનિટથી ઓછા સમયમાં કહી શકવો જોઈએ કે "આ યોગ્ય લાગે છે" અથવા "આ શંકાસ્પદ લાગે છે".
માત્ર ઇતિહાસ નહીં, પણ ફૂટપ્રિન્ટ (Footprint) વાંચો
એજન્ટ રનનું ફૂટપ્રિન્ટ કામનું સ્વરૂપ દર્શાવે છે. શું એજન્ટ ટિકિટની મર્યાદામાં રહ્યો? અથવા શું તે બિનસંબંધિત મોડ્યુલ્સમાં ભટકી ગયો અને એવી વસ્તુઓ બદલી નાખી જેની કોઈએ માંગણી કરી નહોતી? રસીદ જે "Files Read" ની સાથે "Files Edited" ની યાદી આપે છે, તે આ બાબતને સ્પષ્ટ બનાવે છે.
ફૂટપ્રિન્ટ પુનરાવર્તનને પણ પ્રગટ કરે છે. એજન્ટ જે વારંવાર એક જ નિષ્ફળતાનો સામનો કરે છે—જેમ કે એક જ કોન્ફિગ ફાઇલ ત્રણ વાર વાંચવી, અથવા નિષ્ફળ જતા ટેસ્ટને વારંવાર ચલાવવી—તે કમ્પ્યુટ અને કોન્ટેક્સ્ટ વિન્ડોનો બગાડ કરી રહ્યો છે. તે પેટર્ન દેખાવી જોઈએ. જો કોઈ એજન્ટ માઈગ્રેશન સ્ક્રિપ્ટ ચલાવવા માટે નવ પ્રયાસો કરે, તો રસીદમાં તે જણાવવું જોઈએ. આ માહિતી તમે આઉટપુટનું મૂલ્યાંકન કેવી રીતે કરો છો તે બદલી નાખે છે. બ્રુટ-ફોર્સ અરાજતા દ્વારા ઉત્પાદિત "સાચો" diff, સ્વચ્છ રીતે ઉત્પાદિત સાચા diff જેવો નથી.
ખરાબ ડિઝાઇનનો છુપો ખર્ચ
ખર્ચ એટલે માત્ર પ્રતિ ટોકન કિંમત નથી. ખરાબ રીતે ડિઝાઇન કરેલ વર્કફ્લો એજન્ટ એક કેરેક્ટર જ જનરેટ કરે તે પહેલાં જ તેને મોંઘો બનાવી દે છે. ફૂલેલા (bloated) ટૂલ સ્કીમા, બિનજરૂરી ફાઇલ ઇન્ડેક્સિંગ અને અતિશય વ્યાપક સિસ્ટમ પ્રોમ્પ્ટ્સ આ બધું કોન્ટેક્સ્ટ વિન્ડોને વધારે છે. રસીદ દ્વારા આ વધારાના ખર્ચ (overhead) ને ખુલ્લો પાડવો જોઈએ.
જો જનરેશન સસ્તું બને પણ રિવ્યુ અઘરું બને, તો તમે કંઈ જ મેળવ્યું નથી. તમે માત્ર અવરોધ (bottleneck) ને એક જગ્યાએથી બીજી જગ્યાએ ખસેડ્યો છે. એન્જિનિયરનો સમય સામાન્ય રીતે ટીમમાં સૌથી દુર્લભ સંસાધન હોય છે. દરેક પુલ રિક્વેસ્ટ (pull request) પર રિવ્યુનો સમય ૩૦ મિનિટ વધારીને API ખર્ચમાં પાંચ ડોલર બચાવવા એ ખૂબ જ ખરાબ સોદો છે. રસીદ તમને આ સોદાનું સીધું ઓડિટ કરવામાં મદદ કરે છે.
પ્રામાણિકતા એ એક ફીચર છે
એક ઉપયોગી રસીદ જ્યારે જરૂર હોય ત્યારે અસ્વસ્થતા પેદા કરનારી હોવી જોઈએ. તેણે એવા તથ્યો રજૂ કરવા જોઈએ જે એજન્ટને બિનકાર્યક્ષમ બનાવે, કારણ કે તે પ્રામાણિકતા આગામી માનવીય નિર્ણયને ઝડપી અને વધુ સારો બનાવે છે.
ઉદાહરણો મહત્વના છે:
- "એક લાઇનના ફેરફાર માટે 37 ફાઇલો વાંચી."
- "
npm installપીઅર ડિપેન્ડન્સી (peer dependency) સંઘર્ષ સાથે નિષ્ફળ જતાં ટેસ્ટ સ્કીપ કરવામાં આવ્યા." - "એજન્ટે દાખલ કરેલા ઇમ્પોર્ટને ઠીક કરવા માટે વિનંતી કરેલ સ્કોપની બહાર
utils.pyમાં ફેરફાર કર્યો." - "લિંટર (linter) 4 વખત ચલાવ્યું; પાથ મિસકોન્ફિગરેશનને કારણે પ્રથમ ત્રણ નિષ્ફળ ગયા."
આ રસીદમાં રહેલી ભૂલો નથી. તે સંકેતો છે. તેઓ રિવ્યુઅરને જણાવે છે કે ક્યાં શંકા કરવાની જરૂર છે. તેઓ પ્લેટફોર્મ ટીમને પણ જણાવે છે કે વર્કફ્લોમાં ક્યાં સુધારાની જરૂર છે.
નાના રન, સ્પષ્ટ દેખરેખ
એજન્ટોને મોટા પાયે મુક્ત રીતે કામ કરવા દેવાની કુદરતી લાલચ હોય છે. આખી સર્વિસને રિફેક્ટર કરવા માટે એક જ વિશાળ પ્રોમ્પ્ટ આપવો ઝડપી લાગે છે. પણ તે નથી. તે કામનો એવો મોટો ઢગલો બનાવે છે જેનું રિવ્યુ કરવું અશક્ય હોય છે. બદલાયેલી એંસી ફાઇલોમાંથી કઈ ફાઇલોમાં ફેરફાર ઇરાદાપૂર્વક કરવામાં આવ્યા હતા તે શોધવામાં તમારું આખું બપોર વીતી જશે.
નાના અને તપાસી શકાય તેવા રન વધુ સારા છે. કાર્ય માટે સ્પષ્ટ સીમાઓ નક્કી કરો. એજન્ટ જે ફાઇલો વાંચી શકે છે અને જે ફાઇલો લખી શકે છે તેની યાદી અલગ રાખો. નિષ્ફળ ગયેલા કમાન્ડ્સનો ઇતિહાસ સાચવો જેથી નિષ્ફળતાના મુદ્દાઓ સ્પષ્ટ દેખાય. સ્કીપ કરેલા વેરિફિકેશન્સને સ્પષ્ટપણે દર્શાવો. સર્ચ APIs થી લઈને ટેસ્ટ રનર્સ સુધીના દરેક બાહ્ય ટૂલના ઉપયોગની નોંધ લો.
ધ્યેય સંપૂર્ણ સ્વાયત્તતા (autonomy) નથી. એવી સંપૂર્ણ સ્વાયત્તતા જેને કોઈ માનવી ચકાસી ન શકે, તે માત્ર જવાબદારી સાથેનું ઓટોમેશન છે. સાચું લક્ષ્ય રિવ્યુએબિલિટી (reviewability) છે. એજન્ટનું દરેક આઉટપુટ સરળતાથી મંજૂર અથવા અસ્વીકાર કરી શકાય તેવું હોવું જોઈએ. એવો કોઈ અસ્પષ્ટ મધ્યમ માર્ગ ન હોવો જોઈએ જ્યાં તમે તપાસ કરવા માટે ખૂબ થાકી ગયા હોવ એટલે કોડ સ્વીકારી લો.
કોઈપણ કોડિંગ એજન્ટ માટેની કસોટી
કોઈપણ એજન્ટ અથવા પ્લેટફોર્મ અપનાવતા પહેલા, એક પ્રશ્ન પૂછો: શું તે માનવીને આગલું સ્ટેપ આત્મવિશ્વાસ સાથે મંજૂર કરવા માટે પૂરતા પુરાવા છોડી શકે છે?
જો જવાબ 'હા' હોય, તો તે ટૂલ પ્રોફેશનલ વર્કફ્લોમાં બંધબેસે છે. જો જવાબ 'ના' હોય, તો તમે ઉત્પાદકતા (productivity) નથી ખરીદી રહ્યા. તમે એક એવું રહસ્ય ખરીદી રહ્યા છો જે ક્યારેક કમ્પાઈલ થાય છે. વીકેન્ડ સાઇડ પ્રોજેક્ટ માટે તે ઠીક છે, પરંતુ પ્રોડક્શન એન્જિનિયરિંગ માટે તે અસ્વીકાર્ય છે.
જે ટીમો એજન્ટના આઉટપુટને તપાસ્યા વગરની ભેટ તરીકે લે છે, તેઓ અંતે અજાણતા થયેલા સ્કોપ ક્રીપ (scope creep) દ્વારા દાખલ થયેલ સૂક્ષ્મ બગ (bug) સાથે પ્રોડક્ટ રિલીઝ કરશે. ડિફ (diff) નિર્દોષ લાગશે. રસીદ સત્ય જણાવતી હોત.
રસીદની માંગ કરો. રિવ્યુ માટે ડિઝાઇન કરો. વિશ્વાસ એ વ્યૂહરચના નથી. પુરાવા એ છે.
AI ટૂલિંગ અને ડેવલપર વર્કફ્લો વિશે વધુ પ્રેક્ટિકલ ચર્ચાઓ માટે, તમે GyaanSetu on Telegram પર સમુદાયમાં જોડાઈ શકો છો.