ਹਾਰਨੈੱਸ ਇੰਜੀਨੀਅਰਿੰਗ: agent-first ਦੁਨੀਆ ਵਿੱਚ Codex ਦਾ ਲਾਭ ਲੈਣਾ

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

ਉਤਪਾਦ ਦੇ ਅੰਦਰੂਨੀ ਰੋਜ਼ਾਨਾ ਯੂਜ਼ਰ ਅਤੇ ਬਾਹਰੀ ਅਲਫਾ ਟੈਸਟਰ ਹਨ। ਇਹ ਸ਼ਿਪ ਹੁੰਦਾ ਹੈ, ਡਿਪਲੋਇ ਹੁੰਦਾ ਹੈ, ਟੁੱਟਦਾ ਹੈ, ਅਤੇ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਫਰਕ ਇਹ ਹੈ ਕਿ ਕੋਡ ਦੀ ਹਰ ਲਾਈਨ—ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ, ਟੈਸਟ, CI configuration, ਦਸਤਾਵੇਜ਼ੀਕਰਨ, observability, ਅਤੇ ਅੰਦਰੂਨੀ ਟੂਲਿੰਗ—Codex ਨੇ ਲਿਖੀ ਹੈ। ਸਾਡਾ ਅੰਦਾਜ਼ਾ ਹੈ ਕਿ ਅਸੀਂ ਇਹ ਲਗਭਗ ਉਸ ਸਮੇਂ ਦੇ 1/10 ਵਿੱਚ ਬਣਾਇਆ, ਜਿੰਨਾ ਸਮਾਂ ਹੱਥੋਂ ਕੋਡ ਲਿਖਣ ਵਿੱਚ ਲੱਗਣਾ ਸੀ.

ਇਨਸਾਨ ਦਿਸ਼ਾ ਦਿੰਦੇ ਹਨ। ਏਜੰਟ ਕੰਮ ਕਰਦੇ ਹਨ.

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

ਇਹ ਪੋਸਟ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਅਸੀਂ ਏਜੰਟਾਂ ਦੀ ਟੀਮ ਨਾਲ ਇੱਕ ਬਿਲਕੁਲ ਨਵਾਂ ਉਤਪਾਦ ਬਣਾਕੇ ਕੀ ਸਿੱਖਿਆ—ਕੀ ਟੁੱਟਿਆ, ਕੀ ਇਕੱਠਾ ਹੋ ਕੇ ਵਧਿਆ, ਅਤੇ ਸਾਡੇ ਇਕਲੌਤੇ ਸੱਚਮੁੱਚ ਘੱਟ ਸਰੋਤ ਨੂੰ ਕਿਵੇਂ ਵੱਧ ਤੋਂ ਵੱਧ ਕੀਤਾ ਜਾਵੇ: ਮਨੁੱਖੀ ਸਮਾਂ ਅਤੇ ਧਿਆਨ.

ਇੱਕ ਖਾਲੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਪਹਿਲਾ commit ਅਗਸਤ 2025 ਦੇ ਅਖੀਰ ਵਿੱਚ ਆਇਆ.

ਸ਼ੁਰੂਆਤੀ scaffold—ਰਿਪੋਜ਼ਟਰੀ ਬਣਤਰ, CI configuration, formatting rules, package manager setup, ਅਤੇ application framework—Codex CLI ਨੇ GPT‑5 ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਮੌਜੂਦਾ templates ਦੇ ਇੱਕ ਛੋਟੇ ਸੈੱਟ ਦੀ ਰਹਿਨੁਮਾਈ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਸੀ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਸ਼ੁਰੂਆਤੀ AGENTS.md ਫਾਈਲ, ਜੋ ਏਜੰਟਾਂ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ, ਉਹ ਵੀ Codex ਨੇ ਹੀ ਲਿਖੀ ਸੀ.

ਸਿਸਟਮ ਨੂੰ ਆਧਾਰ ਦੇਣ ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਕੋਈ ਮਨੁੱਖ-ਲਿਖਿਆ ਕੋਡ ਨਹੀਂ ਸੀ। ਸ਼ੁਰੂ ਤੋਂ ਹੀ, ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਏਜੰਟ ਨੇ ਹੀ ਆਕਾਰ ਦਿੱਤਾ.

ਪੰਜ ਮਹੀਨੇ ਬਾਅਦ, ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ, infrastructure, tooling, documentation, ਅਤੇ ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਰ ਯੂਟਿਲਿਟੀਆਂ ਵਿੱਚ ਲਗਭਗ ਦੱਸ ਲੱਖ ਲਾਈਨਾਂ ਦਾ ਕੋਡ ਹੈ। ਇਸ ਅਰਸੇ ਦੌਰਾਨ, ਕੇਵਲ ਤਿੰਨ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਟੀਮ ਦੁਆਰਾ Codex ਨੂੰ ਚਲਾ ਕੇ ਲਗਭਗ 1,500 ਪੁੱਲ ਰਿਕਵੈਸਟ ਖੋਲ੍ਹੀਆਂ ਅਤੇ merge ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਇਸ ਦਾ ਮਤਲਬ ਔਸਤ 3.5 PRs ਪ੍ਰਤੀ ਇੰਜੀਨੀਅਰ ਪ੍ਰਤੀ ਦਿਨ ਦਾ ਥਰੂਪੁੱਟ ਹੈ, ਅਤੇ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਟੀਮ ਦੇ ਹੁਣ ਸੱਤ ਇੰਜੀਨੀਅਰ ਹੋ ਜਾਣ ਨਾਲ ਇਹ ਥਰੂਪੁੱਟ ਵਧਿਆ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਸਿਰਫ਼ output ਲਈ output ਨਹੀਂ ਸੀ: ਇਸ ਉਤਪਾਦ ਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ ਤੇ ਸੈਂਕੜਿਆਂ ਯੂਜ਼ਰਾਂ ਨੇ ਵਰਤਿਆ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਰੋਜ਼ਾਨਾ ਵਰਤਣ ਵਾਲੇ power users ਵੀ ਸ਼ਾਮਲ ਹਨ.

ਪੂਰੀ development ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ, ਇਨਸਾਨਾਂ ਨੇ ਕਦੇ ਵੀ ਸਿੱਧਾ ਕੋਈ ਕੋਡ ਨਹੀਂ ਦਿੱਤਾ। ਇਹ ਟੀਮ ਲਈ ਇੱਕ ਕੇਂਦਰੀ ਫ਼ਲਸਫ਼ਾ ਬਣ ਗਿਆ: ਹੱਥੋਂ ਲਿਖਿਆ ਕੋਈ ਕੋਡ ਨਹੀਂ.

ਇਨਸਾਨੀ ਹੱਥੋਂ ਕੋਡਿੰਗ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਨੇ ਇੱਕ ਵੱਖਰੀ ਕਿਸਮ ਦਾ ਇੰਜੀਨੀਅਰਿੰਗ ਕੰਮ ਲਿਆਂਦਾ, ਜੋ ਸਿਸਟਮਾਂ, scaffolding, ਅਤੇ leverage ਉੱਤੇ ਕੇਂਦ੍ਰਿਤ ਸੀ.

