DEV Community: Alex Pimenta

Seu agente pode fazer deploy. Mas consegue desfazer o estrago?

Alex Pimenta — Sat, 31 Oct 2026 11:29:38 +0000

O caso Spawn colocou agentes autônomos em produção no centro do debate. A lição mais útil não está no volume de mudanças: está na diferença entre reverter código e reverter consequências.

Jacob Sansbury descreveu, no final de outubro, como a Spawn opera: dez pessoas, cerca de US$ 3,1 milhões em tokens no mês, 77 mil mudanças substanciais em 30 dias — em média algo como 108 por hora. A "fleet" de agentes permanentes tem permissão real nos sistemas, altera código ao vivo e envia para produção com frequência alta. O texto circulou com força no X; Simon Willison destacou o caso como uma das bordas mais afiadas do que dá para fazer com modelos da geração Fable.

O número que importa para quem opera agentes no dia a dia não é o 77 mil. É o 0,9%. Ao longo de um ano, 1.055 de 123.548 mudanças foram revertidas. A empresa afirma que consegue desfazer uma mudança quebrada em cerca de 30 segundos, no ponto exato do problema. A suíte completa roda a cada 15 minutos. Agentes que não escreveram a alteração tentam quebrá-la de propósito. Quando um monitor ou log dispara, um agente assume o incidente. O desenho assume falha; o que não assume é falha que permanece.

Isso só fecha porque a maior parte do que o agente toca é reversível barato. Código, configuração, estado interno do produto — dá para voltar atrás rápido e com pouco dano colateral. O que toca o mundo externo e não desfaz (pagamento, por exemplo) continua atrás de um conjunto pequeno de portões rígidos, hard-coded. Krish Subramanian resumiu o ponto em uma frase útil: a lista do que você consegue reverter em 30 segundos é o seu orçamento de autonomia.

A maioria dos times copia o "agente faz deploy" e esquece a segunda metade. Sem rollback local, sem teste contínuo que realmente exercita o caminho de recuperação, sem distinção clara entre efeito desfazível e efeito permanente, autonomia vira exposição. O agente pode produzir a alteração; o sistema precisa conseguir detectar, conter e recuperar antes que a consequência saia do perímetro em que o undo ainda é barato.

Para quem já deixa o agente propor ou aplicar mudança, a pergunta prática deixa de ser "ele consegue shipar?" e passa a ser: se essa mudança quebrar, em quanto tempo e com quais perdas o time volta ao estado anterior — e o que acontece se a falha já tiver atravessado a fronteira do que não se desfaz.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada — do contexto à governança de agentes — consultando a série clicando na imagem abaixo:

Cupom de 30% OFF: LEIA30
Disponível também no Kindle Unlimited

Referências

Jacob Sansbury, How I Built the Most AI-Pilled Company in the World (X, out/2026) — Spawn / fleet de agentes.
Simon Willison, cobertura do caso Spawn (simonwillison.net, 29/10/2026).
Discussão pública sobre taxa de revert (~0,9%) e portões hard-coded para ações irreversíveis.

Tags

#EngenhariaDeSoftware #IA #AgentesDeCodigo #Deploy #Rollback #Spawn #SoftwareEngineering #AI #CodeAgents #Reversibilidade

Seu agente continua trabalhando. Mas ainda está avançando?

Alex Pimenta — Thu, 29 Oct 2026 07:59:53 +0000

Executar mais passos não garante aproximação da solução. Controle de custo e de progresso passa por detectar quando a trajetória estagnou.

Um relato circulou no TLDR descrevendo execuções em que o agente repetiu a mesma consulta SQL bem-sucedida centenas de vezes — 113 em um caso, 254 em outro. Sem o texto completo, o episódio serve só como ilustração: atividade intensa, resultado que não muda. O ponto útil não é a frequência desse bug em produção; é a diferença entre "ainda está rodando" e "ainda está progredindo".

O paper TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents (Li et al., UC Berkeley / Microsoft Research / Microsoft Security, arXiv 2610.22732) trata exatamente desse tipo de desperdício em sequências reais de tarefas. Em vez de avaliar o agente em tarefas isoladas, os autores olham repositórios onde o mesmo ambiente e os mesmos padrões se repetem ao longo de várias sessões. O custo recorrente aparece em três frentes: rediscoberta de fatos do ambiente (comando que funciona aqui, variável obrigatória, ordem de build), ferramentas que permanecem irrelevantes e loops de falha improdutivos — o agente insiste no mesmo caminho sem alterar o estado útil do problema.

TokenEconomizer atua como controlador externo, sem alterar pesos do modelo nem o código do loop do agente. Três mecanismos: injetar micro-skills aprendidas de sessões anteriores no mesmo repositório; podar tools que consistentemente não ajudam; intervir quando a trajetória entra em loop de falha. Em Claude Code, Codex e GitHub Copilot CLI com modelos frontier, o método reportou redução média de custo de 18,4-30,9% em SWE-Bench, com Pass@1 comparável ou melhor em 4 de 5 combinações agente-modelo. A economia apareceu em todos os repositórios testados; em web e auditoria de segurança, a faixa foi 6,4-21,2% conforme a estrutura das tarefas.

