અમે 28 દિવસમાં Codex નો ઉપયોગ કરીને Android માટે Sora કેવી રીતે બનાવ્યું

26 એપ્રિલ, 2026થી, Sora પ્રોડક્ટ હવે ઉપલબ્ધ નથી.

નવેમ્બરમાં, અમે Sora Android એપ વિશ્વભરમાં લોન્ચ કરી, જેથી Android ઉપકરણ ધરાવતો કોઈપણ વ્યક્તિ ટૂંકા પ્રોમ્પ્ટને જીવંત વિડિયોમાં ફેરવી શકે. લોન્ચના દિવસે, એપ Play Store માં #1 સ્થાને પહોંચી. Android વપરાશકર્તાઓએ પ્રથમ 24 કલાકમાં દસ લાખથી વધુ વિડિયો બનાવ્યા.

આ લોન્ચ પાછળ એક વાર્તા છે: Sora ની પ્રોડક્શન Android એપનું પ્રારંભિક વર્ઝન 28 દિવસમાં બનાવાયું, અને તે પણ એ જ એજન્ટની મદદથી જે કોઈપણ ટીમ અથવા ડેવલપર માટે ઉપલબ્ધ છે: Codex.

8 ઑક્ટોબરથી 5 નવેમ્બર, 2025 દરમિયાન, Codex સાથે કામ કરતી અને અંદાજે 5 અબજ ટોકન વાપરતી નાની એન્જિનિયરિંગ ટીમે Sora for Android ને પ્રોટોટાઇપથી વૈશ્વિક લોન્ચ સુધી પહોંચાડ્યું. તેના વ્યાપ હોવા છતાં, એપનો ક્રેશ-ફ્રી દર 99.9 ટકા છે અને તેની આર્કિટેક્ચર પર અમને ગર્વ છે. જો તમે વિચારી રહ્યા હો કે શું અમે કોઈ ગુપ્ત મોડલ વાપર્યું, તો અમે GPT‑5.1‑Codex મોડલનું પ્રારંભિક વર્ઝન વાપર્યું હતું – એ જ વર્ઝન જે આજે કોઈપણ ડેવલપર અથવા વ્યવસાય CLI, IDE એક્સ્ટેન્શન, અથવા વેબ એપ દ્વારા વાપરી શકે છે.

જ્યારે Sora iOS પર લોન્ચ થયું, ત્યારે વપરાશમાં વિસ્ફોટ થયો. લોકો તરત જ સતત વિડિયો બનાવવા લાગ્યા. તેની સામે, Android પર અમારી પાસે માત્ર નાનું આંતરિક પ્રોટોટાઇપ હતું અને Google Play પર પૂર્વ-નોંધાયેલા વપરાશકર્તાઓની સંખ્યા વધી રહી હતી.

ઉચ્ચ દાવ અને સમયના દબાણવાળા લોન્ચ માટે સામાન્ય પ્રતિક્રિયા એ વધુ સંસાધનો ઉમેરવાની અને વધુ પ્રક્રિયા લાવવાની હોય છે. આ કદ અને ગુણવત્તાની પ્રોડક્શન એપ માટે સામાન્ય રીતે ઘણા એન્જિનિયરોને મહિનાઓ સુધી કામ કરવું પડે, અને સંકલનને કારણે ગતિ ધીમી પડે.

અમેરિકન કમ્પ્યુટર આર્કિટેક્ટ Fred Brooks એ પ્રસિદ્ધ રીતે ચેતવણી આપી હતી કે “મોડી પડેલા સોફ્ટવેર પ્રોજેક્ટમાં વધુ લોકોને ઉમેરવાથી તે વધુ મોડું થાય છે.” બીજા શબ્દોમાં કહીએ તો, જટિલ પ્રોજેક્ટને ઝડપથી શિપ કરવાનો પ્રયાસ કરતી વખતે વધુ એન્જિનિયર ઉમેરવાથી ઘણી વાર સંચારનો ભાર, કામનું વિખંડન, અને ઇન્ટિગ્રેશન ખર્ચ વધે છે, જે કાર્યક્ષમતા ધીમી કરે છે. અમે આ સમજણને અવગણવાને બદલે તેને સ્વીકારી; અમે ચાર એન્જિનિયરોની મજબૂત ટીમ બનાવી – અને દરેકને Codex થી સજ્જ કર્યા જેથી દરેક એન્જિનિયરની અસર નોંધપાત્ર રીતે વધે.

