28 ദിവസങ്ങൾക്കുള്ളിൽ Android-നായി Sora നിർമ്മിക്കാൻ Codex എങ്ങനെ ഉപയോഗിച്ചുവെന്ന്

26.04.2026 മുതൽ, Sora ഉൽപ്പന്നം ഇനി ലഭ്യമല്ല.

നവംബർ മാസത്തിൽ, Android ഉപകരണമുള്ള ഏവർക്കും ഒരു ചെറിയ പ്രോംപ്റ്റ് ഒരു സജീവമായ വീഡിയോയാക്കി മാറ്റാനുള്ള കഴിവ് നൽകിക്കൊണ്ട്, ഞങ്ങൾ Sora Android ആപ്പ് ലോകത്തിന് അവതരിപ്പിച്ചു. ലോഞ്ച് ദിനത്തിൽ, ആപ്പ് പ്ലേ സ്റ്റോറിൽ #1 സ്ഥാനത്തെത്തി. ആൻഡ്രോയിഡ് ഉപയോക്താക്കൾ ആദ്യ 24 മണിക്കൂറിനുള്ളിൽ ഒരു മില്യണിലധികം വീഡിയോകൾ സൃഷ്ടിച്ചു.

ലോഞ്ചിന് പിന്നിൽ ഒരു കഥയുണ്ട്: Soraയുടെ പ്രൊഡക്ഷൻ ആൻഡ്രോയിഡ് ആപ്പിന്റെ പ്രാരംഭ പതിപ്പ് 28 ദിവസത്തിനുള്ളിൽ നിർമ്മിക്കപ്പെട്ടു, ഏത് Team-നും അല്ലെങ്കിൽ ഡെവലപ്പർക്കും ലഭ്യമായ ഏജൻ്റ് ആയ Codex-നോട് അതിനു നന്ദി പറയുന്നു.

2025 ഒക്ടോബർ 8 മുതൽ നവംബർ 5 വരെ, ഏകദേശം 5 ബില്യൺ token ഉപയോഗിച്ച് കോഡെക്സ്-നൊപ്പം പ്രവർത്തിക്കുന്ന ഒരു lean Engineering Team, ആൻഡ്രോയിഡിനായി Sora പ്രോട്ടോടൈപ്പിൽ നിന്ന് ആഗോള ലോഞ്ചിലേക്ക് കൊണ്ടുവന്നു. അതിന്റെ സ്കെയിൽ വലുതാണെങ്കിലും, ആപ്പിന് 99.9 ശതമാനം ക്രാഷ്-ഫ്രീ നിരക്കും ഞങ്ങൾക്ക് അഭിമാനിക്കാവുന്ന ഒരു ആർക്കിടെക്ചറും ആണ് ഉള്ളത്. ഞങ്ങൾ അതിനായി ഒരു രഹസ്യ മോഡൽ ഉപയോഗിച്ചോ എന്ന് നിങ്ങൾ ആലോചിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ GPT‑5.1‑Codex ന്റെ ഒരു പ്രാരംഭ പതിപ്പ് ഉപയോഗിച്ചു എന്നാണ് ഉത്തരം മോഡൽ – CLI, IDE വിപുലീകരണം, അല്ലെങ്കിൽ വെബ് ആപ്പ് വഴി ഇന്ന് ഏതെങ്കിലും ഡെവലപ്പർക്ക് അല്ലെങ്കിൽ Business-ന് ഉപയോഗിക്കാവുന്ന അതെ പതിപ്പ്.

സോറ iOS-ൽ പുറത്തിറങ്ങിയപ്പോൾ ഉപയോഗം കുതിച്ചുയർന്നു. ആളുകൾ ഉടൻ തന്നെ വീഡിയോകളുടെ ഒരു പ്രവാഹം സൃഷ്ടിക്കാൻ തുടങ്ങി. ആൻഡ്രോയിഡിൽ,നേരെ മറിച്ച്, ഞങ്ങൾക്ക് ഒരു ചെറിയ ആന്തരിക പ്രോട്ടോടൈപ്പ് മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ, കൂടാതെ Google Play-ൽ മുൻകൂട്ടി രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കളുടെ എണ്ണം വർദ്ധിച്ചു വരികയായിരുന്നു.

ഉയർന്ന സമ്മര്‍ദ്ദമുള്ള, സമയപരിധിയുള്ള ഒരു ലോഞ്ചിന് സാധാരണമായ പ്രതികരണം എന്നത് കൂടുതൽ വിഭവങ്ങൾ ചേർക്കുകയും പ്രക്രിയകള്‍ കൂട്ടുകയും ചെയ്യുന്നതാണ്. ഈ വ്യാപ്തിയിലും ഗുണനിലവാരത്തിലും ഉള്ള ഒരു പ്രൊഡക്ഷൻ ആപ്പ് സാധാരണയായി മാസങ്ങളോളം പ്രവർത്തിക്കുന്ന നിരവധി എഞ്ചിനീയർമാരെ ഉൾക്കൊള്ളുകയും അതിന്റെ ഏകോപനം മന്ദഗതിയിൽ ആയിരിക്കുകയും ചെയ്യും. 