ਸ਼ੁਰੂਆਤੀ ਤਰੱਕੀ ਸਾਡੀ ਉਮੀਦ ਨਾਲੋਂ ਹੌਲੀ ਸੀ, ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਕਿ Codex ਅਸਮਰੱਥ ਸੀ, ਪਰ ਇਸ ਲਈ ਕਿ ਇਨਵਾਇਰਨਮੈਂਟ ਘੱਟ ਨਿਰਧਾਰਿਤ ਸੀ। ਏਜੰਟ ਕੋਲ ਉੱਚ-ਪੱਧਰੀ ਲਕਸ਼ਾਂ ਵੱਲ ਤਰੱਕੀ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ tools, abstractions, ਅਤੇ ਅੰਦਰੂਨੀ ਬਣਤਰ ਦੀ ਘਾਟ ਸੀ। ਸਾਡੀ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਦਾ ਮੁੱਖ ਕੰਮ ਏਜੰਟਾਂ ਨੂੰ ਲਾਭਦਾਇਕ ਕੰਮ ਕਰਨ ਯੋਗ ਬਣਾਉਣਾ ਬਣ ਗਿਆ.

ਅਮਲ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਸੀ depth-first ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨਾ: ਵੱਡੇ ਲਕਸ਼ਾਂ ਨੂੰ ਛੋਟੇ building blocks (design, code, review, test, ਆਦਿ) ਵਿੱਚ ਤੋੜਨਾ, ਏਜੰਟ ਨੂੰ ਉਹ blocks ਬਣਾਉਣ ਲਈ ਪ੍ਰੌੰਪਟ ਕਰਨਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਨਾਲ ਹੋਰ ਜਟਿਲ ਕੰਮ ਖੋਲ੍ਹਣਾ। ਜਦੋਂ ਕੁਝ ਫੇਲ੍ਹ ਹੁੰਦਾ ਸੀ, ਹੱਲ ਲਗਭਗ ਕਦੇ ਵੀ “ਹੋਰ ਜ਼ੋਰ ਲਗਾਓ” ਨਹੀਂ ਹੁੰਦਾ ਸੀ। ਕਿਉਂਕਿ ਤਰੱਕੀ ਦਾ ਇਕੱਲਾ ਰਸਤਾ Codex ਤੋਂ ਕੰਮ ਕਰਵਾਉਣਾ ਸੀ, ਮਨੁੱਖੀ ਇੰਜੀਨੀਅਰ ਹਮੇਸ਼ਾਂ ਕੰਮ ਵਿੱਚ ਦਾਖਲ ਹੋ ਕੇ ਪੁੱਛਦੇ ਸਨ: “ਕਿਹੜੀ ਸਮਰੱਥਾ ਗਾਇਬ ਹੈ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਏਜੰਟ ਲਈ ਪੜ੍ਹਨਯੋਗ ਤੇ ਲਾਗੂ ਕਰਨਯੋਗ ਕਿਵੇਂ ਬਣਾਈਏ?”

ਇਨਸਾਨ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪ੍ਰੌੰਪਟਾਂ ਰਾਹੀਂ ਸਿਸਟਮ ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ: ਇੱਕ ਇੰਜੀਨੀਅਰ ਕੰਮ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਏਜੰਟ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਪੁੱਲ ਰਿਕਵੈਸਟ ਖੋਲ੍ਹਣ ਦਿੰਦਾ ਹੈ। ਇੱਕ PR ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਅਸੀਂ Codex ਨੂੰ ਦੱਸਦੇ ਹਾਂ ਕਿ ਉਹ ਆਪਣੀਆਂ ਤਬਦੀਲੀਆਂ ਦੀ ਸਥਾਨਕ ਤੌਰ ਤੇ ਖੁਦ ਸਮੀਖਿਆ ਕਰੇ, ਸਥਾਨਕ ਅਤੇ cloud ਦੋਹਾਂ ਵਿੱਚ ਹੋਰ ਖ਼ਾਸ ਏਜੰਟ ਸਮੀਖਿਆਵਾਂ ਮੰਗੇ, ਕਿਸੇ ਵੀ ਮਨੁੱਖ ਜਾਂ ਏਜੰਟ ਦੁਆਰਾ ਦਿੱਤੇ ਫੀਡਬੈਕ ਦਾ ਜਵਾਬ ਦੇਵੇ, ਅਤੇ ਲੂਪ ਵਿੱਚ iterate ਕਰਦਾ ਰਹੇ ਜਦ ਤੱਕ ਸਾਰੇ ਏਜੰਟ reviewer ਸੰਤੁਸ਼ਟ ਨਾ ਹੋ ਜਾਣ (ਅਸਲ ਵਿੱਚ ਇਹ Ralph Wiggum Loop⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹੈ)। Codex ਸੰਦਰਭ ਇਕੱਠਾ ਕਰਨ ਲਈ ਸਾਡੇ ਮਿਆਰੀ development tools ਨੂੰ ਸਿੱਧੇ ਵਰਤਦਾ ਹੈ (gh, local scripts, ਅਤੇ ਰਿਪੋਜ਼ਟਰੀ-embedded skills), ਬਿਨਾਂ ਇਸਦੇ ਕਿ ਇਨਸਾਨ CLI ਵਿੱਚ copy-paste ਕਰਨ.

ਇਨਸਾਨ ਪੁੱਲ ਰਿਕਵੈਸਟਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਲਾਜ਼ਮੀ ਨਹੀਂ। ਸਮੇਂ ਦੇ ਨਾਲ, ਅਸੀਂ ਲਗਭਗ ਸਾਰੀ review ਮਿਹਨਤ ਨੂੰ agent-to-agent ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਵੱਲ ਧੱਕਿਆ ਹੈ.

ਜਿਵੇਂ ਜਿਵੇਂ ਕੋਡ ਥਰੂਪੁੱਟ ਵਧਿਆ, ਸਾਡੀ bottleneck ਮਨੁੱਖੀ QA ਸਮਰੱਥਾ ਬਣ ਗਈ। ਕਿਉਂਕਿ ਸਥਿਰ ਪਾਬੰਦੀ ਮਨੁੱਖੀ ਸਮਾਂ ਅਤੇ ਧਿਆਨ ਰਹੀ ਹੈ, ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ UI, logs, ਅਤੇ app metrics ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ Codex ਲਈ ਸਿੱਧੇ ਪੜ੍ਹਨਯੋਗ ਬਣਾਕੇ ਏਜੰਟ ਵਿੱਚ ਹੋਰ ਸਮਰੱਥਾਵਾਂ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਕੰਮ ਕੀਤਾ ਹੈ.

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ app ਨੂੰ ਹਰ git worktree ਮੁਤਾਬਕ bootable ਬਣਾਇਆ, ਤਾਂ ਜੋ Codex ਹਰ ਤਬਦੀਲੀ ਲਈ ਇੱਕ instance launch ਕਰਕੇ ਚਲਾ ਸਕੇ। ਅਸੀਂ Chrome DevTools Protocol ਨੂੰ agent runtime ਵਿੱਚ ਵੀ wire ਕੀਤਾ ਅਤੇ DOM snapshots, screenshots, ਅਤੇ navigation ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ skills ਬਣਾਈਆਂ। ਇਸ ਨਾਲ Codex ਨੂੰ bugs ਦੁਹਰਾਉਣ, fixes validate ਕਰਨ, ਅਤੇ UI ਵਿਹਾਰ ਬਾਰੇ ਸਿੱਧੇ ਤੌਰ ਤੇ ਤਰਕ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਮਿਲੀ.

