A principal responsabilidade de um engenheiro: entregar um código que resista ao escrutínio. Este artigo, do blog mais recente de Simon Willison, explora como os engenheiros de software podem redefinir seus valores e responsabilidades essenciais na era das ferramentas de programação de IA disseminadas. Argumento principal: geração de código barata versus entrega de qualidade cara. Na era da IA, a barreira e o custo de "escrever código" foram reduzidos a um nível extremamente baixo. Simon destaca que simplesmente gerar código e enviar uma solicitação de pull (PR) não tem mais valor algum. Se um engenheiro usa IA para gerar uma grande quantidade de código, mas o entrega para revisão por colegas sem verificação, isso não é apenas uma grave negligência de dever, mas também uma falta de respeito para com os outros. O verdadeiro valor de um engenheiro reside em garantir a correção do código. Como cumprir a responsabilidade de "provar que o código é válido"? Simon acredita que, para provar que um código é válido, duas etapas indispensáveis devem ser rigorosamente seguidas: Etapa 1: Teste manual. Este é o ponto fundamental mais básico. O autor enfatiza um princípio: se você não vir o código sendo executado com sucesso com seus próprios olhos, assuma que ele está com defeito. • Ver para crer: você precisa executar o código você mesmo e observar seu comportamento. • Forneça evidências: Ao enviar código para revisão, você deve fornecer evidências proativamente. Por exemplo, cole os logs de execução do terminal na descrição do PR ou, para alterações na interface do usuário, anexe gravações de tela ou capturas de tela. • Cubra os extremos: Não teste apenas o melhor cenário; experimente os casos extremos que são propensos a erros. Etapa 2: Testes automatizados não são suficientes se realizados apenas com testes manuais. A base de código deve conter testes automatizados que garantam a eficácia contínua. • Testar em vez de verificar: As alterações de código enviadas devem incluir um novo caso de teste. Idealmente, o teste deve falhar antes da alteração do aplicativo (vermelho) e ser bem-sucedido após a alteração do aplicativo (verde). • Ponto forte da IA: Os modelos de aprendizagem de linguagem modernos são muito bons em escrever código de teste. O autor acredita que, dado o poder da IA hoje, usar isso como desculpa para não escrever testes é completamente inaceitável. • Relação complementar: Os testes automatizados não podem substituir completamente os testes manuais; os dois devem ser usados em conjunto e nenhum pode ser omitido. O artigo "Regras de Sobrevivência na Era dos Agentes Programáveis de IA" menciona uma tendência significativa para 2025: a proliferação de agentes programáveis capazes de executar tarefas de forma autônoma. Em resposta a essa tendência, o autor oferece conselhos altamente práticos: • Pense como um mentor: você deve tratar os agentes de IA como seus funcionários juniores. Seu trabalho é treiná-los e ensiná-los a "autovalidar" seu trabalho executando código ou escrevendo testes. • O “gosto” determina a altitude: a IA se destaca na imitação. Se o seu projeto já possui um conjunto de testes bem estruturado e padronizado (o que o autor chama de “gosto”), a IA pode muito bem estender esses testes por meio da imitação. • Aproveite os recursos da ferramenta: Os agentes não se entediam com a escrita de testes como os humanos; eles ficam bastante satisfeitos em fazê-lo. Como engenheiro sênior, você deve aproveitar isso para construir uma boa cultura de testes. Em conclusão: a responsabilidade humana é insubstituível. Não importa o quão inteligente a IA se torne, os computadores jamais poderão assumir a responsabilidade por erros. Somente os humanos podem. Nos dias de hoje, gerar milhares de linhas de código via Prompt leva apenas alguns segundos, mas isso é irrelevante. O que realmente importa é você, como "Humano no circuito", apontando com confiança para o código e dizendo à equipe: "Eu assumo a responsabilidade por este código porque provei que ele funciona." Postagem original do blog
