സോഫ്റ്റ്വെയർ എൻജിനീയറിംഗ് അവസാനിച്ചു. ടെക് ട്വിറ്ററിലെ (tech Twitter) ഏറ്റവും ഉച്ചത്തിലുള്ള ശബ്ദങ്ങൾ നിങ്ങളെ വിശ്വസിപ്പിക്കാൻ ആഗ്രഹിക്കുന്നത് ഇതാണ്. ഒരു ചെറിയ പാരഗ്രാഫ് പ്രോംപ്റ്റിൽ നിന്ന് പൂർണ്ണമായ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്ന AI ടൂളുകളുടെ സ്ക്രീൻ റെക്കോർഡിംഗുകൾ അവർ പങ്കുവെക്കുകയും, പിന്നെ എന്തിനാണ് ഒരാൾ കോഡ് എഴുതാൻ മനുഷ്യർക്ക് പണം നൽകുന്നത് എന്ന് ചോദിക്കുകയും ചെയ്യുന്നു. ഈ പരിഭ്രാന്തി മനസ്സിലാക്കാവുന്നതേയുള്ളൂ, പക്ഷേ അത് യഥാർത്ഥ പ്രശ്നത്തെ പാടെ അവഗണിക്കുന്നു.
AI എൻജിനീയർമാരെ ഇല്ലാതാക്കാൻ വരുന്നതല്ല. ടൈപ്പിംഗ് വേഗതയെ സാങ്കേതികമായ വിവേചനമായി (technical judgment) തെറ്റിദ്ധരിക്കുന്നവരെയാണ് അത് ലക്ഷ്യം വെക്കുന്നത്. കോഡിംഗും എൻജിനീയറിംഗും തമ്മിൽ വലിയൊരു വ്യത്യാസമുണ്ട്, ആ വ്യത്യാസത്തിലാണ് ഈ തൊഴിൽ മേഖല നിലനിൽക്കുന്നത്.
നിങ്ങൾ കാപ്പി കുടിച്ചു തീരുന്നതിന് മുമ്പ് തന്നെ ഒരു ഫീച്ചർ നടപ്പിലാക്കാൻ അഞ്ച് വ്യത്യസ്ത വഴികൾ ഒരു AI അസിസ്റ്റന്റിന് നൽകാൻ കഴിയും. ഇവിടെ തടസ്സങ്ങൾ (bottlenecks) മാറിയിരിക്കുന്നു. എവിടെ തുടങ്ങണം എന്ന് ആലോചിച്ച് നമ്മൾ ഇനി വെറുതെ ഒരു ഫയലിലേക്ക് നോക്കിയിരിക്കേണ്ടതില്ല. പകരം, യഥാർത്ഥ ട്രാഫിക് വരുന്ന നിമിഷം തകരാതിരിക്കാൻ ഏത് പരിഹാരമാണ് നല്ലത് എന്ന് ആലോചിച്ച് അഞ്ച് സാധ്യതകളിലേക്ക് നമ്മൾ നോക്കി നിൽക്കും. ആ തീരുമാനമെടുക്കലാണ് എൻജിനീയറിംഗ്. ബാക്കിയെല്ലാം വെറും സിന്റാക്സ് (syntax) മാത്രമാണ്.
ഡെമോ എന്നാൽ ഉൽപ്പന്നമല്ല
ഏതെങ്കിലും ഒരു AI കോഡിംഗ് ഡെമോ കണ്ടാൽ മിനിറ്റുകൾക്കുള്ളിൽ മനോഹരമായ ഒരു ഇന്റർഫേസ് രൂപപ്പെടുന്നത് നിങ്ങൾക്ക് കാണാം. എന്നാൽ ലോഡ് കൂടുമ്പോൾ ഡാറ്റാബേസ് കണക്ഷൻ പൂൾ (database connection pool) എങ്ങനെ തകരാറിലാകുന്നു എന്നത് നിങ്ങൾ കാണില്ല. ഒരു API എൻഡ്പോയിന്റിലെ മിസ്സിംഗ് റേറ്റ് ലിമിറ്റുകൾ (rate limits), ഓഡിറ്റ് ലോഗുകളുടെ (audit logs) അഭാവം, അല്ലെങ്കിൽ AI ഒരു സ്റ്റേറ്റ് ഡമ്പ് ചെയ്യാൻ സൗകര്യപ്രദമായ ഇടം എന്ന് കരുതി ഒബ്ജക്റ്റ് ബക്കറ്റിലേക്ക് (object bucket) എല്ലാ യൂസർ ഇന്ററാക്ഷനുകളും ലോഗ് ചെയ്യുന്നതിലൂടെ ഉണ്ടാകുന്ന സ്റ്റോറേജ് ചിലവ് എന്നിവയും നിങ്ങൾ കാണില്ല.
പ്രൊഡക്ഷൻ സിസ്റ്റങ്ങൾക്ക് സ്കെയിലബിലിറ്റി (scalability), സെക്യൂരിറ്റി (security), പെർഫോമൻസ് (performance), കോസ്റ്റ് കൺട്രോൾ (cost control) എന്നിവ ആവശ്യമാണ്. ഒരു സ്പ്രിന്റ് റിവ്യൂവിൽ (sprint review) ഈ ഗുണങ്ങൾ കാണാൻ കഴിയില്ല. യഥാർത്ഥ ഉപയോക്താക്കൾ അവരുടെ പ്രവചനാതീതമായ പെരുമാറ്റങ്ങളുമായും എഡ്ജ് കേസുകളുമായും (edge cases) എത്തുമ്പോൾ മാത്രമാണ് ഇവ വെളിപ്പെടുന്നത്. QA ഘട്ടത്തിൽ എല്ലാം കൃത്യമാണെന്ന് തോന്നിച്ച പല AI അസിസ്റ്റഡ് പ്രോജക്റ്റുകളും ലോഞ്ച് ചെയ്ത ഒരാഴ്ചയ്ക്കുള്ളിൽ വലിയ സാമ്പത്തിക നഷ്ടമുണ്ടാക്കുന്ന പാഠങ്ങളായി മാറിയത് ഞാൻ കണ്ടിട്ടുണ്ട്.
പ്രവർത്തിക്കുന്ന കോഡ് ഇപ്പോൾ വിലകുറഞ്ഞതാണ്. എന്നാൽ മികച്ച എൻജിനീയറിംഗ് അങ്ങനെയല്ല.
ഇപ്പോൾ പ്രസക്തമാകുന്നത് എന്താണ്
ഈ മാറ്റത്തിൽ വിജയിക്കുന്ന എൻജിനീയർമാർ ഏറ്റവും വേഗത്തിൽ ടൈപ്പ് ചെയ്യുന്നവരല്ല. ഒരു വരി കോഡ് ജനറേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഏത് ചോദ്യങ്ങൾ ചോദിക്കണമെന്ന് അറിയുന്നവരാണ് അവർ.
അവർ പ്രശ്നങ്ങളെ വ്യക്തമായി നിർവചിക്കുന്നു. നിങ്ങൾ അനുവദിച്ചാൽ ഒരു AI മോഡൽ തെറ്റായ പ്രശ്നത്തിന് സന്തോഷത്തോടെ പരിഹാരം കണ്ടെത്തും. ആറ് ഇൻ്റേണൽ അനലിസ്റ്റുകൾ മാത്രം ഉപയോഗിക്കുന്ന ഒരു ഡാഷ്ബോർഡിനായി അത് സങ്കീർണ്ണമായ ഒരു കാഷിംഗ് ലെയർ (caching layer) നിർമ്മിച്ചേക്കാം. യഥാർത്ഥ പ്രശ്നം ഒരു ഡാറ്റാബേസ് ഇൻഡക്സിന്റെ അഭാവമാണോ അതോ അടിസ്ഥാനപരമായി തകരാറിലായ ഒരു ഡാറ്റ മോഡലാണോ എന്ന് അത് ചോദിച്ചു നിൽക്കില്ല. ഒരു വിദഗ്ധനായ എൻജിനീയർ പരിഹാരം കോഡ് വഴിയാണോ അല്ലയോ എന്ന് നോക്കാതെ, പ്രശ്നം വ്യക്തമാകുന്നതുവരെ അതിനെ പുനർനിർവചിച്ചുകൊണ്ടേയിരിക്കും.
അവർ വലിയ സിസ്റ്റങ്ങളെ ചെറിയ ഭാഗങ്ങളായി വിഭജിക്കുന്നു. ലോക്കൽ കോൺടെക്സ്റ്റിൽ (local context) AI മികച്ചതാണ്. അതിന് ഒരു ഫംഗ്ഷൻ, ഒരു കമ്പോണന്റ്, അല്ലെങ്കിൽ ഒരു ടെസ്റ്റ് എന്നിവ എഴുതാൻ കഴിയും. എന്നാൽ ഒരു വലിയ ഡിസ്ട്രിബ്യൂട്ടഡ് ആർക്കിടെക്ചറിനെ (distributed architecture) മുഴുവനായി മനസ്സിലാക്കാൻ അതിന് പ്രയാസമാണ്. ഒരു മോണോലിത്തിനെ (monolith) വിഭജിക്കാനും, സർവീസുകൾക്ക് ചുറ്റും അതിർവരമ്പുകൾ നിശ്ചയിക്കാനും, ടീമുകൾ തമ്മിലുള്ള കരാറുകൾ (contracts) നിർവചിക്കാനും കഴിയുന്ന എൻജിനീയർമാരാണ് ജനറേറ്റ് ചെയ്യപ്പെട്ട സ്നിപ്പറ്റുകളെ (snippets) സുസ്ഥിരമായ സിസ്റ്റങ്ങളാക്കി മാറ്റുന്നത്.
അവർ AI നിർദ്ദേശങ്ങളെ ചോദ്യം ചെയ്യുന്നു. മോഡലിന്റെ ആത്മവിശ്വാസം ഒരു മിഥ്യയാണ്. നെറ്റ്വർക്ക് ലേറ്റൻസി (network latency) അവഗണിക്കുന്ന ആർക്കിടെക്ചറുകൾ നിർദ്ദേശിക്കാനോ, വർഷങ്ങളായി ഉപയോഗശൂന്യമായ ലൈബ്രറികൾ ശുപാർശ ചെയ്യാനോ, അല്ലെങ്കിൽ ആവശ്യകതകളിൽ (requirements) ഇല്ലാത്ത ഫീച്ചറുകൾ നിർമ്മിക്കാനോ അത് ശ്രമിച്ചേക്കാം.