A IA está nos forçando a escrever código de qualidade

• À medida que agentes de IA passam a ocupar o centro da escrita de código, práticas antes “opcionais”, como testes, documentação e tipagem estática, agora se tornam elementos obrigatórios
• A exigência de 100% de cobertura de código garante que cada linha seja de fato verificada e sustentada por exemplos executáveis
• Estrutura de diretórios e nomes de arquivos claros facilitam a navegação da base de código pelo LLM e incentivam a organização em arquivos menores
• É importante construir ambientes de desenvolvimento rápidos, efêmeros e concorrentes, para que vários agentes possam trabalhar em paralelo
• O ponto central é manter um ecossistema de código confiável para a IA por meio de sistemas de tipos estáticos e ferramentas automatizadas de controle de qualidade

---

IA e a obrigatoriedade do ‘bom código’

• Há muito tempo os desenvolvedores reconhecem testes, documentação, módulos pequenos e tipagem estática como critérios de bom código, mas na prática isso muitas vezes era deixado de lado
• Porém, agentes de IA não conseguem organizar o código sozinhos com tanta competência, então essas boas práticas se tornam indispensáveis
• Para evitar que os agentes sigam na direção errada, é essencial estabelecer guardrails claros e mecanismos de execução obrigatória
• Com guardrails robustos, os LLMs tendem a convergir apenas para o caminho correto; em ambientes incompletos, eles amplificam os problemas

100% de cobertura de código

• As equipes estão tornando 100% de cobertura de código uma exigência, não apenas para evitar bugs, mas para validar o comportamento de todo código escrito por agentes
• Em coberturas de 95% ou 99,99%, a origem do código não testado fica ambígua; com 100%, cada linha não verificada pode ser identificada com clareza
• O relatório de cobertura vira uma lista do que precisa ser testado, e o LLM precisa sempre apresentar exemplos executáveis ao propor mudanças no código
• Essa abordagem também traz efeitos colaterais positivos, como remoção de código inacessível, explicitação de edge cases e maior eficiência em code review

Namespaces e estrutura de arquivos

• Os agentes exploram a base de código pelo sistema de arquivos, então a estrutura de diretórios e os nomes dos arquivos funcionam como uma interface importante
• Um caminho claro como ./billing/invoices/compute.ts transmite muito mais informação do que ./utils/helpers.ts
• Deve-se priorizar arquivos pequenos e bem definidos, o que permite ao LLM carregar o arquivo inteiro no contexto e evitar perda de desempenho
• Essa organização melhora a velocidade e a precisão da exploração feita pelos agentes

Ambientes de desenvolvimento rápidos, efêmeros e concorrentes

• Em vez do ambiente único de desenvolvimento do passado, o desenvolvimento com agentes passa a funcionar como gestão paralela de vários processos
• Fast: testes e validações precisam rodar rapidamente, e as equipes otimizam para concluir mais de 10.000 assertions em menos de 1 minuto
  • Velocidade garantida com forte paralelização, isolamento rigoroso e camada de cache para chamadas a terceiros
• Ephemeral: com o comando new-feature <name>, é possível criar um novo ambiente em 1 a 2 segundos, com configuração automática e execução do agente
  • Se houver necessidade de configuração manual, a frequência de uso cai drasticamente; por isso, automação total é essencial
• Concurrent: para executar vários ambientes simultaneamente, são necessárias configurações que evitem conflitos de portas, banco de dados, cache etc.
  • Isso pode ser feito com Docker ou com isolamento baseado em variáveis de ambiente

Sistema de tipos end-to-end e controle de qualidade automatizado

• É preciso automatizar o máximo possível de boas práticas, reduzindo a liberdade do LLM e mantendo a qualidade consistente
• Linters e formatadores automáticos devem ser configurados de forma rigorosa, aplicando correções automáticas sempre que o LLM concluir uma tarefa
• Recomenda-se o uso de linguagens com tipagem estática, em especial aproveitando um sistema de tipos forte com TypeScript
  • Nomes de tipos significativos como UserId, WorkspaceSlug e SignedWebhookPayload deixam a intenção do código mais clara
• OpenAPI ajuda a manter a consistência dos tipos entre frontend e backend
• O sistema de tipos e os triggers do Postgres ajudam a garantir a integridade dos dados, enquanto o Kysely gera clientes type-safe
• Todos os clientes de terceiros também devem ter definições de tipos precisas ou ser usados por meio de wrappers

Conclusão: redefinindo a qualidade de código na era da IA

• Agentes são codificadores excelentes e incansáveis, mas seu desempenho depende da qualidade do ambiente
• ‘Bom código’ já não é uma escolha, e sim uma condição prévia para que a IA funcione corretamente
• A configuração inicial pode parecer um fardo, mas é um investimento essencial que foi adiado por tempo demais
• Com apoio da liderança de engenharia, o objetivo deve ser construir bases de código amigáveis para IA