ਅਸੀਂ observability tooling ਲਈ ਵੀ ਇਹੀ ਕੀਤਾ। Logs, metrics, ਅਤੇ traces ਨੂੰ Codex ਲਈ ਇੱਕ local observability stack ਰਾਹੀਂ ਉਪਲਬਧ ਕਰਾਇਆ ਜਾਂਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ worktree ਲਈ ephemeral ਹੁੰਦੀ ਹੈ। Codex ਉਸ app ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ ਵਰਜਨ ਉੱਤੇ ਕੰਮ ਕਰਦਾ ਹੈ—ਉਸਦੇ logs ਅਤੇ metrics ਸਮੇਤ, ਜੋ ਕੰਮ ਪੂਰਾ ਹੋਣ ਉੱਤੇ ਹਟਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਏਜੰਟ LogQL ਨਾਲ logs ਅਤੇ PromQL ਨਾਲ metrics query ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਸੰਦਰਭ ਦੇ ਉਪਲਬਧ ਹੋਣ ਨਾਲ, “ensure service startup completes in under 800ms” ਜਾਂ “no span in these four critical user journeys exceeds two seconds” ਵਰਗੇ ਪ੍ਰੌੰਪਟ ਕਾਰਗਰ ਬਣ ਜਾਂਦੇ ਹਨ.

ਅਸੀਂ ਨਿਯਮਿਤ ਤੌਰ ਤੇ ਇੱਕੋ Codex run ਨੂੰ ਇੱਕੋ ਕੰਮ ਉੱਤੇ ਛੇ ਘੰਟਿਆਂ ਤੋਂ ਵੀ ਵੱਧ ਸਮੇਂ ਤੱਕ ਕੰਮ ਕਰਦੇ ਵੇਖਦੇ ਹਾਂ (ਅਕਸਰ ਜਦੋਂ ਇਨਸਾਨ ਸੋ ਰਹੇ ਹੁੰਦੇ ਹਨ).

ਸੰਦਰਭ ਪ੍ਰਬੰਧਨ, ਵੱਡੇ ਅਤੇ ਜਟਿਲ ਕੰਮਾਂ ਲਈ ਏਜੰਟਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਣ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਚੁਣੌਤੀ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਸਿੱਖਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਬਹੁਤ ਸਧਾਰਣ ਸੀ: Codex ਨੂੰ ਨਕਸ਼ਾ ਦਿਓ, 1,000-ਪੰਨਿਆਂ ਦੀ ਹਦਾਇਤਾਂ ਵਾਲੀ ਕਿਤਾਬ ਨਹੀਂ.

ਅਸੀਂ “ਇੱਕ ਵੱਡੀ AGENTS.md⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)” ਵਾਲਾ ਢੰਗ ਅਜ਼ਮਾਇਆ। ਇਹ ਅਨੁਮਾਨਯੋਗ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੋਇਆ:

• ਸੰਦਰਭ ਇੱਕ ਘੱਟ ਸਰੋਤ ਹੈ. ਇੱਕ ਵਿਸ਼ਾਲ ਹਦਾਇਤੀ ਫਾਈਲ ਕੰਮ, ਕੋਡ, ਅਤੇ ਸੰਬੰਧਤ docs ਨੂੰ ਪਿੱਛੇ ਧੱਕ ਦਿੰਦੀ ਹੈ—ਇਸ ਲਈ ਏਜੰਟ ਜਾਂ ਤਾਂ ਮੁੱਖ ਪਾਬੰਦੀਆਂ ਗੁਆ ਲੈਂਦਾ ਹੈ ਜਾਂ ਗਲਤ ਚੀਜ਼ਾਂ ਲਈ optimize ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ.
• ਬਹੁਤ ਜ਼ਿਆਦਾ ਰਹਿਨੁਮਾਈ ਗੈਰ-ਰਹਿਨੁਮਾਈ ਬਣ ਜਾਂਦੀ ਹੈ. ਜਦੋਂ ਹਰ ਚੀਜ਼ “ਮਹੱਤਵਪੂਰਨ” ਹੁੰਦੀ ਹੈ, ਤਾਂ ਕੁਝ ਵੀ ਨਹੀਂ ਹੁੰਦਾ। ਏਜੰਟ ਜਾਣਬੁੱਝ ਕੇ ਰਸਤਾ ਲੱਭਣ ਦੀ ਬਜਾਏ ਸਥਾਨਕ pattern-matching ਕਰਨ ਲੱਗਦੇ ਹਨ.
• ਇਹ ਤੁਰੰਤ ਬੇਕਾਰ ਹੋ ਜਾਂਦੀ ਹੈ. ਇੱਕ monolithic manual ਬੇਕਾਰ ਨਿਯਮਾਂ ਦੀ ਕਬਰਗਾਹ ਬਣ ਜਾਂਦਾ ਹੈ। ਏਜੰਟ ਨਹੀਂ ਜਾਣ ਸਕਦੇ ਕਿ ਹਾਲੇ ਕੀ ਸੱਚ ਹੈ, ਇਨਸਾਨ ਇਸਨੂੰ ਸੰਭਾਲਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਫਾਈਲ ਚੁੱਪਚਾਪ ਇੱਕ ਭਰਮਾਉਣ ਵਾਲੀ ਮੁਸੀਬਤ ਬਣ ਜਾਂਦੀ ਹੈ.
• ਇਸਦੀ ਜਾਂਚ ਕਰਨੀ ਔਖੀ ਹੈ. ਇੱਕੋ blob mechanical checks (coverage, freshness, ownership, cross-links) ਲਈ ਢੰਗ ਨਾਲ ਮੌਕਾ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ drift ਲਾਜ਼ਮੀ ਬਣ ਜਾਂਦਾ ਹੈ.

ਇਸ ਲਈ AGENTS.md ਨੂੰ ਵਿਸ਼ਵਕੋਸ਼ ਵਾਂਗ ਦੇਖਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਇਸਨੂੰ ਵਿਸ਼ਾ-ਸੂਚੀ ਵਾਂਗ ਮੰਨਦੇ ਹਾਂ.