അമേരിക്കൻ കമ്പ്യൂട്ടർ ആർക്കിടെക്റ്റ് ഫ്രെഡ് ബ്രൂക്സ് പ്രശസ്തമായി മുന്നറിയിപ്പ് നൽകിയത് ഇങ്ങനെയാണ്: "ഒരു വൈകിയ സോഫ്റ്റ്വെയർ പദ്ധതിയിലേക്ക് കൂടുതൽ ആളുകളെ ചേർക്കുന്നത് അതിനെ കൂടുതൽ വൈകിപ്പിക്കും." മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, സങ്കീർണ്ണമായ ഒരു പദ്ധതി വേഗത്തിൽ പൂർത്തിയാക്കാൻ ശ്രമിക്കുമ്പോൾ, കൂടുതൽ എഞ്ചിനീയർമാരെ ചേർക്കുന്നത് പലപ്പോഴും ആശയവിനിമയ ഭാരം, ടാസ്ക് വിഭജനം, സംയോജന ചെലവുകൾ എന്നിവ വർദ്ധിപ്പിച്ച് കാര്യക്ഷമത കുറയ്ക്കും. ഈ ഉൾക്കാഴ്ച അവഗണിക്കുന്നതിനുപകരം ഞങ്ങൾ അതിലേക്ക് ശ്രദ്ധിച്ചു; നാല് എഞ്ചിനീയർമാരുടെ ഒരു ശക്തമായ Team-നെ ഞങ്ങൾ നിര്‍മ്മിച്ചു- ഓരോ എഞ്ചിനീയറുടെയും സ്വാധീനം ഗണ്യമായി വർദ്ധിപ്പിക്കുന്നതിന് കോഡെക്സ് കൊണ്ട് എല്ലാവരെയും സജ്ജീകരിച്ചു . 

ഈ രീതിയിൽ പ്രവർത്തിച്ച്, 18 ദിവസത്തിനുള്ളിൽ ഞങ്ങൾ Soraയുടെ ഇന്‍റെണൽ ബിൽഡ് ജീവനക്കാർക്ക് അയച്ചു, 10 ദിവസങ്ങൾക്ക് ശേഷം പൊതുവായി പുറത്തിറക്കി. ഞങ്ങൾ ആൻഡ്രോയിഡ് എഞ്ചിനീയറിംഗ് രീതികളിൽ ഉയർന്ന നിലവാരം നിലനിർത്തി, പരിപാലനക്ഷമതയിൽ ശ്രദ്ധിച്ചു, കൂടാതെ ഒരു പരമ്പരാഗത പദ്ധതിയിൽ നിന്ന് പ്രതീക്ഷിക്കപെടുന്ന അതെ നിലവാരത്തില്‍ ആപ്പിന്റെ വിശ്വാസ്യത നിലനിർത്തി. (ആപ്പിനെ വികസിപ്പിക്കുകയും പുതിയ സവിശേഷതകൾ ഉൾപ്പെടുത്തുകയും ചെയ്യുന്നതിനായി ഞങ്ങൾ ഇന്നും കോഡെക്സ് വ്യാപകമായി ഉപയോഗിക്കുന്നത് തുടരുന്നു).

ഞങ്ങൾ Codex-നൊപ്പം എങ്ങനെ പ്രവർത്തിച്ചുവെന്ന് മനസ്സിലാക്കാൻ, Codex എവിടെയാണ് മികച്ചതും എവിടെയാണ് മാർഗ്ഗനിർദ്ദേശം ആവശ്യമെന്നും അറിയുക എന്നത് സഹായകരമാണ്. ഇതിനെ പുതുതായി നിയമിച്ച സീനിയർ എഞ്ചിനീയറെ പോലെ പരിഗണിക്കുന്നത് നല്ല സമീപനമായിരുന്നു. Codex ന്റെ കഴിവ് നിമിത്തം, ഞങ്ങൾക്ക് സ്വയം കോഡ് എഴുതുന്നതിനെക്കാൾ, കോഡ് നിർദ്ദേശിക്കുകയും അവലോകനം ചെയ്യുകയും ചെയ്യുന്നതിൽ കൂടുതൽ സമയം ചെലവഴിക്കാൻ കഴിഞ്ഞു.

കോഡെക്‌സിന് മാർഗ്ഗനിർദ്ദേശം ആവശ്യമുള്ളിടത്ത്

1. Codex ഇതുവരെ നിങ്ങള്‍ അറിയിക്കാത്ത കാര്യങ്ങള്‍ മനസ്സിലാക്കുന്നതിൽ അതത്ര മികച്ചതല്ല.( നിങ്ങളുടെ ഇഷ്ടപ്പെട്ട ആർക്കിടെക്ചർ പാറ്റേണുകൾ, ഉൽപ്പന്ന തന്ത്രം, യഥാർത്ഥ ഉപയോക്തൃ പെരുമാറ്റം, ആന്തരിക മാനദണ്ഡങ്ങൾ അല്ലെങ്കിൽ ഷോർട്ട്കട്ടുകൾ എന്നിവ)
2. അതുപോലെ, കോഡെക്സ്ന് ആപ്പ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നതും കാണാൻ കഴിഞ്ഞില്ല: Sora ഒരു ഉപകരണത്തിൽ തുറക്കാൻ കഴിയില്ല, ഒരു സ്ക്രോൾ ശരിയായില്ലെന്ന് ശ്രദ്ധിക്കാൻ കഴിയില്ല, അല്ലെങ്കിൽ ഒരു പ്രവാഹം ആശയക്കുഴപ്പമുണ്ടാക്കുന്നതായി അനുഭവിക്കാൻ കഴിയില്ല. ഇത്തരം അനുഭവപരിചയം ആവശ്യമുള്ള ടാസ്കുകൾ കൈകാര്യം ചെയ്യാൻ കഴിവുള്ളത് ഞങ്ങളുടെ Team-ന് മാത്രമാണ്.
3. ഓരോ ഘട്ടത്തിനും ഓൺബോർഡിംഗ് ആവശ്യമാണ്. “നാം കാര്യങ്ങൾ എങ്ങനെ ചെയ്യുന്നു” എന്നതിനെക്കുറിച്ചുള്ള വ്യക്തമായ ലക്ഷ്യങ്ങൾ, നിയന്ത്രണങ്ങൾ, മാർഗ്ഗനിർദ്ദേശങ്ങൾ എന്നിവയുള്ള അതാത് സന്ദര്‍ഭത്തില്‍ പങ്കിടുന്നത്, Codex നന്നായി പ്രവർത്തിക്കുനതിന് നിർണായകമായിരുന്നു.
4. അതേ രീതിയിൽ, കോഡെക്സ് ആഴത്തിലുള്ള ആർക്കിടെക്ചറൽ തീരുമാനം എടുക്കുന്നത് സംബന്ധിച്ച് ബുദ്ധിമുട്ടി: സ്വതന്ത്രമായി വിട്ടാൽ, നിലവിലുള്ള ഒരു മോഡൽ വിപുലീകരിക്കേണ്ടിടത്ത് ഒരു അധിക വ്യൂ മോഡൽ അവതരിപ്പിക്കാം അല്ലെങ്കിൽ വ്യക്തമായും ഒരു റിപോസിറ്ററിയിൽ ഉള്‍പ്പെടെണ്ട ലോജിക്കിനെ UI ലെയറിലേക്ക് തള്ളിക്കൊണ്ടുപോകാം. അതിന്റെ സഹജമായ വാസന എന്തെങ്കിലും പ്രവർത്തനക്ഷമമാക്കലാണ്, ദീർഘകാലത്തേക്ക് അടുക്കും ചിട്ടയും ഉണ്ടാക്കുന്നതിനു മുൻഗണന നൽകുന്നത് അല്ല.