O desenho importa para quem opera agentes no dia a dia. Limite de tokens ou de passos corta custo de forma cega e pode interromper trabalho que ainda avançava. Intervir só quando o humano "acha que está travado" depende de atenção intermitente. O que o paper formaliza é política baseada em experiência do próprio repositório: o que já falhou de forma repetida, o que já foi descoberto e não precisa ser redescoberto, quando a sequência de ações deixou de mudar o estado do problema de forma útil.

Progresso, nesse sentido, não é número de tool calls nem de linhas geradas. É mudança observável em direção ao objetivo — teste que passa, erro que some, arquivo que deixa de ser reescrito em loop, consulta cujo resultado informa a próxima decisão em vez de ser reexecutada idêntica. Sem um sinal explícito de estagnação (mesmo que imperfecto), o agente pode consumir orçamento enquanto o humano só vê "ainda está trabalhando".

Para times que já medem custo por tarefa, o próximo passo concreto é registrar, por repositório, quantas sessões rediscobrem o mesmo fato operacional e quantas vezes a mesma ação é repetida sem alteração de estado. Aí a decisão de interromper ou redirecionar deixa de ser só feeling no meio do turno.

Leia o artigo mais aprofundado clicando abaixo.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada do contexto à governança de agentes consultando a série clicando na imagem abaixo:

Cupom de 30% OFF: LEIA30
Disponível também no Kindle Unlimited

Referências

Li et al., TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents, arXiv:2610.22732 (2026) UC Berkeley, Microsoft Research, Microsoft Security.
Projeto: tokeneconomizer.github.io

Tags

#EngenhariaDeSoftware #IA #AgentesDeCodigo #TokenEconomizer #CustoDeAgentes #SWEBench #SoftwareEngineering #AI #CodeAgents #Progresso

Seu agente usa menos contexto. Por que a conta aumentou?

Alex Pimenta — Wed, 28 Oct 2026 15:06:02 +0000

Cortar histórico pode invalidar estados de cache e forçar recomputação. A otimização que falta costuma estar abaixo do prompt.

A intuição mais comum ao controlar custo de agentes é simples: mande menos texto. Resuma o histórico. Descarte respostas antigas de ferramentas. Mantenha só as últimas N rodadas. Em vários benchmarks isso até enxuga o payload. Em outros, a fatura sobe.

O paper Cache Engineering for Agents (Tsinghua e CUHK, arXiv 2610.28577, 20 out 2026) formaliza o mecanismo. Quando o sistema edita o prefixo do histórico — remove ou resume trechos anteriores —, estados de key-value (KV) cache já calculados para o que vinha depois deixam de ser válidos. Para continuar a trajetória, o motor precisa fazer re-prefill: processar de novo tokens que, no texto final, ainda estão presentes. Menos caracteres enviados não implica menos trabalho de atenção. Em um experimento diagnóstico com GPT-OSS-120B em tarefas do BrowseComp-Plus, uma política que mantinha só as doze rodadas mais recentes de ferramentas custou cerca de 1,85 vez o baseline de contexto completo. O agente não "escreveu mais"; o sistema reprocessou o que o cache tinha perdido.

Os autores propõem tratar o cache ativo como objeto de engenharia, não só o texto da trajetória. Operações como drop (excluir trechos selecionados da atenção futura sem reescrever o histórico lógico) e repos (ajustar encodings de posição do que permanece) permitem controlar o KV sem disparar re-prefill do que foi mantido. O serving co-desenhado (AKV) expõe interface compatível com APIs existentes e gerencia reuso, eviction e restauração por baixo. Nos experimentos reportados, uma política de rolling-drop em respostas de ferramenta melhorou a média dos scores em 1,7 ponto e reduziu o custo médio em 27,7% frente a sumarização disparada por limiar de tokens. Há ganho de throughput e de latência P95 no setup deles; política refinada por self-improvement cortou mais 7,1% de custo em relação ao desenho manual.

No mesmo período a AWS publicou padrões de prompt caching para agentes em Bedrock (26 out 2026). O ângulo é complementar: prefixos estáveis (instruções, definições de tools) marcados de forma explícita ou implícita deixam de ser reprocessados a cada turno, com redução de custo e latência de input quando o prefixo de fato reutiliza. A condição prática é a mesma do paper acadêmico sob outro nome — o que muda no meio do prompt quebra o reuso a partir dali. Timestamp, ID de sessão ou tool list reordenada no bloco "estável" invalida o que vinha depois.

Para quem opera agentes em produção, a leitura útil não é "sempre mantenha o contexto inteiro" nem "sempre resuma". É medir onde a edição do histórico está gerando re-prefill, e separar o que pode cair do cache sem reprocessar o restante. Políticas de drop seletivo em tool results, breakpoints de cache em instruções e tools, e observação de custo por turno (não só tokens enviados) passam a fazer parte do desenho. Em stacks que ainda só oferecem sumarização por limiar, o trade-off documentado no paper — texto menor, conta maior — continua no caminho crítico.