આ રીતે કામ કરીને, અમે 18 દિવસમાં કર્મચારીઓ માટે Sora for Android નું આંતરિક બિલ્ડ શિપ કર્યું અને 10 દિવસ પછી જાહેર લોન્ચ કર્યું. અમે Android એન્જિનિયરિંગ પ્રથાઓમાં ઊંચો ધોરણ જાળવ્યો, જાળવણીક્ષમતા માટે રોકાણ કર્યું, અને એપને તે જ વિશ્વસનીયતા ધોરણ પર રાખી જેની અમે વધુ પરંપરાગત પ્રોજેક્ટમાંથી અપેક્ષા રાખીએ. (આજે પણ અમે એપને વિકસાવવા અને તેમાં નવી સુવિધાઓ લાવવા માટે Codex નો વ્યાપક ઉપયોગ ચાલુ રાખ્યો છે.)

Codex સાથે અમે કેવી રીતે કામ કર્યું તે સમજવા માટે, તે ક્યાં તેજસ્વી છે અને ક્યાં તેને માર્ગદર્શનની જરૂર પડે છે તે જાણવું ઉપયોગી છે. તેને નવા ભરતી કરાયેલા સિનિયર એન્જિનિયર તરીકે જોવાનો અભિગમ સારો રહ્યો. Codex ની ક્ષમતાના કારણે અમે કોડ પોતે લખવા કરતાં તેને દિશા આપવા અને સમીક્ષા કરવા વધુ સમય ફાળવી શક્યા.

Codex ને જ્યાં માર્ગદર્શનની જરૂર પડે છે

1. Codex ને હજુ સુધી એવી વસ્તુઓનું અનુમાન કરવામાં ખાસ કુશળતા નથી જે તેને જણાવવામાં આવી નથી (જેમ કે તમારી પસંદની આર્કિટેક્ચર પેટર્ન, પ્રોડક્ટ સ્ટ્રેટેજી, વાસ્તવિક વપરાશકર્તા વર્તન, અને આંતરિક નિયમો અથવા શોર્ટકટ્સ).
2. એ જ રીતે, Codex એપને વાસ્તવમાં ચાલતી જોઈ શકતું નહોતું: તે ડિવાઇસ પર Sora ખોલી શકતું નહોતું, સ્ક્રોલ થોડી અજીબ લાગે છે તે જાણી શકતું નહોતું, અથવા કોઈ ફ્લો ગૂંચવણભર્યો છે તે અનુભવી શકતું નહોતું. આવા અનુભવ આધારિત કામો માત્ર અમારી ટીમ જ કરી શકતી હતી.
3. દરેક ઇન્સ્ટન્સને ઓનબોર્ડિંગની જરૂર પડે છે. સ્પષ્ટ લક્ષ્યો, મર્યાદાઓ અને “અમે કામ કેવી રીતે કરીએ છીએ” તે બાબતે માર્ગદર્શન સાથે સંદર્ભ શેર કરવો Codex ને સારું કામ કરાવવા માટે જરૂરી હતું.
4. એ જ પ્રકારથી, Codex ને ઊંડા આર્કિટેક્ચરલ નિર્ણયોમાં મુશ્કેલી પડતી હતી: તેને એકલા છોડી દેવાય તો તે ત્યાં વધારાનો view model ઉમેરે જ્યાં અમે અસ્તિત્વમાં રહેલો view model વિસ્તૃત કરવા માગતા હોઈએ, અથવા એવી લોજિક UI સ્તરમાં ધકેલે જે સ્પષ્ટ રીતે repository માં હોવી જોઈએ. તેની સ્વાભાવિક વૃત્તિ કંઈક કાર્યરત બનાવી દેવાની છે, લાંબા ગાળાની સ્વચ્છતાને પ્રથમ સ્થાન આપવાની નહીં.