കോഡെക്സ് കോഡ്ബേസിൽ AGENT.md ഫയലുകൾ ധാരാളമായി സൃഷ്ടിക്കുകയും പരിപാലിക്കുകയും ചെയ്യുന്നത് ഉപകാരപ്രദമാണെന്ന് ഞങ്ങൾ കണ്ടെത്തി. ഇത് സെഷനുകളിലുടനീളം അതേ മാർഗ്ഗനിർദ്ദേശങ്ങളും മികച്ച പ്രാക്ടീസുകളും പ്രയോഗിക്കാൻ എളുപ്പമാക്കി. ഉദാഹരണത്തിന്, Codex ഞങ്ങളുടെ ശൈലി മാർഗ്ഗനിർദ്ദേശങ്ങൾ പാലിച്ച് കോഡ് എഴുതിയെന്ന് ഉറപ്പാക്കാൻ, ഞങ്ങൾ താഴെ പറയുന്നവ AGENTS.md-ന്റെ മുകളിൽ ചേർത്തു:

കോഡെക്സ് മികവുറ്റത് എവിടെയാണെന്ന്

1. വലിയ കോഡ്ബേസുകൾ വേഗത്തിൽ വായിക്കുകയും മനസ്സിലാക്കുകയും ചെയ്യുക: കോഡെക്സ് പ്രധാനമായും എല്ലാ പ്രധാന പ്രോഗ്രാമിംഗ് ഭാഷകളും അറിയുന്നു, ഇത് സങ്കീർണ്ണമായ അബ്സ്ട്രാക്ഷനുകൾ ഇല്ലാതെ പല പ്ലാറ്റ്ഫോമുകളിലുടനീളം ഒരേ ആശയങ്ങൾ പ്രയോഗിക്കാൻ എളുപ്പമാക്കുന്നു.
2. ടെസ്റ്റിംഗ് കവറേജ്: കോഡെക്സ് (പ്രത്യേകമായി) വിവിധ കേസുകൾ ഉൾക്കൊള്ളുന്നതിന് യൂണിറ്റ് ടെസ്റ്റുകൾ എഴുതുന്നതിൽ ആവേശഭരിതനാണ്. ഓരോ ടെസ്റ്റും ആഴത്തിലുള്ളതായിരുന്നില്ല, പക്ഷേ കവറേജിന്റെ വ്യാപ്തി നിലനിർത്തുന്നത് പുനരാവർത്തനങ്ങൾ തടയുന്നതിന് സഹായകമായിരുന്നു. 
3. ഫീഡ്ബാക്ക് പ്രയോഗിക്കുന്നത്: അതേ രീതിയിൽ, ഫീഡ്ബാക്കിന് പ്രതികരിക്കുന്നതിൽ കോഡെക്സ് നല്ലതാണ്. CI പരാജയപ്പെട്ടപ്പോൾ, ഞങ്ങൾക്ക് ലോഗ് ഔട്ട്പുട്ട് ഒരു പ്രോംപ്റ്റിലേക്ക് പേസ്റ്റ് ചെയ്ത്, പരിഹാരങ്ങൾ നിർദ്ദേശിക്കാൻ Codex-നോട് ചോദിക്കാമായിരുന്നു.
4. വിപുലമായ സമാന്തരവും, ഉപേക്ഷിക്കാവുന്ന എക്സിക്യൂഷൻ: ഒരേസമയം പ്രവർത്തിപ്പിക്കാവുന്ന സെഷനുകളുടെ പരമാവധി എണ്ണം ഉപയോഗിക്കാന്‍ പലരും ശ്രമിക്കാറില്ല. ഒന്നിലധികം ആശയങ്ങൾ സമാന്തരമായി പരീക്ഷിക്കുകയും കോഡിനെ ഉപേക്ഷിക്കാവുന്നതായി കാണുകയും ചെയ്യുന്നത് വളരെ സാദ്ധ്യമാണ്.
5. പുതിയ കാഴ്ചപ്പാട്: ഡിസൈൻ ചർച്ചകളിൽ, പ്രശ്നപരിഹാരത്തിനുള്ള പുതിയ മാർഗ്ഗങ്ങൾ കണ്ടെത്താനും പരാജയസാധ്യതയുള്ള സ്ഥലങ്ങള്‍ കണ്ടെത്താനും ഒരു നിര്‍മാണ ഉപകരണമായി Codex-നെ ഉപയോഗിച്ചു. ഉദാഹരണത്തിന്, വീഡിയോ പ്ലെയർ മെമ്മറി ഓപ്റ്റിമൈസേഷനുകൾ രൂപകൽപ്പന ചെയ്തപ്പോൾ, ഞങ്ങൾക്ക് വിശകലനം ചെയ്യാൻ സമയം ലഭിക്കാത്ത സമീപനങ്ങൾ നിർദ്ദേശിക്കാൻ കോഡെക്സ് പല SDKകളിലും കൂടി തിരഞ്ഞെടുത്തു. Codexന്റെ ഗവേഷണത്തിൽ നിന്നുള്ള അവബോധങ്ങൾ അന്തിമ ആപ്പിലെ മെമ്മറി ഫുട്പ്രിന്റ് കുറയ്ക്കുന്നതിൽ അമൂല്യമാമായി മാറി.
6. ഉയർന്ന ലീവറേജ് ജോലികൾ പ്രാപ്തമാക്കൽ: പ്രായോഗികമായി, ഞങ്ങൾ സ്വയം കോഡ് എഴുതുന്നതിലും കൂടുതൽ സമയം അവലോകനം ചെയ്യാനും നിർദ്ദേശങ്ങൾ നൽകാനും ചെലവഴിച്ചു. അതുപോലെ, കോഡെക്സ് കോഡ് അവലോകനത്തിൽ വളരെ നല്ലതാണ്, പലപ്പോഴും ബഗുകൾ കൂട്ടിച്ചേർക്കുന്നതിന് മുമ്പ് കണ്ടെത്തുകയും വിശ്വാസ്യത മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്നു.

