Como usar o Codex e seus limites em projetos reais

Uma situação comum é perguntar “como usar o Codex”. Por padrão, ele pergunta sobre teclas de atalho, modelos de prompt de palavras e como fazê-lo escrever mais código.

Mais tarde descobri que essa pergunta foi feita na direção errada.

O maior valor do Codex é permitir que as equipes iniciem mudanças com mais frequência e de forma mais barata. O risco real também está aqui: após aumentar a frequência das mudanças, o mecanismo original de check-in da equipe pode não ser suficiente.

Portanto, não falarei sobre as “Dez técnicas de palavras imediatas” neste artigo. Falarei apenas sobre uma linha principal: Conecte o Codex a um pipeline de alterações que possa ser aceito, revertido e rastreado.

1. Primeiro selecione a “unidade de trabalho adequada para Codex”

O uso mais facilmente anulado é lançar um requisito vago diretamente no Codex:

• “Refatorar este módulo”
• “Otimizar desempenho”
• “Deixe este lugar mais elegante”

Certamente dá um monte de mudanças, e todas parecem corretas. O problema é que não há como aceitá-lo ou revisá-lo.

Condensei as tarefas adequadas ao Codex em três categorias, cada uma com “condições de conclusão” claras.

A. Mudanças de comportamento que podem ser escritas como afirmações

A característica é: a entrada e a saída podem ser descritas em uma frase.

• Adicionar processamento de limite a uma função
• Corrigido um bug definitivo
• Migre uma parte da lógica para uma nova interface, mas mantenha a semântica inalterada

A melhor maneira de fazer a aceitação é escrever testes diretamente ou pelo menos escrever um script de asserção executável.

B. Enumeráveis Mudanças Mecânicas

As características são: regras claras e cobertura controlável.

• Renomeação em lote
• Atualizar chamadas de API
• Anulação completa/tratamento de erros

O Codex é poderoso para esse tipo de trabalho, mas deve ser permitido gerar uma “lista de modificações” e um “escopo pesquisável de alterações”, caso contrário, ele tende a perder cantos.

C. Otimização local com indicadores concretos

A característica é: a capacidade de definir métodos de medição.

• Reduza IO uma vez durante a fase de inicialização
• Reduza a serialização uma vez para um determinado link
• Reduza a reorganização desnecessária de uma determinada página

Não otimize sem métricas. O Codex confundirá “parece mais rápido” com “é muito mais rápido”.

2. Escreva os requisitos como “critérios de aceitação” e, em seguida, escreva as palavras de alerta

Uma situação comum é escrever palavras imediatas, como escrever desejos:

• “Por favor, escreva com elegância”
• “Por favor, siga as melhores práticas”

Estas são inaceitáveis.

Exijo que, sempre antes de deixar o Codex agir, eu primeiro escreva um critério de aceitação e o escreva na mesma descrição da tarefa:

• Que comportamento essa mudança mudará?
• Que comportamentos não podem ser alterados?
• Como se comportar quando você falha
• Como reverter

Você descobrirá que, uma vez que os critérios de aceitação sejam claramente escritos, as palavras de aviso ficarão mais curtas.

Uma estrutura que uso com frequência é:

1. Antecedentes (duas ou três frases, não fale sobre história)
2. Objetivo (apenas comportamento de gravação, não implementação)
3. Restrições (o que não pode ser movido)
4. Aceitação (pontos de teste ou scripts)
5. Formato de saída (forneça o plano primeiro e depois corrija)

3. Peça ao Codex para fornecer um “plano de mudança” primeiro, em vez de fornecer o código final diretamente.

O mais caro em projetos reais é “descobrir que a semântica mudou após a fusão”.

Então transformei a saída padrão do Codex em um processo de duas etapas:

• Passo 1: Liste quais arquivos serão alterados, por que serão alterados e os riscos de cada alteração
• Etapa 2: aplique o patch novamente

Se ele gerar um trecho inteiro de código assim que aparecer, vou apenas chamá-lo de volta e deixá-lo fazer o plano.

A razão é simples:

• A fase de planejamento pode revelar se entende os limites
• Se mudanças excessivas podem ser interrompidas a tempo durante a fase de planejamento