ਰਿਪੋਜ਼ਟਰੀ ਦਾ ਗਿਆਨ-ਅਧਾਰ ਇੱਕ structured docs/ directory ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਜਿਸਨੂੰ system of record ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ AGENTS.md (ਲਗਭਗ 100 ਲਾਈਨਾਂ) ਸੰਦਰਭ ਵਿੱਚ inject ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਮੁੱਖ ਤੌਰ ਤੇ ਨਕਸ਼ੇ ਵਜੋਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਜਿੱਥੋਂ ਹੋਰ ਡੂੰਘੇ ਸੱਚ ਦੇ ਸਰੋਤਾਂ ਵੱਲ ਇਸ਼ਾਰੇ ਹੁੰਦੇ ਹਨ.

ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਨੂੰ catalog ਅਤੇ index ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ verification status ਅਤੇ core beliefs ਦਾ ਇੱਕ ਸੈੱਟ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ agent-first operating principles ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। Architecture documentation⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਡੋਮੇਨਾਂ ਅਤੇ package layering ਦਾ top-level ਨਕਸ਼ਾ ਦਿੰਦੀ ਹੈ। ਇੱਕ quality document ਹਰ product domain ਅਤੇ architectural layer ਨੂੰ grade ਕਰਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ gaps ਨੂੰ track ਕਰਦਾ ਹੈ.

Plans ਨੂੰ first-class artifacts ਵਜੋਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਲਈ ephemeral lightweight plans ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਦਕਿ ਜਟਿਲ ਕੰਮ ਨੂੰ progress ਅਤੇ decision logs ਵਾਲੀਆਂ execution plans⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵਿੱਚ ਕੈਪਚਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ check in ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। Active plans, completed plans, ਅਤੇ ਜਾਣਿਆ technical debt ਸਭ versioned ਅਤੇ ਇਕੱਠੇ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਏਜੰਟ ਬਾਹਰੀ ਸੰਦਰਭ ਉੱਤੇ ਨਿਰਭਰ ਰਹੇ ਬਿਨਾਂ ਕੰਮ ਕਰ ਸਕਣ.

ਇਸ ਨਾਲ progressive disclosure ਸੰਭਵ ਹੁੰਦੀ ਹੈ: ਏਜੰਟ ਇੱਕ ਛੋਟੇ, ਸਥਿਰ entry point ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਇਹ ਸਿਖਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਅਗਲਾ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਉਹ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਭਰਮਿਤ ਹੋ ਜਾਣ.

ਅਸੀਂ ਇਸਨੂੰ mechanical ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਦੇ ਹਾਂ। ਸਮਰਪਿਤ linters ਅਤੇ CI jobs ਇਹ validate ਕਰਦੇ ਹਨ ਕਿ ਗਿਆਨ-ਅਧਾਰ ਅਪ-ਟੂ-ਡੇਟ ਹੈ, cross-linked ਹੈ, ਅਤੇ ਠੀਕ ਢੰਗ ਨਾਲ structured ਹੈ। ਇੱਕ ਦੁਹਰਾਉਂਦਾ “doc-gardening” ਏਜੰਟ ਪੁਰਾਣੀ ਜਾਂ ਬੇਮਤਲਬ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਲੱਭਦਾ ਹੈ ਜੋ ਅਸਲੀ ਕੋਡ ਦੇ ਵਿਹਾਰ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦੀ ਅਤੇ fix-up ਪੁੱਲ ਰਿਕਵੈਸਟ ਖੋਲ੍ਹਦਾ ਹੈ.

ਜਿਵੇਂ ਕੋਡਬੇਸ ਵਿਕਸਤ ਹੋਇਆ, ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਿਆਂ ਲਈ Codex ਦਾ framework ਵੀ ਵਿਕਸਤ ਹੋਣਾ ਲਾਜ਼ਮੀ ਸੀ.

ਕਿਉਂਕਿ ਰਿਪੋਜ਼ਟਰੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਏਜੰਟ-ਜਨਰੇਟਡ ਹੈ, ਇਹ ਸਭ ਤੋਂ ਪਹਿਲਾਂ Codex ਦੀ legibility ਲਈ optimized ਹੈ। ਜਿਸੇ ਤਰ੍ਹਾਂ ਟੀਮਾਂ ਨਵੇਂ ਇੰਜੀਨੀਅਰਿੰਗ hires ਲਈ ਆਪਣੇ ਕੋਡ ਦੀ navigability ਸੁਧਾਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ, ਓਸੇ ਤਰ੍ਹਾਂ ਸਾਡੇ ਮਨੁੱਖੀ ਇੰਜੀਨੀਅਰਾਂ ਦਾ ਲਕਸ਼ ਏਜੰਟ ਲਈ ਪੂਰੇ ਕਾਰੋਬਾਰੀ ਡੋਮੇਨ ਬਾਰੇ ਸਿੱਧੇ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਹੀ ਤਰਕ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਣਾ ਸੀ.

ਏਜੰਟ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ, ਜੋ ਵੀ ਚੀਜ਼ ਉਸਨੂੰ ਚਲਦਿਆਂ in-context ਉਪਲਬਧ ਨਹੀਂ, ਉਹ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹੀ ਨਹੀਂ। Google Docs, chat threads, ਜਾਂ ਲੋਕਾਂ ਦੇ ਮਨ ਵਿੱਚ ਰਹਿੰਦਾ ਗਿਆਨ ਸਿਸਟਮ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ। Repository-local, versioned artifacts (ਜਿਵੇਂ code, markdown, schemas, executable plans) ਹੀ ਉਹ ਸਭ ਕੁਝ ਹਨ ਜੋ ਉਹ ਦੇਖ ਸਕਦਾ ਹੈ.

ਅਸੀਂ ਸਿੱਖਿਆ ਕਿ ਸਮੇਂ ਦੇ ਨਾਲ ਸਾਨੂੰ ਹੋਰ ਅਤੇ ਹੋਰ ਸੰਦਰਭ ਰਿਪੋ ਵਿੱਚ ਧੱਕਣਾ ਪਿਆ। ਉਹ Slack ਚਰਚਾ ਜਿਸ ਨੇ ਟੀਮ ਨੂੰ ਕਿਸੇ architectural pattern ਉੱਤੇ ਇਕਸਾਰ ਕੀਤਾ? ਜੇਕਰ ਉਹ ਏਜੰਟ ਲਈ ਖੋਜਯੋਗ ਨਹੀਂ, ਤਾਂ ਉਹ ਓਸੇ ਤਰ੍ਹਾਂ ਅਪਾਠਯੋਗ ਹੈ ਜਿਵੇਂ ਤਿੰਨ ਮਹੀਨੇ ਬਾਅਦ ਜੁੜੇ ਕਿਸੇ ਨਵੇਂ hire ਲਈ ਅਣਜਾਣ ਹੋਵੇਗੀ.

