ਅਸੀਂ 28 ਦਿਨਾਂ ਵਿੱਚ Codex ਦੀ ਵਰਤੋਂ ਕਰਕੇ Android ਲਈ Sora ਕਿਵੇਂ ਬਣਾਇਆ

26 ਅਪ੍ਰੈਲ, 2026 ਤੋਂ, Sora ਉਤਪਾਦ ਹੁਣ ਉਪਲਬਧ ਨਹੀਂ ਹੈ.

ਨਵੰਬਰ ਵਿੱਚ, ਅਸੀਂ Sora Android ਐਪ ਨੂੰ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ, ਜਿਸ ਨਾਲ Android ਡਿਵਾਈਸ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ ਇੱਕ ਛੋਟੇ ਪ੍ਰੌੰਪਟ ਨੂੰ ਜੀਵੰਤ ਵੀਡੀਓ ਵਿੱਚ ਬਦਲਣਾ ਸੰਭਵ ਹੋਇਆ. ਲਾਂਚ ਵਾਲੇ ਦਿਨ, ਐਪ Play Store ਵਿੱਚ #1 ਤੱਕ ਪਹੁੰਚ ਗਈ. ਪਹਿਲੇ 24 ਘੰਟਿਆਂ ਵਿੱਚ Android ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਦਸ ਲੱਖ ਤੋਂ ਵੱਧ ਵੀਡੀਓ ਬਣਾਈਆਂ.

ਇਸ ਲਾਂਚ ਦੇ ਪਿੱਛੇ ਇੱਕ ਕਹਾਣੀ ਹੈ: 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 'ਤੇ ਪਹਿਲਾਂ ਤੋਂ ਰਜਿਸਟਰ ਕੀਤੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਵਧਦੀ ਗਿਣਤੀ ਸੀ.

ਉੱਚ ਦਾਅਵਾਂ ਅਤੇ ਸਮੇਂ ਦੇ ਦਬਾਅ ਵਾਲੇ ਲਾਂਚ ਲਈ ਆਮ ਪ੍ਰਤੀਕਿਰਿਆ ਹੋਰ ਸੰਸਾਧਨ ਜੋੜਨਾ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਵਧਾਉਣਾ ਹੁੰਦੀ ਹੈ. ਇਸ ਦਾਇਰੇ ਅਤੇ ਗੁਣਵੱਤਾ ਵਾਲੀ ਪ੍ਰੋਡਕਸ਼ਨ ਐਪ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਇੰਜੀਨੀਅਰ ਮਹੀਨਿਆਂ ਤੱਕ ਕੰਮ ਕਰਦੇ, ਜਿਨ੍ਹਾਂ ਦੀ ਰਫ਼ਤਾਰ ਸਮਨਵਯ ਕਰਕੇ ਘਟ ਜਾਂਦੀ.

ਅਮਰੀਕੀ ਕੰਪਿਊਟਰ ਆਰਕੀਟੈਕਟ ਫ੍ਰੈਡ ਬਰੂਕਸ ਨੇ ਮਸ਼ਹੂਰ ਤੌਰ 'ਤੇ ਚੇਤਾਵਨੀ ਦਿੱਤੀ ਸੀ ਕਿ “ਦੇਰ ਨਾਲ ਚੱਲ ਰਹੇ ਸੌਫਟਵੇਅਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹੋਰ ਲੋਕ ਜੋੜਣ ਨਾਲ ਉਹ ਹੋਰ ਦੇਰ ਨਾਲ ਮੁਕੰਮਲ ਹੁੰਦਾ ਹੈ.” ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜਦੋਂ ਕਿਸੇ ਜਟਿਲ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਜਲਦੀ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਹੋਰ ਇੰਜੀਨੀਅਰ ਜੋੜਣ ਨਾਲ ਸੰਚਾਰ ਦੇ ਵੱਧ ਬੋਝ, ਕੰਮ ਦੇ ਟੁਕੜੇ ਹੋਣ ਅਤੇ ਇਕੀਕਰਨ ਦੀ ਲਾਗਤ ਕਰਕੇ ਕੁਸ਼ਲਤਾ ਅਕਸਰ ਘਟ ਜਾਂਦੀ ਹੈ. ਅਸੀਂ ਇਸ ਸਮਝ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਦੀ ਬਜਾਏ ਅਪਣਾਇਆ; ਅਸੀਂ ਚਾਰ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਮਜ਼ਬੂਤ ਟੀਮ ਬਣਾਈ – ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ Codex ਨਾਲ ਲੈਸ ਕੀਤਾ ਤਾਂ ਜੋ ਹਰ ਇੰਜੀਨੀਅਰ ਦਾ ਪ੍ਰਭਾਵ ਕਾਫ਼ੀ ਵੱਧ ਸਕੇ.

ਇਸ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਦਿਆਂ, ਅਸੀਂ 18 ਦਿਨਾਂ ਵਿੱਚ ਕਰਮਚਾਰੀਆਂ ਲਈ Sora for Android ਦੀ ਇੱਕ ਅੰਦਰੂਨੀ ਬਿਲਡ ਭੇਜੀ ਅਤੇ 10 ਦਿਨ ਬਾਅਦ ਜਨਤਕ ਤੌਰ 'ਤੇ ਲਾਂਚ ਕੀਤਾ. ਅਸੀਂ Android ਇੰਜੀਨੀਅਰਿੰਗ ਅਭਿਆਸਾਂ ਲਈ ਉੱਚ ਮਾਪਦੰਡ ਕਾਇਮ ਰੱਖੇ, ਸੰਭਾਲਯੋਗਤਾ ਵਿੱਚ ਨਿਵੇਸ਼ ਕੀਤਾ, ਅਤੇ ਐਪ ਨੂੰ ਉਸੇ ਭਰੋਸੇਯੋਗਤਾ ਦੇ ਮਾਪਦੰਡ 'ਤੇ ਰੱਖਿਆ ਜਿਸਦੀ ਅਸੀਂ ਇੱਕ ਹੋਰ ਰਵਾਇਤੀ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਉਮੀਦ ਕਰਦੇ. (ਅਸੀਂ ਅੱਜ ਵੀ ਐਪ ਨੂੰ ਵਿਕਸਿਤ ਕਰਨ ਅਤੇ ਇਸ ਵਿੱਚ ਨਵੇਂ ਫੀਚਰ ਲਿਆਉਣ ਲਈ Codex ਦੀ ਵਿਆਪਕ ਵਰਤੋਂ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ).

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਅਸੀਂ Codex ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕੀਤਾ, ਇਹ ਜਾਣਨਾ ਮਦਦਗਾਰ ਹੈ ਕਿ ਇਹ ਕਿੱਥੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿੱਥੇ ਇਸਨੂੰ ਦਿਸ਼ਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਇਸਨੂੰ ਨਵੀਂ ਭਰਤੀ ਕੀਤੇ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਲੈਣਾ ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ ਸੀ. Codex ਦੀ ਸਮਰੱਥਾ ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਅਸੀਂ ਕੋਡ ਖੁਦ ਲਿਖਣ ਦੀ ਬਜਾਏ ਇਸਨੂੰ ਦਿਸ਼ਾ ਦੇਣ ਅਤੇ ਸਮੀਖਿਆ ਕਰਨ 'ਤੇ ਵੱਧ ਸਮਾਂ ਬਿਤਾ ਸਕਦੇ ਸੀ.

