Por que insistir em IA agêntica, se os modelos mal conseguem seguir até instruções simples?

• Em um cenário em que modelos de IA para programação não conseguem executar com confiabilidade nem um único comando, vem se formando uma expectativa exagerada em torno da programação agêntica, que opera de forma autônoma em segundo plano
• O autor relata que, mesmo fornecendo como referência uma função em Golang com cerca de 100 linhas, tanto o GPT-5 quanto o Gemini Pro omitiram partes da lógica ou deixaram atualizações de fora
• Fazer um sistema agêntico processar de forma autônoma 50 arquivos e várias funções é irrealista no nível atual da tecnologia e pode, na prática, consumir ainda mais tempo com depuração
• As respostas da comunidade se dividem entre a visão de que é possível obter algum sucesso de forma limitada com prompting estruturado, documentação e validação passo a passo, e a visão cética de que o modelo agêntico ainda não é prático
• Os LLMs atuais são sistemas baseados em conhecimento, não inteligência; por isso, uma abordagem realista é o uso como ferramenta, em que o desenvolvedor fornece o contexto diretamente e valida cada etapa

---

Questionamento do autor do texto original

• Exemplo de falha em instrução simples: foi fornecida como referência uma função em Golang com 100 linhas, e pedido que outra função fosse atualizada com a mesma estrutura; ainda assim, GPT-5 e Gemini Pro omitiram parte da lógica ou deixaram alterações sem aplicar
• Irrealismo da programação agêntica: se o modelo não consegue lidar corretamente nem com uma única função, a ideia de modificar de forma autônoma várias funções em 50 arquivos tende a gerar ainda mais problemas
• Pergunta sobre atualizar um arquivo de 6000 linhas: o autor pediu opiniões da comunidade sobre como modificar com segurança um arquivo desse porte em casos como atualização de versão do Stripe

Casos de uso positivos e metodologias

Abordagem de documentação e indexação estruturadas

• Uso de arquivos de referência em Markdown: ao salvar referências em arquivos .md e instruir a IA a lê-los, a consistência e a precisão melhoram
  • Exemplo de prompt: "Consulte o arquivo anexado goLang_Update_reference.md, resuma os pontos principais da função update e, com base nisso, elabore um rascunho de atualização de software"
• Construção de índice local: no caso de arquivos grandes (mais de 6000 linhas), recomenda-se escanear em blocos de 1000 linhas e gerar um índice com nomes de funções e referências de linha
  • Em trabalho de frontend, pode-se usar índices separados por área específica, como fr.index.md

Gerenciamento de agentes e estruturação do trabalho

• Especialização de agentes: organizar agentes por função, como architect, codeseeker e coder, fornecendo a cada um arquivos de regras .md adequados ao papel
• Abordagem de fatias verticais: dividir o trabalho em pequenas funcionalidades que possam ser concluídas com menos de 100 mil tokens
  • Acima de 100 mil tokens, a chance de mau funcionamento dos agentes aumenta drasticamente
• Obrigatoriedade de documentação do trabalho: tornar obrigatória a atualização de docs/TASKS.md, docs/WORKLOG.md e docs/DECISIONS.md para preservar a continuidade do trabalho

Uso de Plan Mode e Ask Mode

• Plan Mode: revisar o projeto como um todo, montar um plano com base no pedido e seguir por etapas
• Ask Mode: útil para consultar o codebase, explorar ideias e avaliar opções, funcionando bem como substituto de Google/StackOverflow

Abordagem com testes unitários primeiro

• Desenvolvimento guiado por testes: escrever primeiro os testes unitários e depois fazer a IA gerar iterativamente código que passe nesses testes
  • Isso aumenta bastante a chance de obter código funcionalmente correto, restando depois apenas otimização e limpeza

Visões céticas e reconhecimento de limites

Limites práticos do modelo agêntico

• Trabalho sem supervisão é suicídio: no nível atual da tecnologia, atribuir tickets e deixar o sistema trabalhar de forma autônoma em segundo plano tem alta probabilidade de fracassar
• Possibilidade de mentir: o modelo tem maior propensão a gerar alucinações do que sucesso e, no pior caso, pode destruir código existente
• Redundância do Planning Mode: pedir um plano detalhado ao modelo base já seria suficiente; o Planning Mode não oferece, na prática, uma capacidade realmente nova

