Engineers… Your Software Factory NEEDS Agent Sandboxes to SCALE (exe.dev)
IndyDevDan defende que o próximo salto de alavancagem da engenharia agêntica é rodar a "fábrica de software" (pipelines de agentes mais código executando o ciclo de vida de desenvolvimento) dentro de agent sandboxes (VMs dedicadas via exe.dev), porque só assim o engenheiro sai do loop, ganha isolamento, escala e autonomia reais, em vez de dar aos agentes um cantinho do próprio computador ou um container.
talvez
tem ideias reais e úteis para o Bruno (sandboxes efêmeros, best of N, chave OpenRouter limitada, model stack por tiers e orquestração em três camadas com Claude Code), mas vem embrulhado em vídeo longo, muito repetitivo e com forte promoção do exe.dev e do produto pago do canal.
- Coloca o problema como “onde sua fábrica de software roda”: a maioria dos engenheiros aloca um canto do próprio PC ou depende demais de CI/CD e containers, e ele afirma que o gargalo é o próprio engenheiro quando fica dentro do loop.
- Demonstra ao vivo o padrão “best of N”: dispara um único prompt (redesenhar o app fictício de escrita “Inkwell” segundo o princípio de “quiet room”, interface mais limpa) para cinco configurações de agentes em cinco sandboxes separados (Default, Frontier, Deepest Seek, Open Weights, Top Speed), cada uma resolvendo o mesmo problema para depois fundir/comparar resultados.
- Descreve arquitetura de três camadas: um orquestrador fora do sandbox (na máquina dele), um orquestrador dentro de cada sandbox, e a fábrica de software rodando o ciclo plan/build/test/review/document; usa Herder (multiplexador de terminal), Claude Code como orquestrador de topo e o “pi”/PI agent SDK e harnesses customizados como camada de agentes.
- Insiste que “modelo já não é o jogo”: propõe um “model stack” em três tiers (state-of-the-art, workhorse, lightweight) e destaca o DeepSeek V4 Flash 0731 como workhorse de custo absurdamente baixo (config “Deepest Seek” toda em V4 Flash), citando também Gemini 3.6 Flash e GPT-5.6 Luna como modelos rápidos e baratos, e Opus 5 como state-of-the-art caro (13 minutos na fase de plano em high thinking).
- Mostra falhas reais como parte do argumento: a config Open Weights falhou porque um modelo (referido como “ChemK3”/”Kimmy 3”, provável Kimi K3, grafia incerta) não produziu o JSON esperado, e ele usa isso para justificar o best of N e os “gates” determinísticos sobre sistemas não determinísticos.
- Enfatiza segurança e economia operacional: o “blast radius” fica contido na caixa, as chaves de API são resolvidas com uma chave provisionada do OpenRouter limitada a US$ 50 e destruída ao derrubar os sandboxes efêmeros, e ele valoriza o exe.dev por dar VMs próprias e duráveis (não só 24h como outros provedores), com acesso SSH.
- Repete a distinção entre “agentic engineering” e “vibe coding”: vibe coding é não saber o que o sistema faz e não olhar; engenharia agêntica é saber tão bem que não precisa olhar, pensando em sistemas, observabilidade, reusabilidade, isolamento e escala.
- Admite que o total workflow levou quase 45 minutos e que parte dos jobs não terminou, mostra acesso SSH e Claude Code interativo dentro dos sandboxes para inspecionar cada orquestrador, e trata o vídeo como continuação da “super simple software factory” da semana anterior (open source, link na descrição).
- Fecha com o mantra “scale your compute to scale your impact”, diz que ainda espera lançamentos como DeepSeek V4 Pro e um Qwen 3.8 de ~30B, e enquadra tudo como preparo para uma “era de compute abundante”.
My Super Simple Software Factory (For Agentic Engineers)
IndyDevDan apresenta sua "super simple software factory", um sistema de fluxos de trabalho (AI developer workflows) que combina agentes mais código determinístico para dar mais alavancagem ao prompt e rodar de forma observável, customizável e reutilizável, com o lema "agentes mais código superam agentes sozinhos".
talvez
é o vídeo mais alinhado ao interesse do Bruno em agentes/Claude Code, com padrões concretos (código determinístico validando agentes, saída tipada, workflows reutilizáveis) aplicáveis ao Solomon e às rotinas; note que os nomes de modelos ("Opus 5", "Fable 5", "Kimi K3", "GPT 5.6") são cenário especulativo do vídeo, não lançamentos reais.
- Define software factory como algo cujo único propósito é dar mais alavancagem ao prompt, do nível baixo (encadear poucos agentes) ao alto (um sistema de agentes mais código que opera sem você, às vezes melhor que você).
- Os três princípios de projeto são observabilidade (se você não mede, não melhora, com visão em “swim lanes” de cada workflow), customizabilidade e reusabilidade; mostra um painel que registra modelos, prompts compilados (system e user), config de agentes e custos.
- Distingue as “sub-engenharias” dentro da engenharia agêntica, prompt engineering, context engineering, harness engineering e o que chama de rebranding ruim, “loop engineering”, que segundo ele é só o ciclo de vida de desenvolvimento de software (SDLC).
- Demonstra na prática num app de escrita chamado Inkwell: um workflow “scout” simples (um engenheiro, um agente), depois um plan-build-test para adicionar modo claro com design system, e por fim o SDLC completo (plan, build, test, review, document) para um visualizador de markdown lado a lado.
- Enfatiza que nem tudo precisa ser agêntico, “checagens de portão” (gate checks) determinísticas em código validam o trabalho ao fim de cada fase, com saídas em JSON tipado e validado, e devolvem o trabalho ao agente builder se a validação falha; testes que passam não precisam voltar ao contexto do agente.
- Faz um argumento econômico: você é dono do seu código, mas apenas aluga os modelos de IA, então tratar o código como cidadão de primeira classe reduz custo, tempo e alucinação em escala (a centésima e milésima execução, não a primeira).
- Comentário sobre modelos, e é o dado mais notável para o Bruno: menciona rodar “Opus 5” como planejador (elogia a Anthropic por outro “game breaking model”, metade do preço) mas diz sentir que “Fable 5” ainda está um degrau acima, apesar de os benchmarks apontarem Opus 5 na frente; usa também Kimi K3 (primeiro open weights no topo, via Fireworks), Gemini 3.6 Flash e modelos GPT 5.6.
- O sistema é empacotado como uma skill (SSSF) com comando /install que copia tudo para novos repositórios; ele oferece o código open-source de graça e conclui que “vibe coding” é não saber como o sistema funciona, enquanto engenharia agêntica é conhecê-lo tão bem que você não precisa olhar.
Is Anthropic STEALING Your Data? (While You PAY FOR IT)
Não: segundo o registro público e os termos, Anthropic não "está roubando" dados individuais, mas agrega/anonimiza o que recebe e usa esse mapa de mercado para verticalizar produtos — título clickbait do vídeo.
sim
— é tecnicamente e juridicamente relevante para quem projeta agentes com dados sensíveis; vale analisar ToS (Cleo/ZDR), experimentar open-weights e desenhar control plane para preservar IP.
- Autor parte do princípio “ground truth” e conclui que Anthropic não treina diretamente em seus inputs individuais; usa análise agregada/anônima (Cleo) e publica economic indexes com esses insights.
- Cita Satya Nadella (“paga-se duas vezes: dinheiro e conhecimento proprietário”) e Alex Karp (Palantir: clientes querem controle sobre compute/modelos/dados/”alpha”) para justificar o risco de captura por plataformas.
- Exemplos apontados como cadeia de evidência: Cursor → Claude Code; MCP/Figma usage → Claude Design; Claude Security; Claude Life Science — padrão de verticalização a partir de tendências de uso.
- Processo descrito: 1) ver uso; 2) aprender tendências; 3) entrar no vertical; 4) cortar/limitar acesso — com menções a cortes anteriores e à política ZDR/retention (Fable e 30 dias).
- Distinção operacional: commodity agents (protótipos, CRUD, sem valor IP) versus IP agents (traces, prompts, evals, user insights) — teste proposto: “se um concorrente lesse meu trace, isso importaria?”
- Proposta prática: subir na “AI sovereignty ladder” — do nível assinatura/comercial API → model cloud/LLM gateway → montar open-weights em GPUs alugadas → (ideal) GPUs próprios; recomenda ter control plane, roteador (open router), diversificação e, para IP crítico, possuir pesos.
- Modelos/tecnologias citadas: Anthropic/Cleo/Claude, OpenAI, Gemini, Nvidia, Foundry (MS), cloud providers (AWS/GCP/Azure), open-weights citados (Kimmy K3, GLM 5.2, Minimax, Quinn) e warning contra APIs estrangeiras baratas.
Engineers... STOP Picking GPT-5.6 Sol OR Claude Fable 5… FUSE THEM
Não escolha um único LLM; combine modelos em um "fusion harness" (padrão de agentes) com validação pré-execução para decisões de engenharia mais confiáveis e escaláveis.
sim
Relevante para Bruno porque o padrão "fusion + validação" e a ênfase em posse de harness são aplicáveis à construção de pipelines confiáveis para exegese computacional, comparação intermodelo de interpretações e salvaguarda de IP/traços de trabalho.
- Definição e história: padrão já conhecido (architect–editor, prompt chaining, agent chaining) renomeado por alguns como “model fusion” — cita Devon, OpenRouter (transcrição) e a noção de combinar janelas de contexto/inteligências.
- Ferramenta e comandos centrais: demonstração com o PI coding agent usando três comandos principais: /opinion (perspectivas paralelas), /fusion (consolidar respostas) e /autovalidate (gerar e executar gate de validação antes do build).
- Modelos e benchmark simples: experimentos comparando “Cloud Sonnet 5” / “Claude Fable 5” e “GPT 5.6 Soul” em tarefa Scikit-learn (consenso: Random Forest, Gradient Boost, Logistic Regression) e métricas de token/tempo/custo.
- Caso realista: benchmark de bulk-insert SQLite (1M rows) com X-high em ambos; relato de resultados: Fable entregou respostas com menos tokens e rapidez; Soul gastou mais tokens mas apontou speed-ups extremos (ex.: 250–10.000x; menção de 560x para “max tune gen”).
- Padrão de validação-first: o validador escreve um script gate antes da execução; se falha, volta ao builder — argumento: combate a segunda restrição da engenharia agentic (planejamento e revisão).
- Arquitetura e estratégia: defender a posse do agent harness (sovereign AI), customização do system prompt, micro-SDLCs/ADWs (AI Developer Workflows), e padrões adicionais sugeridos: debate, parallel, coordinate, CEO/verifier agent harnesses.
- Riscos e retórica: forte tom promocional pelo PI coding agent; muitas afirmações de desempenho/segurança não profundamente verificadas; promessa de vídeo futuro sobre se Anthropic/OpenAI “roubam dados”.