എ.ഐ കാലത്ത് ഒരു എഞ്ചിനീയറെപ്പോലെ എങ്ങനെ ചിന്തിക്കാം?

എ ഐ ഉപയോഗിച്ച് വേഗത്തിൽ എന്തും നിർമിക്കാം. പക്ഷേ, മൗലികമായ പ്രശ്നങ്ങൾ കണ്ടെത്താനും നല്ല ചോദ്യങ്ങൾ ചോദിക്കാനും ചെയ്ത കാര്യങ്ങൾ പരിശോധിക്കാനും നമുക്ക് അറിയണം. കോളേജ് ജീവിതത്തിലെ ചില ഉദാഹരണങ്ങളിലൂടെ അതെങ്ങനെ ചെയ്യാമെന്ന് നോക്കാം.

നിങ്ങളുടെ കോളേജിനായി ഒരു അറ്റൻഡൻസ് ആപ്പ് ഉണ്ടാക്കാൻ ആവശ്യപ്പെട്ടുവെന്ന് കരുതൂ. നിങ്ങൾ ഒരു എ ഐ ടൂൾ തുറക്കുന്നു. വേണ്ട സ്ക്രീനുകളെക്കുറിച്ച് പറഞ്ഞുകൊടുക്കുന്നു. കോഡ് കിട്ടുന്നു. അധികം വൈകാതെ ഒരു ലോഗിൻ പേജും വിദ്യാർഥികളുടെ ലിസ്റ്റും അറ്റൻഡൻസ് രേഖപ്പെടുത്താനുള്ള ബട്ടണും തയ്യാറാകുന്നു.

കാര്യങ്ങൾ മുന്നോട്ടുപോകുന്നുണ്ടെന്ന് തോന്നും. അപ്പോഴാണ് ഒരു അധ്യാപകൻ ചോദിക്കുന്നത്: “കൂട്ടുകാർക്കുവേണ്ടി മറ്റൊരാൾ അറ്റൻഡൻസ് ഇടുന്നത് ഈ ആപ്പ് തടയുമോ?” ആ ചോദ്യത്തിന് നിങ്ങളുടെ ആപ്പിൽ ഉത്തരമില്ല. എന്താണ് ആവശ്യകത എന്ന് മനസ്സിലാക്കുന്നതിനുമുമ്പേ, ആവശ്യപ്പെട്ടത് നിങ്ങൾ ഉണ്ടാക്കിക്കഴിഞ്ഞു.

ഇവിടെയാണ് ഒരു എഞ്ചിനീയറെപ്പോലെ ചിന്തിക്കേണ്ടത്. ഒരു പരിഹാരം വേഗത്തിൽ ഉണ്ടാക്കാൻ എ ഐ സഹായിക്കും. എന്നാൽ ഏത് പ്രശ്നമാണ് പരിഹരിക്കേണ്ടത്, എന്തിനാണ് പ്രാധാന്യം നൽകേണ്ടത്, ആ പരിഹാരം ശരിക്കും പ്രവർത്തിക്കുന്നുണ്ടോ എന്നൊക്കെ തീരുമാനിക്കേണ്ടത് നിങ്ങളാണ്. ഇങ്ങനെ ചിന്തിച്ചുതുടങ്ങാൻ വർഷങ്ങളുടെ പരിചയമൊന്നും വേണ്ട. ചുറ്റുമുള്ള ചെറിയ, നിത്യജീവിതത്തിലെ പ്രശ്നങ്ങളിൽനിന്നുതന്നെ പരിശീലിക്കാം.

കോളേജിലെ പ്രധാന അറിയിപ്പുകൾ വിദ്യാർഥികൾ പതിവായി കാണാതെ പോകുന്നുവെന്ന് കരുതൂ. ആദ്യം മനസ്സിൽ വരുന്നത് ഒരു ആപ്പ് വികസിപ്പിച്ച് അത് പരിഹരിക്കാം എന്നാവും. പക്ഷേ, എന്തുകൊണ്ടാണ് അവർ അറിയിപ്പുകൾ കാണാതെപോകുന്നത്?

അറിയിപ്പുകൾ അഞ്ച് ഗ്രൂപ്പുകളിലായി ചിതറിക്കിടക്കുന്നതുകൊണ്ടാകാം. പ്രധാന സന്ദേശങ്ങൾ സാധാരണ ചാറ്റുകൾക്കിടയിൽ മുങ്ങിപ്പോകുന്നതാകാം. അല്ലെങ്കിൽ അറിയിപ്പ് എത്തുന്നതുതന്നെ വൈകിയാകാം. ഇതെല്ലാം വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്. മറ്റൊരു ആപ്പ് ഉണ്ടാക്കിയാൽ, വിദ്യാർഥികൾ നോക്കാൻ മറക്കുന്ന ഇടങ്ങളുടെ കൂട്ടത്തിലേക്ക് ഒന്നുകൂടി ചേർന്നെന്നുവരാം.

