Como usamos o Codex para criar o Sora para Android em 28 dias

A partir de 26 de abril de 2026, o produto Sora não estará mais disponível.

Em novembro, lançamos o aplicativo Sora para Android no mundo todo, permitindo que qualquer pessoa com um dispositivo Android transforme um breve prompt em um vídeo vívido. No dia do lançamento, o aplicativo alcançou o primeiro lugar na Play Store. Usuários de Android geraram mais de um milhão de vídeos nas primeiras 24 horas.

Por trás do lançamento, há uma história: a versão inicial do aplicativo Android de produção da Sora foi criada em 28 dias, graças ao mesmo agente disponível para qualquer equipe ou desenvolvedor: o Codex.

De 8 de outubro a 5 de novembro de 2025, uma equipe de engenharia enxuta, trabalhando em conjunto com a Codex e consumindo aproximadamente 5 bilhões de tokens, lançou o Sora para Android, desde o protótipo até o lançamento global. Apesar de sua escala, o aplicativo tem uma taxa de 99,9% de ausência de falhas e uma arquitetura da qual nos orgulhamos. Se você está se perguntando se usamos um modelo secreto, usamos uma versão inicial do GPT‑5.1‑Codex. modelo – a mesma versão que qualquer desenvolvedor ou empresa pode usar hoje via CLI, extensão de IDE ou aplicativo web.

Quando o Sora foi lançado para iOS, seu uso explodiu. Imediatamente, as pessoas começaram a gerar uma série de vídeos. No Android, por outro lado, tínhamos apenas um pequeno protótipo interno e um número crescente de usuários pré-registrados no Google Play.

Uma resposta comum a um lançamento de alto risco e com prazos apertados é acumular recursos e adicionar processos. Um aplicativo de produção com essa abrangência e qualidade normalmente envolveria muitos engenheiros trabalhando por meses, com o processo sendo atrasado por questões de coordenação. 

O arquiteto de computadores americano Fred Brooks alertou, certa vez, que "adicionar mais pessoas a um projeto de software atrasado só o atrasa ainda mais". Em outras palavras, ao tentar entregar um projeto complexo rapidamente, adicionar mais engenheiros muitas vezes pode diminuir a eficiência, aumentando a sobrecarga de comunicação, a fragmentação de tarefas e os custos de integração. Em vez de ignorar essa percepção, demos atenção a ela e reunimos uma equipe sólida de quatro engenheiros, todos equipados com o Codex para aumentar drasticamente o impacto de cada um. 

Dessa forma, conseguimos distribuir uma versão interna do Sora para Android aos funcionários em 18 dias e lançá-la publicamente 10 dias depois. Mantivemos um alto padrão nas práticas de engenharia do Android, investimos na facilidade de manutenção e exigimos do aplicativo o mesmo nível de confiabilidade que esperaríamos de um projeto mais tradicional. (Atualmente, continuamos a usar o Codex amplamente para evoluir e trazer novos recursos para o aplicativo).

Para entender como trabalhamos com o Codex, é útil saber onde ele se destaca e onde precisa de melhorias. Tratar isso como um engenheiro sênior recém-contratado foi uma boa abordagem. A capacidade do Codex significava que podíamos dedicar mais tempo a orientar e revisar o código do que a escrevê-lo nós mesmos.

Onde o Codex precisa de orientação

1. O Codex ainda não é muito bom em inferir o que não lhe foi dito (por exemplo, seus padrões de arquitetura preferidos, estratégia de produto, comportamento real do usuário e normas ou atalhos internos).
2. Da mesma forma, o Codex não conseguia ver o aplicativo em execução: não conseguia abrir o Sora em um dispositivo, perceber que a rolagem estava estranha ou sentir que um fluxo era confuso. Somente nossa equipe poderia realizar essas tarefas práticas.
3. Cada instância requer integração. Compartilhar o contexto com objetivos, restrições e orientações claras sobre "como fazemos as coisas" foi essencial para o bom desempenho do Codex.
4. Da mesma forma, o Codex enfrentou dificuldades com julgamentos arquitetônicos profundos: deixado por conta própria, poderia introduzir um modelo de visualização extra onde, na verdade, queríamos estender um já existente, ou inserir na camada de interface do usuário uma lógica que claramente pertencia a um repositório. Seu instinto é fazer algo funcionar, não priorizar a limpeza a longo prazo.