Limitações intrínsecas dos LLMs

• Previsão, não raciocínio: o modelo funciona prevendo a próxima palavra sem verificar o resultado; por isso, a confiabilidade continuará instável até que grounding, memory e feedback melhorem
• Base de conhecimento sem inteligência: LLMs são bases de conhecimento sofisticadas, mas sem inteligência; o desenvolvedor precisa trazer a própria inteligência (BYOI: Bring Your Own Intelligence) e fornecer o contexto
• Falta de memória: o modelo não tem memória real e depende apenas de context e context cache, então o contexto é reiniciado sempre que uma nova conversa começa

Viés de linguagem e dados

• Desvantagem relativa do Golang: Golang tem menos codebases públicos do que Python ou JavaScript, então o modelo aprendeu menos padrões e convenções da linguagem
  • Esse é um fator estrutural que dificulta obter resultados consistentes em edição ou transformação

Guia prático para uso bem-sucedido

Prompting e fornecimento de contexto

• Instruções claras e detalhadas: usar gramática e pontuação com precisão e fornecer instruções explícitas em vez de formulações ambíguas
• Referência explícita a todos os arquivos relevantes: se o agente não receber todos os arquivos que precisa usar, aumenta a chance de gerar código espaguete
• Configuração de arquivos de regras: definir regras para o workspace inteiro e também regras específicas do projeto para induzir uma geração de código mais consistente
• Uso de @Docs: aproveitar o recurso de referência a documentação para fornecer ao agente o conhecimento essencial de que ele precisa (embora em algumas versões o funcionamento seja instável)

Escopo de trabalho e validação

• Dividir em unidades pequenas: separar o trabalho na menor unidade possível, validar cada etapa e só então seguir para a próxima
• Revisão em tempo real: revisar todo o código gerado em tempo real e pedir correções imediatamente para evitar código espaguete
• Backup e controle de versão: criar backups a cada etapa e usar sistemas de controle de versão como GitHub
• Execução de testes: usar pytest --testmon -q para rodar incrementalmente os testes afetados e, antes de concluir, executar a suíte completa

Modularização e estrutura de código

• Dividir arquivos de 6000 linhas: um único arquivo com 6000 linhas é pouco modular e desfavorável para fornecer contexto; dividir em 12 arquivos de cerca de 500 linhas é mais eficaz
• Preferência por fatias verticais: desenvolver em pequenas unidades funcionais executáveis de ponta a ponta

Escolha de modelo e controle de custos

• Considerar primeiro o Claude Sonnet 4.5: em comparação com GPT ou Gemini, ele oferece mais consistência e precisão, o que pode justificar o custo adicional
• Atenção ao consumo de tokens: planejamentos grandes consomem muitos tokens, então dividir a execução em etapas pequenas é mais eficiente em termos de custo

Casos de uso especiais

Geração de scripts de uso único

• Scripts de análise: quando é preciso escrever centenas de scripts únicos de análise de dados por dia, mesmo com 50% de precisão a geração e execução podem ser 1000 vezes mais rápidas do que escrever manualmente
• Possibilidade de validar o resultado: como o resultado pode ser verificado diretamente, mesmo uma precisão baixa pode ser prática

Construção de apps do zero

• Estrutura multiagente: ao construir um app grande do zero, um agente supervisor revisa o trabalho dos outros agentes para manter a consistência
  • Isso ajuda em pontos como nomes de imports, consistência de nomes de variáveis e prevenção de duplicação de código
• Eficiência em relação ao custo: ainda são necessárias correções complexas e refatoração, então uma abordagem em etapas continua sendo mais barata no longo prazo

Resumo das opiniões da comunidade

Experiências positivas (ganho de produtividade de 3x a 5x)

• Site em Next.js: construção, em poucos minutos, de um site totalmente funcional e pronto para deploy a partir do zero
• Implementação de funcionalidade complexa: criação do recurso de threads em um app de chat em 3 a 4 minutos (algo estimado em 3 dias de trabalho)
• Com abordagem estruturada: regras claras, contexto suficiente e validação passo a passo podem levar a sucessos consistentes

Experiências negativas (ainda impraticável hoje)

• Produção de código espaguete: ao receber objetivos muito amplos, o modelo tende a deixar de atualizar documentação ou de apagar arquivos restantes
• Erros semânticos: tecnicamente funciona, mas com problemas estruturais, como colocar código no lugar errado ou reimplementar funções já existentes
• Falha em execuções longas: rastreamentos com mais de 5 minutos de duração geralmente acabam produzindo resultados inúteis