Codex ਨੂੰ ਹੋਰ ਸੰਦਰਭ ਦੇਣ ਦਾ ਮਤਲਬ ਹੈ ਸਹੀ ਜਾਣਕਾਰੀ ਨੂੰ ਸੁਧਾਰਨਾ ਅਤੇ ਉਜਾਗਰ ਕਰਨਾ ਤਾਂ ਜੋ ਏਜੰਟ ਉਸ ਉੱਤੇ ਤਰਕ ਕਰ ਸਕੇ, ਨਾ ਕਿ ਉਸਨੂੰ ad-hoc ਹਦਾਇਤਾਂ ਨਾਲ ਓਵਰਲੋਡ ਕਰਨਾ। ਜਿਸੇ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਕਿਸੇ ਨਵੇਂ teammate ਨੂੰ product principles, engineering norms, ਅਤੇ team culture (emoji ਪਸੰਦ ਸਮੇਤ) ਬਾਰੇ onboard ਕਰਦੇ ਹੋ, ਓਸੇ ਤਰ੍ਹਾਂ ਏਜੰਟ ਨੂੰ ਇਹ ਜਾਣਕਾਰੀ ਦੇਣ ਨਾਲ output ਹੋਰ aligned ਹੁੰਦੀ ਹੈ.

ਇਸ framing ਨੇ ਕਈ tradeoffs ਸਪੱਸ਼ਟ ਕਰ ਦਿੱਤੇ। ਅਸੀਂ ਉਹ dependencies ਅਤੇ abstractions ਤਰਜੀਹ ਦਿੱਤੀਆਂ ਜਿਨ੍ਹਾਂ ਨੂੰ repo ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ internalize ਕਰਕੇ ਉਨ੍ਹਾਂ ਬਾਰੇ ਤਰਕ ਕੀਤਾ ਜਾ ਸਕੇ। ਜਿਨ੍ਹਾਂ ਤਕਨੀਕਾਂ ਨੂੰ ਅਕਸਰ “boring” ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਉਹ agents ਲਈ composability, api stability, ਅਤੇ training set ਵਿੱਚ representation ਕਰਕੇ ਮਾਡਲ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦੀਆਂ ਹਨ। ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, public libraries ਦੇ opaque upstream behavior ਨਾਲ ਨਿਪਟਣ ਦੀ ਬਜਾਏ agent ਤੋਂ functionality ਦੇ ਕੁਝ ਹਿੱਸੇ ਮੁੜ ਲਾਗੂ ਕਰਵਾਉਣਾ ਸਸਤਾ ਸੀ। ਉਦਾਹਰਨ ਵਜੋਂ, generic p-limit-style package ਲਿਆਉਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਆਪਣਾ map-with-concurrency helper ਬਣਾਇਆ: ਇਹ ਸਾਡੇ OpenTelemetry instrumentation ਨਾਲ ਘਣੀ ਤਰ੍ਹਾਂ ਜੁੜਿਆ ਹੈ, ਇਸਦਾ 100% test coverage ਹੈ, ਅਤੇ ਇਹ ਠੀਕ ਉਸੇ ਤਰ੍ਹਾਂ ਵਿਹਾਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਸਾਡਾ runtime ਉਮੀਦ ਕਰਦਾ ਹੈ.

ਸਿਸਟਮ ਦੇ ਹੋਰ ਹਿੱਸੇ ਨੂੰ ਐਸੇ ਰੂਪ ਵਿੱਚ ਲਿਆਉਣਾ ਜਿਸਦੀ ਏਜੰਟ ਸਿੱਧੀ ਜਾਂਚ, ਪੁਸ਼ਟੀ, ਅਤੇ ਸੋਧ ਕਰ ਸਕੇ, leverage ਵਧਾਉਂਦਾ ਹੈ—ਕੇਵਲ Codex ਲਈ ਹੀ ਨਹੀਂ, ਹੋਰ ਏਜੰਟਾਂ ਲਈ ਵੀ (ਜਿਵੇਂ Aardvark) ਜੋ ਕੋਡਬੇਸ ਉੱਤੇ ਵੀ ਕੰਮ ਕਰ ਰਹੇ ਹਨ.

ਕੇਵਲ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਏਜੰਟ-ਜਨਰੇਟਡ ਕੋਡਬੇਸ ਨੂੰ coherent ਨਹੀਂ ਰੱਖਦੀ। Implementation ਨੂੰ micromanage ਕਰਨ ਦੀ ਬਜਾਏ invariants ਲਾਗੂ ਕਰਕੇ, ਅਸੀਂ ਏਜੰਟਾਂ ਨੂੰ ਬੁਨਿਆਦ ਨੁਕਸਾਨ ਪਹੁੰਚਾਏ ਬਿਨਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦਿੰਦੇ ਹਾਂ. ਉਦਾਹਰਨ ਵਜੋਂ, ਅਸੀਂ Codex ਤੋਂ ਮੰਗ ਕਰਦੇ ਹਾਂ ਕਿ ਉਹ boundary ਉੱਤੇ data shapes parse ਕਰੇ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), ਪਰ ਅਸੀਂ ਇਸ ਬਾਰੇ ਹੁਕਮੀ ਨਹੀਂ ਹੁੰਦੇ ਕਿ ਇਹ ਕਿਵੇਂ ਹੋਵੇ (ਮਾਡਲ ਨੂੰ Zod ਪਸੰਦ ਲੱਗਦਾ ਹੈ, ਪਰ ਅਸੀਂ ਇਹ ਖ਼ਾਸ library ਨਿਰਧਾਰਿਤ ਨਹੀਂ ਕੀਤੀ).

ਏਜੰਟ ਉਹਨਾਂ ਇਨਵਾਇਰਨਮੈਂਟਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦੇ ਹਨ ਜਿੱਥੇ ਸਖ਼ਤ ਹੱਦਾਂ ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਬਣਤਰ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਕੜੇ architectural model ਦੇ ਆਧਾਰ ਉੱਤੇ ਬਣਾਇਆ। ਹਰ business domain ਨੂੰ layers ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੈੱਟ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ, ਜਿੱਥੇ dependency directions ਦੀ ਸਖ਼ਤ validation ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ edges ਦਾ ਸੀਮਿਤ ਸੈੱਟ ਹੈ। ਇਹ ਪਾਬੰਦੀਆਂ custom linters (ਜੋ ਬੇਸ਼ਕ Codex-ਜਨਰੇਟਡ ਹਨ!) ਅਤੇ structural tests ਰਾਹੀਂ mechanical ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ.

ਹੇਠਾਂ ਦਿੱਤਾ ਡਾਇਗ੍ਰਾਮ ਨਿਯਮ ਦਿਖਾਉਂਦਾ ਹੈ: ਹਰ business domain (ਜਿਵੇਂ App Settings) ਦੇ ਅੰਦਰ, ਕੋਡ ਸਿਰਫ਼ layers ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੈੱਟ ਰਾਹੀਂ “forward” depend ਕਰ ਸਕਦਾ ਹੈ (Types → Config → Repo → Service → Runtime → UI)। Cross-cutting concerns (auth, connectors, telemetry, feature flags) ਇੱਕੋ ਸਪੱਸ਼ਟ interface ਰਾਹੀਂ ਅੰਦਰ ਆਉਂਦੀਆਂ ਹਨ: Providers। ਇਸ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੁਝ ਵੀ ਮਨਜ਼ੂਰ ਨਹੀਂ ਅਤੇ mechanical ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.

