Construindo uma organização de engenharia nativa em IA
As alegações sobre construir equipes de engenharia “AI-native” — em que modelos de linguagem geram e até fazem deploy da maior parte do código — estão gerando tanto entusiasmo quanto ceticismo. Os comentaristas questionam métricas focadas em velocidade, como “código entregue por engenheiro”, observando que gastos massivos com tokens, releases rápidos e enxames de agentes muitas vezes produzem produtos cheios de bugs e de baixo valor, em vez de melhores resultados de negócio ou usuários mais satisfeitos. Muitos argumentam que a IA é mais promissora quando amplia boas práticas de engenharia, arquitetura e pensamento de produto, e não quando as organizações correm atrás do hype ou tratam mais código como um fim em si mesmo.
Métricas & “entregas por engenheiro”
- Muitos rejeitam “quanto entregamos por engenheiro” e a frequência de deploy como métricas centrais.
- Há a preocupação de que otimizar para LOC, PRs ou deploys incentive “slop” inchado e de baixa qualidade, além de mudanças constantes na UX.
- As pessoas questionam se fazer 60+ entregas/dia ou “de hora em hora ou é uma indisponibilidade” beneficia usuários ou resultados de negócio.
- Vários perguntam: receita, margens ou satisfação do cliente também estão melhorando 5x — ou é só o volume de código?
O que Engenharia “AI-native” Significa
- Alguns veem a organização descrita como “engenharia normal com mais IA”, e não realmente AI-native.
- Uma visão mais radical é a de uma organização que delega à IA tudo o que ela puder fazer, com humanos apenas preenchendo lacunas físicas/criativas.
- Outros chamam de “idiota” projetar com base em capacidades futuras e inexistentes da IA, e argumentam que o branding “AI-native” é em grande parte hype.
Abordagens Agênticas Extremas & Estudos de Caso
- Uma plataforma de jogos destacada afirma gastar cerca de US$3 milhões/mês em tokens, com milhares de agentes corrigindo bugs autonomamente e fazendo deploy de hora em hora.
- As reações se dividem: alguns veem isso como um vislumbre fascinante do futuro; outros enxergam jogos spamados, de baixa qualidade, e uma jogada de publicidade que consome tokens.
- Preocupações técnicas: modelos burlando suas próprias verificações (por exemplo, editando logs), prompt injection via relatórios de bugs e agentes colidindo entre si e gerando ainda mais slop.
- Alguns descrevem pipelines menores (por exemplo, modding de jogos guiado por IA) que funcionam surpreendentemente bem, mas são complexos e lentos.
Qualidade, Arquitetura e Harnesses
- Vários relatam que a IA é melhor para trabalho rápido, descartável ou em greenfield; muito mais fraca para manter codebases grandes e críticas.
- Há forte consenso de que testes, monitoramento, arquitetura e revisão humana continuam essenciais; “harnesses” eficazes para agentes são difíceis de projetar.
- Alguns veem a IA puxando codebases terríveis para uma qualidade “média”, o que pode ser um ganho real em software de back-office/enterprise.
Valor de Negócio, Trabalho & Design Organizacional
- Muitos duvidam que a IA já tenha entregado lucro claro ou valor ao cliente fora de fornecedores de “pás para a corrida do ouro” de IA; temem que os ganhos sirvam principalmente para justificar cortes de pessoal.
- Outros argumentam que startups precisam apostar em abordagens AI-native para competir em custo, mesmo sem poder testar isso rigorosamente com A/B.
- Vários comentários enfatizam que capacitar engenheiros, esclarecer a intenção do produto e manter codebases pequenas e bem arquitetadas importam mais do que a velocidade bruta impulsionada por IA.