અમને કોડબેઝમાં સર્વત્ર પૂરતી સંખ્યામાં AGENT.md ફાઇલો બનાવવી અને જાળવવી Codex માટે ઉપયોગી લાગી. આથી સત્રો દરમિયાન એ જ માર્ગદર્શન અને શ્રેષ્ઠ પદ્ધતિઓ લાગુ કરવી સરળ બની. ઉદાહરણ તરીકે, Codex અમારા સ્ટાઇલ માર્ગદર્શિકા મુજબ કોડ લખે તેની ખાતરી કરવા માટે અમે અમારી ટોચની AGENTS.md માં નીચેનું ઉમેર્યું:

Codex જ્યાં ઉત્તમ છે

1. મોટા કોડબેઝને ઝડપથી વાંચવા અને સમજવામાં: Codex ને મૂળભૂત રીતે તમામ મુખ્ય પ્રોગ્રામિંગ ભાષાઓનું જ્ઞાન છે, જેનાથી જટિલ એબ્સ્ટ્રેક્શન વગર ઘણી પ્લેટફોર્મ્સ પર સમાન ધારણાઓનો ઉપયોગ કરવો સરળ બને છે.
2. ટેસ્ટિંગ કવરેજ: Codex (અનોખી રીતે) વિવિધ પ્રકારના કેસોને આવરી લેતા યુનિટ ટેસ્ટ્સ લખવા માટે ઉત્સાહી છે. દરેક ટેસ્ટ ખૂબ ઊંડો ન હતો, પણ વિશાળ કવરેજ રિગ્રેશન અટકાવવા મદદરૂપ બન્યું.
3. ફીડબેક લાગુ કરવામાં: એ જ રીતે, Codex ફીડબેક પર પ્રતિસાદ આપવા સારો છે. જ્યારે CI નિષ્ફળ ગયું, ત્યારે અમે લોગ આઉટપુટ પ્રોમ્પ્ટમાં પેસ્ટ કરીને Codex ને સુધારા સૂચવવા કહી શકતા.
4. વિશાળ પાયે સમકાલીન અને બદલી શકાય તેવી કામગીરી: મોટા ભાગના લોકો એક સમયે હકીકતમાં કેટલી સત્રો ચલાવી શકે તેની મર્યાદા સુધી નહીં પહોંચે. અનેક વિચારોને સમકક્ષ રીતે પરીક્ષણ કરવું અને કોડને બદલી શકાય તેવી વસ્તુ તરીકે જોવું સંપૂર્ણપણે શક્ય છે.
5. નવી દૃષ્ટિ આપવી: ડિઝાઇન ચર્ચાઓમાં, અમે Codex ને સંભાવિત નિષ્ફળતા બિંદુઓ શોધવા અને સમસ્યા ઉકેલવાની નવી રીતો શોધવા માટે જનરેટિવ સાધન તરીકે ઉપયોગ કર્યો. ઉદાહરણ તરીકે, જ્યારે અમે વિડિયો પ્લેયર માટે મેમરી ઑપ્ટિમાઇઝેશન ડિઝાઇન કરી રહ્યા હતા, ત્યારે Codex એ અનેક SDK તપાસીને એવા અભિગમ સૂચવ્યા જે અમે સમજવા માટે સમય કાઢી શકતા ન હોત. Codex ના સંશોધનમાંથી મળેલી સમજણ અંતિમ એપમાં મેમરી ફૂટપ્રિન્ટ ઘટાડવામાં અમૂલ્ય સાબિત થઈ.
6. ઉચ્ચ પ્રભાવવાળા કામને શક્ય બનાવવું: પ્રયોગમાં, અમે પોતે કોડ લખવા કરતાં તેની સમીક્ષા કરવા અને દિશા આપવા વધુ સમય ખર્ચ્યો. તેમ છતાં, Codex કોડ રિવ્યૂમાં પણ ખૂબ સારો છે, અને ઘણી વાર બગ્સ મર્જ થાય તે પહેલાં જ પકડી લે છે, જેથી વિશ્વસનીયતા સુધરે.