O texto do prompt é só uma camada. O custo mora no que o runtime recalcula quando essa camada mexe no prefixo.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

Cupom de 30% OFF: LEIA30
Disponível também no Kindle Unlimited

Referências

Fu et al., Cache Engineering for Agents, arXiv:2610.28577 (20 out 2026) - Tsinghua / CUHK; AKV; rolling-drop vs. sumarização.
AWS Machine Learning Blog, Groundhog Day for AI agents: Prompt caching patterns... on Amazon Bedrock (26 out 2026).

Tags

#EngenhariaDeSoftware #IA #AgentesDeCodigo #Cache #KVCache #PromptCaching #LLM #SoftwareEngineering #AI #CustoDeAgentes #Bedrock

Seu agente está adivinhando o que o analisador já sabe

Alex Pimenta — Tue, 27 Oct 2026 01:37:57 +0000

O Type Server Protocol está em discussão e expõe uma oportunidade concreta: consultar tipos e imports por interface estruturada, em vez de reconstruir essa informação só a partir do texto.

Quando o agente precisa do tipo de uma expressão, da declaração de um símbolo ou do arquivo que um import resolve, o caminho mais comum ainda é ler trechos de código e inferir. Às vezes acerta. Às vezes inventa um tipo plausível, resolve o import errado ou propõe um rename que quebra usos fora do contexto que ele carregou. O analisador estático do projeto — Pyright, tsserver, rust-analyzer, gopls — já calculou isso com precisão de compilador. O agente, na maioria dos fluxos atuais, não pergunta a ele.

O Type Server Protocol (TSP), documentado no repositório do Pylance, formaliza exatamente essa pergunta para Python. É JSON-RPC, no mesmo estilo do Language Server Protocol, com métodos sob o prefixo typeServer/: tipo computado em um nó, tipo declarado de um símbolo, tipo esperado no contexto, resolução de import, search paths. O cliente abre documentos pelo LSP de sempre e, na mesma conexão, pede dados de tipo sem passar por hover de editor nem por grep. A especificação 0.4.1 descreve snapshots, canais somente leitura e convenções de posição alinhadas ao LSP. Pyright já expõe um type server separado (pyright-typeserver) pensado para esse uso.

A ideia não é nova em espírito. O LSP já entrega go-to-definition, referências e diagnósticos para IDEs há anos; o que muda é tratar o agente como cliente de primeira classe dessas APIs, e não como um leitor de arquivos que tenta reimplementar análise semântica com tokens. CircleCI e outros já documentaram o ganho de ligar Claude Code (e ferramentas similares) a language servers: menos busca probabilística, mais resposta determinística sobre o grafo de tipos do projeto. O TSP afina isso para quem precisa de tipo puro — não só de features de editor.

Na prática, a diferença aparece em refactors e em mudanças que cruzam módulos. Pedir o tipo esperado no ponto de chamada, ou a lista semântica de usos, custa uma ida ao servidor. Reconstruir a mesma informação a partir de trechos lidos custa contexto, tempo e risco de erro silencioso. Times que já pagam o custo de manter o language server no CI e no IDE têm pouco a ganhar em fazer o agente "adivinhar" de novo o que o analisador acabou de calcular.

Há limites claros. TSP, no estado atual da especificação pública, é focado em Python e no ecossistema Pylance/Pyright. Outras linguagens seguem pelo LSP genérico ou por protocolos paralelos (há propostas no estilo "language server for AI" que empacotam call graph e impacto em uma chamada). Nem todo ambiente de agente expõe ainda o cliente TSP ou LSP de forma estável; em muitos casos o time ainda precisa montar a ponte. E tipo correto no snapshot não garante que a mudança proposta preserve comportamento em runtime — só reduz a classe de erro em que o modelo erra a forma do programa antes mesmo de editar.

Para quem opera agentes no dia a dia, o checklist útil é curto: o agente consulta o analisador antes de propor alteração de tipo ou de import? A resposta que ele usa está amarrada a um snapshot do workspace? Quando a ferramenta especializada existe, a política do time é "consultar" ou "adivinhar e revisar depois"?

A especificação está no ar. O custo de não usá-la, em bases tipadas, é continuar pagando inferência onde já existe dado estruturado.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

Cupom de 30% OFF: LEIA30
Disponível também no Kindle Unlimited

Referências

Microsoft / Pylance - Type Server Protocol (spec no repositório pylance-release; typeServerProtocol.ts, tsp.json).
Pyright type server (pyright-typeserver).
Discussões recentes em Hacker News e cobertura técnica sobre TSP e LSP com agentes de código (out 2026).

Tags

#EngenhariaDeSoftware #IA #TypeServerProtocol #LSP #Python #Pylance #AgentesDeCodigo #SoftwareEngineering #DevTools #TypeChecking

A Anthropic e a Theorem usaram o Claude para gerar provas formais em 123 bibliotecas do OSS-Fuzz.

Alex Pimenta — Sun, 25 Oct 2026 15:14:17 +0000