അതിനാൽ എന്തെങ്കിലും നിർമിക്കുന്നതിന് മുമ്പ് ഈ പ്രശ്നം നേരിടുന്നത് ആരാണ്? ഇപ്പോൾ കാര്യങ്ങൾ എങ്ങനെയാണ് നടക്കുന്നത്? എവിടെയാണ് പിഴയ്ക്കുന്നത്? കാര്യങ്ങൾ മെച്ചപ്പെട്ടു എന്ന് പറയാൻ എന്ത് മാറ്റമാണ് ഉണ്ടാകേണ്ടത്? എന്നീ ചോദ്യങ്ങളെ അഭിസംബോധന ചെയ്യണം. “ഏറ്റവും പുതിയ അവസാന തീയതി ഏതാണെന്ന് വിദ്യാർഥികൾക്ക് ഒരിടത്തുനിന്ന് കണ്ടെത്താൻ കഴിയണം” എന്നതായിരിക്കാം ഈ ഉദാഹരണത്തിന് പാകമായ ലക്ഷ്യം.

“നമുക്കൊരു ആപ്പ് വേണം” എന്നതിനെക്കാൾ വ്യക്തമാണ് ഈ ലക്ഷ്യം. ഇതിൻ്റെ കൃത്യമായ നിർവഹണത്തിന് തുടക്കത്തിൽ എല്ലാവർക്കും കാണാവുന്ന ഒരു അറിയിപ്പ് പേജും അത് പുതുക്കാൻ ഉത്തരവാദിത്വമുള്ള ഒരാളും മതിയായേക്കാം. വലിയൊരു സംവിധാനം ഉണ്ടാക്കുന്നതിനുമുമ്പ് ഒരു ക്ലാസിൽ ഇത് പരീക്ഷിച്ചുനോക്കുകയുമാവാം. എന്ത് നിർമിക്കണമെന്ന് തീരുമാനിക്കുന്നതിനുമുമ്പ്, അതിലൂടെ എന്ത് ഫലമാണ് വേണ്ടതെന്ന് വ്യക്തമായി മനസ്സിലാക്കണം എന്ന് ചുരുക്കം.

വലിയ പ്രശ്നത്തെ ചെറിയ ഘട്ടങ്ങളാക്കുകയും വേണം. “കാന്റീനിൽ ഭക്ഷണം ഓർഡർ ചെയ്യാനുള്ള ഒരു സംവിധാനം ഉണ്ടാക്കുക” എന്നതാണ് ചെയ്യാനുള്ളത് എന്ന് കരുതുക. കേൾക്കുമ്പോൾ ഒറ്റ ജോലിയാണെന്ന് തോന്നും. എന്നാൽ, ഏതൊക്കെ ഭക്ഷണങ്ങൾ ലഭ്യമാണെന്ന് കാണിക്കുക, വിദ്യാർഥിക്ക് ഓർഡർ നൽകാൻ അവസരമൊരുക്കുക, ആ ഓർഡർ കാന്റീനിലെത്തിക്കുക, പണമടയ്ക്കാനുള്ള ക്രമീകരണം ഒരുക്കുക, ഭക്ഷണം എപ്പോൾ, എവിടെനിന്ന് വാങ്ങാമെന്ന് വിദ്യാർഥിയെ അറിയിക്കുക എന്നിങ്ങനെ അതിനുള്ളിൽ പല ഘട്ടങ്ങളുണ്ട്. മെനു പുതുക്കുന്നത് ആരാണ്? ഒരു വിഭവം തീർന്നാൽ എന്തുചെയ്യും? ഏത് വിദ്യാർഥിയാണ് ഓർഡർ നൽകിയതെന്ന് കാന്റീനിലുള്ളവർ എങ്ങനെ തിരിച്ചറിയും? എന്നിങ്ങനെ ഓരോ ഘട്ടത്തിനും അതിന്റേതായ ചോദ്യങ്ങൾ ഉയർന്നുവരും. ഈ സാഹചര്യത്തിൽ ഉപയോഗപ്രദമായ ഏറ്റവും ചെറിയ പതിപ്പിൽനിന്ന് തുടങ്ങുക. കുറച്ച് വിഭവങ്ങളുള്ള മെനുവിൽ നിന്ന് വിദ്യാർഥികൾ ഓർഡർ ചെയ്യട്ടെ. ഭക്ഷണം വാങ്ങുമ്പോൾ പണം നൽകട്ടെ. ഓർഡർ ചെയ്യാനുള്ള പ്രക്രിയ ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കിയശേഷം ഓൺലൈൻ പേയ്‌മെന്റ് ചേർക്കാം. ഇങ്ങനെ ചെയ്യുമ്പോൾ എ ഐയുമായുള്ള ചർച്ചയും പരിശോധിക്കേണ്ട ഫലവും ചെറുതാകും. എന്തെങ്കിലും പിഴച്ചാൽ എവിടെയാണ് തിരുത്തേണ്ടതെന്ന ധാരണയും കിട്ടും.

