Como usámos o Codex para criar o Sora para Android em 28 dias

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

Em novembro, lançámos a aplicação Sora para Android, oferecendo a qualquer pessoa com um dispositivo Android a possibilidade de transformar um curto prompt num vídeo vibrante. No dia do lançamento, a aplicação alcançou o primeiro lugar na Play Store. Os utilizadores 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 da aplicação Android do Sora foi criada em 28 dias, graças ao mesmo agente disponível para qualquer equipa ou programador: o Codex.

De 8 de outubro a 5 de novembro de 2025, uma equipa de engenharia reduzida, a trabalhar em conjunto com o Codex e a consumir aproximadamente 5 mil milhões de tokens, lançou o Sora para Android, desde o protótipo até ao lançamento global. Apesar da sua escala, a aplicação tem uma taxa de 99,9% de ausência de falhas e uma arquitetura da qual nos orgulhamos. Se estás a perguntar-te se usámos um modelo secreto, usámos uma versão inicial do modelo GPT‑5.1‑Codex – a mesma versão que qualquer programador ou empresa pode utilizar hoje através da CLI, extensão IDE ou aplicação web.

Quando o Sora foi lançado para iOS, a sua utilização explodiu. As pessoas começaram imediatamente 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 utilizadores pré-registados no Google Play.

Uma resposta comum a um lançamento de alto risco e com prazos apertados é acumular recursos e adicionar processos. Uma aplicação de produção com esta abrangência e qualidade envolveria normalmente muitos engenheiros a trabalhar durante meses, atrasados pela necessidade de coordenação. 

O arquiteto informático norte-americano Fred Brooks alertou, em tempos, que "adicionar mais pessoas a um projeto de software atrasado só o atrasa ainda mais". Por outras palavras, ao tentar entregar um projeto complexo rapidamente, a adição de mais engenheiros pode muitas vezes 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 esta perceção, demos-lhe atenção e reunimos uma equipa sólida de quatro engenheiros, todos equipados com o Codex para aumentar drasticamente o impacto de cada um. 

Desta forma, conseguimos distribuir uma versão interna do Sora para Android aos colaboradores em 18 dias e lançá-la publicamente 10 dias depois. Mantivemos um padrão elevado nas práticas de engenharia do Android, investimos na facilidade de manutenção e exigimos da aplicação o mesmo nível de fiabilidade que esperaríamos de um projeto mais tradicional. (Atualmente continuamos a utilizar o Codex extensivamente para evoluir e trazer novas funcionalidades para a aplicação).

Para compreender como trabalhamos com o Codex, é útil saber onde se destaca e onde necessita de melhorias. Tratá-lo 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 rever o código do que a escrevê-lo nós próprios.

Onde o Codex precisa de orientação

1. O Codex ainda não é muito bom a inferir o que não lhe foi dito (por exemplo, os seus padrões de arquitetura preferidos, estratégia de produto, comportamento real do utilizador e normas ou atalhos internos).
2. Da mesma forma, o Codex não conseguia ver a aplicação em execução: não conseguia abrir o Sora num dispositivo, perceber que um scroll era estranho ou sentir que um fluxo era confuso. Só a nossa equipa poderia realizar essas tarefas práticas.
3. Cada instância requer integração. Partilhar 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 utilizador uma lógica que claramente pertencia a um repositório. O seu instinto é fazer com que algo funcione, não priorizar a limpeza a longo prazo.

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

Onde o 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 a utilização dos mesmos conceitos em várias plataformas sem abstrações complexas.
2. Cobertura de testes: o Codex demonstra um entusiasmo (singular) pela criação de testes unitários que cubram uma grande variedade de casos. Nem todos os testes foram aprofundados, mas ter uma cobertura alargada foi útil para evitar regressões. 
3. Aplicação de feedback: de forma semelhante, o Codex é bom a reagir ao feedback. Quando a CI falhava, podíamos colar a saída do registo num prompt e pedir ao Codex para sugerir correções.
4. Execução paralela e descartável massiva: a maioria não explorará os limites do número de sessões que podem ser executadas em simultâneo. É perfeitamente viável testar várias ideias em paralelo e encarar o código como descartável.
5. Proposta de uma nova perspetiva: nas discussões de design, utilizámos o Codex como uma ferramenta generativa para explorar potenciais pontos de falha e descobrir novas formas de resolver um problema. Por exemplo, enquanto desenhávamos otimizações de memória para leitores de vídeo, o Codex analisou vários SDKs para propor abordagens que não teríamos tido tempo de analisar. Os insights da pesquisa do Codex revelaram-se inestimáveis para minimizar o uso de memória na aplicação final.
6. Possibilitar um trabalho de maior impacto: na prática, acabámos por despender mais tempo a rever e a orientar o código do que a escrevê-lo nós próprios. Dito isto, o Codex também é muito bom na revisão de código, detetando frequentemente erros antes de serem incorporados, melhorando assim a fiabilidade.