[GN⁺]

Comentários do Hacker News

• Pela minha experiência prática, sinto que a maioria dos LLMs segue bem minhas instruções. Claro, isso exige prompts bem lapidados e planejamento prévio, mas, pegando o jeito dessas três coisas, dá para voar com esses agentes de programação. Às vezes, 1 em cada 10 tentativas dá errado, mas mesmo nesses casos dá para interromper rápido e redirecionar para voltar ao caminho. Fico até surpreso com o quanto muita gente aqui no HN é cética quanto à eficácia. Claro, há muitas preocupações, como custo e impacto no trabalho, mas ainda assim me espanta ver tanta dúvida sobre a utilidade de agentes de programação
  • Seria bom ver vídeos ou casos reais em que sistemas agentes ou LLMs de fato geram mais valor do que uma busca no Google ou no Stack Overflow
  • Se você explicar bem o estado atual, o resultado desejado e como pretende avançar, dá para planejar, refinar e executar junto com o agente. Fazendo assim, o nível atual da tecnologia é bem impressionante. Esperar algo complexo a partir de uma única frase é exagero. Isso exige tempo e esforço reais, como ao delegar uma tarefa técnica a um estagiário inteligente sem experiência prática. A diferença é que o agente de IA trabalha muito mais rápido que um estagiário humano
  • “Na maioria das vezes funciona” significa, na prática, que não existe nenhuma métrica real de confiabilidade (quantos 9s)
  • Acabei de converter um app em Python para Go de uma vez só com o Codex (gpt-5-high) enquanto passeava com o cachorro. Testei o resultado e funcionou bem. Fiquei satisfeito por agora poder distribuir como um binário único, sem ambiente virtual. Não sei se o comando era tão simples assim
  • Para mim, “na maioria das vezes funciona” não é suficiente. Um problema ainda mais grave do que não seguir instruções é não admitir que está errado e continuar insistindo. Quando peço algo de complexidade média ou uma análise de erro, com bastante frequência ele se apega a conclusões erradas. Muitas vezes não encontra uma saída até eu apontar diretamente o problema. É ótimo para código simples ou tarefas de boilerplate, e com um pouco de feedback já consegui até criar bibliotecas novas. Mas como erra com frequência, não quero confiar coisas mais complexas a ele. Ainda assim, quando estou travado, uso para gerar ideias; mesmo errado, ajuda na motivação
• Quando a diferença de experiência dos desenvolvedores com LLMs fica estranhamente grande, a pergunta que realmente deveríamos fazer é: “por que as experiências são tão diferentes?”. A explicação mais simples é “você está usando errado”, mas, como alguém que desenvolve sistemas de IA, também me surpreende ver quantos usuários escrevem só “conserta isso”, “faz um relatório” e esperam resultado sem nenhuma instrução mais elaborada. Também existe um hype exagerado da gestão no estilo “dá para fazer qualquer coisa com IA”, e isso se conecta a valuation e preço das ações. O público em geral também parece tratar IA como “inteligência artificial de verdade”. Na prática, a afirmação de que LLMs não conseguem nem seguir instruções simples é pouco crível; o ponto importante é que eles ainda não conseguem fazer bem tarefas complexas
  • Minha outra teoria é que cada pessoa tem uma especificação mental, escreve isso de forma desorganizada e espera que o LLM implemente, mas o resultado sempre sai desalinhado em relação à especificação. Alguns desenvolvedores ajustam isso retroativamente na cabeça ou simplesmente aceitam pequenas diferenças, enquanto outros se decepcionam porque o LLM não correspondeu ao plano mental deles. É quase uma espécie de “falsa memória” psicológica: alguns são mais flexíveis e conciliadores, outros são mais rígidos. Eu mesmo alterno entre esses dois modos
  • Neste ponto, eu queria muito ver mais screencasts, textos longos, qualquer coisa mostrando o processo completo de alguém realmente construindo uma funcionalidade não trivial. Influenciadores de IA quase sempre só mostram IA criando ferramenta de IA, ou demos de CRUD e hello world. Até desenvolvedores veteranos dizem que a IA escreveu mais da metade do codebase, mas depois admitem que quase tudo foi descartado e só partes foram usadas como referência. A conversa de “prompt único → app pronto” logo vira “é útil quando você precisa de motivação diante de uma tela em branco”. Eu gostaria que houvesse mais transparência sobre como profissionais de fato usam isso no trabalho real
  • Na verdade, a categoria “desenvolvedor” é ampla demais para tornar essa discussão muito significativa. Para a maioria, LLMs funcionam razoavelmente bem para montar pedaços de código no estilo CRUD
  • Cada um trabalha em codebases diferentes e em tarefas diferentes. Quase nunca se fala desse detalhe importante. Quanto mais você usa, mais seu padrão de expectativa sobe e mais rápido você percebe os limites. Usar de vez em quando impressiona; usar o dia inteiro acumula frustração. Muita coisa que “já deveria conseguir fazer” acaba precisando de retrabalho
  • Tenho certeza de que não são os resultados que diferem, e sim as expectativas de cada um. O SVP de TI da minha empresa é um grande evangelista de IA. Recentemente, trabalhando num projeto legado em PHP que ele criou no passado, percebi que o nível de qualidade de código com o qual ele se satisfaz é extremamente baixo. Eu também uso LLMs todos os dias, mas sempre altero os resultados. Ou seja, quanto menor sua exigência de qualidade, maior sua satisfação com o que o LLM entrega