ਇਹ ਉਹ ਕਿਸਮ ਦੀ ਆਰਕੀਟੈਕਚਰ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਆਮ ਤੌਰ ਤੇ ਉਸ ਵੇਲੇ ਤੱਕ ਟਾਲ ਦਿੰਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਸੈਂਕੜੇ ਇੰਜੀਨੀਅਰ ਨਾ ਹੋਣ। Coding agents ਨਾਲ, ਇਹ ਸ਼ੁਰੂਆਤੀ ਪੂਰਵ-ਸ਼ਰਤ ਹੈ: ਇਹ ਪਾਬੰਦੀਆਂ ਹੀ ਹਨ ਜੋ ਘਿਸਾਈ ਜਾਂ architectural drift ਤੋਂ ਬਿਨਾਂ ਗਤੀ ਸੰਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ.

ਅਮਲ ਵਿੱਚ, ਅਸੀਂ ਇਹ ਨਿਯਮ custom linters ਅਤੇ structural tests ਨਾਲ, ਨਾਲ ਹੀ “taste invariants” ਦੇ ਇੱਕ ਛੋਟੇ ਸੈੱਟ ਨਾਲ ਲਾਗੂ ਕਰਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ custom lints ਰਾਹੀਂ structured logging, schemas ਅਤੇ types ਲਈ naming conventions, file size limits, ਅਤੇ platform-specific reliability requirements ਨੂੰ statically ਲਾਗੂ ਕਰਦੇ ਹਾਂ। ਕਿਉਂਕਿ lints custom ਹਨ, ਅਸੀਂ error messages ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਦੇ ਹਾਂ ਕਿ remediation instructions ਏਜੰਟ ਸੰਦਰਭ ਵਿੱਚ inject ਹੋ ਜਾਣ.

ਮਨੁੱਖ-ਪਹਿਲਾਂ workflow ਵਿੱਚ, ਇਹ ਨਿਯਮ ਸ਼ਾਇਦ ਬਹੁਤ ਹੀ pedantic ਜਾਂ ਬੰਨ੍ਹਣ ਵਾਲੇ ਲੱਗਣ। ਏਜੰਟਾਂ ਨਾਲ, ਇਹ multipliers ਬਣ ਜਾਂਦੇ ਹਨ: ਇੱਕ ਵਾਰ encode ਹੋ ਜਾਣ ਉੱਪਰੰਤ, ਇਹ ਹਰ ਥਾਂ ਇਕੋ ਸਮੇਂ ਲਾਗੂ ਹੁੰਦੇ ਹਨ.

ਇਸੇ ਵੇਲੇ, ਅਸੀਂ ਸਪੱਸ਼ਟ ਰਹਿੰਦੇ ਹਾਂ ਕਿ ਕਿੱਥੇ ਪਾਬੰਦੀਆਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਕਿੱਥੇ ਨਹੀਂ। ਇਹ ਇੱਕ ਵੱਡੀ engineering platform organization ਨੂੰ ਲੀਡ ਕਰਨ ਵਰਗਾ ਹੈ: boundaries ਕੇਂਦਰੀ ਤੌਰ ਤੇ ਲਾਗੂ ਕਰੋ, autonomy ਸਥਾਨਕ ਤੌਰ ਤੇ ਦਿਓ। ਤੁਸੀਂ boundaries, correctness, ਅਤੇ reproducibility ਦੀ ਡੂੰਘੀ ਚਿੰਤਾ ਕਰਦੇ ਹੋ। ਇਨ੍ਹਾਂ boundaries ਦੇ ਅੰਦਰ, ਤੁਸੀਂ teams—ਜਾਂ agents—ਨੂੰ ਇਹ ਆਜ਼ਾਦੀ ਦਿੰਦੇ ਹੋ ਕਿ ਹੱਲ ਕਿਵੇਂ ਦਰਸਾਏ ਜਾਣ.

ਨਤੀਜੇ ਵਜੋਂ ਬਣਿਆ ਕੋਡ ਹਮੇਸ਼ਾਂ ਮਨੁੱਖੀ stylistic preferences ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ, ਅਤੇ ਇਹ ਠੀਕ ਹੈ। ਜਦ ਤੱਕ output ਸਹੀ, maintainable, ਅਤੇ ਭਵਿੱਖ ਦੇ agent runs ਲਈ legible ਹੈ, ਇਹ ਮਾਪਦੰਡ ਉੱਤੇ ਖਰਾ ਉਤਰਦਾ ਹੈ.

ਮਨੁੱਖੀ ਰੁਚੀ ਨੂੰ ਸਿਸਟਮ ਵਿੱਚ ਲਗਾਤਾਰ ਵਾਪਸ ਫੀਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। Review comments, refactoring ਪੁੱਲ ਰਿਕਵੈਸਟਾਂ, ਅਤੇ user-facing bugs ਨੂੰ documentation updates ਵਜੋਂ ਕੈਪਚਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਸਿੱਧਾ tooling ਵਿੱਚ encode ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ documentation ਘੱਟ ਪੈਂਦੀ ਹੈ, ਅਸੀਂ ਨਿਯਮ ਨੂੰ ਕੋਡ ਵਿੱਚ ਉੱਪਰ ਲੈ ਜਾਂਦੇ ਹਾਂ

ਜਿਵੇਂ Codex ਦਾ ਥਰੂਪੁੱਟ ਵਧਿਆ, ਕਈ ਰਵਾਇਤੀ engineering norms ਉਲਟ ਨਤੀਜੇ ਦੇਣ ਲੱਗੇ.

ਰਿਪੋਜ਼ਟਰੀ ਘੱਟ ਤੋਂ ਘੱਟ blocking merge gates ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ। ਪੁੱਲ ਰਿਕਵੈਸਟ ਛੋਟੀ ਉਮਰ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। Test flakes ਨੂੰ ਅਕਸਰ ਤਰੱਕੀ ਨੂੰ ਅਣਨਿਰਧਾਰਤ ਸਮੇਂ ਲਈ ਰੋਕਣ ਦੀ ਬਜਾਏ follow-up runs ਨਾਲ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਅਜਿਹੇ ਸਿਸਟਮ ਵਿੱਚ ਜਿੱਥੇ agent throughput ਮਨੁੱਖੀ ਧਿਆਨ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਹੈ, corrections ਸਸਤੀਆਂ ਹਨ ਅਤੇ ਉਡੀਕ ਮਹਿੰਗੀ ਹੈ.

ਘੱਟ ਥਰੂਪੁੱਟ ਵਾਲੇ ਇਨਵਾਇਰਨਮੈਂਟ ਵਿੱਚ ਇਹ ਗੈਰ-ਜ਼ਿੰਮੇਵਾਰਾਨਾ ਹੁੰਦਾ। ਇੱਥੇ, ਇਹ ਅਕਸਰ ਸਹੀ tradeoff ਹੁੰਦੀ ਹੈ.