ਜਿੱਥੇ Codex ਨੂੰ ਮਾਰਗਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ

1. Codex ਅਜੇ ਇਸ ਗੱਲ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਵਿੱਚ ਵਧੀਆ ਨਹੀਂ ਕਿ ਇਸਨੂੰ ਕੀ ਨਹੀਂ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਤੁਹਾਡੇ ਮਨਪਸੰਦ ਆਰਕੀਟੈਕਚਰ ਪੈਟਰਨ, ਪ੍ਰੋਡਕਟ ਰਣਨੀਤੀ, ਅਸਲੀ ਉਪਭੋਗਤਾ ਵਿਵਹਾਰ ਅਤੇ ਅੰਦਰੂਨੀ ਮਿਆਰ ਜਾਂ ਸ਼ਾਰਟਕੱਟ.
2. ਇਸੇ ਤਰ੍ਹਾਂ, Codex ਐਪ ਨੂੰ ਅਸਲ ਵਿੱਚ ਚੱਲਦਿਆਂ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਸੀ: ਇਹ ਡਿਵਾਈਸ 'ਤੇ Sora ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ ਸੀ, ਇਹ ਨਹੀਂ ਦੇਖ ਸਕਦਾ ਸੀ ਕਿ ਸਕ੍ਰੋਲ ਕੁਝ ਗਲਤ ਮਹਿਸੂਸ ਹੋ ਰਿਹਾ ਹੈ, ਜਾਂ ਇਹ ਨਹੀਂ ਸਮਝ ਸਕਦਾ ਸੀ ਕਿ ਕੋਈ ਫਲੋ ਉਲਝਣ ਭਰਾ ਹੈ. ਇਹ ਤਜਰਬਾਤਮਕ ਕੰਮ ਸਿਰਫ਼ ਸਾਡੀ ਟੀਮ ਹੀ ਕਰ ਸਕਦੀ ਸੀ.
3. ਹਰ ਇੰਸਟੈਂਸ ਲਈ ਆਨਬੋਰਡਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਸਪੱਸ਼ਟ ਲਕਸ਼ਾਂ, ਪਾਬੰਦੀਆਂ ਅਤੇ “ਅਸੀਂ ਕੰਮ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ” ਬਾਰੇ ਮਾਰਗਦਰਸ਼ਨ ਦੇ ਨਾਲ ਸੰਦਰਭ ਸਾਂਝਾ ਕਰਨਾ Codex ਤੋਂ ਵਧੀਆ ਕੰਮ ਲੈਣ ਲਈ ਬਹੁਤ ਜ਼ਰੂਰੀ ਸੀ.
4. ਇਸੇ ਤਰ੍ਹਾਂ, ਗਹਿਰੇ ਆਰਕੀਟੈਕਚਰਕ ਫੈਸਲਿਆਂ ਵਿੱਚ Codex ਨੂੰ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਸੀ: ਜੇ ਇਸਨੂੰ ਆਪਣੇ ਹਾਲ 'ਤੇ ਛੱਡਿਆ ਜਾਵੇ, ਤਾਂ ਇਹ ਉੱਥੇ ਇੱਕ ਵਾਧੂ view model ਲਿਆ ਸਕਦਾ ਸੀ ਜਿੱਥੇ ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦਾ ਵਾਲੇ ਨੂੰ ਵਧਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ ਜਾਂ ਲੌਜਿਕ ਨੂੰ UI ਲੇਅਰ ਵਿੱਚ ਧੱਕ ਸਕਦਾ ਸੀ ਜੋ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ. ਇਸਦੀ ਪ੍ਰਵਿਰਤੀ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਚਾਲੂ ਕਰ ਦੇਣ ਵੱਲ ਹੁੰਦੀ ਹੈ, ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਫ਼ਾਈ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਵੱਲ ਨਹੀਂ.

ਸਾਨੂੰ ਇਹ ਲਾਭਦਾਇਕ ਲੱਗਿਆ ਕਿ Codex ਕੋਡਬੇਸ ਵਿੱਚ ਕਈ ਥਾਵਾਂ 'ਤੇ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ AGENT.md ਫਾਈਲਾਂ ਬਣਾਏ ਅਤੇ ਸੰਭਾਲੇ. ਇਸ ਨਾਲ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹਾ ਮਾਰਗਦਰਸ਼ਨ ਅਤੇ ਸਰਵੋਤਮ ਅਭਿਆਸ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਹੋ ਗਿਆ. ਉਦਾਹਰਨ ਲਈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ Codex ਸਾਡੇ ਸਟਾਈਲ ਮਾਰਗਦਰਸ਼ਨਾਂ ਮੁਤਾਬਕ ਕੋਡ ਲਿਖੇ, ਅਸੀਂ ਆਪਣੇ ਟੌਪ-ਲੇਵਲ AGENTS.md ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤਾ ਸ਼ਾਮਲ ਕੀਤਾ:

ਜਿੱਥੇ Codex ਸ਼ਾਨਦਾਰ ਹੈ