એકવાર અમે આ લક્ષણોને સ્વીકારી લીધા પછી, અમારું કાર્ય મોડલ વધુ સીધું બન્યું. અમે સારી રીતે સમજાયેલા પેટર્ન અને સારી રીતે મર્યાદિત ક્ષેત્રોમાં ભારે કામ કરવા માટે Codex પર નિર્ભર રહ્યા, જ્યારે અમારી ટીમે આર્કિટેક્ચર, યુઝર અનુભવ, સિસ્ટમ સ્તરના ફેરફારો અને અંતિમ ગુણવત્તા પર ધ્યાન કેન્દ્રિત કર્યું.

સૌથી ઉત્તમ નવા સિનિયર હાયર પાસે પણ લાંબા ગાળાના સમતોલ નિર્ણયો તરત લેવા માટે યોગ્ય દૃષ્ટિકોણ હોતો નથી. Codex નો અસરકારક ઉપયોગ કરવા અને તેનું કામ મજબૂત તેમજ જાળવણીક્ષમ રહે તેની ખાતરી કરવા માટે, એપની સિસ્ટમ્સ ડિઝાઇન અને મુખ્ય સમતોલ નિર્ણયો પર અમારી જાતે દેખરેખ રાખવી ખૂબ જ જરૂરી હતી. તેમાં એપની આર્કિટેક્ચર, મોડ્યુલરાઇઝેશન, dependency injection, અને navigation ઘડવાનું સામેલ હતું; અમે authentication અને આધારભૂત networking flows પણ અમલમાં મૂક્યા.

આ પાયા પરથી, અમે કેટલીક પ્રતિનિધિ સુવિધાઓ end-to-end લખી. સમગ્ર કોડબેઝે અનુસરવા જોઈએ એવા નિયમોનો ઉપયોગ કર્યો અને કામ દરમિયાન પ્રોજેક્ટ-વ્યાપી પેટર્નનું દસ્તાવેજીકરણ કર્યું. Codex ને પ્રતિનિધિ સુવિધાઓ બતાવતાં, તે અમારા ધોરણો અંદર વધુ સ્વતંત્ર રીતે કામ કરી શક્યું. જે પ્રોજેક્ટનો અંદાજે 85% ભાગ Codex એ લખ્યો હતો, તેમાં ધ્યાનપૂર્વક આયોજન કરેલા પાયાએ ખર્ચાળ પાછાં વળવું અને રિફેક્ટરિંગ ટાળ્યું. આ અમારા સૌથી મહત્વપૂર્ણ નિર્ણયોમાંથી એક હતો.

વિચાર એ નહોતો કે શક્ય તેટલું વહેલું “ચાલી જાય એવું કંઈક” બનાવવું, પરંતુ “અમે વસ્તુઓ કેવી રીતે કામ કરે તે ઇચ્છીએ છીએ તે સમજતું કંઈક” બનાવવું. કોડ લખવાની ઘણી “સાચી” રીતો હોય છે. અમને Codex ને ચોક્કસ શું કરવું તે કહેવાની જરૂર નહોતી; અમને Codex ને બતાવવાની જરૂર હતી કે અમારી ટીમમાં “સાચું” શું છે. એકવાર અમે અમારો પ્રારંભિક બિંદુ અને બનાવવાની પસંદગીની રીત સ્થાપિત કરી, ત્યાર પછી Codex શરૂ કરવા તૈયાર હતું.

શું થાય છે તે જોવા માટે, અમે “iOS કોડ આધારિત Sora Android એપ બનાવો. Go,” એવો પ્રોમ્પ્ટ આપવાનો પ્રયાસ કર્યો, પણ તે રસ્તો જલ્દી છોડ્યો. Codex એ બનાવેલું ટેક્નિકલ રીતે કામ કરતું હતું, પરંતુ પ્રોડક્ટ અનુભવ નબળો હતો. અને endpoints, ડેટા અને user flows ની સ્પષ્ટ સમજણ વિના, Codex દ્વારા એક જ વાર જનરેટ કરાયેલ કોડ વિશ્વસનીય ન હતો. (એજન્ટ વગર પણ, હજારો લાઇન કોડ મર્જ કરવું જોખમી છે.)

