Um assistente de código sugere; uma pessoa aceita, incorpora e assume a responsabilidade. Essa cadeia de responsabilidade não muda porque a pessoa que escreve o rascunho muda, e é melhor que não mude: é a única maneira de garantir que haja alguém a quem recorrer quando o sistema fizer algo inesperado em produção.
O problema surge quando a responsabilidade é implicitamente diluída, sem que ninguém decida explicitamente fazê-lo. Ninguém declara que não é mais responsável pelo seu código. Em suma, o fosso entre aqueles que o aceitam e aqueles que o compreendem aumenta.
Essa confusão é custosa porque consome o orçamento e mina a credibilidade da iniciativa. Quando, seis meses depois, alguém pergunta o que melhorou, a resposta honesta geralmente é "a experiência inicial", e isso não justifica um programa de transformação.
Três mecanismos, todos silenciosos:
A análise torna-se superficial. Quando grandes mudanças ocorrem com frequência, a atitude do revisor muda de "Eu entendo e concordo" para "parece razoável". O relatório DORA de 2024 mediu o efeito agregado: à medida que a adoção de IA aumentou, a estabilidade da entrega caiu 7,2%, associada ao crescimento no tamanho dos lotes de mudanças.
A autoria torna-se imprecisa. Em um dos incidentes, a pergunta "Quem escreveu isso?" é respondida com "Nós criamos isso". Essa resposta impede a continuidade da conversa.
A confiança substitui a verificação. O código funciona nos testes, então presume-se que esteja correto. Mas funcionar e estar correto são coisas diferentes: a segunda inclui o que acontecerá quando o contexto mudar.
No mesmo relatório da DORA, 39,21% dos desenvolvedores declararam pouca ou nenhuma confiança no código gerado. Este é um dado inconveniente, pois aponta na direção oposta: há desconfiança declarada, e ainda assim o volume de código aceito está crescendo.
Não se trata de culpar ninguém. Trata-se da capacidade de responder a quatro perguntas sobre qualquer parte do sistema:
Qualquer pessoa que consiga responder às quatro perguntas é responsável pelo código, independentemente de ter sido escrito por uma pessoa ou por uma ferramenta. Qualquer pessoa que não consiga responder a nenhuma delas não é responsável, mesmo que conste como autora no repositório.
Papel | O que a ferramenta oferece? | O que resta como humano |
|---|---|---|
Projeto | Alternativas e exemplos | Escolher e aceitar a escolha. |
Implementação | Rascunho funcional | Verifique se o produto atende às expectativas da empresa. |
Revisão | Detecção de padrões conhecidos | Avaliação da adequação e das consequências |
Operação | Alertas e diagnósticos | Decidir o que fazer quando algo dá errado |
Responsabilidade | Nenhum | Todos |
A última frase não é retórica. Nenhuma ferramenta compartilha a responsabilidade perante um cliente, um auditor ou um tribunal. A organização é responsável pelo que seu software faz, independentemente de como foi produzido, conforme estabelecido no caso do chatbot da Air Canada, resolvido em 2024.
Ninguém funde o que não consegue explicar. A regra básica. Não é necessário entender todos os detalhes, mas sim ser capaz de responder às quatro perguntas acima.
Cada alteração tem um responsável nomeado. Não se trata de uma equipe. Trata-se de uma pessoa responsável por aquela parte do sistema, a quem se pode fazer perguntas.
Os testes críticos são escritos por uma única pessoa. Se a mesma ferramenta gera tanto a implementação quanto o teste que a valida, o circuito se fecha sobre si mesmo e não verifica nada relevante.
A dimensão da mudança é limitada. É a medida que torna possíveis as três anteriores. Uma mudança importante não pode ser analisada minuciosamente, por melhores que sejam as intenções do analista.
Se sua empresa terceiriza o desenvolvimento, esta conversa tem um impacto contratual direto. Três perguntas para o fornecedor:
Quem é responsável pelos defeitos no código entregue? Um defeito não é uma alteração no escopo. Ele deve ser corrigido sem custos adicionais e documentado por escrito. No nosso caso, é a Garantia Rain: corrigimos quaisquer defeitos no código que entregamos, para sempre.
Você consegue explicar alguma parte do sistema seis meses depois? O teste é simples: peça uma explicação sobre um módulo escolhido aleatoriamente.
Que documentação de decisão é fornecida? Não se trata de uma análise linha por linha, mas sim de explicar por que cada abordagem foi escolhida e o que foi descartado. É isso que permite que outra equipe assuma o controle.
Um fornecedor que aceita essas três condições afirma que mantém a cadeia de responsabilidade intacta. Aquele que as qualifica indica onde estará a lacuna.
Para um diretor técnico que deseja conhecer o estado atual de sua equipe, existe um exercício que leva uma hora: Escolha três partes do sistema aleatoriamente e peça aos responsáveis por elas que respondam às quatro perguntas..
O resultado não mede a qualidade do código. Ele mede algo mais importante: se a organização controla seu sistema ou apenas o possui.
A pessoa que o aceita e o incorpora ao sistema, e a organização que o coloca em produção. Nenhuma ferramenta compartilha a responsabilidade perante um cliente, um auditor ou um tribunal: a empresa é responsável pelo que seu software faz, independentemente de como foi produzido.
Com quatro perguntas: o que isso faz em termos de negócios, por que é assim e qual alternativa foi descartada, o que deixará de funcionar se for alterado e como você sabe que continuará funcionando? Quem conseguir responder a todas as quatro perguntas é responsável por esse código, seja ele escrito por uma pessoa ou por uma ferramenta.
Por meio de três caminhos silenciosos: a revisão torna-se superficial à medida que as mudanças aumentam de tamanho, a autoria fica confusa até que a resposta a um incidente seja "nós o geramos" e a confiança de que os testes passam substitui a verificação de que o comportamento é o que a empresa espera.
Quatro: ninguém mescla o que não consegue explicar, cada alteração tem uma pessoa designada como responsável e não uma equipe, os testes críticos são escritos por uma pessoa e não pela mesma ferramenta que gerou a implementação, e o tamanho das alterações é limitado para que a revisão seja possível.
Eles devem ser responsabilizados por defeitos no código entregue, sem custos adicionais e por escrito, ser capazes de explicar qualquer parte do sistema seis meses depois e fornecer documentação das decisões tomadas e das alternativas descartadas, não apenas comentários no código.
De acordo com o relatório DORA de 2024, 39,21% dos entrevistados expressaram pouca ou nenhuma confiança no sistema. Este é um dado relevante, pois coincide com um aumento no volume de testes aceitos, sugerindo que a desconfiança manifesta nem sempre se traduz em mais testes.
Sua equipe poderia explicar alguma parte do seu sistema? Nossa auditoria técnica avalia a arquitetura, o código, a dívida técnica e a capacidade de manutenção real, por escrito e em até 10 dias úteis. Solicitar auditoria → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
