એન્જિનિયરિંગ જજમેન્ટ હવે સૌથી દુર્લભ સંસાધન બની રહ્યું છે

અમલીકરણ (Implementation) સસ્તું બની રહ્યું છે. આના કારણે જજમેન્ટ મોંઘું બની રહ્યું છે.

જજમેન્ટ એ અંતર્જ્ઞાન (intuition) કે અભિપ્રાય નથી. તે અનિશ્ચિતતા વચ્ચે નિર્ણયો લેવાની ક્ષમતા છે. AI આ કૌશલ્યને પહેલા કરતા વધુ સ્પષ્ટ બનાવે છે.

બે એન્જિનિયરોને એક જ કાર્ય મળી શકે છે: ઇન્વોઇસ રિકોન્સિલિએશન (invoice reconciliation) માટે API બનાવવું. AI બંને માટે કોડ લખી શકે છે. સિન્ટેક્સ (syntax) અને ફ્રેમવર્ક (frameworks) સમાન દેખાશે.

અંતિમ સિસ્ટમ્સ અલગ હશે. એક એન્જિનિયર કદાચ એક અસ્તવ્યસ્ત સર્વિસ બનાવી શકે છે જેને મેન્ટેન કરવી મુશ્કેલ હોય. બીજો એન્જિનિયર બિઝનેસ રૂલ્સ અને લોજિકને સ્વતંત્ર ઘટકોમાં અલગ કરી શકે છે.

AI એ તે પસંદગી કરી નથી. એન્જિનિયરે કરી છે.

આર્કિટેક્ચર હજુ પણ મહત્વનું છે કારણ કે અમલીકરણ હવે તફાવત પાડતું નથી. કોડ પાછળના નિર્ણયો તફાવત પાડે છે.

AI સાથે જટિલતા (complexity) દૂર થતી નથી. તે માત્ર સ્થાનાંતરિત થાય છે.

ભૂતકાળમાં, એન્જિનિયરો વિચારોને કોડમાં રૂપાંતરિત કરવામાં સમય વિતાવતા હતા. હવે, AI તે રૂપાંતરણ કરે છે. અસલી મહેનત તમે એક પણ લાઇન લખતા પહેલા જ થઈ જાય છે.

તમારે આ જેવા પ્રશ્નોના જવાબ આપવા પડશે:

  • આપણે કઈ સમસ્યાનું નિરાકરણ લાવી રહ્યા છીએ?
  • કયો ડેટા 'સોર્સ ઓફ ટ્રુથ' (source of truth) છે?
  • બિઝનેસ રૂલ્સ ક્યાં હોવા જોઈએ?
  • આપણે સફળતા કેવી રીતે માપીશું?

Autocomplete આના જવાબ આપી શકતું નથી. આ માટે સંદર્ભ (context) ની જરૂર પડે છે.

સોફ્ટવેર ડેવલપમેન્ટ હવે ઇન્ફોર્મેશન એન્જિનિયરિંગ જેવું લાગે છે. અવરોધ (bottleneck) કોડ નથી. અવરોધ માહિતી (information) છે.

તમારે આનો સામનો કરવો પડે છે:

  • ખૂટતી જરૂરિયાતો (Missing requirements).
  • અધૂરી ડોક્યુમેન્ટેશન (Incomplete documentation).
  • વિરોધાભાસી બિઝનેસ રૂલ્સ (Conflicting business rules).
  • અસ્પષ્ટ માલિકી (Undefined ownership).

જે એન્જિનિયર માહિતીને વ્યવસ્થિત કરે છે તે ઝડપથી કોડ લખતા એન્જિનિયર કરતા વધુ મૂલ્ય ઊભું કરે છે.

વર્કફ્લો બદલાઈ ગયો છે. તે પહેલા આવો હતો: Requirement -> Design -> Code -> Debug -> Deploy.

હવે તે આવો છે: Business Problem -> Context -> Architecture -> AI Implementation -> Human Review -> Security -> Evaluation -> Production.

કોડિંગ હવે પ્રક્રિયાનો એક નાનો ભાગ છે. તેની આસપાસની પ્રવૃત્તિઓ પ્રાથમિકતા છે.

ઉચ્ચ-અસરકારક નિર્ણયો કોડ એડિટરની બહાર લેવામાં આવે છે. તે ત્યારે લેવાય છે જ્યારે તમે પૂછો છો:

  • શું આ એક અલગ સર્વિસ હોવી જોઈએ?
  • શું આપણે આ નિર્ણયનું ઓડિટ કરી શકીએ?
  • જો AI ખોટું હોય તો શું થશે?
  • શું આ આર્કિટેક્ચર વિકસી શકે છે?

AI એન્જિનિયરિંગ એ માત્ર પ્રોમ્પ્ટ્સ (prompts) અથવા મોડેલ પસંદગી કરતાં વધુ છે. તે માત્ર એક સ્તર છે.

વાસ્તવિક પડકારો આર્કિટેક્ચરલ છે:

  • આપણે બિઝનેસ નોલેજનું મોડેલિંગ કેવી રીતે કરીએ?
  • આપણે અસ્પષ્ટતા (ambiguity) કેવી રીતે દૂર કરીએ?
  • આપણે વિશ્વાસ કેવી રીતે જાળવી રાખીએ?

મોડેલ્સ દર થોડા મહિને બદલાય છે. આર્કિટેક્ચર વર્ષો સુધી ચાલે છે. ખરાબ આર્કિટેક્ચર ખૂબ જ ઝડપથી મોંઘું પડી જાય છે.

શ્રેષ્ઠ ટીમો એવી સિસ્ટમ્સ બનાવે છે જે મોડેલ્સની અનેક પેઢીઓ સુધી ટકી રહે. તેઓ અનુકૂલનક્ષમતા (adaptability) માટે ઓપ્ટિમાઇઝ કરે છે.

AI એ માત્ર એબ્સ્ટ્રેક્શન (abstraction) નું બીજું સ્તર છે. ઉચ્ચ એબ્સ્ટ્રેક્શન માટે મજબૂત તર્ક (reasoning) ની જરૂર છે, નબળા તર્કની નહીં.

સૌથી મજબૂત એન્જિનિયરો સૌથી ઝડપી પ્રોગ્રામરો નથી. તેઓ એ છે જે સ્પષ્ટતા લાવે છે. તેઓ આર્કિટેક્ચર વ્યાખ્યાયિત કરે છે, ડેટાનું માનકીકરણ (standardize) કરે છે અને અસ્પષ્ટતા ઘટાડે છે.

એક સારી સિસ્ટમ માણસો અને AI એજન્ટ્સને સાથે મળીને કામ કરવામાં મદદ કરે છે. ખરાબ સિસ્ટમ માત્ર ભૂલો ઝડપથી થાય તેવું બનાવે છે.

જે એન્જિનિયર સ્પષ્ટતા લાવે છે તે લીવરેજ (leverage) ઊભું કરે છે.

Source: https://dev.to/uigerhana/engineering-judgment-is-becoming-the-scarcest-resource-1a5l

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