Claude produziu provas verificáveis para propriedades de segurança em 123 bibliotecas. O avanço é real, mas desloca o gargalo: o software atende estritamente à especificação formal, mas a especificação pode ignorar vetores reais de falha.

A Anthropic publicou, em 22 de outubro de 2026, o resultado de uma colaboração com a Theorem: Claude gerou provas formais de que 239 pontos de entrada de fuzz test, em 123 bibliotecas do OSS-Fuzz, não crasham para qualquer input abaixo de 64 MB. As provas foram escritas em Rocq, checadas pelo kernel do assistente de prova, e operam no binário compilado para RISC-V — não no código-fonte. São cerca de 180 milhões de linhas de prova no total; uma prova típica passa de 600 mil linhas para um binário mediano de 18 mil instruções.

O pipeline parte do fuzz test que o projeto já tinha. Esse teste vira enunciado formal: sob o modelo de processo Linux e de CPU RISC-V da Theorem, o programa termina sem erro de memória e sem falha de asserção, para todo input no limite. Claude escreve a prova; o Rocq confere se ela bate com a especificação. No caminho, o modelo encontrou e corrigiu bugs — incluindo rediscovery de CVE em libexpat e falhas que anos de fuzzing não tinham pegado.

A prova, porém, demonstra exatamente a propriedade que foi formulada. Single-thread. Binário estático. Orçamento de memória fixo. RISC-V e Linux modelados. Input até 64 MB. Fora desse recorte — multi-thread, glibc em x86/ARM, cenários que a especificação não nomeou — a garantia não se estende. A própria Anthropic deixa isso explícito: "formally verified" não é sinônimo de "sem bug em qualquer uso real".

Isso muda a conversa sobre verificação assistida por IA. Passar no teste deixa de ser o teto quando dá para provar ausência de crash num envelope definido. O trabalho caro e humano migra para outro lugar: escrever a especificação certa, escolher o que entra no teorema e o que fica de fora, e decidir se as hipóteses (modelo de SO, arquitetura, limites de input) cobrem o risco que o time de fato aceita. A ferramenta verifica o artefato. Quem define o que precisa ser verdadeiro continua sendo engenharia.

Para quem opera agentes de código e pipelines de segurança, o recorte prático é direto. Quando o time adotar prova formal gerada por modelo, o checklist deixa de ser só "o kernel aceitou?" e passa a incluir: quais propriedades foram enunciadas, sob quais premissas, e o que o negócio ainda precisa tratar fora do envelope formal. Sem isso, a prova vira um selo sobre um contrato incompleto.

Leia o artigo completo clicando na imagem abaixo:

Referências

Anthropic + Theorem, LLMs are making formal software verification feasible at a much larger scale (22 out 2026) 239 entry points, 123 bibliotecas OSS-Fuzz, ~180M linhas Rocq, RISC-V assembly.
Theorem oss-verify-proofs (subset público).

Cupom de 30% OFF: LEIA30
Disponível também no Kindle Unlimited

Tags

#EngenhariaDeSoftware #IA #VerificacaoFormal #Claude #Anthropic #Seguranca #OSSFuzz #Rocq #ProvasFormais #SoftwareEngineering #AI #FormalVerification #DevSecOps #Backend #RISC-V #Teorema #Especificacao

PHP2Shell e o resto: o que quebrou no runtime e o que fazer agora

Alex Pimenta — Fri, 23 Oct 2026 13:09:20 +0000

Em 21 de outubro de 2026 o PHP publicou patches de emergência para duas falhas críticas no próprio interpretador: CVE-2026-109618 e CVE-2026-109619, batizadas pela comunidade de PHP2Shell. CVSS 9.2 cada uma. O ponto que muda o jogo: o ataque não depende do seu código. Em vários cenários (especialmente Apache com mod_php), a requisição maliciosa é processada antes de qualquer linha da aplicação rodar. Login, middleware e validação de input não entram no caminho.

CVE-2026-109618 é corrupção ligada a out-of-memory. O PHP usa longjmp() para abortar quando estoura o memory_limit. Se isso acontece no meio da montagem interna da requisição (por exemplo no parse de multipart/form-data), a limpeza posterior trata dados pela metade como válidos. Resultado: use-after-free e, nas condições certas, execução remota de código sem autenticação. A CVE-2026-109619 é estado global obsoleto: ponteiros de uma requisição sobrevivem depois que a memória foi liberada; a próxima requisição no mesmo worker reutiliza esse estado. Um dos caminhos confirmados passa por session.upload_progress (ligado por padrão) e, no 8.5, por fatal_error_backtraces.

Versões afetadas: 8.2.x antes de 8.2.35, 8.3.x antes de 8.3.36, 8.4.x antes de 8.4.27, 8.5.x antes de 8.5.12. Ramos mais antigos (8.1 e abaixo) também, com backports de código-fonte para 7.4, 8.0 e 8.1 — sem release oficial compilado. SAPIs em risco: mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. Relatos de exploração tentada já circularam; a superfície é enorme porque o bug está no engine, não no WordPress, Laravel ou no script que você escreveu.

