- O OpenAI Codex é um agente de código multitarefa com integração ao GitHub, oferecendo uma interface que permite instruir várias tarefas em paralelo por meio de linguagem natural
- O usuário pode despejar rapidamente o trabalho do dia e delegar até a criação automática de branches e a abertura de PRs, além de poder usá-lo no celular, o que pode viabilizar, no fim das contas, um fluxo de trabalho centrado em trabalho remoto
- No entanto, hoje ele ainda apresenta problemas como tratamento de erros insuficiente, qualidade de código instável, dificuldade para atualizar branches existentes e bloqueio de rede no sandbox, o que o torna inadequado para tarefas principais de refatoração
- O Codex é útil para automatizar pequenas tarefas de manutenção e é prático para processar rapidamente trabalhos repetitivos
- No futuro, se houver melhorias no modelo, mistura de múltiplos modelos e recursos avançados de integração, ele poderá evoluir para uma ferramenta de orquestração de alto nível
Como o OpenAI Codex funciona
- O OpenAI Codex tem uma UI baseada em chat e pode ser acessado por convite ou por meio da assinatura Pro de US$ 200/mês
- O usuário precisa passar por autenticação multifator e aprovar o app do Codex no GitHub para cada organização; o Codex então clona o repositório para seu próprio sandbox e executa comandos, além de criar branches em nome do usuário
- Para quem gerencia dezenas de repositórios públicos e privados, ele se destaca pela eficiência em alternar entre vários projetos e administrar filas de tarefas
- Se você administra apenas 1 ou 2 repositórios, usar um LLM tradicional ou um editor com recursos de IA pode ser uma opção mais leve
Pontos fortes do Codex
-
Processamento paralelo de múltiplas tarefas e interface
- É possível definir repositório e branch por tarefa, então faz sentido registrar em paralelo, em linguagem natural, todo o trabalho do dia
- O Codex incentiva o processamento simultâneo de várias tarefas, e isso combina bem com esse estilo de trabalho
-
Fluxo de trabalho flexível e suporte a mobile
- O Codex funciona de forma amigável para dispositivos móveis, inclusive no smartphone, o que aumenta o potencial de trabalho eficiente fora do escritório
- A ideia é iniciar o dia registrando várias tarefas e continuar gerenciando planos e progresso mesmo em deslocamento ou ao ar livre
-
Feedback baseado em chat e criação de PR
- É fácil consultar logs e status das tarefas em andamento pela interface de chat, e também é possível enviar instruções adicionais
- Se as mudanças forem satisfatórias, o Codex cria um Pull Request (doravante PR) e completa automaticamente a descrição
- Também é positivo poder verificar os logs de execução e o histórico de comandos em cada etapa
Pontos que precisam melhorar
-
Tratamento de erros insuficiente
- A usabilidade cai por falta de feedback claro quando há falha ao iniciar uma tarefa ou gerar um PR
-
Qualidade do código e execução de tarefas pontuais
- O modelo do Codex é da linha GPT-3 e oferece suporte a mais de 12 linguagens, mas em execução paralela o nível de satisfação fica em torno de 40% a 60%
- Ele é útil para tarefas pequenas de manutenção, mas em refatorações de grande porte a eficiência cai por conta da geração repetitiva de PRs
-
Falta de suporte a atualizações contínuas na mesma branch
- Como é difícil encadear commits continuamente em PRs e branches existentes, trabalhos de refatoração em várias etapas ficam ineficientes
- Por enquanto, o Codex é mais adequado para tarefas simples que possam ser passadas e resolvidas diretamente em uma única execução
-
Restrições de acesso à rede no sandbox de execução
- Por projeto, não há acesso à rede externa, o que limita várias tarefas reais de trabalho, como atualização de pacotes e tratamento de dependências
- Ex.: ao pedir a instalação de um pacote externo, isso não funciona
- Esse tipo de trabalho ainda precisa ser feito localmente ou depender de bots existentes, como o Dependabot
Did it unlock insane productivity gains for me?
- Ainda não houve uma sensação de ganho explosivo de produtividade
- Para que o Codex realmente leve a uma revolução de produtividade, será necessário:
- melhorar o design e os algoritmos para permitir que mais tarefas sejam resolvidas de uma vez só
- melhorar o fluxo de atualização de PRs em branches existentes
- fortalecer a capacidade de delegação e gestão integrada, além de expandir a integração com várias APIs da OpenAI
- fazer com que o Codex evolua para um orquestrador de alto nível
- Hoje, o Codex é especialmente útil para automatizar manutenção rotineira e pequenas atualizações
- Para desenvolvimento de grandes funcionalidades e refatorações, a colaboração entre IDE e suporte de LLM ainda é mais adequada
Considerações finais
- O Codex é uma ferramenta discreta, mas promissora
- Considerando os recursos que ainda devem amadurecer, há grande chance de ele se firmar como ponto de partida e ferramenta de coordenação do trabalho
- Neste momento, é hora de focar em tarefas leves e repetitivas enquanto se espera por melhorias
3 comentários
Parece que ainda não é um clima de gastar 200 dólares nisso.
Comentários do Hacker News
Eu era assinante Plus e fiz upgrade para o Pro para testar o Codex, mas, honestamente, minha experiência foi um tanto decepcionante
A UX ainda parece não estar bem acertada, e é frustrante não saber quanto tempo vai levar para sair um resultado
A parte menos ruim é que, graças à natureza assíncrona do Codex, dá para rodar várias tarefas ao mesmo tempo
Outra reclamação minha é que, para essa ferramenta ser útil, é preciso definir um ambiente à parte
Como não dá para subir os containers necessários para os testes, a utilidade cai bastante
O ambiente é completamente isolado da internet, então o uso fica limitado
O motivo de o o3 do ChatGPT ser tão forte é que ele consegue usar a web e buscar informações por conta própria, e o Codex deixa a desejar nisso
Em comparação, também uso bastante o Claude e, quando crio um projeto usando um repositório do GitHub como fonte, ele encontra bem até bugs desconhecidos em apps React complexos
O Gemini também dá bom suporte a esse tipo de recurso por ter uma janela de contexto grande
Claro, eu entendo o que a OpenAI está tentando fazer
Eu queria que o Codex realmente resolvesse várias tarefas como um colega de equipe, mas, neste momento, parece focado demais em pull requests
Então vou voltar para o Plus e observar mais um pouco
Eu trabalho na OpenAI, mas não no time do Codex, e já usei o Codex com sucesso em vários projetos
Meu jeito de trabalhar é o seguinte
Sempre executo o mesmo prompt várias vezes para obter resultados diferentes
Comparo várias implementações para encontrar a melhor e penso em como eu poderia ter mudado o prompt para induzir um resultado melhor
Corrijo no prompt os pontos em que o modelo errou e aplico isso de forma iterativa
Se você quebrar o trabalho em unidades pequenas e repetir experimentos em paralelo desse jeito, até projetos grandes podem ser concluídos em poucas horas só com ajuste de prompt e revisão de código
Isso é muito útil não só para trabalho de conversão de API, mas também para código mais profundo, como kernels Triton
"Escolho a melhor entre várias implementações e penso no que mais eu deveria ter feito no prompt para chegar a um resultado melhor"
Fico curioso sobre como pessoas não especialistas distinguem o que é 'melhor'
No fim, para encontrar a direção correta, ainda é preciso ter especialização naquele domínio, e acho que isso mostra por que LLMs não vão eliminar os empregos de engenharia de software
Acho que esse jeito manual de trabalhar pode, na prática, virar a base de aprendizado por reforço (RL)
Com um pequeno ajuste nessa experiência da UI para usar dados reais, parece que daria para gerar um bom dataset de treinamento
Tenho curiosidade de saber o quanto isso é realmente mais rápido do que escrever código diretamente
Tenho curiosidade se, quando você muda bastante o prompt, às vezes acaba descartando o trabalho feito até ali
Parece ainda mais difícil quando pequenas mudanças têm grande impacto no resultado e o problema não tem exemplos prévios
Se esse fluxo de trabalho se repetir muitas vezes, acho que ele pode acabar sendo cansativo ou até te afastando do que realmente importa
Para mim pode soar ineficiente, então fico curioso se outras pessoas simplesmente têm mais tolerância para esse tipo de repetição
Compartilhei no pod uma análise do Codex com meu time (https://latent.space/p/codex)
É um modelo excelente para gerar código de uma vez só de ponta a ponta (no pod foi confirmado que ele foi especialmente fine-tuned para tarefas SWE da OpenAI em modo oneshot)
Em comparação, faltam recursos de integração (por exemplo: não há integração com navegador e a integração com GitHub é fraca — como ele pede para abrir um novo pull request a cada iteração, é incômodo adicionar commits posteriores no branch existente, então isso me incomoda)
Ainda assim, espero que esses recursos de integração melhorem com o tempo
O fato de dar para rodar 60 instâncias simultâneas de Codex por hora me parece uma diferença qualitativa em relação ao Devin (5 simultâneas) ou ao Cursor (1 simultânea antes dos agentes em segundo plano)
Eu não senti uma diferença de desempenho do modelo Codex de forma muito clara, mas, embora a OpenAI explique que o Codex deriva do GPT-3, na prática ele é um fine-tuning do o3
Acho que a própria afirmação de “fine-tuning do o3” pode confundir
A OpenAI também cria confusão com suas convenções de nomenclatura, e isso é algo que a maioria das empresas de IA enfrenta
O Codex originalmente era um modelo antigo baseado em GPT-3, e agora o mesmo nome está sendo reutilizado em vários lugares, como CLI e ferramentas
O Google faz exatamente a mesma coisa ao usar “Gemini Ultra” tanto como nome de modelo quanto de assinatura, o que também gera confusão
Para mim, a parte mais incômoda é a limitação de acesso à rede
git fetch, sincronizar com upstream nem corrigir bugs de integraçãoParece que até bloquearam domínios, porque nem
apt installfunciona no script de setupO agente também parece tender a começar com
git grepem vez de entender o contexto completo do código (dá para ver isso na UI), então fiquei com uma impressão apenas medianaTenho curiosidade sobre em que ele difere do Claude Code
Acho muito legal a capacidade de alterar rapidamente vários repositórios
Eu mantenho junto um monte de apps de exemplo, e mudar formato de README ou trocar links fica muito chato quando precisa repetir isso em mais de 20 lugares
Se eu puder deixar esse trabalho mecânico com o Codex e depois só apertar o botão de merge, vou ficar muito feliz
Imagino que ele evolua para isso em breve
Por enquanto, acho que vou espalhar pequenas tarefas de manutenção com o Codex e continuar fazendo refatorações grandes ou desenvolvimento importante no IDE
Tenho curiosidade se esse tipo de ferramenta pode ser usado por não desenvolvedores para fazer mudanças em código
Alterações de conteúdo ou mudanças simples de CSS eu realmente não quero fazer na mão, e como o teste pode ser só visual, para mim bastaria fazer code review
Um não desenvolvedor olha o ticket, inicia o trabalho, e no fim só diz “isso parece bom”, e eu reviso
Acho que seria um fluxo de trabalho ideal para bugs pequenos e melhorias de funcionalidade no backlog
Acho que ferramentas como AI Assist podem acabar virando a melhor plataforma low-code possível
Às vezes até penso se não vai chegar o dia em que engenheiros de software serão realmente substituídos
Mas até mudanças de conteúdo muitas vezes exigem reflexão profunda
Basta ter um pouco de escala para existirem dependências para cima e para baixo, e mesmo adicionar um único campo faz o sistema inteiro precisar prestar atenção em várias coisas
Até mudanças pequenas de CSS parecem triviais, mas o usuário dificilmente sabe o quão pequenas elas realmente são
Você também vai aprender rápido sobre uma infinidade de questões como acessibilidade e multiplataforma (mobile/desktop)
Dá até para ver esse movimento como um funil que leva pessoas a entrarem na engenharia de software
Em tarefas pequenas, acho que uma taxa de sucesso de 40~60% já é bem razoável
É útil saber que ele tem dificuldade em tarefas mais complexas e que exigem lógica mais profunda
O desempenho atual está no nível de um engenheiro júnior muito ruim
Por exemplo, ao pedir uma mudança, ele alterou em massa valores de classes para nullable só para eliminar warnings do compilador
Por fora parecia funcionar e até compilava, mas o resultado era totalmente errado e destruía a integridade dos dados
Há vários casos assim
Se você deixar um codebase inteiro nas mãos do Codex sem supervisão, acho que a dívida técnica vai se acumular muito rápido
Acho otimista demais esperar que o Codex vá nos ajudar a trabalhar bem enquanto estamos longe da mesa
Para muita gente, “trabalhar de forma eficaz mesmo quando você está ausente” toca diretamente na ideia de “fila do desemprego”
Acho curioso que desenvolvedores estejam animados com esse tipo de mudança
Me surpreende esse clima de achar que um dia vamos simplesmente sentar e assistir aos agentes fazerem tudo enquanto continuamos recebendo salário
Mesmo que o trabalho fique mais fácil, o rumo provável no fim é o desaparecimento do próprio emprego
Na história do aumento de produtividade, quase não há precedentes de trabalhadores ganharem mais tempo livre
O padrão costuma ser: mais lucro para acionistas e executivos, metade da equipe restante fazendo mais trabalho, e o resto desempregado
Acho que, por um tempo, ainda vai demorar até chegar ao desemprego em massa
Para esses modelos fazerem corretamente 90~95% de uma ampla categoria de tarefas, vai ser preciso um esforço enorme
Porque os primeiros 60~70% de qualquer coisa até podem ser fáceis, mas os últimos 5~10% são realmente difíceis
Como foi mencionado acima, hoje em dia é muito caro executar várias vezes, obter resultados diversos e escolher entre eles, e também há o problema de o custo de inferência ficar alto se isso for aplicado de forma generalizada a todo tipo de trabalho
Em algum momento, code review vai passar a ser obrigatório justamente porque o código foi escrito por máquina
Em projetos pequenos ou funcionalidades de menor porte, talvez dê para confiar no trabalho da máquina, mas, em codebases que vão ser mantidos por muito tempo, humanos ainda terão de continuar fazendo arquitetura e revisão
A IA pode ajudar a explorar diferentes caminhos mais rápido, mas a decisão final ainda é humana, e a qualidade ainda precisa ser mantida por meio de design ou revisão direta
No futuro próximo, as equipes de engenharia provavelmente vão buscar maneiras de usar agentes em segundo plano de forma agressiva
Sou cético quanto ao modelo atual de terceirizar tudo para um modelo poderoso
O trabalho atual de code review com IA é bem frustrante, então precisamos de um workflow melhor
Por alguns anos, o próprio conceito de ‘agente em segundo plano’ deve se firmar como infraestrutura indispensável em cada empresa
A maioria das empresas provavelmente vai consumir esse tipo de infraestrutura de agentes via API em vez de hospedá-la diretamente
A infraestrutura de engenharia baseada em agentes ainda está em um estágio extremamente inicial, então também deve haver muitas novas oportunidades de trabalho nessa área (nos próximos 3~5 anos)
Numa visão otimista, também existe o fato de que, quanto mais barato fica criar algo (como código), maior tende a ser a demanda por aquilo
É possível que não desenvolvedores atuem como gestores, mas, pela minha experiência, quanto mais importante é uma tarefa, mais as pessoas tendem a querer confiá-la a alguém mais confiável (humano)
Acho que dá para comparar desenvolvedores de software a cavalos, e novos agentes de modelo como Codex ou Claude Code a automóveis
Fico pensando se faz sentido o enquadramento em que alguns cavalos viram motoristas de carro e outros ficam desempregados porque não precisam mais puxar carroças
Não consegui encontrar um lugar com a lista de linguagens suportadas
Isso não aparece direito nem na apresentação oficial nem nos reviews, e quase sempre só explicam com exemplos como corrigir typos em páginas web
Parece algo que daria para montar rapidinho com gptel-tool em uma semana
Então é bom para usar como faz-tudo!