ഈ സവിശേഷതകൾ അംഗീകരിച്ചതോട് കൂടി, ഞങ്ങളുടെ പ്രവർത്തന മോഡൽ കൂടുതൽ ലളിതമായി. ഞങ്ങളുടെ Team ആർക്കിടെക്ചർ, ഉപയോക്താവ് അനുഭവം, സിസ്റ്റമാറ്റിക് മാറ്റങ്ങൾ, അന്തിമ ഗുണനിലവാരം എന്നിവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുമ്പോൾ, നന്നായി മനസ്സിലാക്കാവുന്നതും നന്നായി പരിധി നിശ്ചയിച്ചിരിക്കുന്നതുമായതും പാറ്റേണുകളും പരിധികളും ഉള്ളതുമായ വലിയ തോതിലുള്ള ഭാരം ഏറ്റെടുക്കാനും അത് കൈകാര്യം ചെയ്യാനും ഞങ്ങൾ Codex-നെ ആശ്രയിച്ചു.

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

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

"എത്രയും വേഗം 'പ്രവർത്തിക്കുന്ന ഒന്നിനെ' ഉണ്ടാക്കുക എന്നതായിരുന്നില്ല ആശയം, മറിച്ച് 'നമുക്ക് കാര്യങ്ങൾ പ്രവർത്തിക്കണമെന്ന് ആഗ്രഹിക്കുന്ന രീതിയിൽ ഉള്ള' ഒന്നിനെ ഉണ്ടാക്കുക എന്നതാണ്." കോഡ് എഴുതുന്നതിനുള്ള പല "ശരിയായ" മാർഗങ്ങളുമുണ്ട്. Codex-നെ എന്ത് ചെയ്യണമെന്ന് കൃത്യമായി പറയുകയല്ല; ഞങ്ങളുടെ Team-ന് "ശരിയായത്" എന്താണെന്ന് Codex-നെ കാണിക്കുകയാണ് ചെയ്യാന്‍ ഉണ്ടായിരുന്നത്. ഞങ്ങൾ ഞങ്ങള്‍ക്ക് വേണ്ട തുടക്കവും നിർമ്മിക്കാൻ ഇഷ്ടപ്പെടുന്ന രീതിയും സ്ഥാപിച്ചു കഴിഞ്ഞതോടെ, Codex പ്രവര്‍ത്തനം ആരംഭിക്കാൻ തയ്യാറായി.

എന്ത് സംഭവിക്കുമെന്ന് കാണാൻ, ഞങ്ങൾ “iOS കോഡിനെ അടിസ്ഥാനമാക്കി Sora Android ആപ്പ് നിർമ്മിക്കുക” എന്ന് പ്രോംപ്റ്റ് നല്‍കി ശ്രമിച്ചു നോക്കി. "Go," കൊടുത്തു എങ്കിലും, ആ പാത വേഗത്തിൽ ഉപേക്ഷിച്ചു. കോഡെക്സ് സൃഷ്ടിച്ചത് സാങ്കേതികമായി പ്രവർത്തിച്ചുവെങ്കിലും, ഉൽപ്പന്നം ഉപയോഗിച്ചു നോക്കുമ്പോള്‍ തൃപ്തികരമല്ലായിരുന്നു. എൻഡ്പോയിന്റുകൾ, ഡാറ്റ, ഉപയോക്തൃ പ്രവാഹങ്ങൾ എന്നിവയുടെ വ്യക്തമായ മനസ്സിലാക്കലില്ലാതെ, കോഡെക്സ്‌ന്‍റെ സിംഗിൾ-ഷോട്ട് കോഡ് വിശ്വസനീയമല്ലായിരുന്നു (ഏജൻ്റ് ഉപയോഗിക്കാതെ ആണെങ്കില്‍ പോലും, ആയിരക്കണക്കിന് വരി കോഡ് കൂട്ടിച്ചേർക്കുന്നത് അപകടകരമാണ്.) 

നന്നായി എഴുതിയ ഉദാഹരണങ്ങളുടെ സാൻഡ്ബോക്സിൽ Codex വളരും എന്ന് ഞങ്ങൾ കരുതിയിരുന്നു; ഞങ്ങൾ ശരിയുമായിരുന്നു. കൂടുതൽ സന്ദർഭ വിവരണം ഇല്ലാതെ "ഈ ക്രമീകരണ സ്ക്രീൻ നിർമ്മിക്കുക" എന്ന് കോഡെക്സിനോട് ചോദിക്കുന്നത് വിശ്വസനീയമല്ലായിരുന്നു. "മറ്റൊരു സ്‌ക്രീൻ നിങ്ങൾ കണ്ടതുപോലെ തന്നെ ആർക്കിടെക്ചർ, പാറ്റേണുകൾ ഉപയോഗിച്ച് ഈ സെറ്റിംഗ്സ് സ്‌ക്രീൻ നിർമ്മിക്കാൻ കോഡെക്സിനോട് ആവശ്യപ്പെടുന്ന രീതി വളരെ നന്നായി പ്രവർത്തിച്ചു." മനുഷ്യർ ഘടനാപരമായ തീരുമാനങ്ങൾ എടുത്തു, സ്ഥിരതകൾ നിശ്ചയിച്ചു; തുടർന്ന്, കോഡെക്സ് ആ ഘടനയ്ക്കുള്ളിൽ വലിയ അളവിലുള്ള കോഡ് പൂരിപ്പിച്ചു.