ਜਦੋਂ ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ ਕਿ ਕੋਡਬੇਸ Codex ਏਜੰਟਾਂ ਦੁਆਰਾ ਜਨਰੇਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਸਾਡਾ ਮਤਲਬ ਕੋਡਬੇਸ ਵਿੱਚ ਮੌਜੂਦ ਹਰ ਚੀਜ਼ ਨਾਲ ਹੈ.

ਏਜੰਟ ਇਹ ਤਿਆਰ ਕਰਦੇ ਹਨ:

• ਉਤਪਾਦ ਕੋਡ ਅਤੇ ਟੈਸਟ
• CI configuration ਅਤੇ release tooling
• ਅੰਦਰੂਨੀ ਡਿਵੈਲਪਰ ਟੂਲ
• ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਅਤੇ design history
• Evaluation harnesses
• Review comments ਅਤੇ responses
• Scripts ਜੋ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਆਪ ਸੰਭਾਲਦੀਆਂ ਹਨ
• Production dashboard definition files

ਇਨਸਾਨ ਹਮੇਸ਼ਾਂ ਲੂਪ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਪਰ ਪਹਿਲਾਂ ਨਾਲੋਂ ਇੱਕ ਵੱਖਰੇ abstraction layer ਉੱਤੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਕੰਮਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਾਂ, user feedback ਨੂੰ acceptance criteria ਵਿੱਚ ਤਬਦੀਲ ਕਰਦੇ ਹਾਂ, ਅਤੇ outcomes ਨੂੰ validate ਕਰਦੇ ਹਾਂ। ਜਦੋਂ ਏਜੰਟ ਨੂੰ ਮੁਸ਼ਕਲ ਆਉਂਦੀ ਹੈ, ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ signal ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ: ਪਛਾਣੋ ਕਿ ਕੀ ਗਾਇਬ ਹੈ—tools, guardrails, documentation—ਅਤੇ ਉਸਨੂੰ ਵਾਪਸ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਫੀਡ ਕਰੋ, ਹਮੇਸ਼ਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋਏ ਕਿ fix Codex ਆਪ ਲਿਖੇ.

ਏਜੰਟ ਸਾਡੇ ਮਿਆਰੀ development tools ਨੂੰ ਸਿੱਧੇ ਵਰਤਦੇ ਹਨ। ਉਹ review feedback ਖਿੱਚਦੇ ਹਨ, inline ਜਵਾਬ ਦਿੰਦੇ ਹਨ, updates push ਕਰਦੇ ਹਨ, ਅਤੇ ਅਕਸਰ ਆਪਣੀਆਂ ਹੀ pull requests ਨੂੰ squash ਅਤੇ merge ਵੀ ਕਰਦੇ ਹਨ.

ਜਿਵੇਂ development loop ਦਾ ਹੋਰ ਹਿੱਸਾ ਸਿੱਧੇ ਸਿਸਟਮ ਵਿੱਚ encode ਕੀਤਾ ਗਿਆ—testing, validation, review, feedback handling, ਅਤੇ recovery—ਰਿਪੋਜ਼ਟਰੀ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਅਰਥਪੂਰਨ threshold ਪਾਰ ਕੀਤੀ ਹੈ ਜਿੱਥੇ Codex ਇੱਕ ਨਵੀਂ feature ਨੂੰ end-to-end ਚਲਾ ਸਕਦਾ ਹੈ.

ਇੱਕੋ ਪ੍ਰੌੰਪਟ ਦੇ ਆਧਾਰ ਉੱਤੇ, ਏਜੰਟ ਹੁਣ ਇਹ ਕਰ ਸਕਦਾ ਹੈ:

• ਕੋਡਬੇਸ ਦੀ ਮੌਜੂਦਾ ਹਾਲਤ validate ਕਰਨਾ
• ਰਿਪੋਰਟ ਕੀਤੀ bug ਨੂੰ reproduce ਕਰਨਾ
• ਫੇਲ੍ਹ ਦਿਖਾਉਂਦੀ ਇੱਕ ਵੀਡੀਓ ਰਿਕਾਰਡ ਕਰਨਾ
• ਇੱਕ fix ਲਾਗੂ ਕਰਨਾ
• ਐਪਲੀਕੇਸ਼ਨ ਚਲਾ ਕੇ fix validate ਕਰਨਾ
• ਸਮੱਸਿਆ ਹੱਲ ਦਿਖਾਉਂਦੀ ਦੂਜੀ ਵੀਡੀਓ ਰਿਕਾਰਡ ਕਰਨਾ
• ਇੱਕ ਪੁੱਲ ਰਿਕਵੈਸਟ ਖੋਲ੍ਹਣਾ
• ਏਜੰਟ ਅਤੇ ਮਨੁੱਖੀ feedback ਦਾ ਜਵਾਬ ਦੇਣਾ
• Build failures ਲੱਭ ਕੇ ਠੀਕ ਕਰਨਾ
• ਕੇਵਲ ਉਸ ਵੇਲੇ ਮਨੁੱਖ ਕੋਲ escalate ਕਰਨਾ ਜਦੋਂ ਫੈਸਲੇ ਦੀ ਲੋੜ ਹੋਵੇ
• ਤਬਦੀਲੀ ਨੂੰ merge ਕਰਨਾ

ਇਹ ਵਿਹਾਰ ਇਸ ਰਿਪੋਜ਼ਟਰੀ ਦੀ ਖ਼ਾਸ ਬਣਤਰ ਅਤੇ tooling ਉੱਤੇ ਬਹੁਤ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਇਸੇ ਜਿਹੀ ਨਿਵੇਸ਼ ਤੋਂ ਬਿਨਾਂ ਆਮ ਨਹੀਂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ—ਘੱਟੋ-ਘੱਟ ਹਾਲੇ ਨਹੀਂ.

ਪੂਰੀ agent autonomy ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੀ ਲਿਆਉਂਦੀ ਹੈ. Codex ਉਹ patterns ਦੁਹਰਾਉਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਮੌਜੂਦ ਹਨ—even uneven ਜਾਂ suboptimal ਵਾਲੇ ਵੀ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਸ ਨਾਲ ਲਾਜ਼ਮੀ ਤੌਰ ਤੇ drift ਪੈਦਾ ਹੁੰਦੀ ਹੈ.

ਸ਼ੁਰੂ ਵਿੱਚ, ਇਨਸਾਨ ਇਹ ਹੱਥੋਂ ਸੰਭਾਲਦੇ ਸਨ। ਸਾਡੀ ਟੀਮ ਹਰ ਸ਼ੁੱਕਰਵਾਰ (ਹਫ਼ਤੇ ਦਾ 20%) “AI slop” ਸਾਫ਼ ਕਰਨ ਵਿੱਚ ਲਗਾਉਂਦੀ ਸੀ। ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ, ਇਹ scale ਨਹੀਂ ਹੋਇਆ.