1. ਵੱਡੇ ਕੋਡਬੇਸ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹਨਾ ਅਤੇ ਸਮਝਣਾ: Codex ਨੂੰ ਲਗਭਗ ਸਾਰੀਆਂ ਮੁੱਖ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਦੀ ਜਾਣਕਾਰੀ ਹੈ, ਜਿਸ ਨਾਲ ਜਟਿਲ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਤੋਂ ਬਿਨਾਂ ਕਈ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਇੱਕੋ ਹੀ ਸੰਕਲਪ ਵਰਤਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ.
2. ਟੈਸਟਿੰਗ ਕਵਰੇਜ: Codex ਯੂਨਿਟ ਟੈਸਟ ਲਿਖਣ ਲਈ ਵਿਲੱਖਣ ਤੌਰ 'ਤੇ ਉਤਸ਼ਾਹੀ ਹੈ ਤਾਂ ਜੋ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਕੇਸ ਕਵਰ ਕੀਤੇ ਜਾ ਸਕਣ. ਹਰ ਟੈਸਟ ਗਹਿਰਾ ਨਹੀਂ ਸੀ, ਪਰ ਵਿਸਤ੍ਰਿਤ ਕਵਰੇਜ ਨੇ ਰਿਗ੍ਰੈਸ਼ਨ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕੀਤੀ.
3. ਫੀਡਬੈਕ ਲਾਗੂ ਕਰਨਾ: ਇਸੇ ਤਰ੍ਹਾਂ, Codex ਫੀਡਬੈਕ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ. ਜਦੋਂ CI ਫੇਲ ਹੁੰਦੀ ਸੀ, ਅਸੀਂ ਲੌਗ ਆਉਟਪੁੱਟ ਨੂੰ ਪ੍ਰੌੰਪਟ ਵਿੱਚ ਪੇਸਟ ਕਰਕੇ Codex ਤੋਂ ਹੱਲ ਸੁਝਾਉਣ ਲਈ ਕਹਿ ਸਕਦੇ ਸੀ.
4. ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸਮਾਂਤਰ, ਆਸਾਨੀ ਨਾਲ ਛੱਡੀ ਜਾ ਸਕਣ ਵਾਲੀ ਐਗਜ਼ਿਕਿਊਸ਼ਨ: ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਉਹਨਾਂ ਸੈਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਦੀ ਸੀਮਾ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਣਗੇ ਜੋ ਉਹ ਇੱਕੋ ਸਮੇਂ ਚਲਾ ਸਕਦੇ ਹਨ. ਕਈ ਵਿਚਾਰਾਂ ਨੂੰ ਸਮਾਂਤਰ ਵਿੱਚ ਪਰਖਣਾ ਅਤੇ ਕੋਡ ਨੂੰ ਅਸਥਾਈ ਸਮਝਣਾ ਬਹੁਤ ਹੀ ਸੰਭਵ ਹੈ.
5. ਨਵਾਂ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦੇਣਾ: ਡਿਜ਼ਾਇਨ ਚਰਚਾਵਾਂ ਵਿੱਚ, ਅਸੀਂ Codex ਨੂੰ ਸੰਭਾਵੀ ਨਾਕਾਮੀ ਬਿੰਦੂ ਖੋਜਣ ਅਤੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਦੇ ਨਵੇਂ ਤਰੀਕੇ ਲੱਭਣ ਲਈ ਇੱਕ ਜਨਰੇਟਿਵ ਟੂਲ ਵਜੋਂ ਵਰਤਿਆ. ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਅਸੀਂ ਵੀਡੀਓ ਪਲੇਅਰ ਮੈਮੋਰੀ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਡਿਜ਼ਾਇਨ ਕਰ ਰਹੇ ਸੀ, Codex ਨੇ ਕਈ SDKs ਖੰਗਾਲ ਕੇ ਐਸੇ ਤਰੀਕੇ ਸੁਝਾਏ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣ ਲਈ ਸਾਡੇ ਕੋਲ ਸਮਾਂ ਨਾ ਹੁੰਦਾ. Codex ਦੀ ਖੋਜ ਤੋਂ ਮਿਲੇ ਦਰਸ਼ਨਾਂ ਨੇ ਅੰਤਿਮ ਐਪ ਵਿੱਚ ਮੈਮੋਰੀ ਫੁੱਟਪ੍ਰਿੰਟ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਵਿੱਚ ਅਮੋਲਕ ਭੂਮਿਕਾ ਨਿਭਾਈ.
6. ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਕੰਮ ਨੂੰ ਸੰਭਵ ਬਣਾਉਣਾ: ਅਮਲ ਵਿੱਚ, ਅਸੀਂ ਕੋਡ ਖੁਦ ਲਿਖਣ ਦੀ ਬਜਾਏ ਇਸਦੀ ਸਮੀਖਿਆ ਕਰਨ ਅਤੇ ਦਿਸ਼ਾ ਦੇਣ 'ਤੇ ਵੱਧ ਸਮਾਂ ਲਗਾਇਆ. ਇਹ ਕਹਿਣ ਨਾਲ, Codex ਕੋਡ ਰਿਵਿਊ ਵਿੱਚ ਵੀ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਅਕਸਰ ਮਰਜ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਬੱਗ ਫੜ ਲੈਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਭਰੋਸੇਯੋਗਤਾ ਸੁਧਰਦੀ ਹੈ.

ਜਦੋਂ ਅਸੀਂ ਇਹ ਗੁਣ ਮੰਨ ਲਏ, ਸਾਡਾ ਕੰਮ ਕਰਨ ਦਾ ਮਾਡਲ ਹੋਰ ਸਿੱਧਾ ਹੋ ਗਿਆ. ਅਸੀਂ Codex 'ਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝੇ ਗਏ ਪੈਟਰਨਾਂ ਅਤੇ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਭਾਰੀ ਕੰਮ ਕਰਨ ਲਈ ਭਰੋਸਾ ਕੀਤਾ, ਜਦੋਂ ਕਿ ਸਾਡੀ ਟੀਮ ਨੇ ਆਰਕੀਟੈਕਚਰ, ਉਪਭੋਗਤਾ ਅਨੁਭਵ, ਸਿਸਟਮ-ਪੱਧਰੀ ਬਦਲਾਵਾਂ ਅਤੇ ਅੰਤਿਮ ਗੁਣਵੱਤਾ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ.

ਸਭ ਤੋਂ ਵਧੀਆ ਨਵੀਂ ਸੀਨੀਅਰ ਭਰਤੀ ਕੋਲ ਵੀ ਤੁਰੰਤ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਸਮਝੌਤਿਆਂ ਬਾਰੇ ਸਹੀ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨਹੀਂ ਹੁੰਦਾ. Codex ਦਾ ਲਾਭ ਲੈਣ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਇਸਦਾ ਕੰਮ ਮਜ਼ਬੂਤ ਅਤੇ ਸੰਭਾਲਯੋਗ ਹੋਵੇ, ਇਹ ਬਹੁਤ ਜ਼ਰੂਰੀ ਸੀ ਕਿ ਐਪ ਦੇ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨ ਅਤੇ ਮੁੱਖ ਸਮਝੌਤਿਆਂ ਦੀ ਦੇਖਭਾਲ ਅਸੀਂ ਖੁਦ ਕਰੀਏ. ਇਨ੍ਹਾਂ ਵਿੱਚ ਐਪ ਦੀ ਆਰਕੀਟੈਕਚਰ, ਮੋਡੀਊਲਰਾਈਜ਼ੇਸ਼ਨ, ਡਿਪੈਂਡੈਂਸੀ ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਦੀ ਰਚਨਾ ਸ਼ਾਮਲ ਸੀ; ਅਸੀਂ ਆਥੈਂਟੀਕੇਸ਼ਨ ਅਤੇ ਬੇਸ ਨੈੱਟਵਰਕਿੰਗ ਫਲੋ ਵੀ ਲਾਗੂ ਕੀਤੇ.

