Ideia principal

Dispensar a revisão de um desenvolvedor numa ferramenta que você mesmo montou tem uma contrapartida que não é opcional: quando essa ferramenta quebra, mais ninguém está comprometido. Quem escolheu construí-la come a própria comida, e o conserto é com essa pessoa.

É aí que a promessa racha. Um assistente de código eliminou a barreira de entrada — escrever a funcionalidade — sem eliminar a competência de saída: entender por que o que funcionava ontem parou de funcionar, ler um rastro de erro, isolar uma regressão, distinguir um problema de dados de um problema de lógica. Muitos Product Managers já sabem fazer uma tela ser produzida e não sabem resolver o bug que acabaram de criar.

A assimetria é o coração do assunto: produzir ficou acessível, operar não ficou no mesmo ritmo.

Por que isso importa

Isso dá um critério de entrada mais honesto que o nível de código: não "você saberia escrever isso?", mas "você vai saber se virar quando quebrar, sem mobilizar outra pessoa?". Uma ferramenta que você não saberia consertar não é uma ferramenta pessoal, é uma dívida deixada na mesa do vizinho.

Também nomeia o que se esconde por trás de muitos pedidos de revisão: menos um controle de qualidade do que uma forma de transferir por antecipação a responsabilidade pelo conserto.

Nuances e limites

O assistente assume parte da carga — ele lê o rastro, propõe uma correção, explica o que fez. O limite, portanto, não é absoluto; ele recai sobre os casos em que entender o problema é o pré-requisito da pergunta que você deveria fazer a ele.

E a regra pressupõe que a ferramenta continue pessoal. Assim que um time depende dela, a falha deixa de ser um problema privado, e a responsabilidade individual já não basta para absorvê-la.

Questões em aberto

• Que competência mínima de diagnóstico — ler um rastro, consultar um log, reexecutar uma consulta — é preciso exigir antes de autorizar alguém a colocar em uso uma ferramenta que mandou produzir?