നമ്മൾ വീണ്ടും ആ Dreamweaver തെറ്റ് ആവർത്തിക്കുകയാണ്

AI ഡിസൈനിനെ വീണ്ടും കോഡിന്റെ നിയന്ത്രണത്തിലാക്കുന്നു.

കഴിഞ്ഞ ഇരുപത് വർഷമായി, ഈ ചുമതലകൾ വേർതിരിക്കാനാണ് നമ്മൾ ശ്രമിച്ചത്. ഡിസൈനർമാർ ഡിസൈൻ ചെയ്തു. ഡെവലപ്പർമാർ അത് നിർമ്മിച്ചു. ഒരു മനുഷ്യൻ ഇതിനിടയിൽ ഒരു പാലമായി പ്രവർത്തിച്ചു.

AI ഇത് മാറ്റുന്നു. നിങ്ങൾ ഒരു ഡിസൈൻ ഫയലിലേക്ക് ഒരു മോഡലിനെ ചൂണ്ടിക്കാണിച്ചാൽ അത് കോമ്പോണന്റുകൾ (components) നിർമ്മിക്കുന്നു. ഡിസൈൻ വീണ്ടും കോഡിനെ നയിക്കുന്നു.

ഇത് കാര്യക്ഷമമായി തോന്നാമെങ്കിലും, ഇതിൽ ഒരു അപകടസാധ്യതയുണ്ട്.

പഴയ Dreamweaver കാലഘട്ടത്തിൽ, ഒരു മനുഷ്യൻ ഇതിനിടയിൽ ഉണ്ടായിരുന്നു. ആ വ്യക്തി ഗുണനിലവാരം ഉറപ്പാക്കിയിരുന്നു. എന്നാൽ AI ഉപയോഗിക്കുമ്പോൾ, നിയന്ത്രണങ്ങളൊന്നുമില്ലാതെ ഡിസൈൻ നേരിട്ട് കോഡിലേക്ക് മാറുന്നു.

നിങ്ങൾ രണ്ട് കാര്യങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്:

• ഡിസൈൻ ഫയലുകൾ ഡിസൈൻ സിസ്റ്റങ്ങളല്ല (design systems). ഒരു ഫയൽ എങ്ങനെ കാണപ്പെടുന്നു എന്നതിനെ അടിസ്ഥാനമാക്കിയാണ് അത് വിലയിരുത്തപ്പെടുന്നത്. എന്നാൽ ഒരു സിസ്റ്റം അതിന്റെ പുനരുപയോഗക്ഷമത (reuse), ഈടുനിൽപ്പ് (durability), സ്റ്റേറ്റുകൾ (states) എന്നിവയെ അടിസ്ഥാനമാക്കിയാണ് വിലയിരുത്തപ്പെടുന്നത്. AI ഈ വ്യത്യാസം ഇല്ലാതാക്കുന്നു.
• സ്റ്റാറ്റിക് സൈറ്റുകൾക്ക് (static sites) AI മികച്ചതാണ്. നിങ്ങൾക്ക് ഒരു സ്നാപ്പ്ഷോട്ട് (snapshot) മാത്രമാണ് വേണ്ടതെങ്കിൽ അത് ഉപയോഗിക്കാം. എന്നാൽ ഒരു കസ്റ്റം CMS അല്ലെങ്കിൽ ഡൈനാമിക് UI പോലുള്ള പുനരുപയോഗിക്കാവുന്ന ഒരു സിസ്റ്റം നിർമ്മിക്കുമ്പോഴാണ് പ്രശ്നങ്ങൾ തുടങ്ങുന്നത്.

യഥാർത്ഥ പരാജയം സംഭവിക്കുന്നത് സൂക്ഷ്മമായ കാര്യങ്ങളിലാണ്.

ടീമുകൾ പലപ്പോഴും Figma വേരിയബിൾ പേരുകളെ (variable names) അടിസ്ഥാനമാക്കിയാണ് കോഡ് പൈപ്പ്‌ലൈനുകൾ (code pipelines) നിർമ്മിക്കുന്നത്. പേര് നൽകുന്നത് ഒരു ഡിസൈൻ തീരുമാനമാണ്, എന്നാൽ AI അതിനെ ഒരു കർശനമായ കരാറാക്കി മാറ്റുന്നു. ഒരു ഡിസൈനർ ഒരു വേരിയബിളിന്റെ പേര് മാറ്റിയാൽ പോലും മുഴുവൻ പൈപ്പ്‌ലൈനും തകരാറിലാകും.