Codex-ന്റെ സാധ്യത പരമാവധി ഉപയോഗപ്പെടുത്തുന്നതിലെ അടുത്ത ചുവടുവയ്പ്പ്, Codex-നെ ദീർഘകാലം (സമീപകാലത്ത്, 24 മണിക്കൂറിൽ കൂടുതൽ⁠) നിരീക്ഷണമില്ലാതെ പ്രവർത്തന സജ്ജമാക്കുന്നത് എങ്ങനെ സാധ്യമാക്കാം എന്നതാണ്.

Codex ഉപയോഗിക്കുന്നതിന്റെ തുടക്കത്തിൽ, "ഇവിടെ പ്രോംപ്റ്റ് ആണ്. ഇവിടെ ചില ഫയലുകൾ ഉണ്ട്. "ദയവായി അത് നിർമ്മിക്കുക.” അത് ചിലപ്പോൾ പ്രവർത്തിച്ചു, പക്ഷേ കൂടുതലും സാങ്കേതികമായി കംപൈൽ ചെയ്യുന്ന കോഡ് ഉൽപാദിപ്പിച്ചു, എന്നാൽ നമ്മുടെ ആർക്കിടെക്ചറും ലക്ഷ്യങ്ങളും വിട്ടുമാറി എന്നുമാത്രം.

അതുകൊണ്ട് ഞങ്ങൾ വർക്ക്ഫ്ലോ മാറ്റി. ഏതെങ്കിലും ഗൗരവമായ മാറ്റത്തിനായി, സിസ്റ്റവും കോഡും എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് മനസ്സിലാക്കാൻ ആദ്യം ഞങ്ങൾ കോഡെക്സ്-നെ സഹായത്തിനായി ചോദിച്ചു. ഉദാഹരണത്തിന്, ഞങ്ങൾ അതിനോട് ഒരു കൂട്ടം ബന്ധപ്പെട്ട ഫയലുകൾ വായിച്ച് ആ ഫീച്ചർ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് സംഗ്രഹിക്കാൻ ആവശ്യപ്പെടും; ഉദാഹരണത്തിന്, APIയിൽ നിന്ന് ഡാറ്റ റിപോസിറ്ററി ലെയർ, മോഡൽ, UI എന്നിവയിലേക്ക് എങ്ങനെ ഒഴുകുന്നു എന്ന്. അപ്പോൾ അതിന്റെ മനസ്സിലാക്കുന്നതില്‍ തിരുത്തല്‍ വരുത്തുകയോ മെച്ചപ്പെടുത്തുകയോ ചെയ്യും. (ഉദാഹരണത്തിന്, ഒരു പ്രത്യേക അബ്സ്ട്രാക്ഷൻ വ്യത്യസ്തമായ ഒരു ലെയറിൽ പെട്ടതാണെന്ന് അല്ലെങ്കിൽ ഒരു ക്ലാസ് ഓഫ്‌ലൈൻ മോഡിനായി മാത്രമേ ഉള്ളൂ, അതിനാൽ അത് വിപുലീകരിക്കരുതെന്ന് ഞങ്ങൾ ചൂണ്ടിക്കാണിക്കും.)

നിങ്ങൾ ഒരു പുതിയ, അത്യന്തം കഴിവുള്ള കൂട്ടാളിയുമായി ഏർപ്പെടുന്നതുപോലെ, ഞങ്ങൾ കോഡെക്സ് ഉപയോഗിച്ച് ഒരു ഉറച്ച നടപ്പാക്കാന്‍ കഴിയുന്ന പദ്ധതി സൃഷ്ടിച്ചു. ആ പദ്ധതി പലപ്പോഴും ചെറിയൊരു ഡിസൈൻ ഡോക്യുമെൻ്റ് പോലെ ഫയലുകൾ എങ്ങനെ മാറ്റണം, പുതിയ സ്റ്റേറ്റുകൾ ഏത് പരിചയപ്പെടുത്തണം, ലോജിക് എങ്ങനെ പ്രവഹിക്കണം എന്നതിനെക്കുറിച്ച് നിർദ്ദേശിക്കുന്നതുപോലെ തോന്നി. അപ്പോൾ മാത്രമാണ് ഞങ്ങൾ Codex-നോട് ഓരോ ഘട്ടം വീതം ആയി പദ്ധതി നടപ്പാക്കാൻ തുടങ്ങാൻ ആവശ്യപ്പെട്ടത്. ഒരു ഉപകാരപ്രദമായ ടിപ്പ്: വളരെ ദൈർഘ്യമേറിയ ടാസ്കുകൾക്കായി, ഞങ്ങളുടെ സന്ദർഭ വിൻഡോയുടെ പരിധി തൊടുമ്പോൾ, കോഡെക്സിനോട് അതിന്റെ പദ്ധതി ഒരു ഫയലിൽ സംരക്ഷിക്കാൻ ആവശ്യപ്പെടുക, ഇതുവഴി ഓരോ ഘട്ടത്തിലും ഒരേ രീതി തന്നെ പ്രയോഗിക്കാന്‍ കഴിയും.

