મોટાભાગના ડેવલપર્સ AI કોડિંગ એજન્ટ્સનું મૂલ્યાંકન ખોટી રીતે કરે છે. તેઓ ત્રણ ટૂલ્સ ઇન્સ્ટોલ કરે છે, ટર્મિનલ ખોલે છે, અને એક જ સામાન્ય પ્રોમ્પ્ટ રન કરે છે: build me a landing page. પછી તેઓ જે આઉટપુટ સૌથી સુંદર દેખાય તે પસંદ કરે છે. આ ટેસ્ટ તમને એના વિશે લગભગ કંઈ જ જણાવતું નથી કે આ સિસ્ટમ્સ વાસ્તવિક કોડબેઝમાં કેવી રીતે કામ કરે છે.

વધુ સારો પ્રશ્ન એ નથી કે કયા મોડેલે કોડિંગ બેન્ચમાર્ક પર સૌથી વધુ સ્કોર કર્યો છે. તે એ છે કે કઈ સિસ્ટમ કાચી બુદ્ધિ (raw intelligence) લઈ શકે છે અને ખરેખર તેને અસ્તવ્યસ્ત, મલ્ટી-ફાઇલ સોફ્ટવેર પ્રોજેક્ટ્સ પર લાગુ કરી શકે છે. મોડેલ મગજ પૂરું પાડે છે. હાર્નેસ (harness)—જેમાં કોન્ટેક્સ્ટ મેનેજમેન્ટ, ટૂલ એક્સેસ, એરર હેન્ડલિંગ અને પરમિશન લેયર્સનો સમાવેશ થાય છે—તે હાથ અને આંખો પૂરું પાડે છે. અણઘડ હાથ ધરાતું તેજસ્વી મગજ તમારા પ્રોડક્શન કોડને એટલી જ ઝડપથી તોડી નાખશે જેટલી ઝડપથી એક સામાન્ય મગજ તોડી શકે છે.

જ્યારે તમે નવતાઈના ડેમોથી આગળ વધીને એન્જિનિયરિંગના કામમાં પ્રવેશ કરો છો, ત્યારે ખરેખર અગ્રણી ટૂલ્સ વચ્ચેનો તફાવત અહીં છે.

હાર્નેસ (Harness) એ જ પ્રોડક્ટ છે

એજન્ટ હાર્નેસ નક્કી કરે છે કે રિપોઝિટરીની અંદર બુદ્ધિ કેવી રીતે કાર્ય કરે છે. તે નિયંત્રિત કરે છે કે એજન્ટ કેટલો કોન્ટેક્સ્ટ યાદ રાખે છે, તે કઈ ફાઇલોને સ્પર્શી શકે છે, તે નિષ્ફળ ટર્મિનલ કમાન્ડમાંથી કેવી રીતે રિકવર થાય છે, અને શું તે તમારી .env ફાઇલ ડિલીટ કરતા પહેલા અટકવાનું જાણે છે કે નહીં. બે એજન્ટો સમાન બેન્ચમાર્ક સ્કોર ધરાવતા મોડેલ્સ પર ચાલી શકે છે, પરંતુ જો એક એજન્ટ ત્રણ ફાઇલ એડિટ કર્યા પછી મોડ્યુલ્સ વચ્ચેના સંબંધો ગુમાવી દે છે જ્યારે બીજો તમારી આર્કિટેક્ચરનો સુસંગત નકશો જાળવી રાખે છે, તો બીજો એજન્ટ રિફેક્ટર (refactor) પૂર્ણ કરશે અને પહેલો એજન્ટ રિગ્રેશન (regressions) લાવશે.

આ રીતે વિચારો: મોડેલ એ એન્જિન છે, પરંતુ હાર્નેસ એ સસ્પેન્શન, બ્રેક્સ અને સ્ટીયરિંગ છે. જો તમે રસ્તા પર ટકી ન શકો તો પાવરનો કોઈ અર્થ નથી.

Claude Code: ઊંડું રિપોઝિટરી રીઝનિંગ