4. Deixe o Codex gerar um “patch revisável” em vez de apenas um monte de texto

Copiar e colar centenas de linhas de código no IDE está transformando a revisão em um trabalho manual.

A abordagem correta é: deixar a saída do Codex na forma de diff/patch ou deixá-lo fazer apenas as menores alterações mescláveis.

Vou aderir a duas restrições na equipe:

• Um único PR não abrange duas intenções não relacionadas
• A principal diferença de um único PR está em 200 linhas (caso contrário, deve ser dividido)

É fácil escrever cada vez mais códices e deve ser “fechado em uma pequena caixa” com restrições de PR.

5. Deixe o teste ser a “primeira saída”, não a “última adição”

A armadilha mais comum do Codex é que a implementação está completamente escrita e os testes parecem estar lá, mas o teste está apenas validando a implementação que escreveu.

Então pedi para produzir em ordem:

1. Lista de casos de teste (quais limites são cobertos)
2. Código de teste principal
3. Implementar patch

Se não puder fornecer pontos de teste, significa que os requisitos não estão claramente escritos ou que esta alteração não é adequada para ser feita.

6. Escreva o “caminho de reversão” na mudança

Pessoas que fazem alterações manualmente muitas vezes deixam inconscientemente um caminho alternativo.

É fácil para quem fez a mudança esquecer.

Eu exigiria que cada alteração de build satisfizesse pelo menos uma política de reversão:

• bandeira de recurso
• Opções de configuração
• Mantenha o caminho antigo por um tempo (corrida dupla)

Grandes alterações sem um caminho de reversão, não importa quem as escreveu, não devem ser publicadas. O Codex apenas torna mais fácil fazer “grandes mudanças”.

7. Trate a rastreabilidade como um “item de custo” do uso do Codex

Se você contar apenas “quanto tempo de desenvolvimento é economizado”, muitas vezes será incentivado a escrever cada vez mais Codex.

O que mais me importa é se o problema pode ser reproduzido.

Portanto, no processo, registrarei três coisas:

• Descrição da tarefa para Codex desta vez (incluindo critérios de aceitação)
• Plano de mudança fornecido pelo Codex
• Patch final e resultados de testes

Esses três itens constituem a cadeia de evidências durante a revisão do acidente.

Sem registro, quanto mais você usar o Codex, mais parecerá que você está executando um sistema não reproduzível.

8. Um conjunto de esqueletos de palavras imediatas que podem ser usados diretamente

O parágrafo a seguir é a alteração mínima para que sua saída fique online.

Você pode copiá-lo diretamente e substituir os colchetes:

As alterações precisam ser feitas em um projeto real.

Antecedentes: [Duas ou três frases descrevendo a situação e os problemas atuais] Metas (nível comportamental):

• Obrigatório: [Listar 2 a 4 itens]
• Nunca mude: [Lista 2-4] Restrições:
• Não é permitido introduzir novas dependências/não é permitido alterar a API pública/deve ser compatível com dados antigos (selecione conforme necessário) Aceitação:
• fornece uma lista de pontos de teste
• Forneça pelo menos [N] códigos principais de casos de teste Formato de saída:

1. Forneça primeiro um plano de mudança (lista de documentos + pontos de risco)
2. Forneça o menor patch (diff), não inclua textos explicativos longos

Limites aplicáveis

Os cenários em que o Codex não é adequado também são claros:

• Não consigo nem dizer qual comportamento quero, então só posso “tentar primeiro”
• Esta é uma mudança de alto risco que envolve migração de dados, permissões e financiamento, mas não existe um ambiente de aceitação completo
• Confiança em conhecimento tácito (comutações online, estratégias em escala de cinza, incidentes históricos) sem documentação

Nestes cenários, o Codex solidificará a incerteza diretamente no código.

Resumo

A resposta para “como usar o Codex” é um conjunto de restrições de engenharia.

Pensar nisso como uma autoria mais rápida coloca a responsabilidade na revisão e online.

Trate-o como uma seção do pipeline, utilize critérios de aceitação, testes, rollback e rastreabilidade para conter as mudanças, e ele se tornará uma verdadeira ferramenta de eficiência.