Mudanças nos limites de responsabilidade provocadas pelo Codex

Quando apresentei o Codex à equipe em larga escala pela primeira vez, a primeira coisa boa foi que finalmente estava disposto a fazer algumas pequenas mudanças.

Uma situação comum no passado era que todos sabiam claramente: este código precisa ser refatorado, este script precisa ser testado e este limite precisa ser registrado. Mas eles estão todos presos na mesma realidade. Você tem que prestar atenção aos custos para começar a escrever e revisar depois de escrever.

Codex reduz o “atrito prático”.

Os problemas começaram a surgir a partir daquele dia.

Porque à medida que o atrito diminui, os limites da responsabilidade também se movem silenciosamente.

Superficialmente, você pode pensar que está comprando autores mais rápidos, mas o que na verdade está comprando são mais mudanças. Quando há demasiadas mudanças, o sistema necessita de uma aceitação mais clara e de mecanismos de controlo mais fortes.

Caso contrário, a eficiência do Codex será dada de outra forma: acidentes on-line, fadiga de revisão e retrabalho que “parece certo, mas é instável” repetidas vezes.

Como as coisas gradualmente se tornaram “o revisor é responsável”

Na primeira semana após a introdução do Codex, todos o usaram com muita moderação.

-Escreva um widget

• Alterar o nome de um parágrafo
• Adicione um julgamento if

Estas mudanças, se não forem perfeitas, acarretam riscos limitados.

A partir da segunda semana, as mudanças ficaram maiores.

Algumas pessoas começaram a pedir ao Codex para “organizar o código circundante”, algumas pessoas começaram a pedir para “refatorar este módulo junto”, e algumas até substituíram uma seção inteira de lógica complexa por uma versão gerada.

Nesta fase, a frase mais comum é:

Olha, o código está todo escrito e a lógica está correta.

O problema é que há uma substituição oculta nesta frase.

No passado, o autor era o principal responsável por saber se a lógica estava correta ou não. O autor precisa passar por uma convergência completa ao escrever: motivos das mudanças, quais são os limites, o que acontecerá se falhar e como reverter.

Codex nivela o processo de convergência no meio. O autor passa a ser “aquele que faz exigências” e deixa a restrição para o revisor.

Portanto, o limite de responsabilidade começa em:

• O autor é responsável por convergir as alterações até que estejam prontas para lançamento

tornou-se:

• Os revisores são responsáveis por filtrar as alterações até que não causem problemas

Esta não é uma questão moral, é uma questão mecânica.

O modo de gerar código tende naturalmente a “escrever uma versão primeiro” em vez de “pensar claramente sobre os limites primeiro”. Esta transferência de responsabilidade ocorre enquanto o processo não explicita os limites.

Muitas vezes o preço será pago em três lugares imediatamente

1) A revisão se torna “arqueologia”

No passado, a revisão analisava as escolhas do autor:

• Use isso para alcançar
• Dividir nessas funções
• Adicione esta proteção aqui

Agora a revisão analisa a saída:

• Este código gerado perdeu algum limite?
• Foram introduzidos novos efeitos colaterais?
• Você mudou discretamente a semântica da lógica antiga?

Não é o mesmo tipo de trabalho.

A primeira é julgar o processo de raciocínio do autor, e a segunda é encontrar armadilhas em códigos desconhecidos. Este último é mais caro e depende mais da familiaridade do revisor com o contexto.

Em breve você verá um fenômeno:

• O código é mesclado
• Algo deu errado on-line
• Durante a revisão, ninguém soube dizer por que foi escrito assim.

Porque o “porquê” nunca é escrito.

2) O teste é tratado como “opcional”

A maior tentação na geração de código é: ele parece completo.

As funções são lindamente divididas, os nomes são os mesmos e até mesmo alguns testes individuais adicionais são fornecidos.

O problema é que esses testes unitários geralmente “verificam a implementação” em vez de “verificam os requisitos”.

Os sintomas típicos são:

• Maior cobertura
• Muitos acidentes

Porque o que falta são critérios de aceitação, não um formato JUnit/pytest.

3) O caminho de reversão foi esquecido

Mudanças manuscritas geralmente levam a pensamentos naturais de “e se não funcionar”.

