- Afirma-se que a forma de conexão por MCP é o “futuro”, mas na prática, por causa de falta de composabilidade e consumo excessivo de contexto, a abordagem de escrever código diretamente continua sendo mais eficiente
- Mesmo na era dos LLMs, em automação e tarefas repetitivas, gerar/usar código continua levando vantagem em confiabilidade e verificação
- Os LLMs são mais fortes em geração de código e execução repetida do que em automação baseada em raciocínio; processos baseados em código são superiores em identificação de problemas, verificação e escalabilidade
- Algumas ferramentas como o Playwright (na abordagem MCP) aumentam a incerteza e a dificuldade de depuração em cada etapa “baseada em raciocínio”, enquanto gerar/modificar scripts diretamente em código melhora repetibilidade, velocidade e confiabilidade
- O loop de “código-revisão-repetição”, em que um LLM gera código e outro LLM inspeciona e explica esse código, é na prática o fluxo de automação mais poderoso
Só Código Basta
- Se você me segue no Twitter, provavelmente sabe que eu não tenho sido muito positivo em relação ao Model Context Protocol (MCP) ultimamente
- O motivo não é rejeição à ideia em si, e sim o fato de que o MCP não é tão eficaz quanto foi anunciado
- O MCP tem duas falhas principais
- não oferece composabilidade real
- por exigir contexto em excesso, consome mais contexto do que escrever e executar código diretamente
- Dá para verificar isso com um experimento simples
- por exemplo, se você executar uma tarefa usando o GitHub MCP e depois fizer o mesmo com a ferramenta de linha de comando
gh, a segunda opção usa o contexto de forma muito mais eficiente e chega ao resultado desejado mais rápido
But MCP is the Future! : Mas o MCP é o futuro!
- Quero falar sobre o feedback que recebi a respeito dessa posição minha, de que código é melhor
- Eu experimentei o MCP a fundo no contexto de agentic coding e o avaliei justamente nos pontos em que as limitações aparecem com mais clareza
- Um dos feedbacks foi que “o MCP não é realmente necessário para geração de código de uso geral, porque os modelos já são bons o bastante nisso”. Em contrapartida, também ouvi a opinião de que ele pode fazer sentido em aplicações voltadas ao usuário final em domínios específicos como, por exemplo, tarefas de automação em empresas financeiras
- Outra opinião é que, no futuro, os modelos terão acesso a mais ferramentas e conseguirão lidar com tarefas mais complexas, então devemos focar nesse potencial
- Mas meu julgamento atual é o seguinte: com base nos dados que testei e na experiência real que tive, o MCP atual é sempre mais difícil de usar do que escrever código diretamente
- o maior motivo é que o MCP depende de inferência
- quando vejo hoje “todas as tentativas de conectar mais ferramentas aos LLMs”, no fim sempre entra uma camada em que o LLM recebe todas as ferramentas e as filtra de acordo com a tarefa
- até agora, nunca foi proposta uma estrutura ou abordagem melhor do que essa
- Por isso, chego à seguinte conclusão: mesmo em casos especiais, como automação de domínio específico para não desenvolvedores, no fim geração de código continua sendo sempre a melhor escolha em termos de composabilidade e reutilização
Replace Yourself With A Shellscript
- Uma forma de olhar para esse problema é: sem IA, para um desenvolvedor, a ferramenta para resolver problemas é código
- Para não desenvolvedores, código é difícil, e muitas tarefas que hoje são feitas manualmente na verdade podem ser automatizadas com software
- O problema realista é quem vai escrever esse código. Se você estiver em um ambiente específico e não souber programar, é difícil aprender a programar do zero, e também é complicado esperar que alguém escreva código sob medida para você
- Claro, algumas tarefas podem realmente exigir raciocínio (julgamento humano/flexibilidade), mas na prática a maioria das tarefas repetitivas e bem definidas pode ser automatizada com código
- Existe um velho ditado entre desenvolvedores sobre “substituir a si mesmo por um shell script”, e esse tipo de automação já vem acontecendo há muito tempo
- Na era dos LLMs e da programação, tenta-se substituir a si mesmo por um LLM em vez de um shell script, mas aí surgem três problemas: custo, velocidade e confiabilidade
- Antes de resolver esses três problemas, nem faz sentido discutir o uso de ferramentas como MCP
- Em outras palavras, o ponto central é primeiro garantir que a automação realmente funcione de forma correta e escalável
Automation at Scale : A essência da automação em escala
- O núcleo da automação é tratar tarefas repetitivas e reutilizáveis com código
- Não há necessidade de automatizar algo que você vai fazer uma única vez e nunca mais. A automação começa pelas tarefas que serão repetidas várias vezes, em que a máquina de fato traz ganho real de produtividade
- Na prática, você faz manualmente uma ou duas vezes, organiza como aquilo funciona e depois faz a máquina repetir isso milhares de vezes — essa é a essência da automação
- Para esse tipo de automação repetitiva, usar “código” é sempre a melhor opção
- Se você pedir para um LLM fazer isso por “raciocínio” a cada vez, ele até consegue dar conta de coisas pequenas, mas o tempo e o esforço gastos com verificação acabam reduzindo bastante o efeito da automação
- Exemplo: em vez de pedir que o LLM faça cálculos diretamente, é melhor pedir que ele escreva código Python e realizar os cálculos com esse código, porque isso melhora tanto a confiabilidade quanto a escalabilidade
- Ao usar código, você pode revisar a própria fórmula/lógica e, se necessário, corrigir manualmente ou até pedir que um LLM revise se “essa abordagem está correta”
- Como não há motivo para se preocupar com o Python errando uma conta, fica claro que a abordagem de geração de código é melhor em termos de verificação e confiança
- Essa lógica vai além de cálculos simples e também se aplica ao trabalho real de desenvolvimento
- Exemplo: recentemente fiz um trabalho de converter todo o formato deste blog de reStructuredText para Markdown
- Eu vinha adiando isso havia bastante tempo; em parte por preguiça, mas também porque, se eu entregasse a conversão diretamente para um LLM, não conseguiria confiar que não haveria alguma omissão sutil, erro ou distorção de contexto
- Então, no fim, em vez de usar o LLM para executar a conversão diretamente, fiz com que ele gerasse código de conversão e tratei tudo por código
LLM → código → LLM: como a automação de verificação iterativa funciona na prática
- Na primeira etapa, pedi ao LLM que gerasse a lógica central de conversão de reStructuredText para Markdown
- Não era uma conversão simples, e sim algo que usava diretamente AST (árvore sintática abstrata), de modo que
- reStructuredText fosse analisado em AST → convertido para AST de Markdown → renderizado em HTML
- assim eu teria uma etapa intermediária de conversão e seria mais fácil comparar e verificar diretamente o resultado
- Na segunda etapa, também pedi ao LLM para escrever um script que comparasse o HTML antigo com o HTML novo
- Ao analisar o diff do HTML após a conversão, ele foi projetado para corrigir automaticamente, antes da comparação, pequenas diferenças como espaços em branco e forma de tratar notas de rodapé
- Também fiz com que o LLM considerasse por conta própria os tipos de erro aceitáveis durante o processo de conversão
- Por exemplo, mesmo que a representação em HTML variasse levemente por causa de diferenças entre bibliotecas de Markdown e reStructuredText, o script foi ajustado para filtrar apenas perdas ou erros substanciais
- Na terceira etapa, também pedi ao LLM um script em lote para analisar os resultados de centenas de arquivos
- Com esse script, fui processando todos os arquivos e avançando em uma melhoria iterativa (loop agentic) até que as diferenças diminuíssem
- O processo completo foi o seguinte:
- no começo, rodei apenas uns 10 arquivos de amostra e repeti até que as diferenças diminuíssem bastante
- quando o resultado ficou satisfatório, apliquei em todos os posts e o processamento automático levou cerca de 30 minutos
- o ponto central é que eu pude confiar nisso não porque o LLM “teve sucesso” na conversão em si, mas porque consegui verificar e revisar todo o processo em “código”
- Além disso, ganhei ainda mais confiança ao pedir que outro LLM revisasse e explicasse o código gerado e as alterações
- Eu tinha confiança de que a conversão estava sendo feita mecanicamente de forma correta, sem perda de dados, e era fácil verificar amostras ou corrigir qualquer coisa a qualquer momento
- Mesmo no pior caso, só apareceriam pequenos erros de sintaxe Markdown, sem jamais estragar o conteúdo real do texto
- Outro ponto importante é que, nessa abordagem, o custo de inferência é constante, então a diferença de carga entre o número total de arquivos (15 vs 150) não é tão grande
- Na etapa final de análise, como pequenas diferenças já eram ignoradas automaticamente, a carga de validação iterativa não ficava alta nem em conversões em massa
MCP Cannot Do That
- O ponto desta longa explicação é que todo o pipeline de conversão e automação funciona em “código”
- entrada humana → geração de código → revisão por LLM → melhoria iterativa; essa mesma estrutura pode ser aplicada igualmente a tarefas gerais
- Um exemplo é o Playwright, caso representativo da abordagem MCP
- trata-se de uma ferramenta de automação para controlar o navegador remotamente, ler e entender páginas, clicar em botões etc., e a inferência se repete em cada etapa
- esse tipo de tarefa realmente não é algo que dê para substituir perfeitamente por uma “abordagem em código” em todos os casos
- Mas, se você já conhece a estrutura da página (por exemplo, ao testar um app próprio que você está desenvolvendo)
- é muito mais rápido e confiável pedir ao LLM para gerar um script Python com Playwright e executá-lo
- com essa abordagem, basta criar o script uma vez e ele pode ser executado dezenas ou centenas de vezes sem necessidade de inferência adicional
- não é preciso interpretar a tela em tempo real toda vez nem localizar botões a cada execução; você pode executar o fluxo inteiro de automação de uma vez
- A abordagem MCP exige chamadas de ferramenta abstratas e inferência em cada etapa, o que torna muito difícil fazer o LLM agir corretamente o tempo todo, além de dificultar bastante a depuração
- por exemplo, mesmo que você queira embutir um cliente MCP em um shell script para fazer chamadas eficientes a serviços remotos, na prática percebe que isso é muito ineficiente e difícil de implementar
- No fim das contas, eu sou um humano, não um cliente MCP.
- Código é fácil de executar e depurar, enquanto chamadas MCP são sempre incertas e pouco confiáveis
- na prática, acabo usando como ferramentas de longo prazo do meu processo de desenvolvimento os pequenos utilitários que o LLM cria durante a geração de código (por exemplo, snippets do Claude Code)
Para onde essa conclusão leva?
- Sinceramente, eu também não sei para onde isso vai levar. Mas agora é exatamente um bom momento para pensar em como melhorar mais a abordagem de geração de código para “agentic coding” intencional
- Pode soar estranho, mas às vezes o MCP realmente funciona muito bem. Ainda assim, a estrutura atual depende demais de “inferência” e parece um beco sem saída para automação escalável em larga escala
- Portanto, provavelmente precisamos separar e abstrair com mais clareza as áreas em que o MCP pode ter força e o papel da abordagem de geração de código
- para isso, também será necessário criar sandboxes melhores (ambientes de execução seguros) e tentar mudar o desenho das APIs para que agentes possam raciocinar livremente com fan out/fan in de APIs
- acho desejável uma estrutura em que tudo o que puder ser feito com código seja tratado com código, e depois de uma execução em massa o LLM julgue e revise o resultado geral
- E se adicionarmos contexto suficiente durante o processo de geração de código para que o LLM possa explicar em linguagem natural a um não desenvolvedor o que o script gerado faz, no futuro até pessoas não técnicas poderão usar esse fluxo de automação com facilidade
- Em conclusão, eu recomendo usar de forma mais ousada a capacidade dos LLMs de gerar código em vez de MCP, e experimentar novas possibilidades
- Se deixarmos o LLM escrever código diretamente, podemos automatizar muito mais coisas do que imaginamos
Referências
2 comentários
Concordo, mas acho que a questão é menos o problema do MCP em si e mais a otimização da direção do projeto. Mesmo com a mesma função, dependendo de qual MCP é usado, ele gera código e comandos internamente para reduzir trabalho desnecessário. Se usar o
gh cli mcpou umterminal mcpem vez do Github mcp, ainda vai consumir tokens, mas bem menos, e dá para obter o mesmo efeito. Acho que esse ponto acabou sendo ignorado.Comentários do Hacker News
Em geral, concordo que essa direção faz sentido. O uso de LLMs em larga escala costuma servir para preencher lacunas entre duas interfaces robustas. O ponto-chave da confiabilidade não vem do resultado do LLM em si, mas do fato de que essas interfaces só permitem configurações específicas.
A saída do LLM muitas vezes é forçada a se converter em valores mais determinísticos, como tipos ou primary keys do banco de dados. O valor do LLM varia muito conforme o quanto o código e as ferramentas existentes conseguem modelar bem os dados, a lógica e os comportamentos do meu domínio.
Pessoalmente, hoje vejo os LLMs como algo parecido com impressoras 3D. Ambos ajudam a conectar peças rapidamente em prototipagem rápida, mas, se você quer escalabilidade e robustez, no fim um engenheiro ou o próprio LLM precisa substituir essas conexões temporárias por suportes determinísticos como metal ou código.
Assim como aconteceu com as expectativas exageradas do passado sobre impressoras 3D, os LLMs também parecem capazes de substituir toda a realidade operacional, mas, na prática, só se tornam realmente úteis quando a modelagem digital já existente oferece uma base sólida
Percebi algo ao usar ferramentas com LLM. Se você reduzir o problema a uma forma que o LLM consiga resolver, usando ferramentas repetidamente dentro de um sandbox, dá para resolver esse problema por brute force. O essencial aí é identificar esse tipo de problema e definir o sandbox adequado, as ferramentas a usar e o critério de sucesso.
Esse processo também exige bastante habilidade e experiência, mas ainda assim está em um nível muito mais alto do que ficar fazendo tentativa e erro manualmente.
Percebi isso no meu "experimento do Mandelbrot em assembly".
(link do experimento: https://simonwillison.net/2025/Jul/…)
Idealmente, para automatizar de verdade, seria preciso ter um critério de avaliação em forma de função contínua ou, no mínimo, vários inputs com outputs esperados quantificados
Por exemplo, LLMs são fracos com genéricos de TypeScript, mas, se você deixar o TSC rodando de verdade, dá para testar continuamente e continuar tentando até acertar. A manutenibilidade do código pode piorar, mas, em teoria, é uma estrutura fascinante.
Além disso, o Cursor consegue ver erros de TypeScript, então, se você criar testes de utility types, o próprio Cursor pode escrever os testes e resolver o problema por repetição simples de brute force
Um repositório que vale consultar: https://github.com/davidkimai/Context-Engineering/…
Ainda não vi tudo, mas achei bem impressionante
Fico pensando se isso também seria viável com modelos locais ou com assinaturas como Claude Code Pro.
O experimento do Mandelbrot foi divertido, mas a dificuldade é um pouco diferente da de um codebase comercial complexo de verdade
Não acho que isso seja um problema do MCP em si. No nível atual da IA, uma estrutura com humano no meio é muito melhor.
LLMs são fortes em certas tarefas, mas frequentemente ficam presos em mínimos locais. Então, quando você fica indo e voltando numa interface web em um loop de "escreva o programa → verificar e dar dicas → testar", a qualidade melhora claramente.
Dá para transformar 10.000 linhas de código bagunçado em 400 linhas de código claro. Por enquanto, essa é a realidade.
Claro, muitas empresas e desenvolvedores querem "substituir o próprio programador por um LLM", mas isso ainda é impossível na prática.
O efeito real está em multiplicar a velocidade de trabalho do programador ou permitir que iniciantes façam trabalho produtivo rapidamente com ajuda de LLM. Mas o tal "agentic coding" ainda não funciona bem.
Na situação atual, o jeito certo é usar LLMs como colega ou assistente. A realidade é que, por enquanto, eles não são "agentes de IA" autônomos sem feedback
Trabalho com uma linguagem compilada, type-safe e funcional, então sempre preciso ler o resultado com meus próprios olhos; em uma linguagem menos rígida eu ficaria ainda mais preocupado.
Mesmo assim, a economia de tempo é grande. Gosto especialmente de como isso me ajuda a dividir o trabalho e lidar mais facilmente com objetivos grandes
Na prática, ao tentar fazer tarefas com GitHub MCP e comparar com fazer a mesma coisa com gh CLI, o gh CLI usa o contexto de forma muito mais eficiente e por isso é muito mais rápido.
Eu tenho no diretório "devops" um arquivo CLAUDE.md com uma coleção de comandos bash comuns.
Sempre que termino uma nova tarefa, peço ao Claude para adicionar um exemplo, e depois, em perguntas parecidas, ele resolve de uma vez só.
Conteúdo inicial do CLAUDE.md:
(os comandos específicos foram resumidos)
Então virou um tipo de software self-healing que, quando dá problema, adiciona ao comando instruções para testar e corrigir o app
Entre os usos de MCP que vi até agora, o mais impressionante foi o clojure-mcp de Bruce Hauman.
Ele fornece ao LLM (a) bash, (b) um REPL persistente de Clojure, e (c) ferramentas de edição estrutural.
Por causa disso, ao editar código Clojure ele funciona com muito mais eficiência do que uma abordagem puramente baseada em diff de texto.
Se houver uma suíte de testes adequada, foi impressionante ver como o loop de editar arquivo, recarregar e testar se aproxima bastante do trabalho humano
Ele oferece recursos centrais como debug de código, avaliação de expressões individuais e documentação dos tipos de retorno de funções.
Fiquei com a impressão de que linguagens com REPL poderoso são muito superiores nesse tipo de funcionalidade, e ver o potencial do clojure-mcp mudou bastante minha visão sobre IA
O exemplo com GitHub CLI não mostra toda a força do MCP.
Ferramentas como gh CLI, com documentação muito acessível, são naturalmente melhor aproveitadas por LLMs porque eles conseguem gerar código para elas com facilidade.
Mas a verdadeira vantagem do MCP aparece em ferramentas internas ou APIs de nicho com pouca ou nenhuma documentação online.
Dá para colocar toda a documentação no contexto, mas, nesses casos, o MCP tende a ser mais eficiente.
Se você usar uma ferramenta MCP bem projetada com o input correto, reduz bastante a carga sobre o LLM para entender API, autenticação, edge cases etc.
Talvez o GitHub realmente não precise de MCP, mas em ambientes com APIs internas ou incompletas, uma ferramenta MCP preparada de antemão funciona muito melhor
Por exemplo, no sonnet4 o limite já aparece ao passar de 15 ferramentas. Só o MCP oficial do Playwright já consome capacidade por conta do volume de ferramentas
No fim, a única vantagem do MCP pode ser apenas confirmar mais uma vez que a API era simplesmente complicada demais
Sobre o exemplo do Playwright,
eu também criei esta semana um agente baseado no servidor MCP do Playwright, mas achei lento, ineficiente em tokens e pouco confiável, então voltei para chamadas diretas ao Playwright.
O servidor MCP é bom para testar o que é possível, mas, na prática, chamadas de API são mais eficientes e estáveis.
Compartilho um exemplo e uma demo do agente pessoal de LinkedIn que criei:
O LinkedIn é conhecido como uma plataforma extremamente difícil de automatizar, então fiquei curioso se, ao criar esse agente pessoal de LinkedIn, você encontrou dificuldades ou limitações
Na real, sinto que só o terminal já basta.
Usei MCP diariamente por meses, mas agora só uso um único servidor MCP baseado em iTerm2 (terminal).
Ter uma especificação OpenAPI ajuda quando necessário, mas, na prática, shell commands e curl resolvem quase tudo
A crítica de que "precisa de contexto demais" na verdade se resolve com bons padrões de prompt inicial.
Todas as ferramentas principais, incluindo Claude Code e Gemini CLI, já dão suporte a isso
Passar ao LLM a lista completa de ferramentas para ele mesmo filtrar não é a melhor abordagem, mas
os LLMs mais recentes continuam melhorando, e na prática nunca tive grande dificuldade em fazer a seleção correta de funções MCP.
Sobre custo, velocidade e confiabilidade:
Você nem precisa gastar tempo diretamente na conversa
Num exemplo recente, o LLM lidou automaticamente com grande volume de ferramentas externas como Notion, Linear, git e logs de PR/CI do GitHub,
e eu só precisei revisar o PR uma única vez.
O custo ficou abaixo de 1 dólar
Na verdade, adicionar mais ferramentas pode exigir ainda mais informação logo no início, o que pode virar uma limitação séria
ela ainda está só escondida, e essa estrutura de promoções grátis ou baratas não vai durar muito.
Por exemplo, o Cursor já lançou plano de $200 por mês, e a qualidade do serviço nos planos baratos piorou.
Quando as promoções grátis acabarem, tudo deve voltar ao nível original
Eu trabalho com Julia e me beneficiei de um ambiente de sessão de longa duração.
Como as funções compilam na primeira execução, criei um MCP para o Claude Code enviar código para um kernel Julia persistente (Jupyter).
Rodar código de teste ficou muito mais rápido, e o CC passou a aproveitar melhor as funções existentes do codebase em vez de usar bash bespoke.
Segundo o CCUsage, o consumo de tokens caiu quase 50%.
Nem precisava necessariamente ser MCP, mas o ponto é que anexar uma 'funcionalidade específica' ao codebase é mais fácil do que escrever código customizado toda vez pensando no Claude