Claude Code ત્યારે ચમકે છે જ્યારે તમારે ફક્ત કોડ ઉમેરવાને બદલે જટિલ કોડબેઝને સમજવાની જરૂર હોય. તેની શક્તિ મોડ્યુલ્સ વચ્ચેના સંબંધોનું માનસિક મોડેલ જાળવી રાખવાની છે. જો તમે એવા બગને ટ્રેસ કરી રહ્યા હોવ જે ઓથેન્ટિકેશન મિડલવેર (authentication middleware) થી શરૂ થાય છે, ડેટાબેઝ રેપર (database wrapper) દ્વારા ફેલાય છે, અને વેલિડેશન યુટિલિટીમાં દેખાય છે, તો Claude Code તે કડી જાળવી રાખવાનો પ્રયત્ન કરે છે. તે ખાસ કરીને મોટા રિફેક્ટર્સના આયોજન માટે ઉપયોગી છે જ્યાં તમારે આંતરિક API નું નામ બદલવાની, દરેક કન્ઝ્યુમરને અપડેટ કરવાની અને કોઈ ભૂલી ગયેલા યુટિલિટી ફોલ્ડરમાં શેડોઇંગ ઇમ્પોર્ટ (shadowed import) ને ભૂલ્યા વિના ટેસ્ટ્સને એડજસ્ટ કરવાની જરૂર હોય છે.

તેનો મહત્તમ લાભ લેવાનો વ્યવહારુ રસ્તો તમારા પ્રોજેક્ટ રૂટ પર CLAUDE.md ફાઇલનો ઉપયોગ કરવાનો છે. આ દસ્તાવેજ એક સંસ્થાકીય મેમરી (institutional memory) તરીકે કામ કરે છે જેને તમે કોડિફાઇ કરી શકો છો. તમે નિર્દિષ્ટ કરી શકો છો કે તમામ લોગિંગ માટે console.log ને બદલે આંતરિક રેપરનો ઉપયોગ કરવો જોઈએ, ડેટાબેઝ માઈગ્રેશન ફક્ત /infra/migrations માં જ રહેવું જોઈએ, અથવા દરેક નવા React કમ્પોનન્ટ માટે અનુરૂપ Storybook ફાઇલ હોવી જોઈએ. આ ગાર્ડરેલ (guardrail) વગર, કોઈપણ એજન્ટ તેના ટ્રેનિંગ ડિફોલ્ટ્સ તરફ વળી જશે. આનાથી, Claude Code એવા નિયમોનું પાલન કરી શકે છે જેને સ્થાપિત કરવામાં તમારી ટીમને મહિનાઓ લાગ્યા હોય.

જ્યારે તમારું કામ શોધખોળ અને આર્કિટેક્ચરલ હોય ત્યારે આ ટૂલ પસંદ કરો. જો તમે જટિલ લોજિકને ડીબગ કરી રહ્યા હોવ અથવા મોનોરેપો (monorepo) ના પેકેજો એકબીજા પર કેવી રીતે નિર્ભર છે તેનું પુનર્ગઠન કરી રહ્યા હોવ, તો કોન્ટેક્સ્ટ હેન્ડલિંગની ઊંડાઈ સામાન્ય રીતે ફાયદાકારક સાબિત થાય છે.

OpenAI Codex: સ્ટ્રક્ચર્ડ ઓટોમેશન

Codex એ એવી ટીમો માટે બનાવવામાં આવ્યું છે જેમને મોટા પાયે પુનરાવર્તિત પરિણામોની જરૂર હોય છે. જ્યાં Claude Code એક્સપ્લોરેશન તરફ ઝુકાવ ધરાવે છે, ત્યાં Codex ઓટોમેશન તરફ ઝુકાવ ધરાવે છે. તે ત્યારે શ્રેષ્ઠ રીતે કામ કરે છે જ્યારે તમારી પાસે સ્પષ્ટ રીતે વ્યાખ્યાયિત કાર્યો હોય જે હાલની ટીમ સિસ્ટમમાં સમાઈ શકે: નવા માઇક્રોસર્વિસ માટે બોઇલરપ્લેટ (boilerplate) જનરેટ કરવી, તમારા ચોક્કસ મિડલવેર સ્ટેક સાથે CRUD એન્ડપોઇન્ટ્સ બનાવવી, અથવા સેવાઓના સમૂહમાં કન્ફિગરેશન ફાઇલો અપડેટ કરવી.

