Parte de “Conquistando a Entropia”

A maioria dos problemas que tenho com código gerado por IA está relacionada à confiança. Confio na pessoa que escreveu este ticket? Confio que o engenheiro que abriu este PR entendeu o ticket e guiou o agente de codificação para implementá-lo corretamente? Confio na implementação do agente de codificação? Confio na nossa suíte de testes para detectar regressões antes que cheguem à produção? Confio no nosso CI/CD para construir, testar e implantar corretamente nossas alterações? Confio na nossa configuração de observabilidade para nos alertar quando o código gerado por IA quebrar a produção? Confio no SRE de IA (Engenheiro de Confiabilidade do Site) para diagnosticar corretamente o problema e nos ajudar a mitigá-lo? Confio no Git Hub para não ter um incidente quando mais precisarmos? A confiança é difícil de conquistar e fácil de perder. Por isso, acho crucial fomentar uma cultura de confiança dentro da equipe de engenharia. Você deve confiar nos engenheiros para fazer a coisa certa.

Incentivando a Responsabilização

Acho útil comunicar claramente algo como: “Você é responsável pelo que envia. Se isso quebrar a produção e você escreveu o PR, você deve estar lá para consertar.”

Se os engenheiros são responsabilizados pelo código que enviam, eles devem ter a autonomia para produzi-lo com seus métodos preferidos. Mesmo que você não seja entusiasta de IA, tem que admitir que agentes de IA geram muito código muito rápido. Código ainda precisa ser gerado, e a expectativa é que agora é barato gerar muito dele. Para lidar com isso, os engenheiros devem ter permissão para implementar algumas medidas para garantir que a qualidade da base de código não se degrade. Em uma organização saudável, os engenheiros devem confiar uns nos outros para apenas enviar código de qualidade razoável. Digo razoável porque não é pragmático obsessar com qualidade e tentar enviar sempre código 100% perfeito. Mesmo antes dos agentes de codificação, a maioria do código já era uma bagunça cheia de bugs! Então é compreensível quando uma solução “boa o suficiente” é entregue. Frequentemente, trocamos velocidade de entrega por qualidade, e incorremos em alguma dívida técnica.

Aqui estão algumas práticas que achei úteis para facilitar a responsabilização de engenharia nesta nova era de codificação:

Diretrizes de Codificação

Ter uma estratégia de tecnologia clara: reserve um tempo para decidir o que importa para sua base de código e invista em diretrizes claras. Tanto para humanos quanto para os agentes de codificação. Mesmo que os humanos não leiam as diretrizes, seus agentes de codificação lerão, e as seguirão (na maior parte).

Ferramentas Determinísticas

Fazer uso intensivo de ferramentas determinísticas para garantir qualidade de código. Linguagens tipadas, linters, detecção de código morto, varreduras de segurança, CI/CD, e assim por diante. Todas essas ferramentas existiam antes dos agentes de codificação e nos ajudam na luta contra código de baixa qualidade. (Fique atento para um post de acompanhamento com recomendações específicas!)

Impor PRs Pequenos

Capacitar os engenheiros a rejeitar PRs não revisáveis. Se possível, codificar este critério para que quaisquer PRs não revisáveis sejam imediatamente rejeitados. Claro, certifique-se de deixar espaço para exceções.

Assumir os Testes

Escrever casos de teste à mão. Isso é semelhante ao trabalho de um analista de negócios. Pense profundamente sobre a funcionalidade e defina cenários de teste adequados. Discuta isso dentro da equipe. Agentes de codificação podem implementar os testes, mas eles devem ser definidos por humanos.

Gosto no Produto

Trabalhar em tandem com produto para ter uma visão de produto coerente. É muito fácil enlouquecer com IA e implementar qualquer funcionalidade que venha à mente. Certifique-se de implementar apenas funcionalidades úteis que realmente tragam valor aos usuários!

Protótipo

Código descartável. Como o código é muito fácil de gerar agora, é uma boa oportunidade para tentar abordagens diferentes. Não deixe apenas o agente de codificação gerar uma solução. Por exemplo, tente três abordagens radicalmente diferentes e escolha a que melhor se adapta ao problema e ao sistema existente.

Focar no Resultado

Seja pragmático sobre o resultado. Às vezes o código não é o resultado. O resultado é um relatório, ou uma ferramenta que ajuda você a realizar outra coisa. Para casos como este, a qualidade do código não é tão relevante desde que o resultado seja útil.