Isso não substitui o que já matava aplicação PHP há anos. SQL injection por concatenação de string, XSS por saída sem encoding contextual, inclusão remota de arquivo e funções perigosas habilitadas (exec, system, shell_exec) continuam no Top 10 OWASP e no dia a dia de invasão. PHP2Shell só deixa claro que "aplicação limpa" não basta se o runtime estiver desatualizado.

O que fazer, na ordem

Atualizar o runtime. Única correção completa. Subir para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (conforme o branch). Depois reiniciar todos os workers — processo antigo continua com o código vulnerável em memória. Em hospedagem compartilhada, cobrar o painel ou o provedor; em container, rebuild da imagem base.
Mitigações parciais se o patch ainda não for possível (não substituem o update):
- session.upload_progress.enabled = 0 e reinício dos workers
- no 8.5: fatal_error_backtraces = 0
- pm.max_requests = 1 (ou vida curta do worker) para reduzir a janela de reuso de estado
- onde fizer sentido: bloquear multipart/form-data no proxy se a app não recebe upload
- Aviso oficial: cada medida cobre só parte dos braços do ataque.
Endurecer o php.ini. expose_php=Off, display_errors=Off em produção, logs em arquivo, disable_functions com exec,passthru,shell_exec,system,proc_open,popen (e o que mais a app não precisar). Seguir o OWASP PHP Configuration Cheat Sheet.
Código da aplicação. Prepared statements (PDO com parâmetros bindados — nunca concatenar SQL). Validação por allowlist no input. Encoding contextual na saída (HTML, JS, URL, conforme o destino). Hash de senha com password_hash / password_verify. Frameworks e CMS atualizados reduzem a superfície, mas não fecham o bug de núcleo.

Se você opera servidor ou site em PHP: confira a versão (php -v ou o painel), aplique o patch desta semana e reinicie os workers. Sem isso, o restante do hardening fica em cima de um engine que ainda responde ao pacote errado.

Leia o artigo mais aprofundado clicando abaixo.

Se você quer usar IA com propriedade, e não apenas gerar código.

A série completa (eBook) está disponível com 30% de desconto usando o cupom LEIA30:

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

The PHP Foundation security release 21/10/2026 (8.5.12/8.4.27/8.3.36/8.2.35)
Advisories CVE-2026-109618 (OOM corruption) e CVE-2026-109619 (stale global state)
Análises JFrog, Datadog Security Labs, Censys, Securelist (out 2026)
OWASP PHP Configuration Cheat Sheet e Secure Coding Practices

Tags

#PHP #Seguranca #PHP2Shell #CVE #Ciberseguranca #WebSecurity #DevOps #Backend #OWASP #Atualizacao #RCE

O agente disse "95% de confiança". Quem mediu?

Alex Pimenta — Thu, 22 Oct 2026 15:16:32 +0000

Escores de confiança gerados pelo próprio modelo e o benchmark DecisionPivot mostram por que um número convincente não autoriza sozinho uma decisão.

O agente devolve o diff, a classificação ou o "pode seguir" com um percentual alto. O time trata o número como sinal de segurança. O problema é que esse percentual costuma ser verbalização do modelo — não uma probabilidade calibrada contra frequência real de acerto. Em debate recente no Hacker News, a linha "não peça escore de confiança a um LLM" gerou dezenas de comentários justamente por isso: sem protocolo de calibração, o número é conforto, não evidência.

O paper DecisionPivot (arXiv:2610.28522, out 2026) ataca o ponto de frente. O benchmark tem 48 tarefas e cerca de 40 mil itens em sete papéis de decisão usados em sistemas com LLM: guardrails, verificação de saída, checagem de ferramenta de agente, classificações de raciocínio, etc. O track central traz 7.800 itens em 13 famílias geradas, organizados em grupos de contraste: o mesmo caso com um detalhe plantado que muda a resposta correta, verificado por solvers independentes. Acurácia de item sozinha não basta. O que interessa é se o modelo acerta o grupo inteiro, se ordena probabilidades de forma coerente e se as predições de alta confiança realmente erram menos.

Os resultados expõem o que scores agregados escondem. Dois modelos de 27B com diferença de 2,6 pontos no track de referência ficaram em 70,1% e 44,2% de acurácia em grupos de contraste. Em 2.400 pares binários, um decisor ordenou o membro positivo acima do negativo em 92,3% dos casos e acertou os dois membros em só 74,1%. Modelos com acurácia de item parecida divergem na confiabilidade das predições com probabilidade ≥ 0,90: um erra menos quando se declara muito confiante; outro declara confiança alta com mais frequência e erra mais nesses casos. Há também métricas de cobertura seletiva (quanto o sistema pode decidir sozinho mantendo taxa de erro limitada) e erro de calibração por bins de probabilidade.

Para quem usa agentes em roteamento, guardrail ou aprovação de saída, a implicação é operacional. "Confiança acima de 90%" só vira critério defensável se alguém mediu, no domínio do time, se esse limiar corresponde a erro aceitável. Sem isso, o número vira atalho para automatizar o que ainda precisava de revisão humana — ou de um segundo modelo, ou de um teste, ou de uma trilha de evidência. O DecisionPivot não resolve o pipeline de ninguém; mostra o tipo de pergunta que o pipeline precisa responder antes de tratar escore verbal como gate.