[GN⁺]

Comentários do Hacker News

• A armadilha de alcançar 100% de cobertura é que, se o mesmo agente escreve o código e os testes, pode cair em uma validação auto-contraditória
  Se o agente cria uma lógica errada e também escreve testes errados para validá-la, os testes passam, mas o código continua com erro na prática
  Esse tipo de cobertura só faz sentido quando os testes são escritos antes do código ou quando uma pessoa faz uma validação rigorosa
  Caso contrário, isso apenas cria uma ilusão de confiabilidade

  • Você tem razão, mas a solução não é simplesmente “deixar com humanos” ou “escrever testes antes do código”
    O ponto principal é que pessoas com formas de pensar diferentes validem os pontos cegos umas das outras
    Mesmo que existam vários modelos de IA, no fim eles devem ser tratados como uma só “mente”
    É melhor fazer testes com IA para código humano, testes humanos para código de IA, ou revisar o código uns dos outros
    Ainda assim, mesmo entre humanos, relações de poder podem fazer com que só a opinião de uma pessoa prevaleça, e a IA não impede isso
  • Por isso é preciso testar os testes
    Deve-se inserir bugs de propósito e verificar se eles falham
    Isso não é um problema exclusivo da IA; com humanos acontece o mesmo
    Ainda assim, é bom ver que, graças à IA, muitos desenvolvedores estão aprendendo princípios de engenharia de verdade
  • Parece que a mudança acontece não com 100% de cobertura, mas com 100% de cobertura MC/DC
    SQLite e software aeronáutico buscam esse nível
    Ainda assim, isso ainda não é uma hipótese validada academicamente
  • Testes unitários escritos à mão também têm o mesmo problema
    Por isso é preciso validar cenários reais de usuário com testes de integração ou testes automatizados de UI
    Dados vindos do ambiente de produção ou testes em ambiente sombra também ajudam
  • Já existem boas soluções baseadas em código, como BDD e Acceptance Test
    Antes dos LLMs, a configuração era trabalhosa, mas agora o ROI melhorou
    Como o Uncle Bob enfatizou, é importante investir na estruturação dos testes
    LLMs escrevem testes repetitivos, mas, quando solicitado, também aplicam bem o princípio DRY ou o padrão factory

• É um método que comecei a experimentar ontem: primeiro escrevo a especificação em TLA+/PlusCal e depois peço ao Codex para implementá-la exatamente como está na spec
  Eu digo para ele seguir apenas a especificação, sem criatividade
  O código resultante fica feio, mas correto, e é muito mais rápido do que traduzir isso manualmente
  Mas, quando falta otimização ou fica bagunçado demais, faço alguns ajustes
  Estou especialmente experimentando estruturas de dados sem lock, mas o Codex ainda tenta usar locks, então preciso corrigir isso manualmente
  No fim, eu foco na lógica matemática, e a IA cuida dos detalhes de implementação
  Esse é exatamente o fluxo ideal de “especificação primeiro, código depois”

  • Eu também estou desenvolvendo de forma parecida
    Concordo com o texto de Martin Kleppmann
  • Recentemente tentei iterar com Haskell e Prolog, e seria ótimo existir um grupo para pesquisar LLMs junto com modelagem/verificação
  • O efeito é ainda maior quando o LLM também participa da escrita da especificação
    Nos modelos mais recentes isso funciona bem de verdade, e a eficiência de custo também melhorou de 10 a 100 vezes

• Isso parece alucinação ou papo de vendedor
  Se bugs reais de produção e o custo de manutenção não conseguem forçar código bom, a IA também não vai conseguir
  No nível atual, a IA provavelmente tende mais a piorar o código

  • O problema é a premissa de que “todo mundo sabe o que é código bom”
    Não existe um critério universal de qualidade quando nem o tamanho ideal de um método tem consenso
    Métricas como cobertura de testes também são fáceis de manipular e, se aplicadas errado, podem até ser prejudiciais
  • Cobertura de testes não substitui código bom
    Especialmente quando a IA escreve os testes, isso pode gerar falsa confiança
  • O autor do texto original é CEO de uma empresa de IA, então pode haver viés /s

