Sea deploys Codex to 87% of the team and treats agents as organizational change, not a plugin

Sea deploys Codex to 87% of engineers and talks system design, not autocomplete

OpenAI published an interview with David Chen, co-founder of Sea and Chief Product Officer for Shopee's e-commerce business. Sea Limited is a Singapore-based technology group running large consumer products across digital entertainment, e-commerce, and financial services. According to the article, Sea is deploying Codex across its engineering organization, with OpenAI citing 87% weekly active users internally.

That number is interesting, but the percentage is not the point. The important part is how Chen frames Codex use. He is not only talking about faster coding or a nicer autocomplete. He talks about complex codebases, microservices, CI/CD, tests, system design, and engineering discipline inside a company with real operational pressure.

Codex is not presented as a toy for an individual developer. It is described as a layer that helps a large engineering organization manage complexity. That is much more important than a demo where an agent builds a small greenfield app in five minutes.

A large codebase needs a different kind of agent than a tutorial project

Large codebases have a different problem from small projects. The question is not whether a developer can write a function. The question is whether they can safely understand the impact of a change, find the right places in the code, add tests, pass local and CI validation, and avoid regressions in a system with a long history and many invisible dependencies.

This is where an agent can be more useful than autocomplete. It can search the repository, summarize relevant parts, propose a change plan, create tests, attempt a fix, respond to test failures, and prepare a change for human review. That is still not unsupervised autonomy. It is, however, a much better use of a model than guessing the next line.

Sea is a useful example because this is not an academic sandbox. E-commerce in Southeast Asia means different markets, payment methods, logistics, traffic spikes, local rules, and a huge number of integration details. If an agent helps in that environment, it has to work with real complexity, not only a clean tutorial project.

Engineering-wide deployment has a different dynamic from individual adoption. One enthusiastic developer with an agent is an experiment. An organization where a large share of the team uses Codex every week has to define norms: what good prompts look like, what may be delegated, how agent-created changes are reviewed, when a human is mandatory, how decisions are logged, and how quality is measured.

That is where value is decided. If an agent only accelerates uncontrolled code production, technical debt grows faster. If it is embedded into a process with tests, CI, review, and clear rules, it can accelerate safe iteration. The difference between those outcomes is not the model. It is operational discipline.

Blind trust, uniformity, and missing quality metrics are the three main failure modes

The first failure mode is trust without proof. An agent can sound confident while misunderstanding a domain invariant or skipping a critical edge case. In a large codebase, a mistake often shows up far away from where it was introduced. That is exactly why agentic workflows need tests, smaller changes, review, and a reproducible record of why the change was made.

The second failure mode is uniformity. If everyone uses the same agent in the same way, the organization may gain speed but lose diversity of solutions. The model will prefer familiar patterns, sometimes too conservative, sometimes too confident.

The third failure mode is measurement. Weekly active users is an adoption metric, not a quality metric. More important signals include change lead time, regressions, review load, incidents, test quality, onboarding speed, and the ability to work with old parts of the system.

An agent adds power where a good engineering system already exists, and that is the signal

Watch concrete metrics beyond adoption. How many changes land without regressions? Does onboarding get shorter? Can the agent safely modify older services? Does test coverage improve, or does the team just produce more code? Does review load decrease, or do senior engineers simply move from writing code to cleaning agent output?

The lesson for companies is sharp: do not evaluate coding agents by how nicely they complete lines. Evaluate them by whether they safely increase the throughput of changes in a real system. If they do, you have a new operational layer for engineering. If not, you have an expensive helper for generating pull requests.

Lilith's verdict

The important shift here is from autocomplete to operational agent. Sea talks about complexity, tests, system design, and work inside a large engineering organization. If it works, this is not an editor plugin. It changes how an engineering org absorbs work.