Consideramos útil que o Codex criasse e mantivesse uma quantidade generosa de arquivos AGENT.md em toda a base de código. Isso facilitou a aplicação das mesmas orientações e melhores práticas em todas as sessões. Por exemplo, para garantir que a Codex escrevesse código de acordo com nossas diretrizes de estilo, adicionamos o seguinte ao nosso arquivo AGENTS.md de nível superior:

Onde a Codex se destaca

1. Leitura e compreensão rápidas de grandes bases de código: o Codex é compatível com praticamente todas as principais linguagens de programação, o que facilita o aproveitamento dos mesmos conceitos em diversas plataformas sem abstrações complexas.
2. Abrangência de testes: A Codex demonstra um entusiasmo (excepcional) pela criação de testes unitários que cubram uma ampla variedade de casos. Nem todos os testes foram aprofundados, mas ter uma ampla cobertura foi útil para evitar regressões. 
3. Aplicando feedback: De maneira semelhante, o Codex é bom em reagir ao feedback. Quando a integração contínua (CI) falhava, podíamos colar a saída do log em um prompt e pedir ao Codex para sugerir correções.
4. Execução massivamente paralela e descartável: a maioria não explorará os limites do número de sessões que podem ser executadas simultaneamente. É perfeitamente viável testar várias ideias em paralelo e encarar o código como descartável.
5. Oferecendo uma nova perspectiva: Nas discussões de design, usamos o Codex como uma ferramenta generativa para explorar potenciais pontos de falha e descobrir novas maneiras de resolver um problema. Por exemplo, enquanto projetávamos otimizações de memória para reprodutores de vídeo, a Codex analisou diversos SDKs para propor abordagens que não teríamos tido tempo de analisar. As informações obtidas com a pesquisa da Codex provaram ser inestimáveis para minimizar o uso de memória no aplicativo final.
6. Possibilitando um trabalho de maior impacto: Na prática, acabamos gastando mais tempo revisando e orientando o código do que escrevendo-o nós mesmos. Dito isso, o Codex também é muito bom em revisão de código, frequentemente detectando erros antes que sejam incorporados, melhorando a confiabilidade.

Após reconhecermos essas características, nosso modelo de trabalho tornou-se mais simples. Recorremos ao Codex para realizar uma grande parte do trabalho pesado dentro de padrões bem definidos e escopos bem delimitados, enquanto nossa equipe se concentrava na arquitetura, experiência do usuário, mudanças sistêmicas e qualidade final.

Mesmo o melhor funcionário recém-contratado, em cargo sênior, não possui a perspectiva adequada para tomar decisões de longo prazo imediatamente. Para tirar proveito do Codex e garantir que seu trabalho fosse robusto e de fácil manutenção, foi fundamental que supervisionássemos o design dos sistemas do aplicativo e as principais decisões tomadas. Isso incluiu moldar a arquitetura do aplicativo, modularização, injeção de dependência e navegação; também implementamos autenticação e fluxos básicos de rede. 

Partindo dessa base, desenvolvemos algumas funcionalidades representativas de ponta a ponta. Usamos as regras que queríamos que toda a base de código seguisse e documentamos os padrões de todo o projeto à medida que avançávamos. Ao direcionar o Codex para características representativas, ele conseguiu funcionar de forma mais independente dentro de nossos padrões. Para um projeto que estimamos ter sido escrito em 85% pela Codex, uma base cuidadosamente planejada evitou custos elevados com retrabalho e refatoração. Foi uma das decisões mais importantes que tomamos. 

A ideia não era criar "algo que funcione" o mais rápido possível, mas sim "algo que funcione da maneira que queremos". Existem muitas maneiras "corretas" de escrever código. Não precisávamos dizer exatamente ao Codex o que fazer; precisávamos mostrar ao Codex o que era "correto" em nossa equipe. Assim que definimos nosso ponto de partida e a forma como gostaríamos de construir, o Codex estava pronto para começar.

Para ver o que aconteceria, tentamos executar o seguinte comando: “Crie o aplicativo Sora para Android com base no código do iOS.” "Vá", mas rapidamente abandonou essa ideia. Embora o que a Codex criou funcionasse tecnicamente, a experiência com o produto era inferior. E sem uma compreensão clara dos endpoints, dados e fluxos de usuários, o código de execução única do Codex era pouco confiável (mesmo sem usar um agente, é arriscado mesclar milhares de linhas de código). 