Gerar mudanças pode facilmente dar a ilusão de que esta é uma implementação mais limpa e deve funcionar bem.

Mas a coisa mais dolorosa online é “as mudanças são muito grandes e você não pode voltar atrás”.

Quando as alterações geradas abrangem vários arquivos e são refatoradas em vários locais, a reversão não se trata mais de desfazer um commit, mas de reconstruir a semântica antiga.

Esta é a conta mais cara depois que os limites de responsabilidade são alterados.

Para trazer de volta os limites da responsabilidade, o que precisamos fazer é não “desativar o Codex”

Quando muitas equipes veem esses problemas, a primeira reação é restringir seu uso:

• Desativar geração de segmentos grandes
• A modificação dos módulos principais é proibida
• A lógica chave deve ser escrita à mão

Estas regras são úteis a curto prazo, mas rapidamente se tornam formalistas.

A abordagem verdadeiramente eficaz é avançar a parte da “responsabilidade do autor” para o processo de uso do Codex.

Finalmente reduzi a quatro requisitos rígidos. Se faltar um deles, não vou desistir:

1. A intenção de mudança deve ser escrita de forma clara: descreva o comportamento a ser mudado em uma frase, não “refatore-o”.
2. Os critérios de aceitação devem ser aplicáveis: quais são as entradas, quais são as saídas esperadas e como se comportar em caso de falha.
3. O limite de risco deve ser listado: Quais chamadores são afetados por esta mudança e qual é o pior cenário?
4. O plano de reversão deve ser claro: para qual versão reverter, como processar os dados e onde está a opção de downgrade.

O Codex pode ajudar a escrever implementações, mas não pode substituir esses quatro itens.

Mais importante: depois de escrever esses quatro itens, a resenha ficou mais leve.

O revisor não precisa adivinhar “o que exatamente você quer fazer” no código, mas apenas julgar “se a intenção escrita e a implementação são consistentes”.

Os mal-entendidos mais comuns

Mal-entendido 1: Tratar o Codex como “um novato que pode escrever código”

Os recém-chegados ficam presos em lugares que não conhecem, fazem perguntas e expõem incertezas.

O Codex não.

Ele lhe dará a resposta que parece mais confortável quando você não tem certeza. Sem critérios de aceitação, isso enterra a incerteza no código.

Mito 2: Usar mais palavras rápidas para compensar processos de engenharia ausentes

Palavras-chave podem ajudá-lo a se aproximar mais do estilo, mas não podem substituir o mecanismo de controle.

Colocar processos ausentes no prompt resultará em uma “memória organizacional que é gravada cada vez mais”, mas não tem controle de versão, nem estratégia de reversão, nem exercícios de falha.

Mal-entendido 3: Contando apenas “quanto tempo é economizado”

A métrica mais perigosa é: quanto tempo de desenvolvimento é economizado por requisito.

Porque levará todos a buscar um escopo maior de geração.

Prefiro focar em dois indicadores:

• Gerar taxa de retrabalho após integração da mudança
• Proporção de incidentes introduzidos por mudanças de geração

Eles estão relacionados aos limites de responsabilidade.

Limites aplicáveis

Nem todas as equipes precisam de restrições tão pesadas.

Se o sistema for pequeno o suficiente, os lançamentos forem frequentes o suficiente e as reversões forem simples o suficiente, o risco do Codex será engolido.

Mas uma vez cumprida qualquer uma das seguintes condições, os limites de responsabilidade devem ser explicitados:

• As alterações afetarão links de alto custo, como pagamento, controle de risco e aprovação
• Longo ciclo de lançamento e alto custo de reversão
• A propriedade do código é ambígua e a revisão já é um gargalo

Nesses cenários, o “mais rápido” do Codex irá primeiro passar para mais lento.

Resumo

Codex certamente torna a escrita de código mais rápida.

Mas o que realmente muda é a resposta padrão da equipe para “quem é responsável pela mudança?”

Se a intenção, a aceitação, os limites e as reversões não forem levados adiante, a responsabilidade passará naturalmente para o revisor.

No final, você descobrirá que o que se economiza não é o tempo de desenvolvimento, mas sim a atenção de toda a equipe. Esta conta é muito mais cara que o token.