എല്ലാ ഫീച്ചറുകളും ചേർക്കുന്നതിനുമുമ്പ്, തുടക്കം മുതൽ അവസാനം വരെ ഉപയോഗിക്കാവുന്ന ഒരു പ്രക്രിയ പൂർത്തിയാക്കുക എന്നത് പ്രധാനമാണ്. എ ഐ ടൂളിൽ നിർദേശങ്ങൾ മാത്രം പറയാതെ സാഹചര്യം കൂടി വിശദീകരിക്കണം. “കാന്റീനിൽ ഭക്ഷണം ഓർഡർ ചെയ്യാനുള്ള ഒരു ആപ്പ് ഉണ്ടാക്കൂ” എന്ന നിർദേശവും “ഒരു കോളേജ് കാന്റീനിൽ ഉച്ചഭക്ഷണം ഓർഡർ ചെയ്യാനുള്ള സംവിധാനം ആസൂത്രണം ചെയ്യാൻ സഹായിക്കൂ. വിദ്യാർഥികൾ ഫോണിലാണ് ഇത് ഉപയോഗിക്കുക. ഇന്റർനെറ്റ് എല്ലായ്പ്പോഴും വിശ്വസിക്കാനാകില്ല. ഓർഡറുകൾ കൈകാര്യം ചെയ്യാൻ ഒരു ജീവനക്കാരൻ മാത്രമാണുള്ളത്. ആദ്യ പതിപ്പിൽ ഭക്ഷണം വാങ്ങുമ്പോഴാണ് പണം നൽകുക. പരിഹാരം നിർദേശിക്കുന്നതിനുമുമ്പ്, കൂടുതൽ അറിയേണ്ട കാര്യങ്ങൾ എന്നോട് ചോദിക്കൂ” എന്ന വിശദീകരിച്ച പ്രോംപ്റ്റും താരതമ്യം ചെയ്തുനോക്കൂ.

രണ്ടാമത്തേതിൽ സാഹചര്യം കൃത്യമാണ്. എന്തൊക്കെ പരിമിതികളുണ്ട്, എന്തൊക്കെ പിന്നീട് ചെയ്താൽ മതി എന്നതും വ്യക്തമാക്കിയിട്ടുണ്ട്. ഇത്തരം പരിമിതികളെയാണ് സാധാരണ constraints എന്നു വിളിക്കുന്നത്. കുറഞ്ഞ ബജറ്റ്, വേഗം കുറഞ്ഞ ഇന്റർനെറ്റ്, തിരക്കുള്ള ഒരു ജീവനക്കാരൻ - ഇതെല്ലാം പരിമിതികളാണ്. സ്ക്രീനിൽ കാണാൻ നന്നായിരുന്നാലും യഥാർഥ സാഹചര്യത്തിന് ചേരാത്ത ആശയങ്ങൾ ഒഴിവാക്കാൻ ഇവ സഹായിക്കും.

എ ഐ നൽകുന്ന നിർദേശങ്ങളെ അന്വേഷിച്ചറിയാനുള്ള സാധ്യതകളായിട്ടാണ് കാണേണ്ടത്. അവ അന്തിമ തീരുമാനങ്ങളായി സ്വീകരിക്കരുത്. വിദ്യാർഥികളുടെ ഔദ്യോഗിക രേഖകൾ, പാസ്‌വേഡുകൾ, സ്വകാര്യ പേയ്‌മെന്റ് വിവരങ്ങൾ എന്നിവ പ്രോംപ്റ്റിൽ നൽകരുത്. ഒരു പ്രോജക്ടിന്റെ രൂപരേഖ ചർച്ച ചെയ്യാൻ സാങ്കൽപ്പിക വിവരങ്ങൾ മാത്രമേ ഉപയോഗിക്കാവൂ. എ ഐ നൽകുന്ന ഒരു പരിഹാരത്തെ വിലയിരുത്തേണ്ടത് പ്രായോഗിക തലത്തിൽ എന്താണ് സംഭവിക്കുന്നത് എന്നതിന്റെ അടിസ്ഥാനത്തിലാണ്. അതിനെക്കുറിച്ചുള്ള വിശദീകരണം എത്ര വിശ്വസനീയമായി തോന്നുന്നു എന്നതിന്റെ ബലത്തിലല്ല. രൂപപ്പെടുത്തുന്ന സംവിധാനത്തെ ഉപയോഗിക്കുന്നത് ആരാണ്, അതിന്റെ ലക്ഷ്യവും പരിമിതികളും എന്താണ് എന്നിവ വ്യക്തമായി തിരിച്ചറിയുകയും വേണം. എ ഐ കാലത്ത് ഒരു എഞ്ചിനീയറെപ്പോലെ ചിന്തിക്കുക എന്നത്, ഒരു പരിഹാരം കണ്ടെത്തുക എന്നതിലപ്പുറം അതിന്റെ ഫലത്തിന്റെ ഉത്തരവാദിത്വം കൂടി ഏറ്റെടുക്കുക എന്നതാണ്. ആ തിരിച്ചറിവാണ് ഏറ്റവും പ്രധാനം.