ਇਸ ਬੁਨਿਆਦ ਤੋਂ ਅੱਗੇ, ਅਸੀਂ ਕੁਝ ਨਮੂਨਾਤਮਕ ਫੀਚਰ ਪੂਰੇ ਤਰੀਕੇ ਨਾਲ ਲਿਖੇ. ਅਸੀਂ ਉਹ ਨਿਯਮ ਵਰਤੇ ਜਿਨ੍ਹਾਂ ਦੀ ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਕਿ ਪੂਰਾ ਕੋਡਬੇਸ ਪਾਲਣਾ ਕਰੇ ਅਤੇ ਨਾਲ-ਨਾਲ ਪ੍ਰੋਜੈਕਟ-ਪੱਧਰੀ ਪੈਟਰਨ ਦਸਤਾਵੇਜ਼ ਕੀਤੇ. Codex ਨੂੰ ਨਮੂਨਾਤਮਕ ਫੀਚਰ ਵਿਖਾ ਕੇ, ਇਹ ਸਾਡੇ ਮਿਆਰਾਂ ਦੇ ਅੰਦਰ ਹੋਰ ਖੁਦਮੁਖਤਿਆਰ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰ ਸਕਿਆ. ਉਸ ਪ੍ਰੋਜੈਕਟ ਲਈ ਜਿਸਦਾ ਅਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦੇ ਹਾਂ ਕਿ 85% Codex ਵੱਲੋਂ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਧਿਆਨ ਨਾਲ ਯੋਜਿਤ ਬੁਨਿਆਦ ਨੇ ਮਹਿੰਗੀ ਵਾਪਸੀ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਤੋਂ ਬਚਾਇਆ. ਇਹ ਸਾਡੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਫੈਸਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ.

ਵਿਚਾਰ ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ “ਕੁਝ ਐਸਾ ਬਣਾਇਆ ਜਾਵੇ ਜੋ ਚੱਲ ਪਏ”, ਬਲਕਿ “ਕੁਝ ਐਸਾ ਬਣਾਇਆ ਜਾਵੇ ਜੋ ਸਮਝੇ ਕਿ ਅਸੀਂ ਚੀਜ਼ਾਂ ਕਿਵੇਂ ਚੱਲਦੀਆਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ.” ਕੋਡ ਲਿਖਣ ਦੇ ਕਈ “ਸਹੀ” ਤਰੀਕੇ ਹੁੰਦੇ ਹਨ. ਸਾਨੂੰ Codex ਨੂੰ ਬਿਲਕੁਲ ਠੀਕ ਕੀ ਕਰਨਾ ਹੈ ਇਹ ਦੱਸਣ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ; ਸਾਨੂੰ Codex ਨੂੰ ਇਹ ਵਿਖਾਉਣ ਦੀ ਲੋੜ ਸੀ ਕਿ ਸਾਡੀ ਟੀਮ ਵਿੱਚ “ਸਹੀ” ਕੀ ਹੈ. ਇੱਕ ਵਾਰ ਅਸੀਂ ਆਪਣਾ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਅਤੇ ਬਣਾਉਣ ਦਾ ਮਨਪਸੰਦ ਢੰਗ ਸਥਾਪਿਤ ਕਰ ਲਿਆ, ਤਾਂ Codex ਤਿਆਰ ਸੀ.

ਇਹ ਵੇਖਣ ਲਈ ਕਿ ਕੀ ਹੋਵੇਗਾ, ਅਸੀਂ ਇਹ ਪ੍ਰੌੰਪਟ ਦੇ ਕੇ ਵੇਖਿਆ ਵੀ: “iOS ਕੋਡ ਦੇ ਆਧਾਰ 'ਤੇ Sora Android ਐਪ ਬਣਾਓ. ਸ਼ੁਰੂ ਕਰੋ,” ਪਰ ਅਸੀਂ ਉਹ ਰਾਹ ਜਲਦੀ ਛੱਡ ਦਿੱਤਾ. ਹਾਲਾਂਕਿ Codex ਨੇ ਜੋ ਬਣਾਇਆ ਉਹ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਚੱਲਦਾ ਸੀ, ਪਰ ਪ੍ਰੋਡਕਟ ਅਨੁਭਵ ਕਮਜ਼ੋਰ ਸੀ. ਅਤੇ ਐਂਡਪੌਇੰਟ, ਡਾਟਾ ਅਤੇ ਯੂਜ਼ਰ ਫਲੋ ਦੀ ਸਪੱਸ਼ਟ ਸਮਝ ਤੋਂ ਬਿਨਾਂ, Codex ਦਾ ਇਕੋ ਵਾਰ ਦਾ ਕੋਡ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਸੀ. ਏਜੰਟ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਦਿਆਂ ਵੀ, ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ ਦੇ ਕੋਡ ਨੂੰ ਮਰਜ ਕਰਨਾ ਖਤਰਨਾਕ ਹੁੰਦਾ ਹੈ.

ਅਸੀਂ ਅਨੁਮਾਨ ਲਗਾਇਆ ਕਿ Codex ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਿਖੀਆਂ ਉਦਾਹਰਨਾਂ ਵਾਲੇ ਸੈਂਡਬਾਕਸ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਵੇਗਾ; ਅਤੇ ਅਸੀਂ ਸਹੀ ਸਾਬਤ ਹੋਏ. Codex ਨੂੰ ਲਗਭਗ ਬਿਨਾਂ ਸੰਦਰਭ ਦੇ “ਇਹ ਸੈਟਿੰਗਜ਼ ਸਕ੍ਰੀਨ ਬਣਾਓ” ਕਹਿਣਾ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਸੀ. Codex ਨੂੰ “ਇਹ ਸੈਟਿੰਗਜ਼ ਸਕ੍ਰੀਨ ਉਸੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਪੈਟਰਨਾਂ ਨਾਲ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਹਾਲ ਹੀ ਵਿੱਚ ਇਸ ਹੋਰ ਸਕ੍ਰੀਨ ਵਿੱਚ ਵੇਖੀਆਂ ਹਨ” ਕਹਿਣਾ ਕਾਫ਼ੀ ਵਧੀਆ ਰਿਹਾ. ਮਨੁੱਖਾਂ ਨੇ ਸੰਰਚਨਾਤਮਕ ਫੈਸਲੇ ਕੀਤੇ ਅਤੇ ਅਟੱਲ ਨਿਯਮ ਨਿਰਧਾਰਤ ਕੀਤੇ; Codex ਨੇ ਫਿਰ ਉਸ ਸੰਰਚਨਾ ਦੇ ਅੰਦਰ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਕੋਡ ਭਰ ਦਿੱਤਾ.

Codex ਦੀ ਸੰਭਾਵਨਾ ਦਾ ਪੂਰਾ ਲਾਭ ਲੈਣ ਵੱਲ ਸਾਡਾ ਅਗਲਾ ਕਦਮ ਇਹ ਸਮਝਣਾ ਸੀ ਕਿ Codex ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਕਿਵੇਂ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਇਆ ਜਾਵੇ, ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਦੇ. ਹਾਲ ਹੀ ਵਿੱਚ, ਇਹ ਸਮਾਂ 24 ਘੰਟਿਆਂ ਤੋਂ ਵੱਧ⁠ ਵੀ ਰਿਹਾ ਹੈ.