અમારું અનુમાન હતું કે સારી રીતે લખાયેલા ઉદાહરણોના sandbox માં Codex વધુ સારી રીતે ખીલે; અને અમે સાચા નીકળ્યા. Codex ને લગભગ કોઈ સંદર્ભ વિના “આ settings screen બનાવો” કહેવું વિશ્વસનીય ન હતું. Codex ને “તમે હમણાં જ જોયેલી બીજી screen જેવી જ architecture અને patterns નો ઉપયોગ કરીને આ settings screen બનાવો” કહેવું ઘણી વધુ સારું કામ કરતું. માનવોએ માળખાકીય નિર્ણયો કર્યા અને invariants નક્કી કર્યા; ત્યારબાદ Codex એ તે માળખાની અંદર મોટી માત્રામાં કોડ ભરી દીધો.

Codex ની ક્ષમતા વધુમાં વધુ ઉપયોગી બને તે માટે અમારું આગલું પગલું એ સમજવું હતું કે Codex ને લાંબા સમય સુધી (હમણાં તાજેતરમાં, 24 કલાકથી વધુ⁠) દેખરેખ વિના કેવી રીતે કામ કરવા સક્ષમ બનાવવું.

Codex નો પ્રારંભિક ઉપયોગ કરતા વખતે, અમે સીધા આવા પ્રોમ્પ્ટ પર કૂદી પડતા: “આ રહી સુવિધા. અહીં કેટલીક ફાઇલો છે. કૃપા કરીને તેને બનાવો.” ક્યારેક તે કામ કરતું, પરંતુ મોટાભાગે એવું કોડ મળતું જે ટેક્નિકલ રીતે compile થતું હોવા છતાં અમારી આર્કિટેક્ચર અને લક્ષ્યોથી ભટકી જતું.

અેથી અમે વર્કફ્લો બદલી નાખ્યો. કોઈપણ ગૌણ ન ગણાય એવા ફેરફાર માટે, અમે પ્રથમ Codex ને સિસ્ટમ અને કોડ કેવી રીતે કામ કરે છે તે સમજવામાં મદદ કરવા કહ્યું. ઉદાહરણ તરીકે, અમે તેને સંબંધિત ફાઇલોનો સમૂહ વાંચીને તે સુવિધા કેવી રીતે કામ કરે છે તેનો સારાંશ આપવા કહીએ; જેમ કે ડેટા API માંથી repository layer, view model મારફતે UI સુધી કેવી રીતે વહે છે. ત્યારબાદ અમે તેની સમજણ સુધારતા અથવા વધુ પરિષ્કૃત કરતા. (ઉદાહરણ તરીકે, અમે જણાવી દઈએ કે કોઈ ચોક્કસ abstraction ખરેખર બીજી layer માં હોવું જોઈએ અથવા આપેલ class માત્ર offline mode માટે જ છે અને તેને વિસ્તૃત ન કરવી જોઈએ.)

જેમ તમે નવા, અત્યંત કુશળ સાથી સાથે કામ કરો તેમ, અમે Codex સાથે મળી મજબૂત implementation plan બનાવી. આ યોજના ઘણી વખત નાનકડા design document જેવી દેખાતી હતી, જેમાં કઈ ફાઇલો બદલવી, કયા નવા states ઉમેરવા, અને logic કેવી રીતે વહેવી જોઈએ તે નિર્દેશિત કરવામાં આવતું. ત્યારબાદ જ અમે Codex ને એક સમયે એક પગલું ભરી આ યોજના અમલમાં મૂકવાનું કહ્યું. એક ઉપયોગી સૂચન: ખૂબ લાંબા કામો માટે, જ્યાં અમારી context window મર્યાદા આવી જાય, અમે Codex ને તેની યોજના ફાઇલમાં સાચવવા કહીએ, જેથી વિવિધ instances માં એ જ દિશા લાગુ કરી શકીએ.