Nossa hipótese era de que o Codex prosperaria em um ambiente repleto de exemplos bem escritos; e estávamos certos. Pedir ao Codex para "construir esta tela de configurações" sem praticamente nenhum contexto era algo pouco confiável. Pedir ao Codex para "construir esta tela de configurações usando a mesma arquitetura e padrões que esta outra tela que você acabou de ver" funcionou muito melhor. Os humanos tomaram as decisões estruturais e definiram as invariantes; o Codex então preencheu grandes quantidades de código dentro dessa estrutura.

Nosso próximo passo para maximizar o potencial do Codex foi descobrir como permitir que ele funcionasse por longos períodos (recentemente, mais de 24 horas⁠) sem supervisão.

Logo no início da utilização do Codex, recebíamos mensagens como: "Aqui está a funcionalidade." Aqui estão alguns arquivos. Por favor, construa isso. Isso às vezes funcionava, mas na maioria das vezes produzia código que tecnicamente compilava, embora se desviasse de nossa arquitetura e objetivos.

Então, alteramos o fluxo de trabalho. Para qualquer alteração que não fosse trivial, primeiro pedíamos à Codex que nos ajudasse a entender como o sistema e o código funcionavam. Por exemplo, poderíamos pedir que lesse um conjunto de arquivos relacionados e resumisse como esse recurso funciona; por exemplo, como os dados fluem da API através da camada de repositório, do modelo de visualização e para a interface do usuário. Em seguida, corrigiríamos ou aprimoraríamos sua compreensão. (Por exemplo, poderíamos apontar que uma determinada abstração pertence, na verdade, a uma camada diferente ou que uma determinada classe existe apenas para o modo offline e não deve ser estendida.)

Assim como você contrataria um novo membro de equipe altamente capacitado, trabalhamos com a Codex para criar um plano de implementação sólido. Esse plano muitas vezes se assemelhava a um documento de projeto em miniatura, indicando quais arquivos deveriam ser alterados, quais novos estados deveriam ser introduzidos e como a lógica deveria fluir. Só então pedimos à Codex que começasse a aplicar o plano, um passo de cada vez. Uma dica útil: para tarefas muito longas, em que atingimos o limite da nossa janela de contexto, podemos pedir ao Codex para salvar seu plano em um arquivo, permitindo-nos aplicar a mesma direção em várias instâncias.

Essa etapa extra de planejamento acabou valendo a pena. Isso nos permitiu deixar o Codex rodando "sem supervisão" por longos períodos, porque conhecíamos seus planos. Isso facilitou a revisão de código, porque podíamos verificar a implementação em relação ao nosso plano, em vez de ler uma diferença sem contexto. E quando algo dava errado, podíamos depurar primeiro o plano e depois o código. 

A dinâmica era semelhante à forma como um bom documento de design transmite confiança ao líder técnico em um projeto. Não estávamos apenas gerando código: estávamos produzindo código que dava suporte a um roteiro compartilhado.

No auge do projeto, frequentemente executávamos várias sessões do Codex em paralelo. Um trabalhava na reprodução, outro na busca, outro no tratamento de erros e, às vezes, outro em testes ou refatorações. A sensação era menos de estar usando uma ferramenta e mais de estar gerenciando uma equipe.

Cada sessão nos enviaria relatórios periódicos sobre o progresso. Alguém poderia dizer: "Terminei de planejar este módulo; aqui está o que proponho", enquanto outro ofereceria uma grande alteração para um novo recurso. Cada um deles exigia atenção, feedback e revisão. Era incrivelmente semelhante a ser um líder técnico com vários engenheiros novos, todos progredindo, todos precisando de orientação.

O resultado foi um fluxo colaborativo. A capacidade de codificação direta do Codex nos libertou de muita digitação manual. Tivemos mais tempo para pensar na arquitetura, ler atentamente os pedidos de pull request e testar o aplicativo. 

Ao mesmo tempo, essa velocidade extra significava que sempre tínhamos algo aguardando em nossa fila de revisão. O Codex não foi bloqueado pela troca de contexto, mas nós fomos. Nosso gargalo no desenvolvimento mudou de escrever código para tomar decisões, dar feedback e integrar mudanças.

É aqui que as ideias de Brooks se aplicam de uma nova maneira. Não se pode simplesmente adicionar sessões do Codex e esperar ganhos de velocidade lineares, assim como não se pode continuar adicionando engenheiros a um projeto e esperar que o cronograma diminua linearmente. Cada "par de mãos" adicional, mesmo que virtuais, aumenta a dificuldade de coordenação. Tínhamos nos tornado o maestro de uma orquestra, em vez de simplesmente músicos solistas mais rápidos.