Codex ਵਰਤਣ ਦੇ ਸ਼ੁਰੂਆਤੀ ਦਿਨਾਂ ਵਿੱਚ, ਅਸੀਂ ਅਕਸਰ ਇਹੋ ਜਿਹੇ ਪ੍ਰੌੰਪਟ ਦੇ ਦਿੰਦੇ ਸੀ: “ਇਹ ਫੀਚਰ ਹੈ. ਇਹ ਕੁਝ ਫਾਈਲਾਂ ਹਨ. ਕਿਰਪਾ ਕਰਕੇ ਇਸਨੂੰ ਬਣਾਓ.” ਕਦੇ-ਕਦੇ ਇਹ ਕੰਮ ਕਰ ਜਾਂਦਾ ਸੀ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਵਾਰ ਐਸਾ ਕੋਡ ਮਿਲਦਾ ਸੀ ਜੋ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਕੰਪਾਇਲ ਤਾਂ ਹੋ ਜਾਂਦਾ ਸੀ, ਪਰ ਸਾਡੀ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਲਕਸ਼ਾਂ ਤੋਂ ਹਟ ਜਾਂਦਾ ਸੀ.

ਇਸ ਲਈ ਅਸੀਂ ਵਰਕਫਲੋ ਬਦਲਿਆ. ਕਿਸੇ ਵੀ ਗੈਰ-ਸਧਾਰਣ ਬਦਲਾਅ ਲਈ, ਅਸੀਂ ਪਹਿਲਾਂ Codex ਨੂੰ ਪੁੱਛਦੇ ਸੀ ਕਿ ਸਿਸਟਮ ਅਤੇ ਕੋਡ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਹ ਸਮਝਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰੇ. ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇਸਨੂੰ ਸੰਬੰਧਤ ਫਾਈਲਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਪੜ੍ਹ ਕੇ ਇਹ ਸਾਰ ਦੇਣ ਲਈ ਕਹਿੰਦੇ ਸੀ ਕਿ ਉਹ ਫੀਚਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ; ਉਦਾਹਰਨ ਲਈ, ਡਾਟਾ API ਤੋਂ ਰਿਪੋਜ਼ਟਰੀ ਲੇਅਰ, view model ਅਤੇ ਫਿਰ UI ਤੱਕ ਕਿਵੇਂ ਵਗਦਾ ਹੈ. ਫਿਰ ਅਸੀਂ ਇਸਦੀ ਸਮਝ ਨੂੰ ਠੀਕ ਜਾਂ ਹੋਰ ਸੁਧਾਰਦੇ ਸੀ. ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਦੱਸਦੇ ਸੀ ਕਿ ਕੋਈ ਖਾਸ abstraction ਅਸਲ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਲੇਅਰ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਕੋਈ ਦਿੱਤੀ ਕਲਾਸ ਸਿਰਫ਼ ਆਫਲਾਈਨ ਮੋਡ ਲਈ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇਸਨੂੰ ਵਧਾਇਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ.

ਜਿਵੇਂ ਤੁਸੀਂ ਕਿਸੇ ਨਵੇਂ ਅਤੇ ਬਹੁਤ ਸਮਰੱਥ ਸਾਥੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋ, ਅਸੀਂ Codex ਨਾਲ ਮਿਲ ਕੇ ਇੱਕ ਮਜ਼ਬੂਤ implementation plan ਬਣਾਈ. ਉਹ ਯੋਜਨਾ ਅਕਸਰ ਇੱਕ ਛੋਟੇ ਡਿਜ਼ਾਇਨ ਦਸਤਾਵੇਜ਼ ਵਾਂਗ ਲੱਗਦੀ ਸੀ, ਜਿਸ ਵਿੱਚ ਦੱਸਿਆ ਜਾਂਦਾ ਸੀ ਕਿ ਕਿਹੜੀਆਂ ਫਾਈਲਾਂ ਬਦਲਣੀਆਂ ਹਨ, ਕਿਹੜੀਆਂ ਨਵੀਆਂ ਸਥਿਤੀਆਂ ਲਿਆਂਦੀਆਂ ਜਾਣੀਆਂ ਹਨ ਅਤੇ ਲੌਜਿਕ ਕਿਵੇਂ ਵਗੇਗੀ. ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਅਸੀਂ Codex ਨੂੰ ਕਦਮ-ਦਰ-ਕਦਮ ਯੋਜਨਾ ਲਾਗੂ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਸੀ. ਇੱਕ ਮਦਦਗਾਰ ਸੁਝਾਅ: ਬਹੁਤ ਲੰਬੇ ਕੰਮਾਂ ਲਈ, ਜਿੱਥੇ ਅਸੀਂ ਆਪਣੇ context window ਦੀ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੇ ਸੀ, ਅਸੀਂ Codex ਨੂੰ ਆਪਣੀ ਯੋਜਨਾ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਸੇਵ ਕਰਨ ਲਈ ਕਹਿੰਦੇ ਸੀ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਵੱਖ-ਵੱਖ ਇੰਸਟੈਂਸਾਂ ਵਿੱਚ ਇੱਕੋ ਦਿਸ਼ਾ ਲਾਗੂ ਕਰ ਸਕਦੇ ਸੀ.

ਇਹ ਵਾਧੂ ਯੋਜਨਾਬੰਦੀ ਲੂਪ ਸਮੇਂ ਦੇ ਕਾਬਲ ਸਾਬਤ ਹੋਇਆ. ਇਸ ਨਾਲ ਅਸੀਂ Codex ਨੂੰ ਲੰਬੇ ਅੰਤਰਾਲਾਂ ਲਈ “ਬਿਨਾਂ ਨਿਗਰਾਨੀ” ਦੇ ਕੰਮ ਕਰਨ ਦੇ ਸਕੇ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਇਸ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਦਾ ਪਤਾ ਹੁੰਦਾ ਸੀ. ਇਸ ਨਾਲ ਕੋਡ ਰਿਵਿਊ ਆਸਾਨ ਹੋ ਗਿਆ, ਕਿਉਂਕਿ ਅਸੀਂ ਸੰਦਰਭ ਤੋਂ ਬਿਨਾਂ diff ਪੜ੍ਹਨ ਦੀ ਬਜਾਏ implementation ਨੂੰ ਆਪਣੀ ਯੋਜਨਾ ਦੇ ਖਿਲਾਫ਼ ਜਾਂਚ ਸਕਦੇ ਸੀ. ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਸੀ, ਅਸੀਂ ਪਹਿਲਾਂ ਯੋਜਨਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਕੋਡ ਡੀਬੱਗ ਕਰ ਸਕਦੇ ਸੀ.