આ વધારાનો આયોજન ચક્ર સમયની દૃષ્ટિએ યોગ્ય સાબિત થયો. તેનાથી અમે Codex ને લાંબા સમય સુધી “દેખરેખ વિના” ચલાવવા આપી શક્યા, કારણ કે અમને તેની યોજનાઓ ખબર હતી. તેણે કોડ રિવ્યૂ સરળ બનાવ્યું, કારણ કે અમે સંદર્ભ વિના diff વાંચવાને બદલે અમલને અમારી યોજના સામે ચકાસી શક્યા. અને જ્યારે કંઈ ખોટું ગયું, ત્યારે અમે પહેલા યોજના અને પછી કોડ ડિબગ કરી શક્યા.

આ ગતિશીલતા એવી લાગતી હતી જેવી રીતે સારો design document ટેક લીડને પ્રોજેક્ટમાં વિશ્વાસ આપે છે. અમે ફક્ત કોડ જનરેટ નહોતાં કરી રહ્યા: અમે એવા કોડનું ઉત્પાદન કરી રહ્યા હતા જે સહભાગી માર્ગનકશાને આધાર આપતું હતું.

પ્રોજેક્ટના શિખર સમયે, અમે ઘણી વખત એક સાથે અનેક Codex સત્રો ચલાવતા હતા. એક playback પર કામ કરતું, બીજું search પર, ત્રીજું error handling પર, અને ક્યારેક બીજું tests અથવા refactors પર. તે સાધન વાપરવા કરતાં વધુ, ટીમ મેનેજ કરવા જેવું લાગતું હતું.

દરેક સત્ર સમયાંતરે પ્રગતિ અંગે અમને જાણ કરતું. એક કહે, “હું આ module માટેનું આયોજન પૂર્ણ કર્યું; મારું પ્રસ્તાવ આ છે,” જ્યારે બીજું નવી સુવિધા માટે મોટો diff રજૂ કરે. દરેકને ધ્યાન, પ્રતિસાદ અને સમીક્ષાની જરૂર પડતી. તે આશ્ચર્યજનક રીતે એવા ટેક લીડ જેવું લાગતું હતું જેને ઘણા નવા એન્જિનિયરો હોય, બધા પ્રગતિ કરતાં હોય, અને બધાને માર્ગદર્શન જોઈએ.

પરિણામે સહકારાત્મક પ્રવાહ મળ્યો. Codex ની કાચી કોડિંગ ક્ષમતાએ અમને ઘણું મેન્યુઅલ ટાઇપિંગ કરવાથી મુક્ત કર્યા. આર્કિટેક્ચર વિશે વિચારવા, pull requests ધ્યાનથી વાંચવા, અને એપનું પરીક્ષણ કરવા માટે અમારે વધુ સમય હતો.

સાથે સાથે, આ વધારાની ઝડપનો અર્થ એ પણ હતો કે અમારી રિવ્યૂ કતારમાં હંમેશા કંઈક રાહ જોતું રહેતું. Codex context switching થી અટકતું નહોતું, પણ અમે અટકતા. વિકાસમાં અમારો bottleneck કોડ લખવાથી સરકી ને નિર્ણય લેવો, પ્રતિસાદ આપવો, અને ફેરફારોને એકીકૃત કરવા તરફ ખસી ગયો.

અહીં Brooks ની સમજણ નવી રીતે લાગુ પડે છે. તમે ફક્ત Codex સત્રો ઉમેરતા જાવો અને સીધી રેખામાં ગતિ વધે તેવી અપેક્ષા રાખી શકતા નથી, જેમ તમે સતત એન્જિનિયરો ઉમેરો તો પ્રોજેક્ટનું શેડ્યૂલ સીધું ઘટશે એવી અપેક્ષા રાખી શકતા નથી. દરેક વધારાનો “હાથનો જોડી,” ભલે તે વર્ચ્યુઅલ હોય, સંકલનનો વધારાનો ભાર ઉમેરે છે. અમે ફક્ત વધુ ઝડપી એકલ ખેલાડીઓ ન રહી, પણ જાણે ઓર્કેસ્ટ્રાના સંચાલક બની ગયા હતા.