ਇਸਦੀ ਬਜਾਏ, ਅਸੀਂ ਜੋ ਅਸੀਂ “golden principles” ਕਹਿੰਦੇ ਹਾਂ, ਉਹਨਾਂ ਨੂੰ ਸਿੱਧੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ encode ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਅਤੇ ਇੱਕ ਦੁਹਰਾਉਂਦੀ cleanup ਪ੍ਰਕਿਰਿਆ ਬਣਾਈ। ਇਹ principles ਰਾਇਧਾਰਕ, mechanical rules ਹਨ ਜੋ ਭਵਿੱਖ ਦੇ agent runs ਲਈ ਕੋਡਬੇਸ ਨੂੰ legible ਅਤੇ consistent ਰੱਖਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ: (1) invariants ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖਣ ਲਈ ਅਸੀਂ hand-rolled helpers ਦੀ ਬਜਾਏ shared utility packages ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਾਂ, ਅਤੇ (2) ਅਸੀਂ “YOLO-style” data probe ਨਹੀਂ ਕਰਦੇ—ਅਸੀਂ boundaries validate ਕਰਦੇ ਹਾਂ ਜਾਂ typed SDKs ਉੱਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਏਜੰਟ ਅਨੁਮਾਨੀ shapes ਉੱਤੇ ਅਚਾਨਕ ਨਿਰਮਾਣ ਨਾ ਕਰ ਬੈਠੇ। ਨਿਯਮਿਤ cadence ਉੱਤੇ, ਸਾਡੇ ਕੋਲ ਕੁਝ background Codex tasks ਹੁੰਦੀਆਂ ਹਨ ਜੋ deviations scan ਕਰਦੀਆਂ ਹਨ, quality grades update ਕਰਦੀਆਂ ਹਨ, ਅਤੇ targeted refactoring ਪੁੱਲ ਰਿਕਵੈਸਟ ਖੋਲ੍ਹਦੀਆਂ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਨੂੰ ਇੱਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ review ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ automerge ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ.

ਇਹ garbage collection ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ। Technical debt ਇੱਕ ਉੱਚ-ਵਿਆਜ ਕਰਜ਼ੇ ਵਾਂਗ ਹੈ: ਲਗਭਗ ਹਮੇਸ਼ਾਂ ਇਸਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਲਗਾਤਾਰ ਘਟਾਉਣਾ ਇਸਨੂੰ ਇਕੱਠਾ ਹੋਣ ਦੇਣ ਅਤੇ ਫਿਰ ਦਰਦਨਾਕ ਢੰਗ ਨਾਲ ਨਿਪਟਣ ਨਾਲੋਂ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ। ਮਨੁੱਖੀ ਰੁਚੀ ਇੱਕ ਵਾਰ capture ਹੁੰਦੀ ਹੈ, ਫਿਰ ਕੋਡ ਦੀ ਹਰ ਲਾਈਨ ਉੱਤੇ ਲਗਾਤਾਰ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਸਾਨੂੰ ਮਾੜੇ patterns ਨੂੰ ਰੋਜ਼ਾਨਾ ਆਧਾਰ ਉੱਤੇ ਫੜਨ ਅਤੇ ਸੁਲਝਾਉਣ ਦੇ ਯੋਗ ਵੀ ਬਣਾਉਂਦਾ ਹੈ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਉਹ ਕੋਡਬੇਸ ਵਿੱਚ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਤੱਕ ਫੈਲਦੇ ਰਹਿਣ.

ਇਹ ਰਣਨੀਤੀ ਹੁਣ ਤੱਕ OpenAI ਵਿੱਚ ਅੰਦਰੂਨੀ launch ਅਤੇ adoption ਤੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਆਈ ਹੈ। ਅਸਲ ਯੂਜ਼ਰਾਂ ਲਈ ਅਸਲ ਉਤਪਾਦ ਬਣਾਉਣ ਨਾਲ ਸਾਨੂੰ ਆਪਣੀਆਂ ਨਿਵੇਸ਼ਾਂ ਨੂੰ ਹਕੀਕਤ ਨਾਲ ਜੋੜ ਕੇ ਰੱਖਣ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ maintainability ਵੱਲ ਲੈ ਜਾਣ ਵਿੱਚ ਮਦਦ ਮਿਲੀ.

ਜੋ ਅਸੀਂ ਹਾਲੇ ਨਹੀਂ ਜਾਣਦੇ, ਉਹ ਇਹ ਹੈ ਕਿ ਪੂਰੀ ਤਰ੍ਹਾਂ ਏਜੰਟ-ਜਨਰੇਟਡ ਸਿਸਟਮ ਵਿੱਚ ਕਈ ਸਾਲਾਂ ਦੌਰਾਨ architectural coherence ਕਿਵੇਂ ਵਿਕਸਤ ਹੁੰਦੀ ਹੈ। ਅਸੀਂ ਹਾਲੇ ਵੀ ਸਿੱਖ ਰਹੇ ਹਾਂ ਕਿ ਮਨੁੱਖੀ ਫੈਸਲਾ ਸਭ ਤੋਂ ਵੱਧ leverage ਕਿੱਥੇ ਜੋੜਦਾ ਹੈ ਅਤੇ ਉਸ ਫੈਸਲੇ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ encode ਕਿਵੇਂ ਕੀਤਾ ਜਾਵੇ ਕਿ ਉਹ ਇਕੱਠਾ ਹੋ ਕੇ ਵਧੇ। ਅਸੀਂ ਇਹ ਵੀ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਜਿਵੇਂ ਸਮੇਂ ਨਾਲ ਮਾਡਲ ਹੋਰ ਸਮਰੱਥ ਹੁੰਦੇ ਜਾਣਗੇ, ਇਹ ਸਿਸਟਮ ਕਿਵੇਂ ਵਿਕਸਤ ਹੋਵੇਗਾ.

ਜੋ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਹੈ: ਸਾਫਟਵੇਅਰ ਬਣਾਉਣ ਲਈ ਅਜੇ ਵੀ ਅਨੁਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਪਰ ਇਹ ਅਨੁਸ਼ਾਸਨ ਹੁਣ ਕੋਡ ਦੀ ਬਜਾਏ scaffolding ਵਿੱਚ ਵੱਧ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਉਹ tooling, abstractions, ਅਤੇ feedback loops ਜੋ ਕੋਡਬੇਸ ਨੂੰ coherent ਰੱਖਦੇ ਹਨ, ਹੋਰ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਬਣਦੇ ਜਾ ਰਹੇ ਹਨ.

ਸਾਡੀਆਂ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਚੁਣੌਤੀਆਂ ਹੁਣ ਐਸੇ ਇਨਵਾਇਰਨਮੈਂਟ, feedback loops, ਅਤੇ control systems ਡਿਜ਼ਾਈਨ ਕਰਨ ਉੱਤੇ ਕੇਂਦ੍ਰਿਤ ਹਨ ਜੋ ਏਜੰਟਾਂ ਨੂੰ ਸਾਡਾ ਲਕਸ਼ ਹਾਸਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ: ਵੱਡੇ ਪੈਮਾਨੇ ਉੱਤੇ ਜਟਿਲ, ਭਰੋਸੇਯੋਗ ਸਾਫਟਵੇਅਰ ਬਣਾਉਣਾ ਅਤੇ ਸੰਭਾਲਣਾ.

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