Ideia principal

Uma competência que o uso corrente não exercita mais não se mantém sozinha. Quem pede a um assistente que leia, explique e corrija no seu lugar mantém a habilidade de conduzir a ferramenta e vai perdendo a de ler um código desconhecido, sustentar um diagnóstico ou simplificar uma arquitetura.

O remédio não é abrir mão da ferramenta, é criar situações em que ela não está disponível: dojos sem assistente, exercícios com assistente limitado, revisões em que você mesmo precisa explicar o código, momentos reservados de propósito para ler, entender e simplificar. A mesma lógica é aceita em outros lugares sem discussão — a calculadora é útil, mas nunca fazer uma conta você mesmo gera dependência; no esporte, acrescentamos peso e resistência porque é a resistência que desenvolve o músculo.

Isso não é nostalgia do desenvolvedor que sofre para merecer a profissão, e o objetivo não é desacelerar em tudo. É desacelerar no lugar certo: produzir muito rápido parte do tempo e blindar um tempo longo — um dia de melhoria contínua, revisões de arquitetura, ADRs, refatorações lentas, post-mortems de geração malsucedida — para entender o que foi produzido.

Por que isso importa

Isso trata uma lacuna que nenhuma regra de produção cobre: as contramedidas que protegem a qualidade do sistema não protegem a aptidão de quem o sustenta. Um time pode aplicar uma disciplina de merge impecável e deixar morrer a competência que lhe permitiria julgar o que faz merge.

Também dá uma leitura de um problema anterior às ferramentas: muita gente que desenvolve já ficava de cabeça baixa, produzindo sem tomar a distância que faz subir de nível. A aceleração agrava esse vício se preencher todo o espaço liberado com mais produção, e o corrige se servir para distinguir o tempo de fazer do tempo de entender.

Nuances e limites

A dificuldade acrescentada precisa parecer com a do trabalho real. Um exercício artificial mantém a desenvoltura no exercício, não a competência visada — e uma restrição mal escolhida custa tempo sem formar nada.

E algumas competências tornadas inúteis merecem desaparecer: ninguém treina escrever assembly para continuar lúcido sobre o próprio código. Distinguir o que é preciso manter do que dá para abandonar é uma decisão em aberto, que esta ideia não resolve.

Questões em aberto

• Por qual sinal um time percebe que uma competência se apagou, se a produção diária dele já não a exigia havia tempo e parecia normal?