અમારો પ્રોજેક્ટ એક મોટા stepping stone સાથે શરૂ થયો: Sora પહેલેથી જ iOS પર શિપ થઈ ચૂક્યું હતું. મુખ્ય આવશ્યકતાઓ અને મર્યાદાઓ સમજવામાં મદદ માટે અમે વારંવાર Codex ને iOS અને backend કોડબેઝ તરફ દોરી જતા. સમગ્ર પ્રોજેક્ટ દરમિયાન અમે મજાક કરતાં કે અમે cross-platform framework ની કલ્પનાને ફરી શોધી કાઢી છે. React Native અથવા Flutter ભૂલી જાઓ; cross-platform નું ભવિષ્ય તો માત્ર Codex છે.

આ રમૂજી વાક્ય નીચે બે સિદ્ધાંતો છે:.

1. લોજિક પરિવહનযোগ্য છે. કોડ Swift માં લખાયેલ હોય કે Kotlin માં, મૂળભૂત એપ્લિકેશન લોજિક – data models, network calls, validation rules, business logic – એકસરખી હોય છે. Codex Swift implementation વાંચીને semantics જાળવતું Kotlin માં સમકક્ષ તૈયાર કરવામાં ખૂબ સારો છે.
2. ઠોસ ઉદાહરણો શક્તિશાળી સંદર્ભ આપે છે. નવી Codex session જે “iOS પર આ ચોક્કસ રીતે કામ કરે છે” અને “Android architecture આ છે” જોઈ શકે છે, તે માત્ર પ્રાકૃતિક ભાષાના વર્ણનો પરથી કામ કરતી session કરતાં ઘણી વધુ અસરકારક બને છે.

આ સિદ્ધાંતોને કાર્યરત બનાવતા, અમે iOS, backend અને Android repos એક જ environment માં ઉપલબ્ધ કર્યા. અમે Codex ને આવા પ્રોમ્પ્ટ આપ્યા:

“iOS કોડમાં આ models અને endpoints વાંચો અને પછી અમારા હાલના API client અને model classes નો ઉપયોગ કરીને Android પર સમકક્ષ વર્તન અમલમાં મૂકવાની યોજના રજૂ કરો.”

એક નાની પણ ઉપયોગી યુક્તિ એ હતી કે ~/.codex/AGENTS.md માં સ્થાનિક repos ક્યાં છે અને તેમાં શું છે તે વિગતવાર લખવું. તેનાથી Codex માટે સંબંધિત કોડ શોધવો અને તેમાં માર્ગદર્શન મેળવવું સરળ બન્યું.

અમે મૂળભૂત રીતે shared abstraction ને બદલે translation દ્વારા cross-platform development કરી રહ્યા હતા. કારણ કે મોટાભાગનું translation Codex સંભાળી લેતું હતું, અમે અમલીકરણ ખર્ચ બમણો થતો ટાળ્યો.

વિશાળ પાઠ એ છે કે Codex માટે સંદર્ભ જ બધું છે. જ્યારે Codex સમજી શકતું હતું કે સુવિધા iOS માં પહેલેથી કેવી રીતે કામ કરે છે, અને સાથે જ અમારું Android એપ કેવી રીતે ગોઠવાયેલું છે તે પણ સમજતું હતું, ત્યારે તેણે શ્રેષ્ઠ કામ કર્યું. જ્યારે Codex પાસે આ સંદર્ભ ન હતો, ત્યારે તે “સહકાર આપવાનો ઇનકાર” કરતું નહોતું; તે અનુમાન લગાવી રહ્યું હતું. અમે તેને જેટલું નવા સાથીદારમાં જેવું ગણ્યું અને યોગ્ય ઇનપુટ્સ આપવા જેટલું રોકાણ કર્યું, તેટલું તે વધુ સારું પ્રદર્શન કરતું ગયું.

અમારા ચાર અઠવાડિયાના સ્પ્રિન્ટના અંત સુધી, Codex નો ઉપયોગ પ્રયોગ જેવો લાગવો બંધ થયો અને તે અમારો ડિફોલ્ટ વિકાસ ચક્ર બની ગયો. અમે તેનો ઉપયોગ અસ્તિત્વમાં રહેલો કોડ સમજવા, ફેરફારોનું આયોજન કરવા, અને સુવિધાઓ અમલમાં મૂકવા માટે કર્યો. અમે તેની આઉટપુટની સમીક્ષા એ જ રીતે કરી જેમ અમે સહકર્મીના કામની સમીક્ષા કરીએ. સોફ્ટવેર શિપ કરવાની એ અમારી સામાન્ય રીત બની ગઈ.