અહીં ધ્યાન રાખવાની બાબત એ છે કે તમારે સચોટ હોવું પડશે. જો તમારા સ્વીકૃતિ માપદંડો (acceptance criteria) અસ્પષ્ટ હશે, તો Codex ખુશીથી એવો કોડ જનરેટ કરશે જે ટેકનિકલ રીતે ચાલે છે પરંતુ તમારા નિયમોનું ઉલ્લંઘન કરે છે. માળખું, નામકરણના નિયમો, એરર હેન્ડલિંગ પેટર્ન અને ટેસ્ટ અપેક્ષાઓ અગાઉથી જ વ્યાખ્યાયિત કરો. તે વાતાવરણમાં, Codex પેયર પ્રોગ્રામર તરીકે ઓછું અને નેચરલ લેંગ્વેજ ઇન્સ્ટ્રક્શન સમજતી એસેમ્બલી લાઇન તરીકે વધુ વર્તે છે. તે તેને ઇન્ટરનલ ટૂલિંગ, CI-સંબંધિત વર્કફ્લો અને એવી કોઈપણ પરિસ્થિતિ માટે શક્તિશાળી બનાવે છે જ્યાં સર્જનાત્મક સમસ્યાના ઉકેલ કરતા સુસંગતતા વધુ મહત્વની હોય છે.

Gemini CLI: ઓપન, સ્ક્રિપ્ટેબલ વર્કફ્લો

Gemini CLI તદ્દન અલગ સ્વરૂપ ધરાવે છે. તે વાતચીત કરવા માટેના કોડિંગ આસિસ્ટન્ટ કરતાં તમારા ટર્મિનલ એન્વાયરમેન્ટમાં એક વિસ્તૃત ઘટક (extensible component) તરીકે વધુ છે. તે અત્યંત સ્ક્રિપ્ટેબલ છે, જેનો અર્થ છે કે તમે તેને સ્ટાન્ડર્ડ Unix વર્કફ્લોમાં પાઇપ કરી શકો છો, તેને grep, awk, અથવા jq સાથે જોડી શકો છો, અને કસ્ટમ ટૂલચેઇન્સ બનાવી શકો છો જેમાં તમારે ચેટ વિન્ડો વચ્ચે કોપી અને પેસ્ટ કરવાની જરૂર ન પડે.

આ ખુલ્લુંપણું એ એન્જિનિયરો માટે મહત્વનું છે જેઓ ટર્મિનલને તેમના મુખ્ય ઇન્ટરફેસ તરીકે ગણે છે. તમે તેનો ઉપયોગ સ્ટેજ્ડ ડિફ્સ (staged diffs) માંથી કમીટ મેસેજ ઓટો-જનરેટ કરવા માટે, લેગસી શેલ સ્ક્રિપ્ટ્સને ઇનલાઇન સમજૂતી સાથે Python માં ફરીથી લખવા માટે, અથવા નિષ્ફળ Kubernetes પોડના લોગ આઉટપુટનો સારાંશ મેળવવા માટે કરી શકો છો. તેનો નોન-ઇન્ટરેક્ટિવ મોડ CI પાઇપલાઇન્સ માટે ખાસ કરીને વ્યવહારુ છે. તમે GitHub Action અથવા Makefile સ્ટેપમાં તેને એમ્બેડ કરી શકો છો જેથી લાઇટવેઇટ કોડ ટ્રાન્સફોર્મેશન કરી શકાય, સોર્સમાંથી ડોક્યુમેન્ટેશન સ્નિપેટ્સ જનરેટ કરી શકાય, અથવા Slack ચેનલમાં પોસ્ટ કરતા પહેલા એરર આઉટપુટને સેનિટાઇઝ કરી શકાય.

જો તમારો વર્કફ્લો પહેલેથી જ શેલ સ્ક્રિપ્ટ્સ અને કમ્પોઝેબલ ટૂલ્સની આસપાસ બનેલો હોય, તો Gemini CLI તમારી આદતો બદલવાનું કહે્યા વગર તેમાં ભળી જાય છે.

જે કામ ખરેખર મહત્વનું છે