Quem ainda promove patch ou decisão só porque o agente "disse 95%" está usando um critério que o próprio modelo não validou.

Leia o artigo mais aprofundado clicando abaixo.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada — supervisão, auditoria e o que autoriza uma decisão do agente — pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

Zhuang et al. DecisionPivot: A Diagnostic Benchmark for Decision Models in LLM Systems (arXiv:2610.28522, out 2026)
Discussão HN sobre escores de confiança em LLM (out 2026)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #Calibracao #Agentes #Auditoria #EngenhariaDeSoftwareAssistidaPorIA

O recurso está desativado. Por que o atacante ainda consegue alcançá-lo?

Alex Pimenta — Wed, 21 Oct 2026 18:47:49 +0000

A Anthropic usou Claude para mapear código alcançável e mostrou que segurança também é impedir que código desnecessário rode.

Desligar uma feature no config não garante que o caminho correspondente sumiu do binário. Em vários projetos, o código continua compilado, ligado ao fluxo de entrada e executável antes de qualquer checagem de autenticação ou de política. O atacante não precisa de um bug clássico se a superfície que deveria estar fechada ainda responde.

A Anthropic publicou em 20/10 a pesquisa Using Claude to reduce the attack surface of code. Em vez de caçar vulnerabilidades uma a uma, o time pediu ao modelo que inventariasse configurações e traçasse alcançabilidade: o que a entrada externa consegue ativar, em que momento do protocolo e sob quais combinações de flags. Foram 25 projetos open source (mais de cinco milhões de linhas em C, C++, Java, PHP e Python).

Claude listou mais de 17 mil opções de configuração; 3.842 ligadas a controles de segurança. No fim, 493 issues — não necessariamente CVEs, e sim caminhos expostos demais, código que roda antes do login, pares de opções que enfraquecem um controle quando usados juntos.

Nos onze projetos "gated" (os que exigem autenticação), todos tinham código alcançável antes do login na configuração padrão: 93 superfícies pré-auth desnecessárias, 37 pontos em que código executava ou gravava estado antes da autenticação, 61 combinações de config que silenciavam um controle. No OpenSSH — código intensamente auditado —, cerca de 4.500 linhas de parsing de assinatura pós-quântica podiam ser atingidas por um cliente não autenticado, mesmo quando o administrador excluía o algoritmo. Ordem de 16% do código pré-auth do daemon.

A mudança de pergunta importa. Em vez de "quais bugs existem no código exposto?", passa a ser "por que esse código está exposto?". Reduzir a superfície não elimina a necessidade de achar e corrigir defeitos; reduz o que o atacante consegue tocar enquanto o defeito ainda não foi encontrado. Para times que já usam agentes em revisão e geração de código, o mesmo raciocínio se aplica ao que o agente herda e ao que a aplicação expõe: feature desligada no painel não é feature inacessível no binário se o caminho continua compilado e alcançável.

Quem só conta com "desativei no config" e com o scanner de padrões conhecido deixa no ar exatamente o tipo de caminho que a pesquisa mapeou.

Leia o artigo mais aprofundado clicando abaixo.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada — supervisão, auditoria e o que o sistema (e o agente) realmente expõe — pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

Chris Rohlf - Using Claude to reduce the attack surface of code (Anthropic Research, out 2026) - https://www.anthropic.com/research/attack-surface-reduction

Tags

#EngenhariaDeSoftware #InteligenciaArtificial #SoftwareEngineering #AI #Seguranca #AttackSurface #Auditoria #EngenhariaDeSoftwareAssistidaPorIA

Seu orquestrador de agentes está fazendo trabalho demais

Alex Pimenta — Tue, 20 Oct 2026 14:44:47 +0000

A Meta aumentou a confiabilidade ao tirar decisões de domínio do coordenador - e deixar o roteador deliberadamente magro.

Um único agente carregava todo o conhecimento do pipeline de dados: schemas, regras de geração de código, convenções de repositório, checks de qualidade. Em demo funcionava. Em produção, começou a misturar normas de um subsistema com outro e a inventar configurações. Sem prompts artesanais para cada caso, a taxa de sucesso caía para a faixa de 10-20%. O problema não era "prompt fraco". Era arquitetura: quanto mais contexto o coordenador acumulava, mais interferência entre conceitos e mais alucinação.

A Meta publicou em 19/10 o padrão que adotou: thin orchestrator. Um orquestrador de cerca de 1.300 linhas que roteia mais de 20 workflows para 14 agentes especializados e não faz trabalho de domínio. Classifica intenção, coleta campos obrigatórios, aplica checagens de confiabilidade e delega. Não raciocina sobre código, não gera configuração, não toca no repositório. Cada subagente recebe contexto isolado — schema, população de fontes, validação de build — e não enxerga o quadro inteiro. Essa limitação é intencional.

