કોડિંગ એજન્ટ્સનું મૂલ્યાંકન કરતી એન્જિનિયરિંગ ટીમો સામાન્ય રીતે ખોટા પ્રશ્નથી શરૂઆત કરે છે. તેઓ જાણવા માંગે છે કે એજન્ટ કેટલો સ્વાયત્ત (autonomous) બની શકે છે. તે પાઇપલાઇનનો કેટલો ભાગ સંભાળી શકે છે? શું તે કોઈને હેરાન કર્યા વગર સ્પેક લખી શકે છે, રિપોઝિટરી એડિટ કરી શકે છે અને પ્રોડક્શનમાં પુશ કરી શકે છે? ડેમો આ ઘેલછાને સરળ બનાવે છે. તમે એક સ્લીક વર્કફ્લો જુઓ છો જ્યાં એક સિંગલ પ્રોમ્પ્ટ એડિટ્સ અને ડિપ્લોયમેન્ટ્સની શ્રેણી શરૂ કરે છે, અને સહજ વૃત્તિ તમારી પોતાની સંસ્થામાં તે જ ક્ષમતા મેળવવાની હોય છે. પરંતુ ગ્લેમર એ ખરાબ ડિઝાઇન સિદ્ધાંત છે. વધુ સારા પ્રશ્નો ઘણા ઓછા રોમાંચક છે: આ વસ્તુને સત્તા કોણે આપી, તે ખરેખર કઈ સિસ્ટમ્સને સ્પર્શી શકે છે, અને જ્યારે તે અનિવાર્યપણે કંઈક ખોટું કરે છે ત્યારે શું થાય છે?
સ્વાયત્તતાનો જાળ
રોમાંચક સ્વાયત્તતા એ એક જાળ છે. તે આપણને એવા બોટ્સને વધાવવા માટે તૈયાર કરે છે જે સ્પેસિફિકેશન્સ જનરેટ કરે છે, રિપોઝિટરીઝમાં ફેરફાર કરે છે અને કોડ ડિપ્લોય કરે છે, જ્યારે શાંતિથી એવું કહે છે કે કાર્ય પૂર્ણ થઈ ગયું છે. તે એન્જિનિયરિંગ નથી. તે શેલ એક્સેસ (shell access) સાથેનો વિશ્વાસનો ખેલ છે. કામ પોતે જ બનાવવું ખૂબ જ સરળ બની જાય છે. કોઈપણ મોડેલ સેકન્ડોમાં કોડ, ડોક્યુમેન્ટેશન અથવા આર્કિટેક્ચર પ્લાન બનાવી શકે છે. પરંતુ સોફ્ટવેર ડેવલપમેન્ટમાં વાસ્તવિક ખર્ચ ક્યારેય ટાઇપિંગ સ્પીડ રહ્યો નથી. તે હંમેશા વેરિફિકેશન (validation), રિવ્યુ અને એ સાચો નિર્ણય લેવાનો રહ્યો છે કે હા, આ સાચું છે અને શિપ કરવા માટે સુરક્ષિત છે. જનરેટ કરેલું કામ સસ્તું છે. મંજૂરી (Approval) મોંઘી છે. જે કંપનીઓ મંજૂરીને સ્વચ્છ અને સુસંગત રીતે કેવી રીતે સંભાળવી તે સમજી લેશે, તેઓ જ ખરેખર વિશ્વસનીય સિસ્ટમ્સ શિપ કરશે.
સેલ્ફ-રિવ્યુ કેમ નિષ્ફળ જાય છે
જોખમો અનુમાનિત પેટર્નમાં દેખાય છે. એક મોડેલ પ્લાન ડ્રાફ્ટ કરે છે અને પછી તે પ્લાન સારો છે કે નહીં તેનું મૂલ્યાંકન કરે છે. એક એજન્ટ તમારા કોડબેઝમાં ફેરફાર કરે છે અને તમને સમજાવે છે કે તેના ફેરફારો શા માટે સુરક્ષિત છે. એક ટૂલ કમાન્ડ એક્ઝિક્યુટ કરે છે અને પરવાનગી લેવાને બદલે માફી માંગે છે. આ દરેક એક જ મૂળભૂત નિષ્ફળતા દર્શાવે છે. જો કોઈ એજન્ટ સ્પેસિફિકેશન બનાવે છે, તો તે સત્ય બનતા પહેલા તે એજન્ટની બહારની કોઈ વસ્તુએ તેના પર સહી (sign off) કરવી જોઈએ. જો કોઈ એજન્ટ કોડમાં ફેરફાર કરે છે, તો અલગ પ્રક્રિયાએ diff ની તપાસ કરવી જોઈએ. જનરેટરને તેના પોતાના વેલિડેટર તરીકે કામ કરવા દેવું એ શોર્ટકટ નથી. તે સુવિધાના વેશમાં છુપાયેલું એક સ્ટ્રક્ચરલ બગ (structural bug) છે.
પ્રોમ્પ્ટ્સ એ પરમિશન સિસ્ટમ નથી
તમે ચતુર શબ્દોથી એજન્ટને સુરક્ષિત કરી શકતા નથી. મોડેલને સાવધ રહેવા અથવા કંઈપણ ડિલીટ કરતા પહેલા પૂછવા માટે કહેવાથી કોઈ સીમા (boundary) ઊભી થતી નથી. પ્રોમ્પ્ટ્સ એ પરમિશન સિસ્ટમ નથી. તમે એજન્ટને પ્રોડક્શનની નજીક લાવતા પહેલા, તેની ક્ષમતાઓનું પ્રમાણિક ઇન્વેન્ટરી હોવી જરૂરી છે. શું તે આખી રિપોઝિટરી વાંચી શકે છે? શું તે શેલ કમાન્ડ્સ એક્ઝિક્યુટ કરી શકે છે? શું તે બ્રાઉઝર ખોલી શકે છે? શું તે તેના કોન્ટેક્સ્ટ વિન્ડોમાં ગ્રાહકનો ડેટા ખેંચી શકે છે? મોટાભાગની ટીમો પાસે સંપૂર્ણ જવાબો હોતા નથી. તેઓ માની લે છે કે ટૂલ સેન્ડબોક્સ (sandbox) પૂરતું મર્યાદિત છે જ્યારે વાસ્તવમાં તેની પાસે ક્રિટિકલ પાથ્સ (critical paths) માટે રાઈટ એક્સેસ હોય છે. પહેલા સપાટીના વિસ્તારને (surface area) મેપ કરો. પછી દીવાલો બનાવો.
ટાયર્ડ કંટ્રોલ સિસ્ટમ બનાવો
એકવાર તમે એજન્ટ શું કરી શકે છે તે સમજી લો, પછી જોખમને ઘર્ષણ (friction) સાથે મેચ કરતી કંટ્રોલ સિસ્ટમ ડિઝાઇન કરો. ઓછું જોખમ ધરાવતી ક્રિયાઓ, જેમ કે આંતરિક ડોક્યુમેન્ટેશન અપડેટ કરવું અથવા સુસંગત કોડ ફોર્મેટિંગ કરવું, આપમેળે ચાલી શકે છે. મધ્યમ જોખમ ધરાવતી ક્રિયાઓ, જેમ કે મોડ્યુલ રિફેક્ટરિંગ કરવું અથવા નવી ડિપેન્ડન્સી ઉમેરવી, તે ચેકપોઈન્ટ પર આવવી જોઈએ જ્યાં માનવી અથવા વેરિફાઇડ ટેસ્ટ સ્યુટ તે પગલાની પુષ્ટિ કરે. ઉચ્ચ જોખમ ધરાવતી ક્રિયાઓ, પ્રોડક્શનમાં ડિપ્લોય કરવું, ઇન્ફ્રાસ્ટ્રક્ચર બદલવું અથવા સંવેદનશીલ ડેટા એક્સેસ કરવો, તેના માટે અલગ એપ્રૂવરની જરૂર છે જે જનરેશનમાં સામેલ ન હોય. દરેક એક ક્રિયાએ ઓડિટ ટ્રેલ (audit trail) છોડવો જોઈએ. તમે બરાબર જાણી શકવા સક્ષમ હોવા જોઈએ કે કઈ ફાઇલો વાંચવામાં આવી હતી, કયા ટૂલ્સનો ઉપયોગ કરવામાં આવ્યો હતો અને કયા નિર્ણયો લેવામાં આવ્યા હતા. એજન્ટિક ડેવલપમેન્ટ એ રિવ્યુ છોડવા માટેનું લાઇસન્સ નથી. કંટાળાજનક ઘર્ષણ એ એક ફીચર છે. યોગ્ય એપ્રુવલ ગેટ સર્કિટ બ્રેકરની જેમ કામ કરે છે જ્યારે વસ્તુઓ પલટવા લાગે છે.
સીમાઓને જોખમ સાથે મેચ કરો
તમારી સીમાઓને વાસ્તવિક જોખમ મુજબ સેટ કરો. દરેક માર્કડાઉન ફોર્મેટિંગ ફેરફારને કમ્પ્લાયન્સ સેરેમની (compliance ceremony) બનાવવાથી તમારી ટીમ અટકી જશે. પરંતુ એજન્ટ આત્મવિશ્વાસ ધરાવતો લાગે છે એટલે ઉચ્ચ-જોખમ ધરાવતી ક્રિયાઓને નુકસાન વગરની માનવી એ પણ એટલું જ મૂર્ખામીભર્યું છે. ધ્યેય પ્રમાણસર નિયંત્રણ છે, નાટકીય પ્રતિબંધ નહીં.
આર્ટિફેક્ટ્સ નાના અને અવલોકનક્ષમ રાખો
સૌથી ઉપયોગી એજન્ટ સિસ્ટમો તમને વિશાળ સ્વાયત્ત રન દ્વારા પ્રભાવિત કરવાનો પ્રયાસ કરતી નથી. તેઓ નાના, સમીક્ષા કરી શકાય તેવા આર્ટિફેક્ટ્સ બનાવે છે. એક સચોટ યોજના. એક કેન્દ્રિત ડિફ. એક વાંચી શકાય તેવું લોગ. વિશાળ સ્વાયત્ત એક્ઝિક્યુશન ડિબગ કરવા માટે દુઃસ્વપ્ન સમાન હોય છે. જ્યારે પચાસ ફાઇલોના એજન્ટ સત્ર પછી કંઈક બગડે છે, ત્યારે તમારે ઈરાદો, એક્ઝિક્યુશન અને સાઇડ ઇફેક્ટ્સ - આ બધું એકસાથે ઉકેલવું પડે છે. અસરનો વ્યાપ નાનો રાખો. એજન્ટે કઈ ફાઇલો વાંચી અને કયા ટૂલ્સનો ઉપયોગ કર્યો તે જાણવા પર ભાર મૂકો. અવલોકનક્ષમ સિસ્ટમો જ જાળવી રાખવા યોગ્ય સિસ્ટમો છે. બ્લેક-બોક્સ સ્વાયત્તતા એ માત્ર વધુ સારા માર્કેટિંગ સાથેનું ટેકનિકલ દેવું છે.
એક્સેસ આપતા પહેલા છ પ્રશ્નો
કોઈપણ એજન્ટને વાસ્તવિક જવાબદારી સોંપતા પહેલા, છ કઠિન પ્રશ્નો સાથે તમારા સેટઅપનું પ્રેશર-ટેસ્ટ કરો.
- સિસ્ટમ પાસે વાસ્તવમાં કઈ ક્ષમતાઓ છે?
- કયા કાર્યો ડિફોલ્ટ રીતે નકારવામાં આવે છે, જે સિસ્ટમ પ્રોમ્પ્ટમાં નમ્ર વાક્ય દ્વારા અટકાવવાને બદલે ઇન્ફ્રાસ્ટ્રક્ચર સ્તરે બ્લોક કરવામાં આવ્યા છે?
- કયા કાર્યો માટે સ્પષ્ટ મંજૂરીની જરૂર છે?
- એજન્ટ તેનો ઉપયોગ કરે તે પહેલા કયા આર્ટિફેક્ટ્સને ફ્રીઝ કરવામાં આવે છે, જેથી તે તેના પોતાના ઇનપુટ્સમાં છૂપી રીતે ફેરફાર ન કરી શકે?
- જનરેટરથી સંપૂર્ણપણે અલગ કયો વેલિડેટર અંતિમ આઉટપુટનો નિર્ણય લે છે?
- કયું લોગ કોઈપણ અસ્પષ્ટતા વિના સાબિત કરે છે કે વાસ્તવમાં શું થયું હતું?
આ મૂળભૂત એન્જિનિયરિંગ હાઈજીન છે. જનરેટરને વેલિડેટરથી અલગ કરો. માનવીય સત્તાને સીમા પર રાખો