ਇਹ ਗਤੀਵਿਧੀ ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਸੀ ਜਿਵੇਂ ਇੱਕ ਵਧੀਆ ਡਿਜ਼ਾਇਨ ਦਸਤਾਵੇਜ਼ ਕਿਸੇ tech lead ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ ਭਰੋਸਾ ਦਿੰਦਾ ਹੈ. ਅਸੀਂ ਸਿਰਫ਼ ਕੋਡ ਨਹੀਂ ਬਣਾ ਰਹੇ ਸੀ: ਅਸੀਂ ਐਸਾ ਕੋਡ ਤਿਆਰ ਕਰ ਰਹੇ ਸੀ ਜੋ ਸਾਂਝੇ ਰੋਡਮੈਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਸੀ.

ਪ੍ਰੋਜੈਕਟ ਦੇ ਚਰਮ 'ਤੇ, ਅਸੀਂ ਅਕਸਰ ਕਈ Codex ਸੈਸ਼ਨ ਇੱਕੋ ਸਮੇਂ ਚਲਾ ਰਹੇ ਹੁੰਦੇ ਸੀ. ਇੱਕ ਪਲੇਬੈਕ 'ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਹੁੰਦਾ, ਦੂਜਾ ਖੋਜ 'ਤੇ, ਦੂਜਾ error handling 'ਤੇ, ਅਤੇ ਕਈ ਵਾਰ ਹੋਰ ਕੋਈ ਟੈਸਟਾਂ ਜਾਂ ਰੀਫੈਕਟਰਾਂ 'ਤੇ. ਇਹ ਕਿਸੇ ਟੂਲ ਦੀ ਵਰਤੋਂ ਵਰਗਾ ਘੱਟ ਅਤੇ ਟੀਮ ਸੰਭਾਲਣ ਵਰਗਾ ਵੱਧ ਲੱਗਦਾ ਸੀ.

ਹਰ ਸੈਸ਼ਨ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਤਰੱਕੀ ਬਾਰੇ ਸਾਨੂੰ ਜਾਣਕਾਰੀ ਦਿੰਦਾ ਸੀ. ਇੱਕ ਕਹਿੰਦਾ, “ਮੈਂ ਇਸ ਮੋਡੀਊਲ ਦੀ ਯੋਜਨਾ ਤਿਆਰ ਕਰ ਲਈ ਹੈ; ਇਹ ਮੇਰਾ ਸੁਝਾਅ ਹੈ,” ਜਦੋਂ ਕਿ ਦੂਜਾ ਨਵੇਂ ਫੀਚਰ ਲਈ ਵੱਡਾ diff ਪੇਸ਼ ਕਰਦਾ. ਹਰ ਇੱਕ ਨੂੰ ਧਿਆਨ, ਫੀਡਬੈਕ ਅਤੇ ਸਮੀਖਿਆ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ. ਇਹ ਅਚੰਭਿਤ ਤੌਰ 'ਤੇ ਐਸਾ ਸੀ ਜਿਵੇਂ ਤੁਸੀਂ ਕਈ ਨਵੇਂ ਇੰਜੀਨੀਅਰਾਂ ਵਾਲੇ tech lead ਹੋਵੋ, ਜੋ ਸਭ ਤਰੱਕੀ ਕਰ ਰਹੇ ਹੋਣ ਅਤੇ ਸਭ ਨੂੰ ਮਾਰਗਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੋਵੇ.

ਨਤੀਜਾ ਇੱਕ ਸਹਿਯੋਗੀ ਪ੍ਰਵਾਹ ਸੀ. Codex ਦੀ ਮੂਲ ਕੋਡਿੰਗ ਸਮਰੱਥਾ ਨੇ ਸਾਨੂੰ ਬਹੁਤ ਸਾਰੀ ਹੱਥੋਂ ਟਾਈਪਿੰਗ ਤੋਂ ਆਜ਼ਾਦ ਕੀਤਾ. ਸਾਡੇ ਕੋਲ ਆਰਕੀਟੈਕਚਰ ਬਾਰੇ ਸੋਚਣ, ਪੁੱਲ ਰਿਕਵੈਸਟ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹਣ ਅਤੇ ਐਪ ਟੈਸਟ ਕਰਨ ਲਈ ਵੱਧ ਸਮਾਂ ਸੀ.

ਇਸਦੇ ਨਾਲ ਹੀ, ਉਸ ਵਾਧੂ ਰਫ਼ਤਾਰ ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਸਾਡੀ ਰਿਵਿਊ ਕਿਊ ਵਿੱਚ ਹਮੇਸ਼ਾਂ ਕੁਝ ਨਾ ਕੁਝ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਸੀ. Codex context switching ਨਾਲ ਨਹੀਂ ਰੁਕਦਾ ਸੀ, ਪਰ ਅਸੀਂ ਰੁਕਦੇ ਸੀ. ਡਿਵੈਲਪਮੈਂਟ ਵਿੱਚ ਸਾਡਾ bottleneck ਕੋਡ ਲਿਖਣ ਤੋਂ ਹਟ ਕੇ ਫੈਸਲੇ ਲੈਣ, ਫੀਡਬੈਕ ਦੇਣ ਅਤੇ ਬਦਲਾਵਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਵੱਲ ਚਲਾ ਗਿਆ.

ਇੱਥੇ Brooks ਦੀ ਸਮਝ ਇੱਕ ਨਵੇਂ ਢੰਗ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ. ਤੁਸੀਂ ਸਿਰਫ਼ Codex ਸੈਸ਼ਨ ਵਧਾ ਕੇ ਰੇਖੀ ਗਤੀ-ਵਾਧੇ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਜਿਵੇਂ ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਇੰਜੀਨੀਅਰ ਜੋੜਦੇ ਜਾਣ ਨਾਲ ਸਮਾਂ-ਸਾਰਣੀ ਦੇ ਰੇਖੀ ਤੌਰ 'ਤੇ ਘਟਣ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰ ਸਕਦੇ. ਹਰ ਵਾਧੂ “ਹੱਥਾਂ ਦੀ ਜੋੜੀ,” ਭਾਵੇਂ ਵਰਚੁਅਲ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ, ਸਮਨਵਯ ਦਾ ਵਾਧੂ ਬੋਝ ਲਿਆਉਂਦੀ ਹੈ. ਅਸੀਂ ਸਿਰਫ਼ ਤੇਜ਼ ਇਕੱਲੇ ਖਿਡਾਰੀ ਰਹਿਣ ਦੀ ਬਜਾਏ ਇੱਕ ਆਰਕੈਸਟਰਾ ਦੇ ਕੰਡਕਟਰ ਬਣ ਗਏ ਸੀ.

