- Um experimento de um produto interno em beta com a restrição fixa de 0 linhas de código escritas manualmente, no qual o Codex escreveu a lógica da aplicação, testes, configuração de CI, documentação, observabilidade e até ferramentas internas
- Começando de um repositório git vazio, a base de código chegou a cerca de 1 milhão de linhas em aproximadamente 5 meses, com alta taxa de PRs: três engenheiros operando o Codex abriram e mesclaram cerca de 1.500 PRs
- O trabalho principal do engenheiro deixou de ser escrever código e passou a ser projetar o ambiente, especificar intenções e construir loops de feedback para fazer os agentes trabalharem de forma confiável
- O conhecimento do repositório é gerido com um
AGENTS.mdcurto,docs/estruturado, planos de execução, lint e CI, enquanto UI, logs, métricas e traces foram transformados em legibilidade da aplicação que o Codex pode ler e validar diretamente - Com o aumento de throughput, minimizar os gates de merge e corrigir com base em execuções subsequentes tornou-se uma escolha prática, mas a consistência arquitetural de longo prazo e a codificação do julgamento humano ainda são temas em aprendizado
Beta interno criado com 0 linhas de código escritas manualmente
- Nos últimos 5 meses, foi conduzido um experimento para construir e lançar um produto interno de software em beta com 0 linhas de código escritas manualmente
- O produto tem usuários internos diários e testadores alfa externos, e já passa na prática por fluxos de lançamento, deploy, incidentes e correções
- Cada linha de código — da lógica da aplicação e testes até configuração de CI, documentação, observabilidade e ferramentas internas — foi escrita pelo Codex, com a estimativa de que tudo foi construído em cerca de 1/10 do tempo necessário para escrever o código manualmente
- Humanos pilotam, agentes executam
- Era preciso lançar em poucas semanas um resultado que acabaria chegando à escala de 1 milhão de linhas, e por isso o trabalho principal da equipe de engenharia migrou de escrever código para projetar o ambiente, especificar intenções e construir loops de feedback
Começando de um repositório git vazio
- O primeiro commit do repositório vazio aconteceu no fim de agosto de 2025
- A estrutura inicial do repositório, configuração de CI, regras de formatação, configuração do gerenciador de pacotes e framework da aplicação foram gerados pelo Codex CLI usando GPT-5, com orientação de partes de templates existentes
- O arquivo inicial
AGENTS.md, que orienta como os agentes devem trabalhar no repositório, também foi escrito pelo Codex - Não havia código legado escrito por humanos sustentando o sistema; o repositório foi moldado por agentes desde o início
- Cinco meses depois, o repositório chegou a cerca de 1 milhão de linhas entre lógica da aplicação, infraestrutura, ferramentas, documentação e utilitários internos para desenvolvedores
- Três engenheiros operando o Codex abriram e mesclaram cerca de 1.500 PRs, o que equivale a uma média de 3,5 PRs por dia por engenheiro
- Mesmo depois de a equipe crescer para sete engenheiros, o throughput continuou aumentando
- O resultado não é produção por produção: o produto é usado por centenas de usuários internos, incluindo power users internos
- Ao longo de todo o processo de desenvolvimento, humanos não contribuíram código diretamente, e nenhum código escrito manualmente é a filosofia central da equipe
Redefinindo o papel do engenheiro
- A restrição de humanos não codificarem diretamente introduziu um tipo diferente de trabalho de engenharia, focado em sistemas, scaffolding e alavancagem
- O progresso inicial foi mais lento do que o esperado, não por limitação do Codex, mas porque o ambiente não estava especificado o suficiente
- Faltavam aos agentes ferramentas, abstrações e estrutura interna para progredir em direção a objetivos de alto nível
- O principal trabalho da equipe de engenharia passou a ser tornar possível que os agentes façam trabalho útil
- Na prática, o trabalho segue uma abordagem depth-first: dividir grandes objetivos em blocos menores como design, código, revisão e testes, dar prompts para que o agente construa esses blocos e usá-los como base para tarefas mais complexas
- Quando há falha, a solução não é “tentar mais forte”, mas descobrir qual capacidade está faltando para permitir que o Codex faça o trabalho e então torná-la legível e utilizável pelo agente
- Humanos interagem com o sistema principalmente por prompts: o engenheiro descreve a tarefa, executa o agente e faz com que ele abra um PR
- No processo de concluir um PR, o Codex revisa localmente as próprias mudanças, solicita revisões adicionais de agentes localmente e na nuvem, responde a feedback humano ou de agente e repete até que todos os revisores-agentes estejam satisfeitos, em um fluxo próximo ao Ralph Wiggum Loop
- O Codex usa diretamente ferramentas padrão de desenvolvimento como
gh, scripts locais e skills embutidas no repositório para coletar contexto sem que humanos precisem copiar e colar nada - Humanos podem revisar PRs, mas isso não é obrigatório, e com o tempo quase todo o trabalho de revisão migrou para interações entre agentes
Aumentando a legibilidade da aplicação
- Com o aumento do throughput de código, o gargalo passou a ser a capacidade humana de QA
- Como a restrição fixa era o tempo e a atenção humanos, as capacidades dos agentes foram ampliadas tornando a própria UI da aplicação, os logs e as métricas do app diretamente legíveis pelo Codex
- A aplicação foi estruturada para poder inicializar por
git worktree, permitindo que o Codex execute e manipule uma instância para cada mudança - O Chrome DevTools Protocol foi conectado ao runtime do agente, e foram criadas skills para snapshots do DOM, screenshots e ações de navegação
- Com isso, o Codex consegue reproduzir bugs, validar correções e inferir diretamente o comportamento da UI
- Logs, métricas e traces são expostos ao Codex por meio de uma stack local de observabilidade que existe temporariamente para um
worktreeespecífico - O Codex trabalha em uma versão totalmente isolada do app, incluindo logs e métricas, e quando a tarefa termina esses logs e métricas também são removidos
- Os agentes consultam logs com LogQL e métricas com PromQL
- Prompts como “garanta que a inicialização do serviço termine em menos de 800ms” ou “garanta que nenhum span de quatro jornadas principais do usuário ultrapasse 2 segundos” tornam-se tarefas executáveis
- É comum que uma única execução do Codex trabalhe em uma tarefa por mais de 6 horas, muitas vezes enquanto os humanos estão dormindo
Transformando o conhecimento do repositório em sistema de registro
- Um dos principais desafios para tornar agentes eficazes em tarefas grandes e complexas é o gerenciamento de contexto
- O Codex não precisa de um manual de 1.000 páginas, e sim de um mapa
- Contexto é um recurso escasso, e arquivos enormes de instruções expulsam do contexto a tarefa, o código e os documentos relevantes, fazendo o agente perder restrições centrais ou otimizar para restrições erradas
- Orientação demais deixa de ser orientação: quando tudo é importante, nada é importante, e o agente acaba preso em correspondência local de padrões em vez de explorar de forma deliberada
- Um único manual gigante envelhece imediatamente, vira um cemitério de regras antigas e corre o risco de se tornar uma distração atraente que humanos não mantêm
- Um arquivo monolítico dificulta verificação mecânica de cobertura, atualidade, ownership e links cruzados, tornando o drift inevitável
- O
AGENTS.mdé tratado não como enciclopédia, mas como sumário - A base de conhecimento do repositório fica em um diretório
docs/estruturado, tratado como sistema de registro - Um
AGENTS.mdcurto, de cerca de 100 linhas, é injetado no contexto e atua como mapa que aponta para fontes de verdade mais profundas - Documentos de design são catalogados e indexados junto com um conjunto central de crenças que define estado de validação e princípios operacionais agent-first
- O documento de arquitetura fornece o mapa de mais alto nível do domínio e das camadas de pacotes
- Documentos de qualidade classificam cada domínio do produto e camada arquitetural, acompanhando lacunas ao longo do tempo
- Planos são tratados como artefatos de primeira classe: mudanças pequenas usam planos leves e efêmeros, enquanto tarefas complexas são commitadas no repositório como planos de execução, com progresso e registro de decisões
- Planos ativos, planos concluídos e dívida técnica conhecida são todos versionados e colocados lado a lado, permitindo que os agentes trabalhem sem depender de contexto externo
- Essa estrutura permite divulgação progressiva: em vez de serem sobrecarregados desde o início, os agentes partem de um ponto de entrada pequeno e estável e aprendem para onde olhar depois
- Jobs dedicados de lint e CI verificam atualidade, links cruzados e correção estrutural da base de conhecimento
- Agentes recorrentes de “jardinagem” da documentação localizam documentos antigos ou obsoletos que não refletem o comportamento real do código e geram PRs de correção
Legibilidade para agentes é a meta
- Como toda a base de código é produto de agentes, a prioridade máxima de otimização é a legibilidade para o Codex
- Assim como se facilita para um novo engenheiro navegar pelo código, o objetivo dos engenheiros humanos é fazer com que os agentes consigam inferir o domínio inteiro do negócio diretamente do repositório
- Do ponto de vista do agente, o que não está acessível no contexto de execução efetivamente não existe
- Conhecimento em Google Docs, threads de chat ou na cabeça das pessoas não é acessível ao sistema; só código, Markdown, schemas e planos de execução versionados localmente no repositório são visíveis aos agentes
- Mesmo que a equipe tenha concordado em um padrão arquitetural no Slack, se o agente não consegue descobrir isso, esse conhecimento fica tão invisível quanto algo que um novo integrante que entrou três meses depois ainda não sabe
- Dar mais contexto ao Codex não significa despejar instruções arbitrárias, mas organizar e expor as informações corretas para que o agente possa raciocinar sobre elas
- Assim como um novo integrante recebe onboarding sobre princípios do produto, normas de engenharia, cultura da equipe e até preferências de emoji, fornecer isso aos agentes leva a saídas mais alinhadas
- Dependências e abstrações são preferidas quando estão totalmente internalizadas e podem ser inferidas dentro do repositório
- Tecnologias consideradas “sem graça” frequentemente são mais fáceis para agentes modelarem por sua composabilidade, estabilidade de API e presença nos dados de treino
- Em alguns casos, é mais barato para o agente reimplementar parte de uma funcionalidade do que contornar o comportamento opaco de alto nível de uma biblioteca pública
- Em vez de trazer um pacote genérico estilo
p-limit, foi implementado um helper próprio de map-with-concurrency, estreitamente integrado com instrumentação OpenTelemetry, com 100% de cobertura de testes e comportamento que corresponde exatamente às expectativas de runtime - Quanto mais partes do sistema forem trazidas para um formato que os agentes possam inspecionar, validar e corrigir diretamente, maior será a alavancagem não só do Codex, mas também de outros agentes como o Aardvark trabalhando na mesma base
Forçando arquitetura e preferências
- Só documentação não basta para manter a consistência em uma base de código totalmente gerada por agentes
- Ao impor invariantes sem microgerenciar a implementação, cria-se uma estrutura na qual os agentes podem lançar rápido sem enfraquecer a fundação
- Exige-se do Codex fazer parsing da forma dos dados na borda, mas sem prescrever exatamente como
- Como os agentes funcionam melhor em ambientes com fronteiras rígidas e estrutura previsível, a aplicação é organizada em torno de um modelo arquitetural robusto
- Cada domínio de negócio é dividido em um conjunto fixo de camadas, e a direção das dependências e conexões permitidas é rigidamente validada
- Essas restrições são impostas mecanicamente por lints customizados e testes estruturais gerados pelo próprio Codex
- Em cada domínio de negócio, o código só pode depender para frente seguindo as camadas fixas
Types → Config → Repo → Service → Runtime → UI - Interesses transversais como autenticação, conectores, telemetria e feature flags só podem entrar por uma única interface explícita chamada
Providers - Qualquer outra dependência não é permitida e é bloqueada mecanicamente
- Esse tipo de arquitetura normalmente é adiado até existirem centenas de engenheiros, mas num ambiente com agentes de programação ela vira pré-condição inicial para manter velocidade enquanto se evita deterioração e drift arquitetural
- Na prática, as regras são impostas por lints customizados, testes estruturais e um pequeno conjunto de “invariantes de preferência”
- Logging estruturado, convenções de nomes para schemas e tipos, limites de tamanho de arquivo e requisitos de confiabilidade por plataforma são impostos estaticamente com lint customizado
- As mensagens de erro desses lints são escritas para injetar instruções de correção no contexto do agente
- Em fluxos de trabalho voltados a humanos, essas regras podem parecer excessivamente detalhistas ou restritivas, mas em um ambiente com agentes elas funcionam como multiplicadores: uma regra codificada uma vez passa a valer em todo lugar ao mesmo tempo
- No centro, fronteiras, correção e reprodutibilidade são fortemente controladas; dentro disso, equipes ou agentes mantêm grande liberdade na forma de expressar a solução
- O código resultante nem sempre combina com preferências estilísticas humanas, mas se for correto, manutenível e legível para futuras execuções de agentes, o critério está atendido
- Preferências humanas continuam voltando ao sistema por comentários de review, PRs de refatoração e bugs voltados ao usuário, atualizando documentação ou ferramentas
- Quando a documentação não basta, a regra é promovida a código
A filosofia de merge mudou com o throughput
- À medida que o throughput do Codex aumentou, muitas normas tradicionais de engenharia passaram a ter efeito contrário ao desejado
- O repositório opera com o mínimo possível de gates de merge bloqueantes
- Os PRs são mantidos curtos
- Flakes de teste muitas vezes são tratados em execuções subsequentes em vez de bloquear indefinidamente o progresso
- Em um sistema no qual o throughput de agentes supera muito a atenção humana, o custo de corrigir é baixo e o custo de esperar é alto
- Em ambientes de baixo throughput, essa abordagem poderia ser irresponsável, mas aqui ela frequentemente representa o trade-off correto
O escopo real de “gerado por agente”
- Dizer que a base de código é gerada por agentes Codex significa tudo dentro da base
- O que os agentes produzem
- código do produto e testes
- configuração de CI e ferramentas de release
- ferramentas internas para desenvolvedores
- documentação e histórico de design
- harnesses de avaliação
- comentários de review e respostas
- scripts que gerenciam o próprio repositório
- arquivos de definição de dashboards de produção
- Humanos continuam sempre no loop, mas agora operam em uma camada de abstração mais alta do que antes
- Humanos definem prioridades de trabalho, traduzem feedback dos usuários em critérios de aceitação e validam resultados
- Quando os agentes têm dificuldade, isso é tratado como sinal de que falta ferramenta, guardrail ou documentação, e essa correção também é devolvida ao repositório para ser escrita pelo Codex
- Os agentes usam diretamente ferramentas padrão de desenvolvimento, trazem feedback de review, respondem inline, fazem push de atualizações e muitas vezes até fazem squash e merge dos próprios PRs
Aumentando o nível de autonomia
- À medida que teste, validação, review, tratamento de feedback e recuperação foram sendo mais codificados dentro do sistema, o Codex recentemente cruzou o limiar em que consegue levar uma nova feature do início ao fim
- Tarefas que o agente consegue executar a partir de um único prompt
- validar o estado atual da base de código
- reproduzir um bug reportado
- gravar um vídeo mostrando a falha
- implementar a correção
- validar a correção manipulando diretamente a aplicação
- gravar um segundo vídeo mostrando a solução
- abrir um PR
- responder a feedback de agentes e humanos
- detectar e corrigir falhas de build
- escalar para um humano só quando julgamento for necessário
- mesclar a mudança
- Esse comportamento depende fortemente da estrutura e das ferramentas específicas desse repositório, e não se deve presumir que ele se generalize sem investimento semelhante
Entropia e coleta de lixo
- Autonomia total dos agentes também introduz novos problemas
- O Codex replica padrões já existentes no repositório, mesmo quando esses padrões são inconsistentes ou não ideais
- Com o tempo, essa repetição leva a drift
- No começo, humanos tratavam isso manualmente, e a equipe usava todas as sextas-feiras — 20% da semana — para limpar “AI slop”
- Como esse método não escalava, os “princípios de ouro” foram codificados diretamente no repositório e foi criado um processo recorrente de limpeza
- Os princípios de ouro são regras mecânicas e opinativas para manter a base de código legível e consistente para futuras execuções de agentes
- Um exemplo é preferir pacotes utilitários compartilhados em vez de helpers feitos à mão, para centralizar invariantes
- Outro exemplo é validar fronteiras ou depender de SDKs tipados, em vez de explorar dados de forma “YOLO” e deixar o agente construir por acaso sobre formatos que ele apenas adivinhou
- Periodicamente, jobs em background do Codex escaneiam desvios, atualizam notas de qualidade e geram PRs de refatoração direcionados
- A maioria desses PRs de refatoração pode ser revisada em menos de 1 minuto e mesclada automaticamente
- Esse processo funciona como coleta de lixo
- Dívida técnica é como empréstimo com juros altos: quase sempre é melhor pagá-la continuamente em pequenas parcelas do que deixar acumular para resolver de uma vez com dor
- Preferências humanas, uma vez capturadas, passam a ser aplicadas continuamente a cada linha de código
- Padrões ruins podem ser detectados e corrigidos diariamente, antes de se espalharem pela base por dias ou semanas
Ainda aprendendo
- Até agora, essa estratégia funcionou bem para lançamentos e adoção internos na OpenAI
- Construir produtos reais para usuários reais mantém o investimento preso à realidade e empurra o sistema para manutenção de longo prazo
- Ainda não se sabe como a consistência arquitetural evolui ao longo de anos em um sistema totalmente gerado por agentes
- Também continua em aprendizado onde o julgamento humano traz maior alavancagem e como codificá-lo para gerar efeito cumulativo
- Ainda é desconhecido como esse sistema vai evoluir à medida que os modelos ficarem mais capazes com o tempo
- O que ficou claro é que construir software continua exigindo disciplina, mas essa disciplina aparece mais no scaffolding do que no código
- A importância de ferramentas, abstrações e loops de feedback para manter a consistência da base de código continua crescendo
- Hoje, o desafio mais difícil é projetar ambientes, loops de feedback e sistemas de controle que ajudem agentes a criar e manter software complexo e confiável em larga escala
- Quanto mais agentes como o Codex assumem partes maiores do ciclo de vida do software, mais importantes essas perguntas se tornam
- Os aprendizados iniciais ajudam a avaliar onde investir esforço para simplesmente conseguir construir algo
1 comentários
Comentários do Hacker News
A taxa de entrega é absurda. Fico curioso sobre qual deveria ser a linha de base. Antes da codificação com agentes, quantos PRs normalmente se esperava que um engenheiro abrisse? Algo como 2 a 10 por dia?
Também fico me perguntando se, nos últimos 6 meses, o software de fato parece melhor. Se o número de engenheiros for parecido, o ciclo de iteração dos principais aplicativos deveria estar umas 5 vezes mais rápido, mas não parece ser o caso. Apps de IA mudam muito rápido, mas isso é esperado por ser uma área nova; fora disso, quase não dá para perceber
Aqui, são 1.500 PRs para 1 milhão de linhas, então o aumento líquido é de cerca de 650 linhas por PR. Isso não quer dizer que cada PR tenha 650 linhas no total, mas sim que o saldo entre linhas adicionadas e removidas é de +650
Há algumas perguntas para o leitor atento. Como seria, daqui a 10 anos, um projeto que aumenta em linhas o equivalente a um codebase do Firefox por ano? O que a contagem de linhas diz sobre a verbosidade das ferramentas, e o que o fato de o objetivo do projeto não ter sido claramente divulgado diz sobre o resultado? Em um mundo onde humanos não escrevem mais código diretamente, ainda há motivo para se importar com contagem de linhas? Se o codebase ficar muito maior, o que acontece com o consumo de tokens? Se ficar confirmado que o uso de LLM faz a contagem de linhas explodir, o que isso significa para um codebase que, depois de alguns meses, queira voltar à codificação manual por causa dos custos?
Curiosamente, a maior parte dos usos de “agentes” serve para criar outro produto de IA. É uma estrutura de tartarugas até o infinito. Talvez isso diga mais sobre a área da Harness do que sobre o poder dos “agentes”
No MS Office, por exemplo, vejo muitas mudanças pequenas recentemente, e a maioria é irritante. Coisas como perder o foco ao marcar um colega com @ em comentários do Word, ter de clicar duas vezes para digitar na busca do Outlook, ou o seletor de data do Outlook mobile aparentemente ter perdido a função de mostrar minha disponibilidade e a dos participantes
Então parece haver muita entrega, mas infelizmente estragando coisas que já funcionavam bem. Ou gastando tempo com coisas pouco importantes, como a barra de status da busca do OneDrive dando voltas ao redor do campo de entrada
A maior parte do código escrito seria num modelo em que eu continuo no volante e no controle, enquanto a IA é usada para reforçar o estado de fluxo e remover travas. Quero deixar a ferramenta gerar código de fato só no mínimo necessário
Nos últimos 5 meses, venho fazendo o mesmo experimento no tsz[1] e cheguei a conclusões muito parecidas. É preciso bastante harness para forçar uma boa separação de arquitetura, e também muitos testes e CI
O objetivo de criar o tsz é aprender a fazer projetos muito grandes com IA. No fim, o mesmo fluxo de trabalho e a mesma postura também podem ser aplicados para criar apps de produto voltados a clientes com UI. A OpenAI aparentemente está usando testes automatizados de navegador e até vídeo como parte do fluxo de trabalho. À medida que os modelos melhorarem, esse rumo de desenvolvimento de software provavelmente vai fazer sentido no fim, mas ainda não estamos lá. Mesmo assim, ao contrário das alegações vagas da OpenAI, aqui pelo menos dá para compartilhar o resultado e ver por conta própria
Soluções como Lovable, que oferecem um nível muito alto de automação, parecem otimistas demais e não estão acopladas de perto a muitos testes automatizados
[1] https://github.com/tsz-org/tsz
Isso coincide exatamente com a forma como venho trabalhando. Dê ao Claude/Codex meios de validar o próprio trabalho: navegador, smoke tests, testes end-to-end, ambientes locais de alta fidelidade e assim por diante
Coloco todo o contexto — rastreamento de issues, documentação, ideias, planos e logs de trabalho — dentro do repositório (https://github.com/shepherdjerred/monorepo/tree/main/package...)
Dou ao Claude/Codex acesso a ferramentas de observabilidade como Grafana, Prometheus, Tempo e PagerDuty, e faço com que sigam boas diretrizes de engenharia, como fail fast, type safety e parsing nas bordas
Só que, no homelab, ainda não cheguei à autonomia completa por causa do custo e da carga de CI
Outro dia vi um vídeo de trabalhadores de uma fábrica de cigarros eletrônicos. Eles pegavam um maço de vapes na esteira, puxavam um deles, davam uma tragada forte por uns 5 segundos e depois testavam o próximo lote. Revisar centenas de linhas alteradas em um PR escrito por IA não é tão diferente assim
Um PR não é assim. Um único PR ruim pode ser fatal para o negócio, enquanto um vape ruim normalmente não é
Além disso, se um engenheiro de software fizer amostragem da saída de IA, vai considerar que a qualidade atual ainda não atende de forma consistente ao padrão desejado para o produto. Por isso, todos os PRs ainda precisam ser revisados e uma boa parte precisa ser corrigida
Uma abordagem por amostragem pode funcionar quando o alcance do impacto das mudanças puder ser limitado e a saída for aceitável na maior parte do tempo mesmo sem supervisão, a ponto de, no ambiente de produção, só ser preciso confirmar em dobro que não houve regressões
Sou um dos três engenheiros que escreveram este post. Posso responder perguntas, se houver
Não sou cético de IA, mas desconfio da intenção deste post. Ele faz grandes afirmações sobre engenharia agent-first com base em um produto real, usuários reais e uma equipe real em crescimento, fazendo parecer um caso concreto, mas não diz nem mostra o que foi construído. É igual a todo o resto dos textos exagerados sobre IA
Isso só pode funcionar quando se tem recursos de computação infinitos e tokens infinitos
Pela minha experiência usando o plano de $20, esse tipo de abordagem puramente agentiva é impossível. Você bate no limite rápido e produz menos resultado
O que funcionou muito bem foi fornecer código escrito por humanos como referência e mandar expandir a partir dele. Definir toda a estrutura, desenhar a arquitetura e escrever alguns exemplos de código para controladores, serviços, modelos, componentes, schema de banco de dados, forma de autenticação etc., para que o LLM tenha uma base a partir da qual começar a focar
Normalmente escrevo stubs detalhando como implementar. É algo como pseudocódigo em um nível mais alto de abstração. Depois peço ao LLM para implementar
Se falhar, muitas vezes é melhor reverter toda a mudança, ajustar o stub para que ele consiga capturar a falha anterior e então tentar de novo
Ou então fazer commit da mudança e, em um novo contexto, lidar só com as partes erradas
Quando tento abordar de forma agentiva desde o começo, sempre fico decepcionado tanto com os resultados quanto com os limites. Às vezes bato no limite em menos de uma hora
Dá para usar mais se fizer upgrade para $200 por mês, mas mesmo para alguém que usa pesado como eu, o uso continua sempre insuficiente
Ainda invejo as pessoas que receberam 200x mais uso só por terem confirmado presença na festa da OpenAI
Mais um texto ofegante de venda. É vender picareta para garimpeiro, mas onde está o ouro? Onde estão os produtos incríveis de fato criados por chatbots conversando entre si em cima do Git e gerando montanhas de linhas de código? Não vejo nenhum
Eu queria que esses posts empolgados de blog fossem um pouco mais didáticos
Por exemplo, queria que mostrassem passo a passo como configurar na prática o workflow que dizem ser tão poderoso e fizessem uma demonstração concreta
Não sou cético de IA. Pelo contrário, se existe um superpoder real aqui, não quero perder isso
Para features novas, escrevo especificações de funcionalidades em Gherkin; para melhorias, atualizo isso; para refatorações, não mexo. Nos PRs, coloco labels com esses substantivos
No hook de pre-push, rodo verificação de tipos, lint, testes unitários e outras validações rápidas e passíveis de script
Crio um subsite VitePress dentro do repositório e deixo o agente manter isso. Documento princípios importantes, arquitetura etc.
Crio um comando de CLI que lista todas as páginas e descrições do frontmatter em YAML, para o agente escolher o que ler sem estourar a janela de contexto
Uso design orientado a domínio e monorepo. Escrevo a lógica em camadas headless e componho as camadas em apps. O agente navega muito bem pelas camadas
Uso zod, ou a ferramenta equivalente da linguagem, e desenvolvimento de API contract-first. Pessoalmente, esta é a parte de que mais gosto, e uso orpc
Crio apenas uma skill única chamada “code” e descrevo o ciclo de vida. Abrir a worktree, configurar o
.envpara não conflitar com outros agentes, escolher portas que não estejam em uso, e o Docker ajuda nisso. Escrever ou atualizar o arquivo de feature, alinhar a especificação ali, depois implementar, validar com algo como playwright mcp, executar as verificações antes do push, esperar a revisão depois do push, limpar tudo e fazer fast-forward merge namainO testcontainers é bom para garantir que vários agentes consigam rodar testes sem conflito
Sério, só existe uma skill. Todo o resto está na documentação. Parece muito produtivo, não no sentido de número de linhas de código, mas no sentido de “fazer software bom”
Para isso, toda vez que o agente encontrava um problema, eu perguntava como resolvê-lo usando ferramentas ou scripts de validação. Durante esse processo de auditoria, também fiz com que ele mesmo programasse essas ferramentas. Como resultado, agora há mais de 30 regras para validação de commits[2], e isso funciona bem
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (“demo” mode aparece se você deixar o timer acabar)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
Tentamos isso no início. Antes de escrever qualquer código, usamos o ChatGPT como “gerente de projeto” para configurar todo o harness. Uma semana depois, tinham surgido mais de 140 documentos de regras, arquitetura e framework, e o total de linhas de código era 0
Mais tarde, quando pedimos para outra ferramenta revisar, o veredito foi “um cofre vazio perfeitamente seguro”. O harness era impecável, mas não havia nada dentro
O harness é importante, mas, se não avançar em paralelo com a entrega do código, você está apenas escrevendo ficção