Pergunte ao HN: Como lidar com publicar código escrito por IA que você não entende?
À medida que os grandes modelos de linguagem aceleram rapidamente o desenvolvimento de software, muitos engenheiros agora estão publicando código que não escreveram — e muitas vezes não entendem totalmente. Os comentários vão de “se os testes passam, publique” até insistir que liberar código opaco gerado por IA é negligência, com mitigações propostas incluindo testes automatizados mais pesados, verificação formal, controle arquitetural rígido e revisão multiagente. Por trás do debate sobre ferramentas, há uma preocupação mais profunda: se essa mudança está corroendo o domínio e a responsabilidade no software, ou simplesmente elevando os engenheiros a um nível maior de abstração, voltado para design e especificação.
Testes, verificação e “se funciona”
- Muitos argumentam que testes automatizados pesados são a única forma sensata de publicar código escrito por IA: grandes suítes de testes unitários e de integração, farms de teste cross-arch, fuzzing, teste de caos, teste de mutação e testes e2e.
- Alguns adotam TDD rigorosamente, inclusive para agentes: o agente escreve primeiro testes que falham e depois o código até que eles passem.
- Outros se preocupam com deixar o mesmo LLM escrever tanto o código quanto os testes, pois eles podem compartilhar pontos cegos; as mitigações incluem:
- Agentes separados de “código” e de “teste”.
- Vários LLMs diferentes em ciclos de revisão adversariais.
- Injetar falhas intencionalmente e verificar se os testes as detectam.
- Vários insistem que testes sozinhos não são suficientes: eles não verificam o design, não conseguem provar a ausência de vulnerabilidades, e testes escritos por IA muitas vezes são fracos ou autojustificativos.
Arquitetura, design e o papel humano
- Um padrão comum: humanos desenham a arquitetura e as abstrações (“esqueleto”), e os LLMs preenchem as implementações (“carne”).
- As pessoas enfatizam planejamento antecipado: documentos de design de funcionalidades, planos de implementação, diagramas de arquitetura, invariantes e contratos; depois os LLMs implementam dentro desses limites.
- Alguns comparam isso ao trabalho de principal engineer: você entende a intenção e a estrutura, não cada linha.
- Outros dizem que, se você não entende o código, você é efetivamente um gerente/autor de especificação, não um engenheiro.
Qualidade, débito técnico e segurança
- Entusiastas relatam grandes ganhos de velocidade e afirmam que a qualidade pode ser alta com bom planejamento e boas proteções.
- Céticos veem “slop” e temem uma explosão de débito técnico, arquiteturas frágeis e enorme custo futuro de manutenção.
- Há debate sobre segurança: alguns preveem CVEs “épicos” vindos de código de IA não revisado; outros observam que o código escrito por humanos já é inseguro e argumentam que o problema de raiz é a falta de padrões profissionais, não a IA em si.
Ferramentas, guardrails e fluxos de trabalho
- As pessoas constroem frameworks de guardrails: análise estática, linters, limites de cobertura, scanners de CVE, verificações de desempenho, painéis de observabilidade, staging/feature flags, backups e rollback automatizado.
- Alguns usam “equipes” de agentes: construtor, revisor, QA e um agente de nível superior “CTO”/gerente coordenando tarefas.
- Surgem novas ferramentas para:
- Resumo e categorização de PRs.
- Visualização de arquitetura e do grafo de chamadas.
- Exploração interativa de código e “explicadores” para subsistemas complexos.
- Vários agora passam menos tempo digitando código e mais tempo em testes, revisão de design e monitoramento.
Normas profissionais e ansiedades de carreira
- Um lado: “nunca publique código que você não entende”; fazer isso é negligente e rebaixa a profissão.
- O outro: em sistemas grandes, você nunca entendeu completamente todo o código publicado (dependências, trabalho de colegas), então isso é uma extensão da prática existente.
- Há uma forte corrente de ansiedade: medo de virar “proxies de carne” para agentes, de degradação da cultura de engenharia e de uma futura desvalorização dos papéis de SWE em comparação com PM/“engenheiro de manutenção”.
- Outros abraçam a mudança, argumentando que recusar usar IA limita a carreira e que a verdadeira alavanca agora está em design, especificação e em construir processos robustos em torno de agentes.
Nível de abstração e diferenças de domínio
- Muitos comparam a codificação com LLM a saltos de abstração do passado (compiladores, ORMs, frameworks), mas críticos respondem que LLMs são caixas-pretas não determinísticas, ao contrário de compiladores.
- A tolerância a código escrito por IA e mal compreendido depende fortemente do raio de explosão:
- Mais relaxado para UI, ferramentas internas, dashboards, recursos sociais.
- Muito mais rigoroso para sistemas de pagamento, livros-caixa, infra, domínios tipo aeroespacial/médico.