• No fórum do Cursor, só se repete “você usou errado”, mas o que realmente me interessa é confiança, processo e uso real no trabalho. Aqui também fica a impressão de que quase ninguém o usa em escala de verdade. Nós também usamos IA mais como um “colega meio burro”, e de forma mais experimental em projetos paralelos com menos restrições. Agentes me parecem em grande parte hype, ou então algo extremamente de nicho
  • O motivo de o OP ter resultados ruins é que ele usa Cursor. O Cursor corta o contexto de forma brutal para economizar custos. Ao contrário dos provedores de modelo, ele tem de pagar custo de varejo pelo uso de LLM, então compete em desvantagem de preço. O Cursor não é transparente sobre o quanto corta o contexto, e pela minha experiência ele corta de forma tão agressiva que você precisa reenviar os mesmos arquivos repetidamente para ele sequer entender a situação. Meu conselho é parar de investir tempo no Cursor. O código que ele gera só cria dívida. Migrei para Codex e Claude e estou bem mais satisfeito
  • Gostaria de saber especificamente que melhorias você quer ver. O post original não traz exemplos concretos, prompts nem metodologia; é basicamente só “eu sei fazer prompt”, e assim fica difícil avaliar ou aconselhar. Também entendo o ceticismo com fluxos de trabalho agentic, mas desse jeito as pessoas nem tiveram chance de responder de forma adequada. Eu também trabalho com agentes há alguns meses e ainda estou aprendendo o que funciona e o que falha. Pela minha experiência:
    • orquestração com frameworks como agent-os é essencial
    • é importante equilibrar orientação e autonomia
    • planejamento prévio é realmente importante, especialmente em código legado
    • meu exemplo: num sistema legado, o contexto estoura a janela o tempo todo, e quando você resume o contexto, informações essenciais acabam ficando de fora, então os mesmos erros se repetem.
    • método que funcionou: estruturar o problema com clareza, registrar detalhadamente cada descoberta e aprendizado, e dividir em subagentes muito específicos (o que permite gerenciar a janela de contexto). Só então o agente passou a ajudar de forma concreta na exploração do código legado
  • Já tive experiência em que um agente encontrou vários bugs de produção que eu não estava conseguindo achar (bugs desconhecidos para os quais eu não tinha conseguido dedicar tempo suficiente). Claro, há muito mais bugs que ele não encontra, mas comparado a uma hora de um engenheiro de software, isso é praticamente de graça; se às vezes funciona, já é uma estratégia útil
  • Um texto com exemplos práticos e concretos seria mais valioso e levaria a respostas melhores. Mostrar um problema real de trabalho e como o LLM falhou seria muito mais útil
  • O valor real para negócios é muito menor do que as pessoas pensam, e isso é frustrante. Sem dúvida, em boilerplate ou em áreas familiares, às vezes ele pode ser usado melhor que um humano. Mas os outros problemas são grandes demais: dependência de big tech, contaminação de dados, informação impossível de verificar, redução da criatividade, colapso da originalidade, ignorância dos fanáticos por IA, consumo de energia, apropriação de criações humanas etc. Acho espantoso que alguém acredite que isso traga saldo líquido positivo para a humanidade