AI એજન્ટ સ્વીકૃતિ દરો પરના સંશોધનથી એક એવો પેટર્ન સામે આવે છે જે અનુભવી એન્જિનિયરોને નવાઈ પમાડશે નહીં: નવા ફીચરના કામ કરતાં ડોક્યુમેન્ટેશનના ફેરફારો વધુ વારંવાર મંજૂર થાય છે. Docstrings અપડેટ કરવા, કોમેન્ટ્સ સુધારવા અથવા README ને વિસ્તૃત કરવું એ એજન્ટની શક્તિઓનો ઉપયોગ કરે છે કારણ કે તેનો સંદર્ભ મર્યાદિત હોય છે અને સ્ટાઇલ રિપોઝિટરીમાં પહેલેથી જ સ્થાપિત હોય છે. નવા ફીચરના કામ માટે સંશોધન, એજ કેસનું અનુમાન અને યુઝર ઇન્ટેન્ટની સમજણ જરૂરી છે જે કદાચ ક્યાંય લખેલી ન હોય. કોઈ પણ એક સાધન બંને શ્રેણીઓમાં વિજેતા બની શકતું નથી કારણ કે હાર્નેસની જરૂરિયાતો મૂળભૂત રીતે અલગ હોય છે.

આનો અર્થ એ છે કે તમારું મૂલ્યાંકન તમે જે વાસ્તવિક કામ કરો છો તેની સાથે સુસંગત હોવું જોઈએ. જો તમે ફક્ત મર્યાદિત કાર્યો પર જ ટેસ્ટ કરશો, તો દરેક સાધન જાદુઈ (genius) લાગશે.

જ્યાં એજન્ટ્સ ખરેખર નિષ્ફળ જાય છે

મોટાભાગની નિષ્ફળતાઓ એક્ઝિક્યુશન લેયરમાં થાય છે, મોડેલ લેયરમાં નહીં. કોડ સિન્ટેક્ટિકલી પરફેક્ટ હોઈ શકે છે, પરંતુ ઇન્ટરનલ API માં નેટવર્ક ટાઇમઆઉટ, macOS પર કામ કરે છે પરંતુ GNU/Linux પર નિષ્ફળ જાય તેવો sed કમાન્ડ, અથવા એજન્ટ ઓળખી શકતું નથી તેવું પરમિશન બાઉન્ડ્રી હોવાને કારણે એજન્ટ હજુ પણ નિષ્ફળ જઈ શકે છે. એજન્ટ્સ ત્યારે સંઘર્ષ કરે છે જ્યારે:

  • એક API કામચલાઉ નિષ્ફળતા (transient failure) આપે છે અને લૂપ અટકવાને બદલે ચાલ્યા જ કરે છે.
  • એક ટૂલ એરર સ્ટ્રીમ રિટર્ન કરે છે જે એજન્ટ ખોટી રીતે સમજી લે છે.
  • એક કમાન્ડ માટે sudo એક્સેસની જરૂર હોય છે જે એજન્ટ પાસે નથી, જેના કારણે સિસ્ટમ અટકી જાય છે.
  • જનરેટ કરેલા ટેસ્ટ આઇસોલેશનમાં પાસ થાય છે પરંતુ વાસ્તવિક ડેટાબેઝ સાથે ચલાવવામાં આવે ત્યારે નિષ્ફળ જાય છે કારણ કે હાર્નેસ કનેક્શન સ્ટ્રિંગને યોગ્ય રીતે દર્શાવતું નથી.

આ ઇન્ટિગ્રેશન સમસ્યાઓ છે. તેના માટે એવા હાર્નેસની જરૂર છે જે એરર વાંચતા, સીમાઓનું સન્માન કરતા અને ભૂલ કરવાને બદલે માનવ હસ્તક્ષેપ માટે પૂછતા જાણે છે.

આ સાધનોનું વાસ્તવિક રીતે મૂલ્યાંકન કેવી રીતે કરવું