ਅਸੀਂ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਵੱਡੇ ਸਹਾਰੇ ਨਾਲ ਕੀਤੀ: Sora ਪਹਿਲਾਂ ਹੀ iOS 'ਤੇ ਭੇਜਿਆ ਜਾ ਚੁੱਕਿਆ ਸੀ. ਅਸੀਂ Codex ਨੂੰ ਅਕਸਰ iOS ਅਤੇ backend ਕੋਡਬੇਸ ਵੱਲ ਦਿਖਾਉਂਦੇ ਰਹੇ ਤਾਂ ਜੋ ਇਹ ਮੁੱਖ ਲੋੜਾਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਨੂੰ ਸਮਝ ਸਕੇ. ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਦੌਰਾਨ ਅਸੀਂ ਮਜ਼ਾਕ ਕਰਦੇ ਰਹੇ ਕਿ ਅਸੀਂ cross-platform framework ਦਾ ਵਿਚਾਰ ਮੁੜ ਤੋਂ ਘੜ ਲਿਆ ਹੈ. React Native ਜਾਂ Flutter ਭੁੱਲ ਜਾਓ; cross-platform ਦਾ ਭਵਿੱਖ ਸਿਰਫ਼ Codex ਹੈ.

ਇਸ ਮਜ਼ਾਕ ਦੇ ਹੇਠਾਂ ਦੋ ਸਿਧਾਂਤ ਹਨ:.

1. ਲੌਜਿਕ ਲਿਜਾਣਯੋਗ ਹੁੰਦੀ ਹੈ. ਚਾਹੇ ਕੋਡ Swift ਵਿੱਚ ਲਿਖਿਆ ਹੋਵੇ ਜਾਂ Kotlin ਵਿੱਚ, ਅਧਾਰਭੂਤ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ – ਡਾਟਾ ਮਾਡਲ, ਨੈੱਟਵਰਕ ਕਾਲਾਂ, ਵੈਲੀਡੇਸ਼ਨ ਨਿਯਮ, ਕਾਰੋਬਾਰੀ ਲੌਜਿਕ – ਇਕੋ ਹੀ ਰਹਿੰਦੀ ਹੈ. Codex Swift implementation ਪੜ੍ਹ ਕੇ Kotlin ਵਿੱਚ ਉਸਦਾ ਸਮਾਨ ਰੂਪ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਚੰਗਾ ਹੈ ਜੋ semantics ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੇ.
2. ਠੋਸ ਉਦਾਹਰਨਾਂ ਤਾਕਤਵਰ ਸੰਦਰਭ ਦਿੰਦੀਆਂ ਹਨ. ਇੱਕ ਨਵਾਂ Codex ਸੈਸ਼ਨ ਜੋ ਦੇਖ ਸਕਦਾ ਹੈ ਕਿ “iOS 'ਤੇ ਇਹ ਬਿਲਕੁਲ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ” ਅਤੇ “Android ਦੀ ਆਰਕੀਟੈਕਚਰ ਇਹ ਹੈ,” ਉਹ ਉਸ ਸੈਸ਼ਨ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੇ ਵਰਣਨਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ.

ਇਹ ਸਿਧਾਂਤ ਅਮਲ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹੋਏ, ਅਸੀਂ iOS, backend ਅਤੇ Android ਰਿਪੋਜ਼ਟਰੀਆਂ ਨੂੰ ਇੱਕੋ ਵਾਤਾਵਰਣ ਵਿੱਚ ਉਪਲਬਧ ਕਰਾਇਆ. ਅਸੀਂ Codex ਨੂੰ ਇਹੋ ਜਿਹੇ ਪ੍ਰੌੰਪਟ ਦਿੱਤੇ:

“iOS ਕੋਡ ਵਿੱਚ ਇਹ ਮਾਡਲ ਅਤੇ ਐਂਡਪੌਇੰਟ ਪੜ੍ਹੋ ਅਤੇ ਫਿਰ ਸਾਡੇ ਮੌਜੂਦਾ API client ਅਤੇ ਮਾਡਲ ਕਲਾਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਿਆਂ Android 'ਤੇ ਸਮਾਨ ਵਿਵਹਾਰ ਲਾਗੂ ਕਰਨ ਲਈ ਇੱਕ ਯੋਜਨਾ ਸੁਝਾਓ.”

ਇੱਕ ਛੋਟੀ ਪਰ ਲਾਭਦਾਇਕ ਤਰਕੀਬ ਇਹ ਸੀ ਕਿ ~/.codex/AGENTS.md ਵਿੱਚ ਇਹ ਵਿਸਥਾਰ ਨਾਲ ਦਰਜ ਕੀਤਾ ਜਾਵੇ ਕਿ ਲੋਕਲ ਰਿਪੋਜ਼ ਕਿੱਥੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਕੀ ਹੈ. ਇਸ ਨਾਲ Codex ਲਈ ਸੰਬੰਧਤ ਕੋਡ ਲੱਭਣਾ ਅਤੇ ਉਸ ਵਿੱਚ ਨੇਵੀਗੇਟ ਕਰਨਾ ਆਸਾਨ ਹੋ ਗਿਆ.

ਅਸੀਂ ਪ੍ਰਭਾਵੀ ਤੌਰ 'ਤੇ shared abstraction ਦੀ ਬਜਾਏ translation ਰਾਹੀਂ cross-platform development ਕਰ ਰਹੇ ਸੀ. ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ translation Codex ਸੰਭਾਲ ਰਿਹਾ ਸੀ, ਅਸੀਂ implementation ਦੀ ਲਾਗਤ ਨੂੰ ਦੁੱਗਣਾ ਹੋਣ ਤੋਂ ਬਚਾ ਲਿਆ.

ਵਿਸਤ੍ਰਿਤ ਸਬਕ ਇਹ ਹੈ ਕਿ Codex ਲਈ ਸੰਦਰਭ ਹੀ ਸਭ ਕੁਝ ਹੈ. Codex ਨੇ ਆਪਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਤਦੋਂ ਕੀਤਾ ਜਦੋਂ ਇਸਨੂੰ ਇਹ ਸਮਝ ਸੀ ਕਿ ਫੀਚਰ iOS ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਇਹ ਵੀ ਕਿ ਸਾਡੀ Android ਐਪ ਦੀ ਬਣਤਰ ਕੀ ਹੈ. ਜਦੋਂ Codex ਕੋਲ ਇਹ ਸੰਦਰਭ ਨਹੀਂ ਹੁੰਦਾ ਸੀ, ਤਾਂ ਇਹ “ਸਹਿਯੋਗ ਕਰਨ ਤੋਂ ਇਨਕਾਰ” ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਸੀ; ਇਹ ਸਿਰਫ਼ ਅਨੁਮਾਨ ਲਾ ਰਿਹਾ ਹੁੰਦਾ ਸੀ. ਜਿੰਨਾ ਵੱਧ ਅਸੀਂ ਇਸਨੂੰ ਨਵੇਂ ਸਾਥੀ ਵਾਂਗ ਲਿਆ ਅਤੇ ਇਸਨੂੰ ਸਹੀ ਇਨਪੁਟ ਦੇਣ ਵਿੱਚ ਨਿਵੇਸ਼ ਕੀਤਾ, ਉੱਨਾ ਹੀ ਇਹ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਗਿਆ.