ഈ അധിക പദ്ധതിയിടൽ ലൂപ്പിനായി എടുത്ത സമയം നഷ്ടമായില്ല എന്ന് തെളിഞ്ഞു. കോഡെക്സ്സിനെ ദീർഘകാലം "മേല്‍നോട്ടം ഇല്ലാതെ" പ്രവർത്തിക്കാൻ ഞങ്ങൾക്ക് അനുവദിച്ചു, കാരണം അതിന്റെ പദ്ധതികൾ ഞങ്ങൾക്കറിയാമായിരുന്നു. ഇത് കോഡ് അവലോകനം എളുപ്പമാക്കി, കാരണം ഞങ്ങൾക്ക് ഒരു സന്ദർവ്യത്യാസം വായിക്കുന്നതിനുപകരം, ഞങ്ങളുടെ പദ്ധതിക്കെതിരെ നടപ്പാക്കല്‍ ഉണ്ടാകുന്നുണ്ടോ പരിശോധിക്കാൻ കഴിഞ്ഞു. എന്തെങ്കിലും പിശക് സംഭവിച്ചാൽ, ആദ്യം ഞങ്ങൾ പദ്ധതി ഡീബഗ് ചെയ്യുകയും, പിന്നെ കോഡ് ഡീബഗ് ചെയ്യുകയും ചെയ്യും. 

ഒരു നല്ല ഡിസൈൻ ഡോക്യുമെൻ്റ് ഒരു ടെക് ലീഡിന് ഒരു പദ്ധതിയിൽ ആത്മവിശ്വാസം നൽകുന്ന രീതിയോട് സമാനമായിരുന്നു ആ ഡൈനാമിക്. ഞങ്ങൾ കേവലം കോഡ് സൃഷ്ടിച്ചിരുന്നില്ല: ഒരു പങ്കിട്ട റോഡ്‌മാപ്പിനെ പിന്തുണയ്ക്കുന്ന കോഡ് ഉൽപാദിപ്പിക്കുകയായിരുന്നു.

പദ്ധതിയുടെ ഉച്ചസ്ഥായിയിൽ, ഞങ്ങൾ പലപ്പോഴും സമാന്തരമായി ഒന്നിലധികം Codex സെഷനുകൾ നടത്തുകയായിരുന്നു. ഒരാൾ പ്ലേബാക്കിൽ പ്രവർത്തിക്കുകയായിരുന്നു, മറ്റൊരാൾ തിരച്ചിലിൽ, മറ്റൊരാൾ പിശക് കൈകാര്യം ചെയ്യലിൽ, ചിലപ്പോൾ മറ്റൊരാൾ പരീക്ഷണങ്ങളിൽ അല്ലെങ്കിൽ പുനഃസംഘടനകളിൽ. ഇത് ഒരു ഉപകരണം ഉപയോഗിക്കുന്നതുപോലെ എന്നതിനേക്കാള്‍, ഒരു Team മാനേജുചെയ്യുന്നതുപോലെ തോന്നി.

ഓരോ സെഷനും കാലാകാലങ്ങളിൽ പുരോഗതി ഞങ്ങളിലേക്ക് റിപ്പോർട്ട് ചെയ്യും. ഒരാൾ പറയാം, "ഞാൻ ഈ മോഡ്യൂൾ പദ്ധതിയിടുന്നത് പൂർത്തിയാക്കി; ഞാൻ നിർദ്ദേശിക്കുന്നത് ഇതാണ്," മറ്റൊരാൾ ഒരു പുതിയ ഫീച്ചറിനായി വലിയ വ്യത്യാസം നിർദ്ദേശിക്കും. ഓരോന്നിനും ശ്രദ്ധ, ഫീഡ്ബാക്ക്, അവലോകനം ആവശ്യമായിരുന്നു. പുതിയ എഞ്ചിനീയർമാരുമായി ടെക് ലീഡായിരുന്ന അനുഭവം അത്ഭുതകരമായി സമാനമായിരുന്നു, എല്ലാവരും പുരോഗതി കൈവരിക്കുന്നു, എല്ലാവർക്കും മാർഗ്ഗനിർദ്ദേശം ആവശ്യമുണ്ട്.

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

അതേ സമയം, ആ അധിക വേഗത കാരണം ഞങ്ങളുടെ അവലോകന ക്യൂവിൽ എപ്പോഴും എന്തെങ്കിലും കാത്തിരിപ്പുണ്ടായിരുന്നു. Codex-ന് സന്ദർഭം മാറുന്നതിൽ തടസ്സം നേരിട്ടില്ല, പക്ഷേ ഞങ്ങൾ അത് നേരിട്ടു. വികസനത്തിലെ ഞങ്ങളുടെ തടസ്സം കോഡ് എഴുതുന്നതിൽ നിന്ന് തീരുമാനങ്ങൾ എടുക്കൽ, ഫീഡ്ബാക്ക് നൽകൽ, മാറ്റങ്ങൾ സംയോജിപ്പിക്കൽ എന്നിവയിലേക്ക് മാറി.

ഇവിടെയാണ് ബ്രൂക്സ്‌യുടെ ഉൾക്കാഴ്ചകൾ പുതിയ രീതിയിൽ എത്തുന്നത്. നിങ്ങൾക്ക് കോഡെക്സ് സെഷനുകൾ ചേർക്കുകയും തുടര്‍ച്ചയായ വേഗത വർദ്ധനവുകൾ പ്രതീക്ഷിക്കുകയും ചെയ്യാനാകില്ല, നിങ്ങൾക്ക് എഞ്ചിനീയർമാരെ ഒരു പദ്ധതിയിലേക്ക് ചേർക്കുകയും അങ്ങനെ ഷെഡ്യൂൾ നേര്‍ രേഖയിലേക്ക് ചുരുങ്ങുമെന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യാനാകില്ല. ഓരോ അധിക "ജോഡി കൈകളും," വെർച്വൽ ആയാല്‍ പോലും, ഏകോപനത്തിന്റെ അധികഭാരവും കൂട്ടുന്നു. ഞങ്ങൾ വേഗത്തിൽ സോളോ കളിക്കാരാകുന്നതിന് പകരം ഒരു ഓർക്കസ്ട്രയുടെ കൺഡക്ടറായി മാറി.

