વર્ષો સુધી, આર્ટિફિશિયલ ઇન્ટેલિજન્સ એડિટરમાં તમારી બાજુમાં બેસીને આગળ શું આવશે તેનો અંદાજ લગાવતું હતું. તમે એક લાઇન લખતા; તે પછીની લાઇન સૂચવતું. આર્કિટેક્ચર, ડિબગિંગ અને સિન્ટેક્સ પર હજુ પણ તમારો જ અધિકાર હતો. હવે આ વ્યવસ્થાનો અંત આવ્યો છે.
આપણે Intent-Driven Development તરફ આગળ વધી રહ્યા છીએ. તમે લૂપ્સ (loops) અને કન્ડિશનલ્સ (conditionals) ટાઈપ કરવાનું બંધ કરશો. તેના બદલે, તમારે જે પરિણામ જોઈએ છે તેનું વર્ણન કરશો. એક એજન્ટ તે લક્ષ્યને સમજી લેશે, પગલાંઓનું આયોજન કરશે, કોડ લખશે, ટેસ્ટ ચલાવશે અને તમે પરિણામ જોતા પહેલા જ પોતાની ભૂલો સુધારી લેશે. કીબોર્ડ હવે મુખ્ય સાધન નથી રહ્યું, પરંતુ સ્પષ્ટ વિચારસરણી (clear thinking) મુખ્ય સાધન છે.
લાઇન-બાય-લાઇન કોડિંગનો અંત
જૂની કાર્યપ્રણાલી તમને દરેક ઈરાદાને કમ્પાઈલર સમજી શકે તેવી ચોક્કસ ભાષામાં અનુવાદ કરવા માટે મજબૂર કરતી હતી. તમે બિઝનેસ જરૂરિયાતને તમારા મનમાં રાખતા હતા, અને પછી તેને મેન્યુઅલી ફંક્શન્સ, ઈમ્પોર્ટ્સ, એરર હેન્ડલિંગ અને ટેસ્ટ કેસમાં વિભાજિત કરતા હતા. Intent-Driven Development આ અનુવાદના સ્તરને નાબૂદ કરે છે.
ધારો કે તમારે પેમેન્ટ વેબહૂક (payment webhook) ઇન્ટિગ્રેટ કરવાની જરૂર છે. અગાઉ, તમે રૂટ હેન્ડલર લખતા, પેલોડ પાર્સ કરતા, સિગ્નેચર વેલિડેટ કરતા, ટ્રાન્ઝેક્શનની અંદર ડેટાબેઝ અપડેટ કરતા અને રસીદ ઈમેલ ક્યુ (queue) કરતા. હવે તમે જરૂરિયાતનું વર્ણન કરો છો: “Validate the incoming Stripe webhook, record the event idempotently, and trigger the receipt flow. Roll back if the database write fails.” એજન્ટ હેન્ડલર લખે છે, પાર્સિંગ સ્ટ્રેટેજી પસંદ કરે છે, રિટ્રાય લોજિક તૈયાર કરે છે અને ટેસ્ટ જનરેટ કરે છે. તમારી ભૂમિકા લેખક (author) માંથી નિર્દેશક (director) માં બદલાઈ જાય છે.
આ ફક્ત એટલા માટે જ કામ કરે છે કારણ કે એજન્ટ માત્ર કોડ જનરેશન પર અટકતો નથી. તે એક લૂપમાં પ્રવેશે છે.
એજન્ટ લૂપની અંદર
મુખ્ય કામ હવે માનવીય ટાઈપિંગ કે મેન્યુઅલ ડિબગિંગ નથી. તે જનરેશન અને વેલિડેશન વચ્ચેનું એક ચુસ્ત ચક્ર છે. એજન્ટ કોડ બનાવે છે, તેને તમારા ટેસ્ટ સ્યુટ સામે ચલાવે છે, આઉટપુટ વાંચે છે અને પોતાની રીતે નિષ્ફળતાઓ સુધારે છે. મિસિંગ ઈમ્પોર્ટ, ટાઈપ મિસમેચ, ફેઈલિંગ એસર્શન — એજન્ટ સ્ટેક ટ્રેસ જુએ છે, ફાઈલ એડિટ કરે છે અને સ્યુટ ફરીથી ચલાવે છે. તમે તે લૂપમાં નથી હોતા. આ ચક્ર મશીનની ગતિએ ચાલે છે.
જ્યારે લૂપ પોતે તૂટી જાય ત્યારે તમે હસ્તક્ષેપ કરો છો. કદાચ એજન્ટ બે ડિપેન્ડન્સીઝ વચ્ચેનો સંઘર્ષ ઉકેલી શકતો નથી, અથવા તે એવો કોડ સતત જનરેટ કરે છે જે યુનિટ ટેસ્ટ પાસ કરે છે પરંતુ ઉચ્ચ સ્તરના બિઝનેસ નિયમોનું ઉલ્લંઘન કરે છે. આ સીમાઓ પર માનવીય નિર્ણય હજુ પણ મહત્વનો છે.
તમારી સાચી નોકરી: Constraint Designer અને Edge-Case Hunter
જો મશીન ફંક્શન્સ લખે છે, તો તમારા માટે શું બાકી રહે છે? બે વસ્તુઓ, અને તે સિન્ટેક્સ ટાઈપ કરવા કરતાં વધુ અઘરી છે.
પ્રથમ, તમે એવા કન્સ્ટ્રેન્ટ્સ (constraints) લખો છો જે એજન્ટને સાચા માર્ગ પર રાખે છે. એજન્ટ પાસે વ્યાપક જ્ઞાન છે પરંતુ તમારા ચોક્કસ વાતાવરણ (environment) ની સમજ નથી. તમારે તેને કહેવું પડશે: “Use only the internal billing API, never log raw card tokens, and keep the response latency under two hundred milliseconds.” આ સીમાઓ માત્ર સામાન્ય પ્રોમ્પ્ટ્સ નથી. તે એવી વિશિષ્ટતાઓ (specifications) છે જે સફળતા અથવા નિષ્ફળતા નક્કી કરે છે.
બીજું, તમે એ દસ ટકા કિસ્સાઓને પકડો છો જ્યાં એજન્ટ નિષ્ફળ જાય છે. એજન્ટ સામાન્ય પાથને સારી રીતે સંભાળે છે. તેઓ સૂક્ષ્મ રેસ કન્ડિશન (race conditions), અસ્પષ્ટ બિઝનેસ લોજિક એજ કેસ અને તેમના ટ્રેનિંગ ડેટામાં રહેલી સુરક્ષા ધારણાઓ પર અટકી જાય છે. તમારી વિશેષતા વેબહૂક હેન્ડલર અને રિફંડ ક્રોન જોબ વચ્ચેની રેસને ઓળખવામાંથી અથવા જનરેટ કરેલું રિટ્રાય લોજિક ચાર્જ ડુપ્લીકેટ કરી શકે છે તે ઓળખવામાંથી આવે છે. મશીન પ્રમાણભૂત સમસ્યા ઉકેલે છે. તમે જોખમી અપવાદ (exception) પકડો છો.
કોડ રિવ્યુને Verification Harness સાથે બદલો
જ્યારે એજન્ટ રાતોરાત પચાસ ફાઇલો બનાવી શકે છે, ત્યારે તમે માત્ર ડિફ્સ (diffs) જોઈને તે “સાચા લાગે છે કે નહીં” તે રીતે રિવ્યુ કરી શકતા નથી. આટલી મોટી સંખ્યામાં ફાઇલોને માનવીય રીતે તપાસવી અશક્ય છે. તમારે એવા હાર્નેસની જરૂર છે જે કોડ તમારા સુધી પહોંચે તે પહેલાં ભૂલો પકડી લે.
આ હાર્નેસ ત્રણ સ્તંભો પર આધારિત છે.
Durable execution. એજન્ટના કાર્યો ઘણીવાર સિંગલ રિક્વેસ્ટ ટાઈમઆઉટ કરતા લાંબા સમય સુધી ચાલે છે. જો કોઈ સ્ટેપ કામચલાઉ નેટવર્ક સમસ્યાને કારણે નિષ્ફળ જાય, તો હાર્નેસ સ્થિર થાય છે, ફરી પ્રયાસ કરે છે અને સ્ટેટને બગાડ્યા વિના ફરી શરૂ થાય છે. કામમાં વિક્ષેપ છતાં કાર્ય ચાલુ રહે છે.
Structured outputs. એજન્ટ યોગ્ય રીતે બનાવેલી કોન્ફિગરેશન ફાઇલ આપશે તેવી આશા રાખવાને બદલે, તમે અગાઉથી જ કરાર (contract) લાગુ કરો છો. JSON Schema જેવા સાધનો આઉટપુટને તરત જ વેલિડેટ કરે છે. જો એજન્ટ જરૂરી ફિલ્ડ છોડી દે છે અથવા ખોટો ડેટા પ્રકાર વાપરે છે, તો કોડ તમારા રિપોઝિટરીમાં પહોંચે તે પહેલાં હાર્નેસ તેને નકારી દે છે.
Dynamic guardrails. એજન્ટ પાસે સિક્રેટ્સ વાંચવા અથવા પ્રોડક્શન ડેટાબેઝમાં લખવા માટે મુક્ત છૂટ હોવી જોઈએ નહીં. હાર્નેસ પરમિશનને ડાયનેમિક રીતે નિયંત્રિત કરે છે, એજન્ટને સેન્ડબોક્સ (sandboxing) કરે છે જેથી તે ફક્ત નિર્દિષ્ટ ટેસ્ટ ડેટાબેઝ અને ઇન્ટરનલ એન્ડપોઇન્ટ્સને જ સ્પર્શી શકે. તમે દરેક લાઇન રિવ્યુ નથી કરી રહ્યા, પરંતુ તમે એજન્ટની આસપાસની સુરક્ષા કવચનું ઓડિટ કરી રહ્યા છો.
જ્યારે કોડ કામ કરે છે પણ પ્રોડક્ટ નિષ્ફળ જાય છે
અહીં એક વિરોધાભાસ છે. હાર્નેસ ખરાબ કોડને પકડી લે છે. તે ખરાબ હેતુને પકડી શકતું નથી.
જો તમારું સ્પષ્ટીકરણ કહે છે કે, “દરેક નવા વપરાશકર્તાને સ્વાગત ઈમેલ મોકલો,” તો એજન્ટ તે ઈમેલ મોકલતો ચોખ્ખો, ટેસ્ટ કરેલો કોડ લખશે. તેને એ ખબર નહીં હોય કે તમારો અર્થ એ હતો કે, “સ્વાગત ઈમેલ ત્યારે જ મોકલો જો વપરાશકર્તાએ તેમના સરનામાની ચકાસણી કરી હોય, માર્કેટિંગ માટે સંમતિ આપી હોય, અને તેમના સ્થાનિક ટાઈમઝોનમાં વ્યવસાયિક કલાકો દરમિયાન સાઇન અપ કર્યું હોય.” કોડ તકનીકી રીતે ખામી રહિત છે પરંતુ વ્યાવસાયિક રીતે જોખમી છે.
Intent-Driven Development માં વાસ્તવિક જોખમ અસ્પષ્ટ સ્પષ્ટીકરણ છે. અસ્પષ્ટ હેતુ એવું સોફ્ટવેર બનાવે છે જે પાઠ્યપુસ્તક જેવી સુંદરતા સાથે ખોટી સમસ્યાનો ઉકેલ લાવે છે. આથી જ તમારે તમારા સ્પષ્ટીકરણોને વાસ્તવિક સંપત્તિ તરીકે ગણવા જોઈએ. તેને વર્ઝન કરો. સ્ટેકહોલ્ડર્સ સાથે તેની સમીક્ષા કરો. એજન્ટ નિર્માણ શરૂ કરે તે પહેલાં વાસ્તવિક વર્કફ્લો સામે તેને ચકાસો. ચેટ બોક્સમાં લખાયેલું પ્રોમ્પ્ટ એ સ્પષ્ટીકરણ નથી. તે એક જવાબદારી (liability) છે.
એન્જિનિયરિંગ જજમેન્ટ ઉપરના સ્તરે જાય છે
એન્જિનિયરિંગ જજમેન્ટ અદૃશ્ય થઈ રહી નથી. તે ઉચ્ચ સ્તરે સ્થળાંતર કરી રહી છે.
હવે તમે મેપ કેવી રીતે ઇટરેટ કરવો અથવા ક્લાસ હાયરાર્કી કેવી રીતે બનાવવી તેના પર માનસિક ઉર્જા ખર્ચતા નથી. તમે તે આ બાબતો પર ખર્ચો છો કે નિષ્ફળતાના સમયે સિસ્ટમે શું કરવું જોઈએ, કયો ડેટા ક્યારેય જાહેર ન કરવો જોઈએ, અને વિતરિત સેવાઓ (distributed services) માં કયા ઇન્વેરિયન્ટ્સ જળવાઈ રહેવા જોઈએ. કોડિંગની કળા હવે જરૂરિયાતો (requirements) ની કળા બની રહી છે.
આનો અર્થ એ છે કે તમારા સ્પષ્ટીકરણોને તે જ સચોટતાની જરૂર છે જે તમે એક સમયે તમારા કોડ પર લાગુ કરતા હતા. તમારી મર્યાદાઓનું ચોકસાઈથી નામ આપો. નિષ્ફળતાના પ્રકારો (failure modes) સ્પષ્ટ રીતે વ્યાખ્યાયિત કરો. બિઝનેસ નિયમો એટલી જ સ્પષ્ટતાથી જણાવો જેટલી સ્પષ્ટતા તમે તમારા ટાઇપ્સ (types) જાહેર કરવા માટે કરતા હતા. એજન્ટ અમલીકરણ (implementation) સંભાળશે. તમારે ખાતરી કરવાની રહેશે કે અમલીકરણ બનાવવા જેવું છે.
તમારા ગુણવત્તાના ધોરણોને પુલ રિક્વેસ્ટ (pull request) થી બદલીને પ્રોમ્પ્ટ (prompt) પર લઈ જાઓ. પહેલા હાર્નેસ બનાવો. બીજું સ્પષ્ટીકરણ લખો. પછી મશીનને સિન્ટેક્સ સંભાળવા દો જ્યારે તમે સમસ્યા યોગ્ય રીતે વ્યાખ્યાયિત કરવામાં આવી છે અને સીમાઓ સુરક્ષિત રીતે દોરવામાં આવી છે તેના પર ધ્યાન કેન્દ્રિત કરો.
જો તમે આ પરિવર્તન પાછળના વિચારોને વધુ ઊંડાણપૂર્વક જાણવા માંગતા હોવ, તો Intent-Driven Development પરની મૂળ ચર્ચા અહીં ઉપલબ્ધ છે. AI-native એન્જિનિયરિંગ અંગેની ચાલુ ચર્ચાઓ માટે, તમે GyaanSetu community માં પણ જોડાઈ શકો છો.