ഒരു ഡിസൈൻ എന്നത് ഒരു സ്റ്റാറ്റിക് സ്നാപ്പ്ഷോട്ട് മാത്രമാണ്. അത് ഒരു സ്ക്രീനിന്റെ ഒരു പ്രത്യേക അവസ്ഥയെ (state) മാത്രമേ കാണിക്കുന്നുള്ളൂ. അത് താഴെ പറയുന്നവ കാണിക്കുന്നില്ല:

• ലോഡിംഗ് അല്ലെങ്കിൽ എറർ സ്റ്റേറ്റുകൾ (Loading or error states).
• കണ്ടന്റ് അടിസ്ഥാനമാക്കിയുള്ളതും (content-driven) സ്ഥിരമായതുമായ (fixed) ലേഔട്ടുകൾ.
• ഒരു CMS എങ്ങനെയാണ് ഡാറ്റ നൽകുന്നത് എന്നത്.

ആ വിവരങ്ങൾ (context) ഒരു ഡെവലപ്പറുടെ മനസ്സിലുണ്ടാകും, ഒരു ഡിസൈൻ ഫയലിലല്ല.

വ്യവസായ രംഗത്തെ പ്രമുഖർ ഇത് പരിഹരിക്കാൻ ശ്രമിക്കുന്നുണ്ട്. AI-ക്ക് കൂടുതൽ ഘടന നൽകുന്നതിനായി Google DESIGN.md പുറത്തിറക്കി. Figma-യുമായി കോഡ് ഒത്തുനോക്കി ഡിസൈനിലെ മാറ്റങ്ങൾ (design drift) കണ്ടെത്താൻ Fixel പോലുള്ള ടൂളുകൾ സഹായിക്കുന്നു.

എന്നാൽ മികച്ച ടൂളുകൾക്കും പരിധികളുണ്ട്. അവയ്ക്ക് പിക്സലുകളോ ടോക്കണുകളോ (pixels or tokens) വേർതിരിച്ചെടുക്കാൻ കഴിയും, എന്നാൽ അവയ്ക്ക് ആർക്കിടെക്ചറൽ തീരുമാനങ്ങൾ (architectural decisions) എടുക്കാൻ കഴിയില്ല. നിലവിലുള്ള ഒരു കോമ്പോണന്റ് വീണ്ടും ഉപയോഗിക്കണോ അതോ പുതിയൊന്ന് നിർമ്മിക്കണോ എന്ന് തീരുമാനിക്കാൻ അവയ്ക്ക് കഴിയില്ല.

ഭാവി എന്നത് ഡിസൈൻ കോഡിനെ നയിക്കുന്നതിനെക്കുറിച്ചല്ല. അത് ഒരു മധ്യമാർഗ്ഗത്തെക്കുറിച്ചാണ്.

ഈ മധ്യമാർഗ്ഗത്തിന് താഴെ പറയുന്നവ ആവശ്യമാണെന്ന് ഞാൻ വിശ്വസിക്കുന്നു:

• ബിൽഡ് സമയത്ത് (build time) ടൈപ്പ് ചെയ്ത CSS ഇൻപുട്ടുകൾ.
• ഡിസൈനുകൾ നിങ്ങളുടെ നിലവിലുള്ള സിസ്റ്റവുമായി എങ്ങനെ യോജിക്കുന്നു എന്ന് AI നിർദ്ദേശിക്കുക.
• പെരുമാറ്റത്തെയും (behavior) അർത്ഥത്തെയും കുറിച്ച് UX എഞ്ചിനീയർമാർ അന്തിമ തീരുമാനമെടുക്കുക.

AI ഡിസൈനർമാരെ കോഡിന്റെ ഗുണനിലവാരത്തിന് കൂടുതൽ ഉത്തരവാദികളാക്കുന്നു. ഡിസൈൻ തന്നെ കോഡായി മാറുന്നതിനാൽ, ആ മാറ്റത്തെ നിയന്ത്രിക്കാൻ (gatekeep) ആരും അവശേഷിക്കുന്നില്ല.

UX എഞ്ചിനീയർമാരെ നമ്മൾ ഒഴിവാക്കരുത്. ഡിസൈനും സിസ്റ്റവും തമ്മിലുള്ള ബന്ധവും (mapping) കരാറും (contract) കൈകാര്യം ചെയ്യാൻ ആളുകൾ ആവശ്യമാണ്.

AI നിർദ്ദേശിക്കുന്ന കാര്യങ്ങളിൽ നിന്ന് നിങ്ങളുടെ തീരുമാനങ്ങൾക്കായി എന്തിനെ തിരഞ്ഞെടുക്കണമെന്ന് നിങ്ങൾ എങ്ങനെ തീരുമാനിക്കും?

Source: https://dev.to/slafleche/were-making-the-dreamweaver-mistake-again-on-purpose-this-time-ema