એજન્ટ્સને build a landing page જેવા પ્રોમ્પ્ટ્સ સાથે ટેસ્ટ કરવાનું બંધ કરો. તે વિઝ્યુઅલ આઉટપુટ માપે છે, એન્જિનિયરિંગ ક્ષમતા નહીં. તેના બદલે, દરેક સાધનને વાસ્તવિક કાર્યોના સમાન પરીક્ષણ દ્વારા પસાર કરો:

  • એવા બગને ઠીક કરો જે મલ્ટીપલ ફાઇલ્સમાં ફેલાયેલો હોય, જ્યાં મૂળ કારણ અને લક્ષણ સ્ટેકનાં અલગ-અલગ લેયરમાં હોય.
  • બાહ્ય વર્તનમાં ફેરફાર કર્યા વિના ડિપ્રિકેટેડ ડિપેન્ડન્સી દૂર કરવા માટે મોડ્યુલને રિફેક્ટર કરો, અને પછી ચકાસો કે ટેસ્ટ સ્યુટ હજુ પણ પાસ થાય છે.
  • થર્ડ-પાર્ટી API તેના રિસ્પોન્સ શેપમાં ફેરફાર કરે તે પછી દરેક મોક ફિક્સ્ચર (mock fixture), ટાઇપ ડેફિનેશન અને ઇન્ટિગ્રેશન ટેસ્ટ અપડેટ કરો.
  • વર્ઝન સંઘર્ષને કારણે બગડેલા બિલ્ડનું નિદાન કરો અને એવો ફિક્સ સૂચવો જે ખરેખર કમ્પાઇલ થાય.

વાઇબ્સ નહીં, હાર્ડ મેટ્રિક્સ ટ્રેક કરો. કમ્પ્લીશન રેટ ગણો: શું એજન્ટે કામ પૂરું કર્યું કે અધવચ્ચેથી છોડી દીધું? કોડ મર્જ કરી શકાય તે પહેલાં કેટલા માનવ સુધારાની જરૂર પડી તેનો લોગ રાખો. તપાસો કે ટેસ્ટ પ્રથમ પ્રયાસમાં પાસ થયા કે તેના માટે પેચવર્કના અનેક રાઉન્ડની જરૂર પડી. સીનિયર એન્જિનિયરે આઉટપુટ રિવ્યૂ કરવામાં કેટલો સમય વિતાવ્યો તે માપો. જો તમારે એ ચકાસવામાં એક કલાક વિતાવવો પડે કે તેણે જે ફાઇલોને અડકવું નહોતું તેને અડકી નથી, તો બસો લાઇનનો ભૂલરહિત કોડ લખતું સાધન નકામું છે.

વાસ્તવિક નિષ્કર્ષ

વિજેતા સાધન તે નથી જે સૌથી વધુ કેરેક્ટર્સ જનરેટ કરે છે અથવા સૌથી આકર્ષક ડેમો આપે છે. તે એ છે જે ઓછામાં ઓછા રિવ્યૂ ફ્રિક્શન સાથે સૌથી વધુ મર્જ કરી શકાય તેવો કોડ બનાવે છે. આ ક્ષેત્રમાં સ્પર્ધા હવે રો મોડેલ ઇન્ટેલિજન્સથી ખસીને વિશ્વસનીય એન્જિનિયરિંગ હાર્નેસિસ તરફ જઈ રહી છે. એવા એજન્ટને પસંદ કરો જેની સિસ્ટમ ડિઝાઇન તમારા વાસ્તવિક કામ સાથે સુસંગત હોય: આર્કિટેક્ચરલ સર્જરી માટે ઊંડું તર્ક (deep reasoning), ટીમ ઓટોમેશન માટે સ્ટ્રક્ચર્ડ ચોકસાઈ, અથવા કસ્ટમ વર્કફ્લો માટે ટર્મિનલ એક્સટેન્સિબિલિટી. પછી તેને રમકડા જેવા પ્રશ્નો પર નહીં, પણ વાસ્તવિક નિષ્ફળતાઓ પર ટેસ્ટ કરો.

આ વિશ્લેષણ this detailed breakdown માં દર્શાવેલ સીધા તુલનાત્મક અભ્યાસ અને એજન્ટ વર્તનના સંશોધન પર આધારિત છે.

એન્જિનિયરિંગ ટૂલ્સ અને AI વર્કફ્લો પર વધુ ચર્ચાઓ માટે, GyaanSetu learning community માં જોડાઓ.