• Em 2025, o marketing está extremamente bem feito em fóruns como Reddit, LinkedIn e praticamente todos os outros, com marcas se infiltrando nas conversas. CEOs, “pensadores” de IA e VCs promovem LLMs como se fossem magia e empacotam v0, Lovable e afins como a próxima grande inovação. As respostas da liderança são todas parecidas (vídeo relacionado). Mas, na prática, por mais que você crie coisas como CLAUDE.md ou cursorrules, quase não faz diferença. No fim, o LLM precisa seguir instruções, mas na prática parece aleatório. Ele quase não obedece nem regras muito simples, então acabo achando que quem posta no fórum do Cursor parece tudo amador. E, além disso, LLMs são realmente ruins para trabalho de código novo. Assumem bibliotecas que nem existem e produzem texto inútil. Eu literalmente uso mais como speech-to-text, porque os LLMs conseguem pegar melhor casos de borda que eu deixei passar, boas práticas que eu não conhecia, sintaxe etc.
  • [1] Resultados de busca, Perplexity e similares são em sua maioria blocos de marketing espalhados por equipes de marketing
  • Concordo totalmente com a ideia de que LLMs são péssimos para trabalho de código novo. Os modelos SOTA atuais conseguem gerar boilerplate ou estruturas simples em frameworks muito conhecidos e com padrões consistentes (MVC etc.). Onde eles realmente se destacam é em tarefas de vasculhar muita informação para encontrar algo específico (codebase, logs, stack traces etc.). Mas esse marketing de que “o agente constrói o codebase inteiro” não me parece realidade no estado atual
  • Minha experiência é completamente oposta. Na última semana, o Claude Code praticamente corrigiu sozinho problemas de compilador que eu mantenho. Tirando alguns momentos frustrantes, ele corrigiu de forma consistente até bugs sutis de geração de código e parser, e as partes em que eu precisei intervir têm mais a ver com limitações da ferramenta, como o gerenciamento de compaction. Também implementou abordagens que eu só esperaria ver em livro, e confirmei na prática que funcionavam. Talvez haja pouca coisa realmente nova e “inovadora”, mas, na verdade, quase nenhum código é realmente novo. Pela minha experiência, se você dá instruções com base em um guia bem estruturado, ele costuma seguir muito bem. Não basta simplesmente jogar qualquer coisa num CLAUDE.md. O ponto-chave é orientar cuidadosamente o processo. Meu fluxo de trabalho se divide em: 1) guia de depuração por projeto, 2) critérios de aceitação claros, 3) executar testes com frequência e mandar registrar pequenas mudanças por unidade em arquivos. Desse jeito, consigo deixar o Claude trabalhando por horas quase sem supervisão (só dando um “continue” no meio ou usando /compact). Ele não entrega código perfeito toda vez, mas eu também não. Ainda assim, no geral isso tem levado a mudanças positivas e reduzido bastante meu esforço. Eu ainda não recomendaria bootstrap sem um design bem pensado, mas às vezes ele até consegue fazer isso também (desde que com revisão prévia). Hoje em dia já penso em deixar o Claude resolvendo problemas sem parar por dias
  • Acho realmente fascinante como a experiência de cada um com LLMs pode ser tão diferente. No meu caso, sinto um aumento de produtividade de 5x com codex-cli. Conseguiu lidar tranquilamente com fontes de estrutura muito incomum, converter traces internos de execução em SVG para um formato customizado de grafo JSON, e até extrair documentação com precisão de um codebase Python/C++ complexo, incluindo um kernel RISCV de baixo nível. Tenho muita curiosidade sobre o motivo de resultados tão diferentes com a mesma ferramenta
  • Programar com Claude parece jogar caça-níquel. Às vezes sai exatamente o que você quer, mas muito mais frequentemente não sai ou sai totalmente errado. É perigoso demais deixar rodando sozinho sem supervisão
  • Também sinto que o valor mais consistente dos LLMs está em detectar pequenos erros que humanos deixam passar, melhores exemplos e sintaxe de código. Por isso, como revisor de PR, funciona bem com uma pitada de cautela