ഞങ്ങളുടെ പദ്ധതി ഒരു വലിയ മൈൽസ്റ്റോൺ കൊണ്ട് ആരംഭിച്ചു: Sora ഇതിനകം iOS-ൽ ഷിപ്പുചെയ്തിരുന്നു. കോടെക്സ്-ന് പ്രധാന ആവശ്യകതകളും നിയന്ത്രണങ്ങളും മനസ്സിലാക്കാൻ സഹായിക്കുന്നതിനായി, ഞങ്ങൾ പലപ്പോഴും iOS, ബാക്ക്എൻഡ് കോഡ്ബേസുകളിലേക്ക് അതിനെ തിരിച്ചു വിട്ടു. പദ്ധതിയുടെ മുഴുവൻ സമയത്തും ഞങ്ങൾ ഒരു ക്രോസ്-പ്ലാറ്റ്ഫോം ഫ്രെയിംവർക്കിന്റെ ആശയം പുനരാവിഷ്കരിച്ചുവെന്ന് തമാശയായി പറഞ്ഞു. റിയാക്ട് നേറ്റീവ് അല്ലെങ്കിൽ ഫ്ലട്ടർ മറക്കുക; ക്രോസ്-പ്ലാറ്റ്ഫോമിന്റെ ഭാവി വെറും കോഡെക്സ് മാത്രമാണ്.

ആ പരിഹാസത്തിനുള്ളില്‍ രണ്ട് തത്വങ്ങളുണ്ട്:.

1. ലോജിക് പോർട്ടബിൾ ആണ്. കോഡ് സ്വിഫ്റ്റിലോ കോട്ലിനിലോ എഴുതിയാലും, അടിസ്ഥാന ആപ്ലിക്കേഷൻ ലജിക് - ഡാറ്റ മോഡലുകൾ, നെറ്റ്‌വർക്ക് കോൾസ്, സാധൂകരണ നിയമങ്ങൾ, Business ലജിക് - എല്ലാം ഒരേപോലെയാണ്. Codex ഒരു Swift നടപ്പാക്കൽ വായിച്ച് അർത്ഥം സംരക്ഷിക്കുന്ന അതെ രീതിയില്‍ Kotlin-ൽ സമാനമായ ഒരു നടപ്പാക്കൽ നിർമ്മിക്കുന്നതിൽ വളരെ നല്ലതാണ്.
2. കൃത്യമായ ഉദാഹരണങ്ങൾ ശക്തമായ സന്ദർഭം വിവരണം നൽകുന്നു. iOS-ൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കുന്നതും Android ആർക്കിടെക്ചർ ഇതാ എന്നതും കാണിക്കുന്ന ഒരു പുതിയ കോഡെക്സ് സെഷൻ, പ്രകൃതിദത്ത ഭാഷാ വിവരണങ്ങളിൽ നിന്ന് മാത്രം പ്രവർത്തിക്കുന്നതിനെക്കാൾ വളരെ ഫലപ്രദമാണ്.

ഈ തത്വങ്ങൾ പ്രയോഗത്തിൽ കൊണ്ടുവന്ന്, iOS, ബാക്ക്എൻഡ്, ആൻഡ്രോയിഡ് റീപോകൾ ഒരേ പരിസ്ഥിതിയിൽ ലഭ്യമാക്കി. ഞങ്ങൾ കോഡെക്സ് പ്രോംപ്റ്റുകൾ നൽകി, ഉദാഹരണങ്ങൾ ഇങ്ങനെ:

“ഈ മോഡലുകളും എൻഡ്പോയിന്റുകളും iOS കോഡിൽ വായിച്ച്, നിലവിലുള്ള API ഉപഭോക്താവും മോഡൽ ക്ലാസുകളും ഉപയോഗിച്ച് സമാനമായ സ്വഭാവം Android-ൽ നടപ്പിലാക്കാനുള്ള ഒരു പദ്ധതി നിർദ്ദേശിക്കുക.”

ഒരു ചെറിയ പക്ഷേ ഉപകാരപ്രദമായ തന്ത്രം പ്രാദേശിക റിപ്പോസിറ്ററികൾ എവിടെയാണുള്ളത്, അവയിൽ എന്താണ് ഉള്ളത് എന്നിവ ~/.codex/ഏജൻ്റുകൾ.md ൽ വിശദീകരിക്കുന്നതായിരുന്നു. അത് കോഡെക്സിന് അനുയോജ്യമായ കോഡ് കണ്ടെത്താനും നാവിഗേറ്റ് ചെയ്യാനും എളുപ്പമാക്കി.

ഞങ്ങൾ പങ്കിടുന്ന അബ്സ്ട്രാക്ഷൻ ഉപയോഗിക്കുന്നതിന് പകരം വിവർത്തനം വഴി ക്രോസ്-പ്ലാറ്റ്ഫോം വികസനം ഫലപ്രദമായി നടത്തുകയായിരുന്നു. കോടെക്സ് ഭൂരിഭാഗം വിവർത്തനം കൈകാര്യം ചെയ്തതുവഴി, നടപ്പാക്കൽ ചെലവുകൾ ഇരട്ടിയാക്കുന്നത് ഒഴിവാക്കാൻ ഞങ്ങൾ കഴിഞ്ഞു.

വിപുലമായ പാഠം എന്തെന്നാല്‍ Codex-നെ സംബന്ധിച്ച്, സന്ദർഭം ആണ് എല്ലാം . iOS-ൽ ഫീച്ചർ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചും, നമ്മുടെ ആൻഡ്രോയിഡ് ആപ്പ് എങ്ങനെ അതുമായി ഘടിപ്പിച്ചിരിക്കുന്നു എന്നതിനെക്കുറിച്ചും മനസിലാക്കിയപ്പോൾ, കോഡെക്സ് അതിന്റെ മികച്ച പ്രവർത്തനം നടത്തി. Codex-ന് ആ സാഹചര്യത്തിൽ ആ സന്ദർഭം ഇല്ലാതിരുന്നപ്പോൾ, അത് "സഹകരിക്കാൻ നിരസിക്കുന്നതല്ല"; അത് ഒരു ഊഹം മാത്രമായിരുന്നു. ഞങ്ങൾ അതിനെ ഒരു പുതിയ സഹപ്രവർത്തകനായി പരിഗണിച്ച്, ശരിയായ ഇൻപുട്ടുകൾ നൽകുന്നതിൽ ശ്രദ്ധിച്ചപ്പോള്‍ അതിന്റെ പ്രകടനവും മെച്ചപ്പെട്ടു.

