Codex orchestration ಗಾಗಿ ಒಂದು ಓಪನ್-ಸೋರ್ಸ್ ಸ್ಪೆಕ್: Symphony
Alex Kotliarskyi, Victor Zhu, ಮತ್ತು Zach Brock ಇವರಿಂದ
ಆರು ತಿಂಗಳುಗಳ ಹಿಂದೆ, ಒಂದು ಆಂತರಿಕ ಉತ್ಪಾದಕತೆ ಟೂಲ್ ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾಗ, ನಮ್ಮ ತಂಡ ಒಂದು ವಿವಾದಾತ್ಮಕವಾದ (ಆ ಸಮಯದಲ್ಲಿ) ನಿರ್ಧಾರ ಮಾಡಿತು: ನಮ್ಮ ರಿಪೊವನ್ನು ಮಾನವರು ಬರೆದ ಕೋಡ್ ಇಲ್ಲದೆ ನಿರ್ಮಿಸಬೇಕು ಎಂದು. ನಮ್ಮ project ರಿಪೊಸಿಟರಿಯಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಸಾಲನ್ನೂ Codex ರಚಿಸಿರಬೇಕು.
ಅದು ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡಲು, ನಾವು ನಮ್ಮ engineering workflow ಅನ್ನು ನೆಲೆಯಿಂದ ಮರುವಿನ್ಯಾಸಗೊಳಿಸಿದೆವು. ಏಜೆಂಟ್-ಸ್ನೇಹಿ ರಿಪೊಸಿಟರಿಯನ್ನು ನಿರ್ಮಿಸಿದೆವು, automated test ಗಳು ಮತ್ತು guardrail ಗಳಲ್ಲಿ ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ ಹೂಡಿಕೆ ಮಾಡಿದೆವು, ಮತ್ತು Codex ಅನ್ನು ಪೂರ್ಣ ಪ್ರಮಾಣದ ತಂಡದ ಸದಸ್ಯನಂತೆ ನೋಡಿದೆವು. ಆ ಪ್ರಯಾಣವನ್ನು ನಮ್ಮ ಹಿಂದಿನ harness engineering ಕುರಿತು ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ನಲ್ಲಿ ದಾಖಲಿಸಿದೆವು.
ಅದು ಕೆಲಸ ಮಾಡಿತು, ಆದರೆ ನಂತರ ನಾವು ಮುಂದಿನ bottleneck ಅನ್ನು ಎದುರಿಸಿದೆವು: context switching.
ಈ ಹೊಸ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು Symphony ಎಂಬ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಿದೆವು. Symphony(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಎನ್ನುವುದು Linear ಹೀಗಿನ project-management board ಅನ್ನು ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಳ control plane ಆಗಿ ಪರಿವರ್ತಿಸುವ ಒಂದು ಏಜೆಂಟ್ orchestrator. ಪ್ರತಿಯೊಂದು ತೆರೆದ ಕೆಲಸಕ್ಕೂ ಒಂದು ಏಜೆಂಟ್ ಸಿಗುತ್ತದೆ, ಏಜೆಂಟ್ಗಳು ನಿರಂತರವಾಗಿ ಓಡುತ್ತವೆ, ಮತ್ತು ಮಾನವರು ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ.
ಈ ಪೋಸ್ಟ್ ನಾವು Symphony ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿದೆವು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ—ಇದರಿಂದ ಕೆಲವು ತಂಡಗಳಲ್ಲಿ landed pull request ಗಳಲ್ಲಿ 500% ಹೆಚ್ಚಳ ಕಂಡುಬಂದಿತು—ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ issue tracker ಅನ್ನು ಯಾವಾಗಲೂ ಸಕ್ರಿಯವಾಗಿರುವ ಏಜೆಂಟ್ orchestrator ಆಗಿ ಮಾಡಲು ಅದನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನೂ ತಿಳಿಸುತ್ತದೆ.
ಪರಸ್ಪರ ಕ್ರಿಯಾತ್ಮಕ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಳ ಮಿತಿ
ಅವುಗಳನ್ನು ಬಳಸುವುದು ಸುಲಭವಾಗುತ್ತಿದ್ದರೂ, web app ಅಥವಾ CLI ಮೂಲಕ ಬಳಸುವ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಳು ಇನ್ನೂ ಪರಸ್ಪರ ಕ್ರಿಯಾತ್ಮಕ ಟೂಲ್ಗಳೇ ಆಗಿವೆ.
OpenAI ಯಲ್ಲಿ ಏಜೆಂಟ್ ಆಧಾರಿತ ಕೆಲಸದ ಪ್ರಮಾಣ ಹೆಚ್ಚಾದಂತೆ, ನಾವು ಹೊಸ ರೀತಿಯ ಭಾರವನ್ನು ಕಂಡೆವು. ಪ್ರತಿಯೊಬ್ಬ engineer ಕೆಲವು Codex ಸೆಷನ್ಗಳನ್ನು ತೆರೆಯುತ್ತಿದ್ದರು, ಕೆಲಸಗಳನ್ನು ನೀಡುತ್ತಿದ್ದರು, output ಪರಿಶೀಲಿಸುತ್ತಿದ್ದರು, ಏಜೆಂಟ್ಗೆ ದಿಕ್ಕು ತೋರಿಸುತ್ತಿದ್ದರು, ಮತ್ತು ಅದನ್ನೇ ಪುನರಾವರ್ತಿಸುತ್ತಿದ್ದರು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, context switching ನೋವಿನಾಯಕವಾಗುವ ಮೊದಲು ಹೆಚ್ಚಿನವರು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಮೂರರಿಂದ ಐದು ಸೆಷನ್ಗಳನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಬಹುದಾಗಿತ್ತು. ಅದಕ್ಕಿಂತ ಮುಂದೆ, ಉತ್ಪಾದಕತೆ ಇಳಿಯುತ್ತಿತ್ತು. ಯಾವ ಸೆಷನ್ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ನಾವು ಮರೆತೇ ಬಿಡುತ್ತಿದ್ದೆವು, ಏಜೆಂಟ್ಗಳನ್ನು ಮತ್ತೆ ಸರಿಯಾದ ದಾರಿಯಲ್ಲಿಡಲು terminal ಗಳ ನಡುವೆ ಹೋಗಿಬರುತ್ತಿದ್ದೆವು, ಮತ್ತು ಮಧ್ಯದಲ್ಲೇ ನಿಂತ ದೀರ್ಘಕಾಲದ ಕೆಲಸಗಳನ್ನು debug ಮಾಡುತ್ತಿದ್ದೆವು.
ಏಜೆಂಟ್ಗಳು ವೇಗವಾಗಿದ್ದವು, ಆದರೆ ನಮ್ಮಲ್ಲಿ ಒಂದು system bottleneck ಇತ್ತು: ಮಾನವ ಗಮನ. ನಾವು ವಾಸ್ತವದಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮರ್ಥ್ಯವಿರುವ ಕಿರಿಯ engineer ಗಳ ತಂಡವೊಂದನ್ನು ನಿರ್ಮಿಸಿ, ನಂತರ ನಮ್ಮ ಮಾನವ engineer ಗಳಿಗೆ ಅವರನ್ನು ಸೂಕ್ಷ್ಮವಾಗಿ ನಿರ್ವಹಿಸುವ ಕೆಲಸ ನೀಡಿದ್ದೆವು. ಅದು scale ಆಗುವುದಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿತ್ತು.
ದೃಷ್ಟಿಕೋನದಲ್ಲಿನ ಬದಲಾವಣೆ
ನಾವು ತಪ್ಪಾದ ವಿಷಯವನ್ನು optimize ಮಾಡುತ್ತಿದ್ದೇವೆ ಎಂಬುದು ನಮಗೆ ಅರ್ಥವಾಯಿತು. ನಾವು ನಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು coding session ಗಳು ಮತ್ತು merge ಆದ PR ಗಳ ಸುತ್ತ ರೂಪಿಸುತ್ತಿದ್ದೇವೆ, ಆದರೆ PR ಗಳು ಮತ್ತು session ಗಳು ನಿಜವಾಗಿ ಅಂತಿಮ ಗುರಿಗೆ ದಾರಿ ಮಾಡುವ ಸಾಧನಗಳಷ್ಟೇ. software workflow ಗಳು ಬಹುಪಾಲು deliverable ಗಳ ಸುತ್ತ ಸಂಘಟಿತವಾಗಿರುತ್ತವೆ: issue ಗಳು, task ಗಳು, ticket ಗಳು, milestone ಗಳು.
ಹೀಗಾಗಿ ನಾವು ನಮ್ಮನ್ನೇ ಕೇಳಿಕೊಂಡದ್ದು: ನಾವು ಏಜೆಂಟ್ಗಳನ್ನು ನೇರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಅವುಗಳಿಗೆ ನಮ್ಮ task tracker ನಿಂದ ಕೆಲಸವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಅವಕಾಶ ನೀಡಿದರೆ ಏನಾಗುತ್ತದೆ?
ಆ ಕಲ್ಪನೆಯೇ Symphony ಆಯಿತು, ಏಜೆಂಟ್ ಆಧಾರಿತ ಕೆಲಸವನ್ನು orchestrate ಮಾಡಲು supervisor ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಒಂದು ಲಿಖಿತ ಸ್ಪೆಕ್.
ನಮ್ಮ issue tracker ಅನ್ನು ಏಜೆಂಟ್ orchestrator ಆಗಿ ಪರಿವರ್ತಿಸುವುದು
Symphony ಒಂದು ಸರಳ ಕಲ್ಪನೆಯಿಂದ ಆರಂಭವಾಯಿತು: ಯಾವುದೇ ತೆರೆದ ಕೆಲಸವಿದ್ದರೂ, ಅದನ್ನು ಒಂದು ಏಜೆಂಟ್ ತೆಗೆದುಕೊಂಡು ಪೂರ್ಣಗೊಳಿಸಬೇಕು. ಹಲವು tab ಗಳಲ್ಲಿ Codex ಸೆಷನ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಬದಲು, ನಾವು ನಮ್ಮ issue tracker ನ್ನೇ control plane ಆಗಿ ಮಾಡಿದೆವು.
ಈ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಪ್ರತಿ ತೆರೆದ ಲಿನಿಯರ್ ಇಶ್ಯೂ ಒಂದು ಸಮರ್ಪಿತ ಏಜೆಂಟ್ ವರ್ಕ್ಸ್ಪೇಸ್ಗೆ ನಕ್ಷೆ ಮಾಡಲ್ಪಡುತ್ತದೆ. ಸಿಂಫನಿ ನಿರಂತರವಾಗಿ ಕಾರ್ಯಪಟ್ಟಿಯನ್ನು ಗಮನಿಸಿ, ಪ್ರತಿಯೊಂದು ಸಕ್ರಿಯ ಕಾರ್ಯ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಅದರಿಗಾಗಿ ಏಜೆಂಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆಯೇ ಅಥವಾ ಸ್ಥಗಿತಗೊಂಡಿದೆಯೇ ಎಂದರೆ, ಸಿಂಫನಿ ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಹೊಸ ಕೆಲಸ ಕಾಣಿಸಿಕೊಂಡರೆ, ಸಿಂಫನಿ ಅದನ್ನು ಸ್ವೀಕರಿಸಿ ಕೆಲಸವನ್ನು ವ್ಯವಸ್ಥಿತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ನಾವು ticket status ಗಳ ಆಧಾರದ ಮೇಲೆ ನಮ್ಮ workflow ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ, task manager ಆದ Linear ಅನ್ನು state machine ಆಗಿ ಬಳಸುತ್ತೇವೆ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, Symphony ಕೆಲಸವನ್ನು session ಗಳಿಂದಲೂ ಮತ್ತು pull request ಗಳಿಂದಲೂ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಕೆಲವು issue ಗಳು ವಿವಿಧ ರಿಪೊಗಳಲ್ಲಿ ಅನೇಕ PR ಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಇನ್ನಾವುವೋ ಸಂಪೂರ್ಣ ತನಿಖೆ ಅಥವಾ ವಿಶ್ಲೇಷಣೆಯ ಕೆಲಸವಾಗಿದ್ದು, ಕೋಡ್ಬೇಸ್ ಅನ್ನು ಎಂದಿಗೂ ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ.
ಕೆಲಸವನ್ನು ಈ ರೀತಿಯಾಗಿ ಅಮೂರ್ತಗೊಳಿಸಿದ ಬಳಿಕ, ticket ಗಳು ಬಹಳ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಕೆಲಸದ ಘಟಕಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಬಹುದು.
We regularly use Symphony to orchestrate complex features and infrastructure migrations. For example, we might file a task asking the agent to analyze the codebase, Slack, or Notion and produce an implementation plan. Once we’re happy with the plan, the agent generates a tree of tasks, breaking the work into stages and defining dependencies between tasks.
Agents only start working on tasks that aren’t blocked, so execution unfolds naturally and optimally in parallel for this DAG (a sequence of execution steps). For example, we marked the React upgrade as blocked on a migration to Vite. As expected, agents started upgrading React only after the migration to Vite was complete.
Agents can also create work themselves. During implementation or review, they often notice improvements that fall outside the scope of the current task: a performance issue, a refactoring opportunity, or a better architecture. When that happens, they simply file a new issue that we can evaluate and schedule later—many of these follow-up tasks also get picked up by agents. While we oversee this process, agents stay organized and keep work moving forward.
This way of working dramatically reduces the cognitive cost of kicking off ambiguous work. If the agent gets something wrong, that’s still useful information, and the cost to us is near zero. We can very cheaply file tickets for the agent to go prototype and explore, and throw away any explorations we don’t like.
Because the orchestrator runs on devboxes and never sleeps, we can add tasks from anywhere and know an agent will pick it up. For instance, one engineer on our team made three significant changes from the Linear app on his phone from a cozy cabin on shoddy wifi.
An increase in exploration from working this way
When observing the effects of working with Symphony, the most obvious change was output. Among some teams at OpenAI, we saw the number of landed PRs increase by 500% in the first three weeks. Outside of OpenAI, Linear founder Karri Saarinen highlighted a spike in workspaces created(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) as we released Symphony. However, the deeper shift is how teams think about work.
When our engineers no longer spend time supervising Codex sessions, the economics of code changes completely. The perceived cost of each change drops because we’re no longer investing human effort in driving the implementation itself.
That changed our behavior. It's become trivial to spin up speculative tasks in Symphony. Try an idea, explore a refactor, test a hypothesis, and only keep the results that look promising.
It also broadens who can initiate work. Our product manager and designer can now file feature requests directly into Symphony. They don’t need to check out the repo or manage a Codex session. They describe the feature and get back a review packet that includes a video walkthrough of the feature working inside the real product.
Symphony also shines in large monorepos (like the one we have at OpenAI) where the last mile of landing a PR is slow and fragile. The system watches CI, rebases when needed, resolves conflicts, retries flaky checks, and generally shepherds changes through the pipeline. By the time a ticket reaches Merging, we have high confidence the change will make it into the main branch without human babysitting.
Symphony ಅನ್ನು ಅಳವಡಿಸಿದ ನಂತರ, ನಾವು ಹೆಚ್ಚು ಕೆಲಸವನ್ನು ಏಜೆಂಟ್ಗಳಿಗೆ ವಹಿಸುತ್ತೇವೆ ಮತ್ತು ಇನ್ನಷ್ಟು ಕಠಿಣ, ಹೆಚ್ಚು ಅನ್ವೇಷಣಾತ್ಮಕ ಕೆಲಸಗಳ ಮೇಲೆ ಗಮನ ಹರಿಸುತ್ತೇವೆ.
ಪ್ರಗತಿ ಹೊಸ, ಭಿನ್ನ ಸಮಸ್ಯೆಗಳನ್ನೂ ತರುತ್ತದೆ
ಈ ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಕ್ಕೆ ಕೆಲವು tradeoff ಗಳು ಇವೆ. ನಾವು ಏಜೆಂಟ್ಗಳನ್ನು ಪರಸ್ಪರ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ steer ಮಾಡುವುದರಿಂದ ticket ಮಟ್ಟದಲ್ಲಿ ಕೆಲಸ ಹಂಚುವ ಕಡೆಗೆ ಬದಲಾಗಿದಾಗ, ಅವುಗಳನ್ನು ಮಧ್ಯದಲ್ಲೇ ನಿರಂತರವಾಗಿ ತುಳಕಿ ಬೇಕಾದಾಗ ದಿಕ್ಕು ಸರಿಪಡಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಕಳೆದುಕೊಂಡೆವು. ಕೆಲವೊಮ್ಮೆ ಏಜೆಂಟ್ ಗುರಿಯನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಿದ ಯಾವುದನ್ನೋ ಉತ್ಪಾದಿಸಿತು. ಅದು ಸಹ ಉಪಯುಕ್ತವಾಗಿತ್ತು—ಅಂತಹ ವಿಫಲತೆಗಳು ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಕೊರತೆಗಳನ್ನು ಬಯಲಿಗೆಳೆದು, ಅದನ್ನು ಇನ್ನಷ್ಟು ದೃಢವಾಗಿಸಲು ನಮಗೆ ಸಹಾಯ ಮಾಡಿದ್ದವು.
ಫಲಿತಾಂಶವನ್ನು ಕೈಯಾರೆ patch ಮಾಡುವ ಬದಲು, ಮುಂದಿನ ಬಾರಿ ಏಜೆಂಟ್ಗಳು ಯಶಸ್ವಿಯಾಗಲು guardrail ಗಳು ಮತ್ತು ಕೌಶಲ್ಯಗಳನ್ನು ಸೇರಿಸಿದೆವು. ಕಾಲಕ್ರಮೇಣ, ಇದರಿಂದ end-to-end test ಗಳನ್ನು ಓಡಿಸುವುದು, Chrome DevTools ಮೂಲಕ app ಅನ್ನು ನಡೆಸುವುದು, ಮತ್ತು QA smoke test ಗಳನ್ನು ನಿರ್ವಹಿಸುವಂತಹ ಹೊಸ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನಮ್ಮ harness ಗೆ ಸೇರಿಸಲು ಪ್ರೇರಣೆ ದೊರಕಿತು. ನಮ್ಮ documentation ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸಿದೆವು ಮತ್ತು ಉತ್ತಮ ಕೆಲಸ ಹೇಗಿರಬೇಕು ಎಂಬುದನ್ನು ಇನ್ನಷ್ಟು ಸ್ಪಷ್ಟಪಡಿಸಿದೆವು.
ಪ್ರತಿ ಕೆಲಸವೂ Symphony ಶೈಲಿಯ ಕೆಲಸಕ್ಕೆ ಸರಿಹೊಂದುತ್ತಿಲ್ಲ. ಕೆಲವು ಸಮಸ್ಯೆಗಳು ಇನ್ನೂ engineer ಗಳು ನೇರವಾಗಿ ಪರಸ್ಪರ ಕ್ರಿಯಾತ್ಮಕ Codex session ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಗತ್ಯವಿರುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ಅಸ್ಪಷ್ಟ ಸಮಸ್ಯೆಗಳು ಅಥವಾ ಗಟ್ಟಿಯಾದ ನಿರ್ಣಯ ಮತ್ತು ಪರಿಣತಿ ಬೇಕಾದ ಕೆಲಸಗಳಲ್ಲಿ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇವೇ ಸಾಮಾನ್ಯವಾಗಿ ನಮ್ಮ engineer ಗಳು ಸಮಯ ಕಳೆಯಲು ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಆನಂದದಾಯಕ ಕೆಲಸಗಳಾಗಿವೆ.
ವ್ಯತ್ಯಾಸವೆಂದರೆ Symphony ಸಾಮಾನ್ಯ implementation ಕೆಲಸದ ಬಹುಪಾಲನ್ನು ನಿಭಾಯಿಸಬಲ್ಲದು. ಇದರಿಂದ engineer ಗಳು ನಿರಂತರವಾಗಿ ಚಿಕ್ಕಚಿಕ್ಕ ಕೆಲಸಗಳ ನಡುವೆ context-switch ಮಾಡುವ ಬದಲು, ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಂದು ಕಠಿಣ ಸಮಸ್ಯೆಯ ಮೇಲೆ ಗಮನ ಕೇಂದ್ರೀಕರಿಸಬಹುದು.
ಏಜೆಂಟ್ಗಳನ್ನು state machine ನಲ್ಲಿನ ಕಟ್ಟುನಿಟ್ಟಾದ node ಗಳಂತೆ ನೋಡಿಕೊಳ್ಳುವುದು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನೂ ನಾವು ಕಲಿತೆವು. ಮಾಡೆಲ್ಗಳು ಇನ್ನಷ್ಟು ಚತುರವಾಗುತ್ತವೆ ಮತ್ತು ನಾವು ಅವುಗಳನ್ನು ಒತ್ತಿಹಾಕಲು ಯತ್ನಿಸುವ ಚೌಕಟ್ಟಿಗಿಂತ ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬಲ್ಲವು. ಉದಾಹರಣೆಗೆ, ಆರಂಭಿಕ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಎಲ್ಲಾ GitHub integration ಗಳು ಹೊರಗಿನ harness ನ ಭಾಗವಾಗಿದ್ದವು—ಹಾಗೆಂದರೆ, ಆರಂಭಿಕ ಆವೃತ್ತಿಗಳು Codex ಕೇವಲ code change ಗಳನ್ನೇ ಮಾಡಬೇಕು ಎಂದು ನಿರೀಕ್ಷಿಸಿ, ಉಳಿದ ಪ್ರಕ್ರಿಯೆಯನ್ನು (ಬದಲಾವಣೆಗಳನ್ನು ಸಲ್ಲಿಸುವುದು, test ಗಳನ್ನು ಓಡಿಸುವುದು) code ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಗೊಳಿಸುತ್ತಿದ್ದವು. ಏಜೆಂಟ್ ಆಧಾರಿತ ಕೆಲಸದ ನಮ್ಮ ಮೊದಲ ಆವೃತ್ತಿಗಳು Codex ಗೆ ಕೇವಲ task ಅನ್ನು implement ಮಾಡಲು ಮಾತ್ರ ಕೇಳುತ್ತಿದ್ದವು. ಆ ವಿಧಾನ ತುಂಬಾ ಮಿತಿಗೊಳಿಸುವುದಾಗಿ ಹೊರಬಂದಿತು. Codex ಅನೇಕ PR ಗಳನ್ನು ರಚಿಸುವುದಕ್ಕೂ, review feedback ಓದಿ ಅದನ್ನು address ಮಾಡುವುದಕ್ಕೂ ಸಂಪೂರ್ಣ ಸಮರ್ಥವಾಗಿದೆ. ಆದ್ದರಿಂದ ನಾವು ಅದಕ್ಕೆ gh CLI, CI log ಗಳನ್ನು ಓದಲು ಕೌಶಲ್ಯಗಳು ಇತ್ಯಾದಿ ಟೂಲ್ಗಳನ್ನು ನೀಡಿದೆವು—ಮತ್ತು ಈಗ ಹಳೆಯ PR ಗಳನ್ನು ಮುಚ್ಚುವುದು ಅಥವಾ ಪೂರ್ಣಗೊಂಡ ಕೆಲಸ ಮತ್ತು ತ್ಯಜಿಸಿದ ಕೆಲಸಗಳ ಕುರಿತು ವರದಿಗಳನ್ನು ತರಿಸುವಂತಹ ಇನ್ನಷ್ಟು ಕೆಲಸಗಳನ್ನು Codex ಗೆ ಕೇಳಬಹುದು. ಇಂತಹ ಕೆಲಸಗಳು ಆರಂಭಿಕ feature implementation ಚೌಕಟ್ಟಿಗಿಂತ ಬಹಳ ಹೊರಗಿದ್ದವು.
ಹೀಗಾಗಿ ಕೊನೆಯಲ್ಲಿ ನಾವು ಏಜೆಂಟ್ಗಳಿಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ transition ಗಳ ಬದಲು ಉದ್ದೇಶಗಳನ್ನು ನೀಡುವ ದಿಕ್ಕಿಗೆ ಬದಲಾಗಿದ್ದೇವೆ, ಒಳ್ಳೆಯ manager ಒಬ್ಬರು ತಮ್ಮ ತಂಡದ ನೇರ ವರದಿಗಾರರಿಗೆ ಗುರಿಯನ್ನು ಹಂಚುವಂತೆಯೇ. ಮಾಡೆಲ್ಗಳ ಶಕ್ತಿ ಅವುಗಳ ರೀಜನಿಂಗ್ ಸಾಮರ್ಥ್ಯದಿಂದ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಅವುಗಳಿಗೆ ಟೂಲ್ಗಳು ಮತ್ತು ಸನ್ನಿವೇಶ ನೀಡಿ, ಕೆಲಸ ಮಾಡಲು ಬಿಡಿ.
Symphony ನಿಂದಲೇ Symphony ನಿರ್ಮಿಸುವುದು
ನೀವು Symphony ರಿಪೊಸಿಟರಿಯನ್ನು ತೆರೆಯುವಾಗ, ಮೊದಲು ಗಮನಕ್ಕೆ ಬೀಳುವ ವಿಷಯವೆಂದರೆ Symphony ತಾಂತ್ರಿಕವಾಗಿ ಕೇವಲ ಒಂದು SPEC.md ಫೈಲ್ ಮಾತ್ರ—ಸಮಸ್ಯೆ ಮತ್ತು ಉದ್ದೇಶಿತ ಪರಿಹಾರದ ಒಂದು ವ್ಯಾಖ್ಯಾನ. ಸಂಕೀರ್ಣ supervision system ನಿರ್ಮಿಸುವ ಬದಲು, ನಾವು ಸಮಸ್ಯೆ ಮತ್ತು ಉದ್ದೇಶಿತ ಪರಿಹಾರಗಳನ್ನು ನಿರ್ವಚಿಸಿ, ಏಜೆಂಟ್ಗಳಿಗೆ ಉನ್ನತ-ಮಟ್ಟದ ದಿಕ್ಕು ನೀಡಿದೆವು.
ಇದರ ರೆಫರೆನ್ಸ್ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಅನ್ನು Elixir ಭಾಷೆಯಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ. ಕೋಡ್ ಬರೆಯುವ ವೆಚ್ಚ ಕಡಿಮೆಯಾದಾಗ, Elixir ನ ಕನ್ಕರೆನ್ಸಿಯಂತಹ (concurrency) ವಿಶಿಷ್ಟ ಸಾಮರ್ಥ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ ಭಾಷೆಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಿಕೊಳ್ಳಬಹುದು. ಆದರೆ ಇದರ ಮೂಲ ಆಲೋಚನೆಯನ್ನು ಸರಳ Markdown ಡಾಕ್ಯುಮೆಂಟ್ ಮೂಲಕವೂ ವಿವರಿಸಬಹುದು. ನಿಮ್ಮ ನೆಚ್ಚಿನ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗೆ ಈ ಸ್ಪೆಸಿಫಿಕೇಶನ್ ನೀಡಿ, ಅದರದ್ದೇ ಆದ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಪ್ರಯತ್ನಿಸಿ..
Symphony ಯ ಮೊದಲ ಆವೃತ್ತಿ tmux ನಲ್ಲಿ ಓಡುತ್ತಿದ್ದ ಒಂದು Codex ಸೆಷನ್ ಮಾತ್ರವಾಗಿತ್ತು, ಅದು Linear ಅನ್ನು poll ಮಾಡಿ ಹೊಸ ಕೆಲಸಗಳಿಗೆ ಉಪ-ಏಜೆಂಟ್ಗಳನ್ನು ಆರಂಭಿಸುತ್ತಿತ್ತು. ಅದು ಕೆಲಸ ಮಾಡಿತು, ಆದರೆ ವಿಶೇಷವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರಲಿಲ್ಲ. ಎರಡನೇ ಆವೃತ್ತಿ ನಮ್ಮ ಮುಖ್ಯ project ರಿಪೊಸಿಟರಿಯೊಳಗೆ ಇತ್ತು, ಅದು ಏಜೆಂಟ್ಗಳನ್ನು ಗಮನದಲ್ಲಿಟ್ಟು ನಿರ್ಮಿಸಲ್ಪಟ್ಟಿತ್ತು. ಈ ರಿಪೊದಲ್ಲಿ ಏಜೆಂಟ್ಗಳು ಉನ್ನತ ಗುಣಮಟ್ಟದ ಕೆಲಸ ಮಾಡಲು ಬೇಕಾದ ಕೌಶಲ್ಯ ಮತ್ತು ಸನ್ನಿವೇಶವನ್ನು ನೀಡಲು ನಾವು ಈಗಾಗಲೇ agent harness ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೆವು, ಆದ್ದರಿಂದ Symphony ಅದನ್ನೆಲ್ಲಾ ಸರಳವಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆ.
ಮೂಲ ಕಾರ್ಯಕ್ಷಮತೆ ಸಿದ್ದವಾದ ಬಳಿಕ, Symphony ನಿಂದಲೇ Symphony ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ.
ಸಿಸ್ಟಮ್ ಕೆಲಸಗಳನ್ನು ನಿರ್ವಹಿಸಿ ತನ್ನ proof-of-work ವಿಡಿಯೋವನ್ನು ಜೋಡಿಸುತ್ತಿರುವುದನ್ನು ನಾವು ಆಂತರಿಕವಾಗಿ demo ಮಾಡಿದಾಗ, ಪ್ರತಿಕ್ರಿಯೆ ಅತ್ಯಂತ ಧನಾತ್ಮಕವಾಗಿತ್ತು: ನಮ್ಮ Symphony project channel ಬೆಳೆಯಿತು, ಮತ್ತು ಸಂಸ್ಥೆಯಾದ್ಯಂತದ ತಂಡಗಳು ಅದನ್ನು ಸ್ವಾಭಾವಿಕವಾಗಿ ಬಳಸಲು ಆರಂಭಿಸಿದವು. OpenAI ಯಲ್ಲಿ ಹೊರಗೆ ಬಿಡುಗಡೆ ಮಾಡಲು ಮುನ್ನ ಆಂತರಿಕ product market fit ಅವಶ್ಯಕವಾಗಿದೆ. OpenAI ಯಲ್ಲಿ ನಾವು ಕಂಡ ಬಳಕೆಯ ಆಧಾರದ ಮೇಲೆ, Symphony ಯನ್ನು ಕಂಪನಿ ಗೋಡೆಗಳಾಚೆ ಹಂಚಿಕೊಳ್ಳಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು.
ಹೀಗಾಗಿ ನಾವು ಈ ಕಲ್ಪನೆಯನ್ನು ಸ್ವತಂತ್ರ SPEC.md ಆಗಿ ಹೊರತೆಗೆದು, ಅದನ್ನು ಇಂಪ್ಲಿಮೆಂಟ್ ಮಾಡಲು Codex ಅನ್ನು ಕೇಳಿದೆವು. ರೆಫರೆನ್ಸ್ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ಗಾಗಿ, ಒಂದೇ ಸಮಯದಲ್ಲಿ ನಡೆಯುವ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು orchestrate ಮತ್ತು supervise ಮಾಡಲು ಅತ್ಯುತ್ತಮ primitives ಹೊಂದಿರುವ, ತೀರ niche ಆಗಿರುವ Elixir ಭಾಷೆಯನ್ನು ಆರಿಸಿದೆವು. Codex ಒಂದು ಪ್ರಯತ್ನದಲ್ಲೇ Elixir ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ನಿರ್ಮಿಸಿತು, ಮತ್ತು ಅಲ್ಲಿಂದ ಸ್ಪೆಕ್ ಹಾಗೂ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಎರಡರ ಮೇಲೂ ನಾವು ಪುನರಾವರ್ತನೆ ಮುಂದುವರಿಸಿದೆವು. ಸ್ಪೆಕ್ ಅನ್ನು ಇನ್ನಷ್ಟು ತಿದ್ದಲು, ಅದನ್ನು TypeScript, Go, Rust, Java, Python ಮುಂತಾದ ಇನ್ನೂ ಹಲವು ಭಾಷೆಗಳಲ್ಲಿ ಇಂಪ್ಲಿಮೆಂಟ್ ಮಾಡಲು Codex ಅನ್ನು ಕೇಳಿ, ಫಲಿತಾಂಶಗಳಿಂದ ಗೊಂದಲಗಳನ್ನು ಗುರುತಿಸಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಸರಳಗೊಳಿಸಿದೆವು. ಅದು ಪ್ರತಿಯೊಂದು ಭಾಷೆಯಲ್ಲೂ ಯಶಸ್ವಿಯಾಯಿತು.
Codex ಅನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ರಿಪೊಸಿಟರಿಗಳು ಅಥವಾ Linear MCP ಮೇಲಿನ ಅವಲಂಬನೆಗಳಂತಹ ಅನೇಕ incidental complexity ಗಳನ್ನು ತೆಗೆದುಹಾಕಿದೆವು. Symphony ಇನ್ನು ಮುಂದೆ ನಮ್ಮ ಆಂತರಿಕ ರಿಪೊಸಿಟರಿಗಳು ಅಥವಾ workflow ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿಲ್ಲ. ಮೂಲ ವಿಧಾನ ಸರಳವಾಯಿತು:
ಪ್ರತಿ ತೆರೆದ ಕಾರ್ಯಕ್ಕಾಗಿ, ಅದರದೇ ಸ್ವಂತ ಕಾರ್ಯಕ್ಷೇತ್ರದಲ್ಲಿ ಒಂದು ಏಜೆಂಟ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವುದನ್ನು ಖಚಿತಪಡಿಸಿ.
ಸಕ್ರಿಯ ಕೆಲಸಕ್ಕೆ ಸಹಾಯ ಮಾಡುವುದರ ಜೊತೆಗೆ, development workflow ಈಗ ಏಜೆಂಟ್ಗಳಿಗೆ ತಿಳಿದಿದ್ದು, ಅವು ಅನುಸರಿಸುವ ವಿಷಯವಾಗಿದೆ. development workflow—ಒಂದು issue ಮೇಲೆ ಕೆಲಸ ಮಾಡುವುದು, ರಿಪೊ check out ಮಾಡುವುದು, PM ಗೆ ಕೆಲಸ ನಡೆಯುತ್ತಿದೆ ಎಂದು ತಿಳಿಯಲು ಅದನ್ನು in progress ಗೆ ಹಾಕುವುದು, PR ಸೇರಿಸುವುದು, ಅದನ್ನು Review status ಗೆ ಸಾಗಿಸುವುದು, ವಿಡಿಯೋಗಳನ್ನು ಜೋಡಿಸುವುದು, ಇತ್ಯಾದಿ—ಇವೆಲ್ಲವೂ ಈಗ ಸರಳ WORKFLOW.md ಫೈಲ್ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಲ್ಪಟ್ಟಿದೆ. ಇವೆಲ್ಲವೂ ಮಾನವರು ಅನುಸರಿಸುತ್ತಿದ್ದ ಪ್ರಕ್ರಿಯೆಯಾಗಿತ್ತು, ಆದರೆ ಅದು ಎಂದಿಗೂ ದಾಖಲಾಗಿರಲಿಲ್ಲ. ಈ ಅಪ್ರತ್ಯಕ್ಷ ಹಂತಗಳ ಸಮೂಹದ ಮೇಲೆ ಅವಲಂಬಿಸುವ ಬದಲು, ನಾವು ಈಗ ಅದನ್ನು ದಾಖಲಿಸುತ್ತೇವೆ, ಮತ್ತು Symphony ಏಜೆಂಟ್ಗಳು ಅದನ್ನು ಅನುಸರಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಇದರಿಂದ ನಮ್ಮ ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುವ ಏಜೆಂಟ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಮುಗಿದ ಕೆಲಸಕ್ಕೆ ಏಜೆಂಟ್ಗಳು self-reflection ಕೂಡ ಜೋಡಿಸಬೇಕು ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದರೆ, ಅದನ್ನು WORKFLOW.md ಗೆ ಸೇರಿಸುತ್ತೇವೆ, ಮತ್ತು Symphony ಏಜೆಂಟ್ಗಳನ್ನು ಆ ಹಂತದವರೆಗೆ ಮಾರ್ಗದರ್ಶಿಸುತ್ತದೆ.
ನಾವು Codex ಅನ್ನು app server mode(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ನಲ್ಲಿಯೂ ಬಳಸಲು ಸಾಧ್ಯವಾಯಿತು. ಇದು Codex ಗಾಗಿ ಅಂತರ್ನಿರ್ಮಿತ headless mode ಆಗಿದೆ. ಈ mode ನಿಂದ thread ಆರಂಭಿಸುವುದು ಅಥವಾ turn ಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು ಮುಂತಾದ ಕೆಲಸಗಳಿಗೆ ಉತ್ತಮವಾಗಿ ದಾಖಲಿಸಲಾದ JSON-RPC API ಮೂಲಕ Codex ಅನ್ನು ಚಾಲನೆ ಮಾಡಿ ಅದೊಂದಿಗೇ programmatically ಮಾತಾಡಲು ಸಾಧ್ಯವಾಯಿತು. CLI ಅಥವಾ live tmux session ಗಳ ಮೂಲಕ Codex ಜೊತೆ ಸಂವಹನ ಮಾಡಲು ಯತ್ನಿಸುವುದಕ್ಕಿಂತ ಇದು ಬಹಳ ಅನುಕೂಲಕರ ಮತ್ತು scale ಆಗುವ ವಿಧಾನವಾಗಿದೆ.
Codex App Server ನಮ್ಮ use case ಗೆ ಪರಿಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೊಂಡಿತು: plug in ಮಾಡಲು ಬೇಕಾದ knobs ಮತ್ತು hook ಗಳು ನಮ್ಮ ಕೈಯಲ್ಲೇ ಇರುವಾಗ, Codex ನೀಡುವ harness ನ ಲಾಭವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ. ಉದಾಹರಣೆಗೆ, Linear access token ಅನ್ನು subagent ಗಳಿಗೆ ಬಹಿರಂಗಗೊಳಿಸದಿರಲು, MCP ಮೇಲೆ ಅವಲಂಬಿಸದೆ ಅಥವಾ access token ಅನ್ನು container ಗಳಿಗೆ ತೋರಿಸದೆ, Linear ವಿರುದ್ಧ arbitrary request ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ raw linear_graphql function ಅನ್ನು ಬಹಿರಂಗಗೊಳಿಸಲು ನಾವು dynamic tool calls(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಅನ್ನು ಬಳಸುತ್ತೇವೆ.
ಮುಂದೇನು
Symphony ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅತ್ಯಲ್ಪ orchestration layer ಆಗಿದೆ. Linear ಹೀಗಿನ ವಿಭಿನ್ನ workflow tool ಗಳ ಜೊತೆ ಜೋಡಿಸಿದಾಗ Codex App Server ನ ಶಕ್ತಿಯನ್ನು ತೋರಿಸಲು ನಾವು ಇದನ್ನು open source ಮಾಡುತ್ತಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, Symphony ಯನ್ನು ಸ್ವತಂತ್ರ ಉತ್ಪನ್ನವಾಗಿ ನಿರ್ವಹಿಸುವ ಯೋಜನೆ ನಮ್ಮಲ್ಲಿಲ್ಲ. ಇದನ್ನು ಒಂದು reference implementation ಎಂದು ಭಾವಿಸಿ. ಅನೇಕ developer ಗಳು ತಮ್ಮ ರಿಪೊಸಿಟರಿಗಳನ್ನು scaffold ಮಾಡಲು harness engineering ಪೋಸ್ಟ್ಗೆ ತಮ್ಮ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಳನ್ನು ತೋರಿಸಿದಂತೆಯೇ, ನಿಮ್ಮ ಪರಿಸರಗಳಿಗೆ ತಕ್ಕಂತೆ ನಿಮ್ಮದೇ ಆವೃತ್ತಿಗಳನ್ನು ನಿರ್ಮಿಸಲು Symphony spec(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮತ್ತು repository(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಗಳಿಗೆ ನಿಮ್ಮ ಮೆಚ್ಚಿನ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಅನ್ನು ತೋರಿಸುತ್ತೀರಿ ಎಂದು ನಾವು ಆಶಿಸುತ್ತೇವೆ.
ಶಕ್ತಿ Codex ಮತ್ತು ಅದರ app server ನಿಂದ ಬರುತ್ತದೆ. ಕೆಲಸ ನಿರ್ವಹಣೆಯ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಈಗಾಗಲೇ ಬಳಸುತ್ತಿದ್ದ Codex ಮತ್ತು Linear ಎಂಬ ಎರಡು ವಿಷಯಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಮಾರ್ಗವೇ Symphony ಆಗಿತ್ತು. ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಳು ರೀಜನಿಂಗ್ ಮತ್ತು ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸುವಲ್ಲಿ ಇನ್ನಷ್ಟು ಉತ್ತಮವಾಗುತ್ತಿದ್ದಂತೆ, ಇತರ ಕಂಪನಿಗಳ bottleneck ಕೂಡ ಕೋಡ್ ಬರೆಯುವುದರಿಂದ ಏಜೆಂಟ್ ಆಧಾರಿತ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುವ ದಿಕ್ಕಿಗೆ ಸರಿಯಬಹುದು ಎಂದು ನಾವು ಅನುಮಾನಿಸುತ್ತೇವೆ. ಉತ್ಸಾಹಕರ ಭಾಗವೆಂದರೆ, ಈ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ವ್ಯವಸ್ಥೆಗಳೊಂದಿಗೆ ಪ್ರಯೋಗ ಮಾಡಲು ಇರುವ ಅಡ್ಡಿ ಈಗ ಆಶ್ಚರ್ಯಕರವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ. ನೀವು Codex ನಿಂದ ಸರಳವಾಗಿ ವಸ್ತುಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು.
ಸಮುದಾಯದ ಅಭಿನಂದನೆಗಳು
ಬಿಡುಗಡೆಯಾದ ನಂತರದ ಈ ವಾರಗಳಲ್ಲಿ engineering ಸಮುದಾಯ Symphony ಬಳಸುತ್ತಿರುವುದನ್ನು ನೋಡಿ ನಾವು ಆನಂದಿತರಾಗಿದ್ದೇವೆ. ಏಪ್ರಿಲ್ 23 ರ ವೇಳೆಗೆ ಇದಕ್ಕೆ 15K GitHub stars(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಗಿಂತ ಹೆಚ್ಚು ದೊರೆತಿವೆ.