Enxames de agentes e a nova economia dos modelos
Enxames de agentes que geram milhares de commits de código por segundo estão sendo vendidos como um vislumbre de “fábricas de software”, mas os comentaristas questionam se isso apenas produz enormes quantidades de código de baixa qualidade e dívida técnica mais rápido. Muitos argumentam que esses sistemas dependem fortemente de código existente e especificações detalhadas (como a documentação do SQLite), então ainda não provam que agentes consigam projetar ou implementar software realmente novo. Os principais desafios identificados são verificação, desenho de harness/ferramentas e o julgamento humano escasso sobre intenção e valor do produto, e não a capacidade bruta de codificação.
Enxames de agentes de alto throughput e VCS customizado
- Um novo VCS e 1.000 commits/segundo desencadeiam debate sobre se o gargalo é o controle de versão ou a avaliação e a supervisão.
- Alguns veem um VCS customizado como apropriado para fluxos de trabalho autônomos; outros o consideram um over-engineering (“inventar o universo para fazer um botão”).
- O paralelismo é atraente, mas muitos argumentam que acompanhar o que é bom, ruim ou redundante é a verdadeira restrição.
Busca aleatória vs inteligência orientada (“macacos infinitos”)
- Vários comentários comparam enxames de agentes ao Teorema do Macaco Infinito ou à biblioteca de Borges: gerar oceanos de “slop” para encontrar raras joias.
- Críticos dizem que a busca aleatória é intratável em escalas do mundo real; os modelos só funcionam porque codificam fortes “funções de aptidão” aprendidas com dados de treinamento.
- Há preocupação de que aumentar o throughput sem seleção e verificação proporcionais apenas amplifique lixo.
Experimento SQLite em Rust e preocupações com dados de treinamento
- Muitos questionam a alegação de “apenas a partir da documentação”, observando que reescritas de SQLite e até de Rust provavelmente existem nos dados de treinamento.
- Alguns argumentam que o sistema é essencialmente descompactar conhecimento memorizado e refiná-lo com testes, não realmente construir do zero.
- Outros contrapõem que diferenças de arquitetura e refatoração em várias etapas ainda tornam o resultado da orquestração interessante.
- Vários observam que isso é uma demonstração no estilo benchmark; diz pouco sobre construir sistemas novos ou integrá-los a ambientes caóticos do mundo real.
Especificações, intenção e definição de produto como gargalos
- A especificação de 835 páginas é vista como extremamente detalhada; alguns duvidam que seja mais fácil do que escrever o software diretamente.
- Comentários ressaltam que specs frequentemente surgem ao construir software, e não o contrário, e são mais difíceis de validar do que código.
- Muitos veem a “descrição correta da intenção” e uma boa direção de produto como os verdadeiros recursos escassos, não as linhas de código.
Economia, harnesses e orquestração de agentes
- Modelos de fronteira confiáveis o suficiente para autonomia são vistos como mais caros do que humanos; os custos são amplificados por designs de enxame e caching ruim.
- Alguns defendem agentes hierárquicos, baseados em papéis, e pequenos modelos locais para implementação, com modelos maiores para planejamento.
- Outros relatam melhores resultados com um único agente de longa duração e gerenciamento cuidadoso de contexto, em vez de grandes enxames.
Entusiasmo vs ceticismo
- Entusiastas veem isso como uma fase empolgante de “carro-conceito” e um vislumbre de engenharia automatizada em grande escala.
- Céticos descrevem visões de “fábrica de software” e ferramentas de meta-agentes como hype, procrastinação e queima de tokens, sem grande retorno comprovado no mundo real até agora.