• Acho que desenvolvimento de software pode ser a única aplicação realmente prática dos LLMs
  Dá para criar um loop de feedback mais rápido do que em outras áreas
  Você faz um plano com o LLM e, algumas horas depois, vê que deu errado, e o LLM diz “pois é, por isso não devia fazer assim”
  É como construir uma casa com padrão elétrico americano e descobrir o problema ao instalar uma lava-louças canadense

  • É por isso que outras áreas da engenharia têm regras rígidas e sistemas de certificação
    Software era relativamente seguro, então desenvolvimento anônimo era possível, mas agora está surgindo uma cultura de assinatura responsável
    No futuro, talvez só quem escrever código inovador e de alto risco receba remuneração alta
  • Mas não entendo por que essa experiência leva à conclusão de que LLM é útil
    A IA continua gerando código sem sentido, a gente depura, ela gera outra coisa sem sentido, e ficamos presos num loop infinito
  • Também dá para instalar uma lava-louças canadense
    Basta que a especificação de corrente elétrica esteja correta para ser seguro
  • Se pensar em simuladores ou gêmeos digitais, também dá para criar um loop de feedback sem construir nada no mundo real
    Ainda assim, acho um alívio poder confirmar o contato com a realidade por meio de testes unitários
  • Dizer que “fora software não existe aplicação prática” é uma afirmação arrogante
    Eu estou estudando circuitos RLC e inerter com LLM

• Muita gente se impressiona ao ver LLMs gerarem código rapidamente, mas velocidade ou volume não são o gargalo da qualidade
  A verdadeira revolução vai acontecer quando a IA produzir código mais preciso do que humanos

  • Ao usar LLMs, o engenheiro se afasta da compreensão da implementação real do sistema
    O valor de verdade vem de saber como o código funciona
    Entre engenheiros que ficam apenas supondo durante uma reunião, o momento mais valioso é quando alguém abre o código real e mostra o que está acontecendo

• Talvez “código bom” seja, no fundo, código otimizado para a memória de trabalho limitada dos humanos
  O modelo consegue ver todo o contexto de uma vez, então não tem essa limitação
  Se a janela de contexto ficar 100 vezes maior, esse debate talvez perca importância

• Fico preocupado que exigir 100% de cobertura de um LLM possa cristalizar premissas erradas
  Ainda assim, se houver revisão humana, dá para dizer “isso está errado, então vamos apagar os testes e reescrever”?

  • Sim, ainda há revisão humana dos casos de teste
    O LLM ajuda a escrever o PRD como se estivesse entrevistando, para deixar escopo e expectativas claros
  • Na prática, LLMs criam muitos testes sem sentido, tipo “1=1?”

• “Boas práticas” mudam conforme o ambiente técnico
  Agora que escrever código ficou mais fácil, 100% de cobertura pode ser mais útil para LLMs
  Testes dão ao LLM um objetivo claro e tornam as interações seguintes mais seguras

  • Em sistemas que evoluem por muito tempo, testes são uma linha de vida
    Cada teste referencia tickets antigos de bug e garante que as correções continuem preservadas
  • “Boas práticas” têm padrões parecidos mesmo quando a implementação difere
    Se você der cenários ao LLM, na maioria dos casos ele vai gerar código com qualidade semelhante
    Diferentemente da arte criativa, software é uma indústria especialmente adequada à automação

• Ao ver o título, achei que o texto diria que “para a IA ser eficaz, nós precisamos escrever bom código”
  Na prática, o Claude erra com frequência quando há nomes de variáveis ambíguos ou código sem lógica clara
  Se a variável se chama “iteration_count” mas guarda uma soma, a IA se confunde
  No fim, código limpo ajuda tanto a IA quanto humanos

  • Graças à IA, as equipes passaram a dar mais atenção à documentação e à manutenção de comentários
    Como a IA usa documentação interna como recurso de aprendizado, agora documentação atualizada é vista como essencial
    Antes isso tinha prioridade baixa, mas hoje afeta diretamente a qualidade do modelo
  • Humanos lembram do contexto de um código que já viram, mas a IA precisa aprender de novo a cada sessão
    Ainda assim, com o tempo isso também deve melhorar
  • Um método eficaz é deixar clara a intenção e a lógica em assinaturas de métodos e comentários
    Assim, aumenta a chance de o LLM implementar corretamente de primeira

• Este texto revela a compreensão rasa de engenharia das empresas de prompt
  100% de cobertura não verifica todas as combinações de entrada
  Apenas executa todas as linhas com alguns exemplos
  No fim, o que seria necessário é prova formal, mas isso custa absurdamente caro e LLMs não servem para isso

  • Então qual é a solução? Um sênior olhar o PR e dizer “LGTM” é apenas um teste emocional
    Em vez disso, criar um ambiente de desenvolvimento reativo aos testes pode abrir uma nova era de ouro
    Se surgir problema de cobertura, dá para expandir depois
    O ideal é configurar os testes da forma mais minuciosa possível desde o começo
  • É exagero dizer que LLMs não servem para verificação formal
    Já existem muitas tentativas de conectá-los a proof assistants
    Mesmo quando a especificação tem pequenos erros, na maioria das vezes eles ainda geram resultados úteis