നമ്മുടെ നാലാഴ്ച നീണ്ട സ്പ്രിന്റിന്റെ അവസാനം, കോഡെക്സ് ഉപയോഗിക്കുന്നത് ഒരു പരീക്ഷണമായി തോന്നുന്നത് നിർത്തി, അത് നമ്മുടെ ഡിഫോൾട്ട് വികസന ചക്രമായി മാറി. ഞങ്ങൾ നിലവിലുള്ള കോഡ് മനസ്സിലാക്കാനും, മാറ്റങ്ങൾക്കുള്ള പദ്ധതി തയ്യാറാക്കാനും, സവിശേഷതകൾ നടപ്പിലാക്കാനും ഇത് ഉപയോഗിച്ചു. ഞങ്ങൾ അതിന്റെ ഔട്ട്പുട്ട് അവലോകനം ചെയ്തത്, ഞങ്ങളുടെ ഒരു സഹപ്രവർത്തകന്റെത് അവലോകനം ചെയ്യുന്ന അതേ രീതിയിൽ ആയിരുന്നു. അത് ഞങ്ങൾ സോഫ്റ്റ്വെയർ വിതരണം ചെയ്ത രീതിയായിരുന്നു.

AI സഹായത്തോടെ വികസനം കൃത്യതയുടെ ആവശ്യം കുറയ്ക്കുന്നില്ലെന്ന് വ്യക്തമായി; മറിച്ച്, അത് അതിനെ വർദ്ധിപ്പിക്കുന്നു. കോഡെക്സ് എത്രത്തോളം കഴിവുള്ളതാണെങ്കിലും, അതിന്റെ ലക്ഷ്യം ഇപ്പോൾ A മുതൽ B വരെ എത്തിച്ചേരുക എന്നതാണ്. ഇതാണ് AI സഹായത്തോടെ കോഡിംഗ് മനുഷ്യരെ കൂടാതെ പ്രവർത്തിക്കാത്തതിന്റെ കാരണം. സോഫ്റ്റ്വെയർ എഞ്ചിനീയർമാർ സിസ്റ്റങ്ങളുടെ യഥാർത്ഥ ലോക നിയന്ത്രണങ്ങൾ മനസ്സിലാക്കുകയും പ്രയോഗിക്കുകയും ചെയ്യുന്നു, സോഫ്റ്റ്വെയർ എങ്ങനെ മികച്ച രീതിയിൽ രൂപകൽപ്പന ചെയ്യാമെന്ന്, ഭാവിയിലെ വികസനവും ഉൽപ്പന്ന പദ്ധതികളും മനസ്സിൽ വെച്ച് എങ്ങനെ നിർമ്മിക്കാമെന്നും മനസ്സിലാക്കുകയും ചെയ്യുന്നു. നാളെയുടെ സോഫ്റ്റ്വെയർ എഞ്ചിനീയറുടെ അത്യന്തിക കഴിവുകൾ ആഴത്തിലുള്ള സിസ്റ്റംസ് മനസ്സിലാക്കലും ദീർഘകാല ദൂരക്കാഴ്ചകളിൽ AI-യുമായി സഹകരിച്ച് പ്രവർത്തിക്കാനുള്ള കഴിവുമാണ്. 

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

ഒരു സമ്പന്നമായ സന്ദർഭത്തിൽ Codex സജ്ജീകരിക്കുമ്പോൾ, അത് നിങ്ങളുടെ ലക്ഷ്യങ്ങളും നിങ്ങൾ നിർമ്മിക്കാൻ ഇഷ്ടപ്പെടുന്ന രീതിയും മനസ്സിലാക്കുമ്പോൾ, ഏതൊരു Team-നും അതിന്റെ ശേഷികളെ പല മടങ്ങ്‌ വര്‍ദ്ധിപ്പിക്കാന്‍ കഴിയും. ഞങ്ങളുടെ ലോഞ്ച് റെട്രോ ഒരു സർവസാധാരണ പരിഹാരമല്ല, AI സഹായത്തോടെ വികസനം പരിഹരിച്ചുവെന്ന് ഞങ്ങൾ അവകാശപ്പെടുന്നില്ല. എന്നാൽ കോഡെക്സ് ഉപയോഗിച്ച് നിങ്ങളെ ശാക്തീകരിക്കാൻ മികച്ച മാർഗങ്ങൾ കണ്ടെത്താൻ ഞങ്ങളുടെ അനുഭവം എളുപ്പമാക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു. 

ഏഴ് മാസങ്ങൾക്ക് മുമ്പ് ഗവേഷണ പ്രിവ്യൂയിൽ കോഡെക്സ് ആരംഭിച്ചപ്പോൾ, സോഫ്റ്റ്വെയർ എഞ്ചിനീയറിംഗ് വളരെ വ്യത്യസ്തമായിരുന്നു. Sora വഴി, ഞങ്ങൾക്ക് എഞ്ചിനീയറിംഗിന്റെ അടുത്ത അധ്യായം കണ്ടെത്താൻ കഴിഞ്ഞു. ഞങ്ങളുടെ മോഡലുകളും ഹാർനെസും മെച്ചപ്പെടുന്നതിനാൽ, AI, നിർമ്മാണത്തിന്റെ അനിവാര്യമായ ഭാഗമായി മാറും.

നിങ്ങളുടെ സ്വന്തം കോഡെക്സ് Team ഉപയോഗിച്ച് നിങ്ങൾ എന്താണ് നിർമ്മിക്കുക?