Ideia principal

Quando um assistente de desenvolvimento propõe uma arquitetura complicada demais para a necessidade, esquece os testes ou coloca o negócio nos endpoints, o reflexo é corrigir e seguir em frente. A correção trata o sintoma e deixa a causa intacta: nada havia dito à ferramenta o que o time esperava naquele ponto específico.

Essas falhas têm uma propriedade que as torna aproveitáveis: elas são reproduzíveis. Diferente de um erro humano, que depende do cansaço ou da desatenção de um dia, uma saída malsucedida vai repetir o mesmo defeito enquanto a instrução que falta não for escrita. Cada correção não capitalizada é, portanto, paga tantas vezes quantas ela se repetir.

O gesto completo tem três tempos: corrigir, identificar o sinal que não foi dado, ajustar as diretrizes. Um post-mortem de geração malsucedida vale aqui o que um post-mortem de incidente vale em operação.

Por que isso importa

Isso transforma um item de custo em mecanismo de aprendizado. A energia gasta corrigindo um assistente é gasta de todo jeito; se ela produz ou não uma prática duradoura depende apenas do que fazemos depois da correção.

Também devolve um ciclo de tentativa e erro onde a ferramenta o tinha cortado: não é mais quem desenvolve que erra e aprende, é o time que vai explicitando aos poucos o que considera bem feito — e essa explicitação serve tanto a ele quanto à ferramenta.

Nuances e limites

Nem toda saída malsucedida se corrige com uma diretriz. Algumas vêm de um contexto que não dava para fornecer, de um limite do modelo, ou de uma necessidade que não estava clara do lado humano — e escrever uma instrução nesses casos desloca o problema sem tratá-lo.

E o arquivo de diretrizes tem o próprio custo: acréscimos demais acumulados o tornam contraditório, e um time pode gastar mais tempo mantendo suas instruções do que ganha com elas.

Questões em aberto

• Que falhas merecem uma diretriz permanente, e quais ficam melhor tratadas por uma correção pontual que aceitamos repetir?