O protocolo de cada pedido é fixo (sete passos): ler instrução do subagente, checar duplicata, reunir campos, inferir o que for automático, passar pelo gate de confiabilidade, delegar, tratar o resultado. Raciocínio de LLM aparece de forma concentrada no passo em que o especialista atua, não no roteador. Em produção, o onboarding de coluna de dados que levava dias manualmente (ou cerca de um dia com o sistema anterior) passou a ficar abaixo de uma hora; boa parte das mudanças chega sem retrabalho pesado de engenheiro.

Para quem monta sistemas de agentes em engenharia de software, o caso reforça uma regra antiga com evidência nova: separação de responsabilidades continua valendo quando o "trabalhador" é um modelo. Concentrar roteamento, política e domínio no mesmo agente amplia a superfície de erro. Deixar o orquestrador determinístico e magro, e o raciocínio especializado em agentes com contexto delimitado, reduz contaminação e torna falha mais localizada e mais fácil de auditar e reexecutar.

Quem ainda coloca "um agente que sabe de tudo" no centro do fluxo pode estar pagando o mesmo preço que a Meta pagou antes da troca: demo boa, produção instável.

Leia o artigo mais aprofundado clicando abaixo.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada — em especial delegação técnica e limites do que o agente (e o orquestrador) deve fazer — pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

Rath, Jindal, Verma et al. The Thin Orchestrator: How We Made Our AI Agents More Reliable by Giving the Router Less to Do (Engineering at Meta, 19 out 2026) https://engineering.fb.com/2026/10/19/ml-applications/thin-orchestrator-ai-agent-architecture/

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #Agentes #Orquestracao #DelegacaoTecnica #EngenhariaDeSoftwareAssistidaPorIA

O agente não precisa pensar em voz alta

Alex Pimenta — Mon, 19 Oct 2026 16:17:11 +0000

Hybrid Reasoning Agents combinam raciocínio latente com ações em texto - e forçam a separar eficiência, observabilidade e validação.

Agentes de LLM ainda raciocinam e agem quase só em texto. Cada passo intermediário vira token legível, mesmo quando ninguém precisa ler o raciocínio — só o resultado ou a chamada de ferramenta. O custo sobe. A latência também. Raciocínio latente (em espaço contínuo, sem decodificar para palavras) é mais barato, mas tradicionalmente perde acesso nativo a ferramentas e deixa o processo opaco.

Hybrid Reasoning Agents (arXiv:2610.18861, 13/10 - Stanford, Together AI, UIUC, Meta) propõem um meio-termo arquitetural: o agente alterna, na mesma geração, entre modo latente (pensar sem verbalizar) e modo texto (agir no ambiente, chamar ferramenta, devolver resposta). Um módulo leve (HybridLink) faz a transição; uma memória de trabalho contínua preserva o contexto híbrido entre turnos. Pensamentos latentes podem ser mapeados de volta a tokens próximos quando for preciso inspecionar. Treinamento em duas etapas (HybridSFT e HybridRL) ensina o modelo a coordenar os dois modos e a decidir quando permanecer em silêncio e quando falar.

Nos benchmarks do paper (11 tarefas, três escalas de modelo), o ganho médio de desempenho ficou em cerca de 10,4% frente a agentes textuais e a métodos latentes anteriores, com redução de tokens na faixa de 35% a 55%, inferência entre 1,8x e 2,6x mais rápida e economia de custo estimada entre 2,7x e 3,7x[1†L1-L5]. O ponto para quem opera agentes em produção não é só "fica mais barato". É que eficiência e legibilidade deixam de ser o mesmo eixo. O que precisa ser texto (chamada de API, diff, resposta ao usuário, evidência para auditoria) continua texto. O que só serve para o modelo avançar internamente pode ficar latente — desde que exista forma de recuperar ou amostrar esse raciocínio quando a validação exigir.

Na engenharia de software assistida por IA, isso muda o desenho do pipeline de supervisão. Quem mede só o log textual completo pode estar pagando por tokens que não inspeciona. Quem apaga o intermediário sem política de recuperação perde a trilha quando o agente erra. Separar "quando pensar em silêncio" de "quando expor passo a passo" vira decisão de arquitetura e de governança, não detalhe de prompt.

Leia o artigo mais aprofundado clicando abaixo.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada — do contexto à governança de agentes — pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

Zou et al., 13 out 2026 Hybrid Reasoning Agents (arXiv:2610.18861)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AIAgentes #HybridReasoning #Governanca #EngenhariaDeSoftwareAssistidaPorIA

O agente mudou as próprias regras. Quem aprovou a nova versão?

Alex Pimenta — Mon, 19 Oct 2026 15:03:45 +0000

Agentes autoevolutivos já alteram prompts, memória, ferramentas e workflows sem trocar o modelo. O desafio passa a ser controlar o que pode persistir.

O harness do agente - prompts, memória, workflows, ferramentas e trechos de código de controle deixou de ser só configuração inicial. Papers recentes tratam esse andamento como alvo de evolução: o modelo permanece fixo; o que muda, e persiste entre execuções, é o andaime de software que define o que o agente vê, chama e decide.