Assim que reconhecemos estas características, o 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 âmbitos bem delimitados, enquanto a nossa equipa se concentrava na arquitetura, experiência do utilizador, mudanças sistémicas e qualidade final.

Mesmo o melhor colaborador recém-contratado, em cargo sénior, não possui a perspetiva adequada para tomar decisões a longo prazo no imediato. Para tirar partido do Codex e garantir que o seu trabalho era robusto e de fácil manutenção, foi fundamental supervisionarmos o design dos sistemas da aplicação e os principais compromissos. Isto incluiu moldar a arquitetura da aplicação, modularização, injeção de dependências e navegação. Também implementámos autenticação e fluxos básicos de rede. 

Partindo desta base, desenvolvemos algumas funcionalidades representativas do início ao fim. Utilizámos as regras que queríamos que toda a base de código seguisse e documentámos os padrões do projeto à medida que avançávamos. Ao direcionar o Codex para funcionalidades representativas, ele conseguiu trabalhar de forma mais independente dentro dos nossos padrões. Para um projeto que estimamos ter sido redigido em 85% pela Codex, uma base cuidadosamente planeada evitou custos elevados com retrocessos e correções. Foi uma das decisões mais importantes que tomámos. 

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

Para ver o que aconteceria, tentámos executar o seguinte prompt: "Cria a aplicação Sora para Android com base no código do iOS. Vai", mas rapidamente abandonámos essa ideia. Embora a criação do Codex funcionasse tecnicamente, a experiência do produto era inferior. E sem uma compreensão clara dos pontos de acesso, dados e fluxos de utilizadores, o código de execução única do Codex era pouco fiável (mesmo sem utilizar um agente, é arriscado fundir milhares de linhas de código). 

A nossa hipótese era que o Codex prosperaria num ambiente repleto de exemplos bem escritos - e estávamos certos. Pedir ao Codex para "construir este ecrã de definições" quase sem contexto era algo pouco fiável. Pedir à Codex para "construir este ecrã de definições usando a mesma arquitetura e padrões deste outro ecrã que acabaste de ver" funcionou muito melhor. Os humanos tomaram as decisões estruturais e definiram as invariantes; o Codex preencheu então grandes quantidades de código dentro desta estrutura.

O nosso passo seguinte para maximizar o potencial do Codex foi descobrir como permitir que funcionasse durante 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 ficheiros. Por favor, constrói-o". Às vezes, isto funcionava, mas na maioria das vezes produzia código que tecnicamente compilava, embora se desviasse da nossa arquitetura e objetivos.

Por isso, mudámos o fluxo de trabalho. Para qualquer alteração que não fosse trivial, primeiro pedíamos ao Codex que nos ajudasse a perceber como o sistema e o código funcionavam. Por exemplo, poderíamos pedir-lhe que lesse um conjunto de ficheiros relacionados e resumisse o funcionamento desta funcionalidade. 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 utilizador. Em seguida, corrigiríamos ou melhoraríamos a sua compreensão. (Por exemplo, poderíamos salientar que uma determinada abstração pertence, na realidade, a uma camada diferente ou que uma determinada classe existe apenas para o modo offline e não deve ser estendida.)

Tal como faríamos para contratar um novo membro da equipa altamente capacitado, trabalhámos com o Codex para criar um plano de implementação sólido. Este plano assemelhava-se muitas vezes a um documento de projeto em miniatura, indicando quais os ficheiros que deveriam ser alterados, quais os novos estados que deveriam ser introduzidos e como a lógica deveria fluir. Só então pedimos ao 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, pediríamos ao Codex para guardar o seu plano num ficheiro, permitindo-nos aplicar a mesma direção em várias instâncias.

Esta etapa extra de planeamento acabou por valer a pena. Permitiu-nos deixar o Codex a correr "sem supervisão" por longos períodos, porque conhecíamos os seus planos. Isto facilitou a revisão de código, porque podíamos verificar a implementação em relação ao nosso plano, em vez de ler um diff sem contexto. E quando algo corria mal, 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 num projeto. Não estávamos só a gerar código: estávamos a produzir código que suportava um guião partilhado.