ਸਾਡੇ ਚਾਰ ਹਫ਼ਤਿਆਂ ਦੇ sprint ਦੇ ਅੰਤ ਤੱਕ, Codex ਦੀ ਵਰਤੋਂ ਕਿਸੇ ਪ੍ਰਯੋਗ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣ ਦੀ ਬਜਾਏ ਸਾਡਾ ਡਿਫੌਲਟ development loop ਬਣ ਗਈ. ਅਸੀਂ ਇਸਨੂੰ ਮੌਜੂਦਾ ਕੋਡ ਸਮਝਣ, ਬਦਲਾਵਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਅਤੇ ਫੀਚਰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਤਿਆ. ਅਸੀਂ ਇਸਦੇ ਆਉਟਪੁੱਟ ਦੀ ਸਮੀਖਿਆ ਉਸੇ ਤਰ੍ਹਾਂ ਕੀਤੀ ਜਿਵੇਂ ਅਸੀਂ ਕਿਸੇ ਸਾਥੀ ਦੀ ਕਰਦੇ. ਇਹ ਸਿਰਫ਼ ਸੌਫਟਵੇਅਰ ਭੇਜਣ ਦਾ ਸਾਡਾ ਤਰੀਕਾ ਬਣ ਗਿਆ ਸੀ.

ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ AI-assisted development ਕੜਾਈ ਦੀ ਲੋੜ ਘਟਾਉਂਦੀ ਨਹੀਂ; ਇਹ ਇਸਨੂੰ ਵਧਾਉਂਦੀ ਹੈ. Codex ਜਿੰਨਾ ਵੀ ਸਮਰੱਥ ਹੋਵੇ, ਇਸਦਾ ਉਦੇਸ਼ ਹੁਣੇ A ਤੋਂ B ਤੱਕ ਪਹੁੰਚਣਾ ਹੁੰਦਾ ਹੈ. ਇਸ ਲਈ AI-assisted coding ਮਨੁੱਖਾਂ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੀ. ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਸਿਸਟਮਾਂ ਦੀਆਂ ਅਸਲੀ ਦੁਨੀਆ ਵਾਲੀਆਂ ਪਾਬੰਦੀਆਂ ਨੂੰ ਸਮਝ ਅਤੇ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਨ, ਸੌਫਟਵੇਅਰ ਦੀ ਵਧੀਆ ਆਰਕੀਟੈਕਚਰ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਭਵਿੱਖ ਦੀ development ਅਤੇ ਪ੍ਰੋਡਕਟ ਯੋਜਨਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਬਣਾ ਸਕਦੇ ਹਨ. ਕੱਲ੍ਹ ਦੇ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਦੀਆਂ ਮਹਾਸਮਰੱਥਾਵਾਂ ਗਹਿਰੀ ਸਿਸਟਮ ਸਮਝ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਤੱਕ AI ਨਾਲ ਸਹਿਯੋਗੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੋਣਗੀਆਂ.

ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਹਿੱਸੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਪ੍ਰੋਡਕਟ ਬਣਾਉਣਾ, ਸਕੇਲ ਕਰਨ ਯੋਗ ਸਿਸਟਮ ਡਿਜ਼ਾਇਨ ਕਰਨਾ, ਜਟਿਲ ਐਲਗੋਰਿਦਮ ਲਿਖਣਾ, ਅਤੇ ਡਾਟਾ, ਪੈਟਰਨਾਂ ਅਤੇ ਕੋਡ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨਾ ਹਨ. ਹਾਲਾਂਕਿ, ਪਿਛਲੇ ਅਤੇ ਮੌਜੂਦਾ ਸਮੇਂ ਦੀ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀ ਹਕੀਕਤ ਅਕਸਰ ਹੋਰ ਰੋਜ਼ਮਰ੍ਹਾ ਦੀ ਰਹੀ ਹੈ: ਬਟਨ ਸੈਂਟਰ ਕਰਨਾ, ਐਂਡਪੌਇੰਟ ਜੋੜਨਾ, ਅਤੇ boilerplate ਲਿਖਣਾ. ਹੁਣ, Codex ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਸਭ ਤੋਂ ਅਰਥਪੂਰਨ ਹਿੱਸਿਆਂ ਅਤੇ ਸਾਡੇ ਹੁਨਰ ਨਾਲ ਪਿਆਰ ਦੇ ਕਾਰਨਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ.

ਇੱਕ ਵਾਰ Codex ਨੂੰ ਐਸੇ ਸੰਦਰਭ-ਭਰਪੂਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸੈਟ ਕਰ ਦਿੱਤਾ ਜਾਵੇ ਜਿੱਥੇ ਇਹ ਤੁਹਾਡੇ ਲਕਸ਼ ਅਤੇ ਤੁਹਾਡੇ ਬਣਾਉਣ ਦੇ ਢੰਗ ਨੂੰ ਸਮਝਦਾ ਹੋਵੇ, ਕੋਈ ਵੀ ਟੀਮ ਆਪਣੀਆਂ ਸਮਰੱਥਾਵਾਂ ਕਈ ਗੁਣਾ ਵਧਾ ਸਕਦੀ ਹੈ. ਸਾਡਾ ਲਾਂਚ ਰੈਟ੍ਰੋ ਹਰ ਸਥਿਤੀ ਲਈ ਇੱਕੋ ਜਿਹਾ ਨੁਸਖਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਹ ਦਾਅਵਾ ਨਹੀਂ ਕਰ ਰਹੇ ਕਿ ਅਸੀਂ AI-assisted development ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਲਈ ਹੈ. ਪਰ ਅਸੀਂ ਆਸ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡਾ ਤਜਰਬਾ ਤੁਹਾਡੇ ਲਈ Codex ਨੂੰ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨ ਯੋਗ ਬਣਾਉਣ ਦੇ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕੇ ਲੱਭਣਾ ਆਸਾਨ ਕਰੇਗਾ.

ਜਦੋਂ Codex ਸੱਤ ਮਹੀਨੇ ਪਹਿਲਾਂ research preview ਵਿੱਚ ਲਾਂਚ ਹੋਇਆ ਸੀ, ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਬਹੁਤ ਵੱਖਰੀ ਦਿਖਦੀ ਸੀ. Sora ਰਾਹੀਂ, ਸਾਨੂੰ ਇੰਜੀਨੀਅਰਿੰਗ ਦੇ ਅਗਲੇ ਅਧਿਆਇ ਦੀ ਖੋਜ ਕਰਨ ਦਾ ਮੌਕਾ ਮਿਲਿਆ. ਜਿਵੇਂ ਜਿਵੇਂ ਸਾਡੇ ਮਾਡਲ ਅਤੇ harness ਸੁਧਰਦੇ ਜਾਣਗੇ, AI ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦਾ ਹੋਰ ਵੱਧ ਅਟੁੱਟ ਹਿੱਸਾ ਬਣਦਾ ਜਾਵੇਗਾ.

ਤੁਸੀਂ Codex ਦੀ ਆਪਣੀ ਟੀਮ ਨਾਲ ਕੀ ਬਣਾਉਗੇ?