સ્પષ્ટ થયું કે AI-assisted development કડકતા માટેની જરૂરિયાત ઘટાડતું નથી; તે વધારતું છે. Codex જેટલો સક્ષમ છે, તેનો હેતુ A થી B સુધી, હમણાં જ, પહોંચવાનો છે. આ જ કારણ છે કે માનવો વિના AI-assisted coding કામ કરતી નથી. સોફ્ટવેર એન્જિનિયરો સિસ્ટમોની વાસ્તવિક દુનિયાની મર્યાદાઓ સમજાવી અને લાગુ કરી શકે છે, સોફ્ટવેરને શ્રેષ્ઠ રીતે કેવી રીતે આર્કિટેક્ટ કરવું તે જાણે છે, અને ભવિષ્યના વિકાસ તેમજ પ્રોડક્ટ યોજનાઓને ધ્યાનમાં રાખીને કેવી રીતે નિર્માણ કરવું તે સમજે છે. આવતીકાલના સોફ્ટવેર એન્જિનિયરની સુપરપાવર્સ ઊંડું સિસ્ટમ્સ સમજણ અને લાંબા સમયગાળા સુધી AI સાથે સહકારથી કામ કરવાની ક્ષમતા હશે.

સોફ્ટવેર એન્જિનિયરિંગના સૌથી રસપ્રદ ભાગોમાં આકર્ષક પ્રોડક્ટ્સ બનાવવી, સ્કેલેબલ સિસ્ટમ્સ ડિઝાઇન કરવી, જટિલ અલ્ગોરિધમ્સ લખવા, અને ડેટા, પેટર્ન્સ અને કોડ સાથે પ્રયોગ કરવો આવે છે. જોકે, ભૂતકાળ અને વર્તમાનના સોફ્ટવેર એન્જિનિયરિંગની વાસ્તવિકતાઓ ઘણી વાર વધુ સામાન્ય રહી છે: બટનોને મધ્યમાં ગોઠવવા, endpoints જોડવા, અને boilerplate લખવું. હવે, Codex સોફ્ટવેર એન્જિનિયરિંગના સૌથી અર્થસભર ભાગો અને અમારી કળા પ્રત્યેના પ્રેમના કારણો પર ધ્યાન કેન્દ્રિત કરવાનું શક્ય બનાવે છે.

એકવાર Codex ને એવા સંદર્ભ-સમૃદ્ધ environment માં ગોઠવવામાં આવે જ્યાં તે તમારા લક્ષ્યો અને તમે કેવી રીતે નિર્માણ કરવું પસંદ કરો છો તે સમજે, કોઈપણ ટીમ પોતાની ક્ષમતાઓને અનેકગણી કરી શકે છે. અમારો launch retro દરેક માટે સમાન નુસ્ખો નથી, અને અમે એવો દાવો પણ નથી કરતા કે અમે AI-assisted development ઉકેલી દીધી છે. પરંતુ અમને આશા છે કે અમારો અનુભવ તમને Codex દ્વારા તમને સશક્ત બનાવવાની શ્રેષ્ઠ રીતો શોધવામાં સરળતા કરશે.

જ્યારે Codex સાત મહિના પહેલાં research preview માં લોન્ચ થયું, ત્યારે સોફ્ટવેર એન્જિનિયરિંગ ખૂબ અલગ લાગતું હતું. Sora દ્વારા, અમને એન્જિનિયરિંગના આગામી અધ્યાયને શોધવાની તક મળી. જેમ જેમ અમારા મોડલ્સ અને harness વધુ સુધરતા જશે, AI નિર્માણ પ્રક્રિયાનો વધતો અનિવાર્ય ભાગ બનશે.

Codex ની તમારી પોતાની ટીમ સાથે તમે શું બનાવશો?