Começamos nosso projeto com um grande passo: o Sora já havia sido lançado para iOS. Frequentemente, direcionávamos o Codex para as bases de código do iOS e do backend para ajudá-lo a entender os principais requisitos e restrições. Ao longo do projeto, brincamos que havíamos reinventado a ideia de um framework multiplataforma. Esqueça React Native ou Flutter; o futuro da multiplataforma é simplesmente o Codex.

Por trás da piada, existem dois princípios:

1. Logic é portátil. Seja o código escrito em Swift ou Kotlin, a lógica subjacente do aplicativo – modelos de dados, chamadas de rede, regras de validação, lógica de negócios – é a mesma. O Codex é muito bom em ler uma implementação em Swift e produzir um equivalente em Kotlin que preserva a semântica.
2. Exemplos concretos fornecem um contexto poderoso. Uma nova sessão do Codex que mostre "como isso funciona exatamente no iOS" e "a arquitetura do Android" é muito mais eficaz do que uma que se baseia apenas em descrições em linguagem natural.

Colocando esses princípios em prática, disponibilizamos os repositórios de iOS, backend e Android no mesmo ambiente. Fornecemos prompts ao Codex como:

“Leia esses modelos e endpoints no código iOS e, em seguida, proponha um plano para implementar o comportamento equivalente no Android usando nosso cliente de API e classes de modelo existentes.”

Um truque pequeno, mas útil, foi detalhar em ~/.codex/AGENTS.md onde os repositórios locais estavam localizados e o que eles continham. Isso facilitou para o Codex descobrir e navegar pelo código relevante.

Estávamos efetivamente realizando desenvolvimento multiplataforma por meio de tradução, em vez de abstração compartilhada. Como a Codex cuidou da maior parte da tradução, evitamos dobrar os custos de implementação.

A lição mais ampla é que, para o Codex, o contexto é tudo. A Codex apresentou seu melhor desempenho quando compreendeu como o recurso já funcionava no iOS, juntamente com o conhecimento da estrutura do nosso aplicativo para Android. Quando o Codex não tinha esse contexto, não estava "se recusando a cooperar"; estava apenas supondo. Quanto mais o tratávamos como um novo membro da equipe e investíamos em fornecer os parâmetros corretos, melhor era seu desempenho.

Ao final do nosso sprint de quatro semanas, usar o Codex deixou de parecer um experimento e se tornou nosso ciclo de desenvolvimento padrão. Usamos essa ferramenta para entender o código existente, planejar mudanças e implementar funcionalidades. Analisamos o resultado da mesma forma que analisaríamos o de um colega de equipe. Era simplesmente a forma como distribuíamos o software.

Ficou claro que o desenvolvimento assistido por IA não reduz a necessidade de rigor; pelo contrário, aumenta-a. Por mais competente que o Codex seja, seu objetivo é ir do ponto A ao ponto B, agora. É por isso que a programação assistida por IA não funciona sem humanos. Os engenheiros de software conseguem compreender e aplicar as restrições do mundo real dos sistemas, as melhores práticas de arquitetura de software e como desenvolver considerando planos futuros de desenvolvimento e produto. As grandes habilidades do engenheiro de software do futuro serão o profundo conhecimento de sistemas e a capacidade de trabalhar em colaboração com IA em longos períodos de tempo. 

As partes mais interessantes da engenharia de software são a criação de produtos atraentes, o design de sistemas escaláveis, a escrita de algoritmos complexos e a experimentação com dados, padrões e código. No entanto, a realidade da engenharia de software, tanto do passado quanto do presente, costuma ser mais prosaica: centralizar botões, conectar dispositivos e escrever código repetitivo. Agora, o Codex torna possível focar nas partes mais significativas da engenharia de software e nos motivos pelos quais amamos nossa profissão.

Uma vez que o Codex esteja configurado em um ambiente rico em contexto, onde ele entenda seus objetivos e sua forma de trabalhar, qualquer equipe poderá multiplicar suas capacidades. Nossa abordagem de lançamento não é uma fórmula única e não afirmamos ter resolvido o problema do desenvolvimento assistido por IA. Mas esperamos que nossa experiência facilite a busca pelas melhores maneiras de capacitar o Codex para que você também possa se capacitar. 

Quando o Codex foi lançado em versão prévia para pesquisa, há sete meses, a engenharia de software era muito diferente. Por meio do Sora, pudemos explorar o próximo capítulo da engenharia. À medida que nossos modelos e sistemas de automação continuam a melhorar, a IA se tornará uma parte cada vez mais indispensável da construção. 

O que você criará com sua própria equipe do Codex?