• Na nossa empresa, aplicamos a abordagem clássica de XP. Ao desenvolver novas funcionalidades em um app brownfield, dividimos o trabalho em quase 8 subagentes, como red-test-writer, minimal-green-implementer e refactorer. Agora basta digitar no Claude Code algo como “crie a funcionalidade X com este processo de TDD” e, em 30 minutos, sai um resultado com código muito melhor, 90% de cobertura de testes e pronto para aceitação imediata. Isso se apoia em anos de experiência com XP, programação em par e TDD, mas já faz mais de um ano que 95% do nosso código de produção é escrito por IA (incluindo funcionalidades complexas e não triviais). Não existe nenhum segredo especial; simplesmente funciona muito bem para nós
• Há uma divergência enorme de opiniões aqui. Sem dizer em que exatamente cada um falhou e para que tipo de tarefa usa, é impossível ter uma discussão de verdade. Se não falarmos de categorias concretas em que LLMs falham ou têm sucesso, tudo isso não passa de ruído
  • Em discussões assim, é preciso detalhar linguagem/framework, domínio do problema, nível de SRE, LLM (modelo/versão), harness agentic (claude code, codex, copilot etc.), casos de falha/sucesso e até o nível de proficiência com LLM. Também importa se o engenheiro trabalha há 10 anos no mesmo codebase ou alterna entre vários projetos, se é desenvolvimento novo (greenfield) ou manutenção, pesquisa inovadora ou CRUD, e assim por diante
• Do ponto de vista de um cientista, muitas vezes é preciso repetir boilerplate ligeiramente diferente para cada dataset, e agentes de programação resolvem boa parte disso. Em especial, às vezes o Claude ignora mesmo quando você escreve cinco vezes em CAIXA ALTA “NUNCA INVENTE DADOS, NÃO USE np.random”. Isso é surpreendentemente absurdo. Quando funciona, é fantástico; quando não funciona, nem há sinal de falha. Do ponto de vista do marketing de LLMs, até imagino um agente tipo “PIPA (Performance Improvement Plan Agent)” acompanhando o agente de programação e monitorando em tempo real se ele está fazendo o trabalho direito. O PIPA avaliaria o desempenho do agente de programação, e RH ou a gestão passariam a gerenciar funcionários de IA (agentes). Talvez o futuro venha por esse caminho
  • Se eu disser “não pense em um elefante de tutu rosa!”, você não pensou justamente nisso? Como cientista, você deveria saber que LLMs têm dificuldade inerente com instruções negativas. Eles são treinados em nível de token, então mesmo que você diga “NO ELEPHANTS”, a palavra “elefante” continua presente no contexto. Isso acaba induzindo exatamente esse termo. Instruções positivas funcionam melhor
  • Só de imaginar um PIPA já dá medo
• O ponto-chave é o prompt (como boas mensagens de erro) para que o modelo encontre sozinho o contexto adequado, e dividir o trabalho em partes muito pequenas e consistentes. Assim, fica possível passar os resultados de testes iterativos e em etapas como contexto da próxima tarefa. Uns 50% dos problemas se encaixam bem nessa abordagem, e em outros 50% o loop com LLM ainda é menos trabalhoso do que automação tradicional, mas metade desses casos não vale tanto o investimento. No fim, se existe um “12,5% mágico”, então a abordagem ideal é um agente fortemente restrito (Constrained)
  • Seria ótimo transmitir esse processo ao vivo no YouTube ou algo assim — não como tutorial, mas como live coding natural — para compartilhar bons insights
• Quase 30 anos atrás, quando comecei em IA, ouvi o seguinte: quando você ouvir a expressão “intelligent agent”, pense em “formiga treinável”
  • Quero muito mais detalhes
• Para mim, o maior problema é que o desempenho das ferramentas de IA varia demais de tarefa para tarefa, e é difícil prever onde elas vão falhar, o que acaba consumindo tempo. Imagino que, com mais experiência, eu vá melhorar na arte de escrever prompts, mas ainda é frustrante. Ainda assim, há uma sobreposição entre a utilidade de agentes e de IA em geral (por exemplo, gerar automaticamente boilerplate de um projeto novo). Nesses casos, o “modo agente” é mais conveniente. Ainda não tenho tanta experiência prática assim
  • Quanto melhor funciona, mais as expectativas sobem e mais você amplia o uso; quando então bate no limite, a frustração acaba sendo ainda maior do que no começo