Self-Evolving Agent Harness (arXiv:2610.18813, 13/10) formaliza um processo guiado por feedback em que revisões aceitas permanecem. Distingue mudança de estado interpretado (prompt, memória) de revisão de ferramentas, lógica de repositório e composição de plugins. Propõe mecanismos de admissão com validação independente e discute limites de generalização quando a distribuição de tarefas e os avaliadores também mudam. Harness² (arXiv:2610.14224, 09/10) leva a ideia a um segundo nível: recursão na tarefa atual (editar o harness da execução em curso) e recursão no harness de melhoria contínua, extraindo experiência das edições para as próximas. Em benchmarks profissionais, um passo já elevou desempenho de configs com GLM-5 e Gemini 3.5 Flash em relação ao harness base.

O ponto prático para quem opera agentes em produção não é se a autoevolução "funciona". É quem decide o que pode persistir. Uma lição de uma corrida bem-sucedida pode virar regra permanente inclusive a regra que julga a próxima mudança. Se a proposta de alteração e o critério de aceite residem no mesmo loop, o sistema passa a governar a si mesmo sem trilha clara de aprovação humana. Validação contínua, orçamento de regressão e separação entre o que o agente pode propor e o que pode gravar no harness compartilhado deixam de ser detalhe de pesquisa e viram requisito de engenharia.

Na prática: inventariar o que o harness pode reescrever; exigir evidência e validação fresca antes de promover mudança persistente; manter rollback e identidade de versão do que o agente herda na próxima execução. Quem não define isso está deixando o agente alterar as regras do jogo sem assinatura de quem responde pelo resultado.

Leia o artigo mais aprofundado clicando abaixo.

Autor da série de livros "Engenharia de Software Assistida por IA" (disponível na Amazon). Aprofunde-se no tema de forma estruturada do contexto à governança de agentes pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

Wei et al., 13 out 2026 - Self-Evolving Agent Harness (arXiv:2610.18813)
Xu et al. (Google Cloud AI Research et al.), 9 out 2026 Harness2: Recursive Agent Harnessing for an Open World (arXiv:2610.14224)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #Agentes #Harness #Governanca #EngenhariaDeSoftwareAssistidaPorIA

O contexto virou perímetro de segurança: por que agentes corporativos não podem receber acesso antes de receber critérios

Alex Pimenta — Thu, 15 Oct 2026 16:16:18 +0000

Em 8 de outubro o Google Cloud apresentou o Gemini agent como agente universal para o trabalho: planeja, usa ferramentas, conecta sistemas empresariais e devolve tarefas concluídas dentro de documentos, e-mail e ambientes de desenvolvimento. Poucos dias depois, o Gemini 4 Argon entrou em disponibilidade com ênfase em tarefas longas de código, finanças, jurídico, cibersegurança e ciência. O movimento é claro. Agentes deixam de ser assistentes de prompt e passam a operar com dados, ferramentas e fluxos reais da empresa.

O risco não começa no erro do modelo. Começa no momento em que a organização concede permissão de ação sem ter convertido regras, evidências e limites em critérios operacionais verificáveis. Contexto incompleto produz decisão aparentemente correta e operacionalmente perigosa - especialmente quando o agente atravessa sistemas, chama APIs e altera estado.

Na prática de segurança e engenharia, isso muda a ordem das perguntas. Antes de "quais ferramentas o agente pode usar?", vem "quais decisões ele está autorizado a tomar, com que evidência e em que ponto precisa escalar ou parar?". Autoridade precisa ser escopada à menor fronteira de decisão que ainda entregue valor: tarefa, workflow ou fatia de sistema, não cargo ou departamento inteiro. Permissões explícitas, propósito auditável e barreira dura no que pode ser alterado. O que exige julgamento cruzado de domínio ou altera risco de forma material continua com humano ou com ponto de controle de confiança mais alta.

Controles de runtime passam a importar mais do que a configuração inicial. Autorização por ação, identidade separada de agente e subagente, trilha de auditoria atribuída ao agente e revogação rápida quando o comportamento muda. Política fora do agente - no gateway, no registro de ferramentas, no plano de identidade - evita que o modelo seja o único juiz do que pode fazer. Contexto deixa de ser só prompt de qualidade. Vira o perímetro que define o que o agente pode ver, decidir e executar.

Quem libera agente corporativo com acesso amplo e critérios vagos está tratando permissão como detalhe de setup. Quem trata contexto como perímetro define, antes do acesso, o que conta como evidência suficiente, o que exige aprovação e o que o agente não pode decidir sozinho.

Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.

Cupom de 30% OFF: LEIA30.
Disponível também no Kindle Unlimited.

Referências

Google Cloud, 8 out 2026 - Gemini at Work: Gemini agent (agente universal, ferramentas, sistemas empresariais, governança)
Google Cloud / DeepMind, out 2026 - Gemini 4 Argon (tarefas longas em código, finanças, jurídico, cibersegurança, ciência)
Práticas de autoridade de agentes e autorização em runtime (escopo por tarefa, least privilege, controles fora do agente)

Tags

#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #Agentes #Governanca #Seguranca #Contexto #EngenhariaDeSoftwareAssistidaPorIA