No auge do projeto, executávamos frequentemente várias sessões do Codex em paralelo. Um trabalhava na reprodução, outro na pesquisa, outro no tratamento de erros e, por vezes, outro em testes ou correções. A sensação era menos de estar a utilizar uma ferramenta e mais de estar a gerir uma equipa.

Cada sessão enviava-nos relatórios periódicos sobre o progresso. Alguém poderia dizer: "Terminei de planear este módulo; eis o que proponho", enquanto outro ofereceria uma grande alteração para uma nova funcionalidade. Cada um exigia atenção, feedback e revisão. Era incrivelmente semelhante a ser um líder técnico com vários engenheiros novos, todos a progredir, todos a precisar de orientação.

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

Ao mesmo tempo, essa velocidade extra significava que tínhamos sempre algo à espera na nossa fila de revisão. O Codex não ficou bloqueado pela mudança de contexto, mas nós ficámos. O nosso estrangulamento no desenvolvimento mudou da escrita de código para a tomada de decisões, o feedback e a integração de mudanças.

É aqui que as ideias de Brooks se aplicam de uma nova forma. Não se pode simplesmente adicionar sessões do Codex e esperar ganhos de velocidade lineares, tal como não se pode continuar a adicionar 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ínhamo-nos tornado o maestro de uma orquestra, em vez de músicos solistas mais rápidos.

Começámos o nosso projeto com um enorme trampolim: o Sora já tinha sido lançado para iOS. Direcionávamos frequentemente o Codex para as bases de código do iOS e do backend para o ajudar a compreender os principais requisitos e restrições. Ao longo do projeto, brincávamos que tínhamos reinventado a ideia de uma estrutura multiplataforma. Esquece o React Native ou o Flutter; o futuro do desenvolvimento multiplataforma é simplesmente o Codex.

Por detrás da piada, estão dois princípios:

1. A lógica é portátil. Independentemente de o código ser escrito em Swift ou Kotlin, a lógica subjacente da aplicação – modelos de dados, chamadas de rede, regras de validação, lógica de negócio – é a mesma. O Codex é muito bom a ler uma implementação em Swift e a produzir um equivalente em Kotlin que preserva a semântica.
2. Exemplos concretos dão um contexto poderoso. Uma nova sessão do Codex que mostre "como é que isto 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 estes princípios em prática, disponibilizámos os repositórios iOS, backend e Android no mesmo ambiente. Demos ao Codex prompts como:

“Lê estes modelos e endpoints no código iOS e depois propõe um plano para implementar o comportamento equivalente no Android utilizando o nosso cliente da API e as classes de modelo existentes.”

Um pequeno truque, mas útil, foi detalhar em  ~/.codex/AGENTS.md onde se encontravam os repositórios locais e o que continham. Isto tornou mais fácil para o Codex descobrir e navegar pelo código relevante.

Estávamos efetivamente a realizar desenvolvimento multiplataforma através de tradução, em vez de abstração partilhada. Como a Codex tratou da maior parte da tradução, evitámos duplicar os custos de implementação.

A lição mais ampla é que, para o Codex, o contexto é tudo. O Codex apresentou o seu melhor desempenho quando compreendeu como a funcionalidade já funcionava no iOS, juntamente com a compreensão da estrutura da nossa aplicação para Android. Quando o Codex não tinha este contexto, não estava a "recusar-se a cooperar"; estava só a adivinhar. Quanto mais o tratávamos como um novo membro da equipa e investíamos em dar-lhe as entradas certas, melhor era o seu desempenho.

No final do nosso sprint de quatro semanas, a utilização do Codex deixou de parecer uma experiência e passou a ser o nosso ciclo de desenvolvimento padrão. Usámo-lo para compreender o código existente, planear alterações e implementar funcionalidades. Analisámos o resultado da mesma forma que analisaríamos o de um colega de equipa. 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, o 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 criar considerando os planos de desenvolvimento e de produto futuros. Os superpoderes do engenheiro de software do futuro serão o profundo conhecimento dos sistemas e a capacidade de trabalhar em colaboração com a 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 como do presente, é muitas vezes mais prosaica: centrar botões, ligar pontos de acesso e escrever código repetitivo. Agora, o Codex possibilita focarmo-nos nas partes mais significativas da engenharia de software e nas razões pelas quais amamos a nossa profissão.

Uma vez configurado num ambiente rico em contexto, onde compreenda os seus objetivos e a sua forma de trabalhar, qualquer equipa poderá multiplicar as capacidades do Codex. A nossa visão 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 a nossa experiência torne mais fácil encontrar as melhores formas de capacitar o Codex, para que também se possa capacitar. 

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

O que vais criar com a tua própria equipa de Codex?