Ricardo Coelho

Estou usando Claude Code massivamente. Não para sugestão de carteira, mas para análise dos documentos do RI e cruzamento de outras informações públicas. É absurdo.

A Anthropic anunciou que vai consumir toda a capacidade computacional do Colossus 1 da SpaceX, mais de 300 megawatts e 220 mil GPUs NVIDIA disponíveis em um mês, e declarou intenção de desenvolver com a SpaceX gigawatts de compute orbital. O efeito imediato pra quem trabalha com Claude Code é animador: dobram os limites da janela de cinco horas nos planos Pro, Max, Team e Enterprise, e acaba a redução de limite no horário de pico pros planos Pro e Max. Trabalhar com agentes em sessões longas estava virando um exercício de orçamento (quanto contexto eu posso queimar nesta janela / quanto sobra pra próxima), e o orçamento era apertado o suficiente pra condicionar o desenho da tarefa, mesmo no Max 20x. Dobrar a janela e tirar a punição de pico é a luz no fim do túnel para o regime onde o limite de taxa decidia o que dava pra fazer com o agente. A Anthropic agora tem cinco frentes simultâneas de processamento: Amazon com até 5 GW, Google com 5 GW, Microsoft/NVIDIA com 30 bilhões em Azure, Fluidstack com 50 bilhões em infraestrutura americana, e agora SpaceX. Num mercado em que o gargalo tem sido mais e mais a entrega física de energia, silício e refrigeração, a nova parceria funciona como hedge contra a escassez energética. Na leitura da Forbes, Jon Markman aponta que a SpaceX vem sinalizando há meses que 80% da produção projetada de chips do Terafab vai pra satélites em órbita baixa, e que a empresa já protocolou licença na FCC pra lançar até um milhão de satélites de data center. Este interesse da Anthropic representa a primeira vez que um laboratório de fronteira se compromete publicamente a avaliar a infraestrutura de IA espacial como opção real de procurement, abandonando o terreno da mera curiosidade. Se um único gigawatt entrar em operação no fim desta década, a estrutura de computação da IA deve mudar para sempre. Ganhamos, portanto, uma janela operacional que muda o desenho do trabalho com agentes, e mais uma confirmação de que o capex de IA está cada vez mais sendo travado não pela pesquisa, mas pela entrega de energia. Publicado originalmente em: https://www.anthropic.com/news/higher-limits-spacex

Claude_n_dev.MP4

É exatamente o mesmo case do Paperclip. Meu azar é que eu montei meu primeiro pipeline em fev. 2025 e ele não existia ainda... 😅 Mas se eu me perceber precisando implementar alguma grande mudança eu certamente vou considerar a migração.

Meu caso de uso é muito diferente disso. Meu objetivo não é usar a IA pra automatizar rotinas. É usar a IA para gerar código que automatiza rotinas. Isso é muito diferente. Quando você citou APM e SIEM ficou claro pra mim o seu prisma, mas este é um uso muito limitado e que te deixa dependente da IA pra sempre. Nesse contexto eu concordo com a sua visão. Mas este não é nem de longe o meu uso atual. Routines pra mim funciona muito bem porque eu consigo remover todo o pipeline de controle de versão do meu workflow principal. Posso focar na geração de código e análise de qualidade (não só testes unitários, mas end-to-end, UI/UX, segurança, pra citar alguns). Eu já faço isso hoje em um VPS dedicado e por isso me empolguei com a possibilidade de delegar esta camada inteira para um serviço gerenciado. Entendo que para você talvez não faça sentido, mas para a minha dinâmica atual é algo extremamente útil e reversível. Nos meus pipelines o controle de epics, stories, tasks e issues são centrais. Eu converso com meus agentes inserindo tarefas no quadro. A atuação dos agentes é automática, disparada pela inclusão de novos itens. Em seguida, o workflow é iniciado com as análises que citei em um loop de implementação-verificação-correção, até o all-green. Todos os agentes são instruídos a trabalhar em feature-branches, submeter pull requests que são avaliados e incorporados por outros agentes criados especificamente para este fim. É como um escritório de desenvolvimento de software, mas operado por agentes, usando skills, baseados em rules, dentro de um workflow previsível. Esta pra mim é a grande beleza deste ecossistema. Eu consigo desenvolver quatro, cinco projetos em paralelo, simplesmente cuidando da especificação e avaliação. Todo o processo de geração de PRD.md, SPEC.md, STACK.md, WORKFLOW.md ocorre a "quatro mãos", mas a partir daí, tudo cabe ao pipeline automatizado. É um admirável mundo novo e as primeiras naus apenas começaram a zarpar.

Eu achei bem útil porque já tira bastante da complexidade do workflow local. Se você pode delegar isto para uma outra camada, o pipeline fica bem mais simples e o contexto demanda menos podas. É verdade que aumenta o lock-in, mas nada que não possa ser revertido facilmente ou mesmo delegado a uma instância em um VPS. Pessoalmente eu gostei muito da ideia. Quando estiver pronto de fato acho que vai ser ainda mais útil.

Dia 14 de abril de 2026 a Anthropic anunciou Routines, transformando o Claude Code de um assistente que responde dentro de uma sessão interativa em um agente de fato, que executa trabalho sozinho, de madrugada, sem terminal aberto, sem operador presente. A documentação oficial descreve uma routine como "a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically". Uma definição que subestima a mudança de categoria que isso representa, se você me perguntar. Pra quem vem de ops, imagine um cron job que, em vez de rodar um script engessado, determinístico, usa um modelo de linguagem com acesso a repositórios, conectores MCP e pode commitar, enviar pushes e abrir pull requests. A Anthropic posiciona o projeto Routines entre cron jobs e "agentes persistentes com estado contínuo". Na prática, ele é mais flexível que um cron e mais efêmero que agentes persistentes. Quando li sobre Routines pela primeira vez, me veio logo à cabeça o Manus. Me perguntei se ele seria a próxima vítima da Anthropic. Afinal, os dois estão tentando responder à mesma pergunta: o que acontece quando o agente roda sem supervisão? Mas o Manus opera numa categoria diferente: é um agente de propósito geral com VM dedicada, browser real, terminal e sistema de arquivos, rodando tarefas de longa duração independentes do contexto de desenvolvimento. As duas arquiteturas divergem desde a fundação, e são disparadas de forma completamente distintas. As Routines são iniciadas por agendamento (horário, diário, semanal, ou cron customizado com intervalo mínimo de uma hora), webhook (GitHub, usando o Claude GitHub App, disparado por pull requests, releases e outros eventos) ou API (um POST HTTP com bearer token pra um endpoint dedicado). É possível que uma routine combine os três gatilhos. A Anthropic destaca como exemplo o review automático de PRs: um trigger de pull_request.opened executa a routine, que aplica um checklist do time e deixa comentários inline. Cada evento de webhook gera uma sessão isolada. Já o Manus não opera por triggers. Você descreve um objetivo em linguagem natural e o agente monta um plano com navegação web num Chromium real, execução de código numa sandbox e produção de arquivos. Só para quando considera a tarefa concluída, com uma média de cerca de 50 chamadas de ferramenta por sessão. Ganho real Não creio que o real valor das routines esteja no agendamento em si. Agendar tarefas é trivial. O ganho está no ciclo completo proporcionado: desde a intenção descrita no prompt, a execução autônoma na infraestrutura de nuvem da Anthropic, seguida do resultado materializado num PR ou numa mensagem de Slack/Telegram, concluindo com a possibilidade de inspecionar e analisar a sessão posteriormente. Ou seja, o ciclo entre "o que eu quero que aconteça" e "o que de fato aconteceu" que roda em loop, sem intervenção manual, até que o resultado seja atingido. Este é o valor efetivamente entregue pelas Routines, quando comparado com um script agendado via API do Claude. No caso do Manus, o mesmo problema de ciclo completo também é resolvido, mas pra um domínio mais amplo. A arquitetura usa CodeAct (ações primárias executadas via código Python) ao invés de tool calls pré-definidas, fazendo uso inclusive do Claude e de versões fine-tuned de Qwen como modelos de raciocínio, escolhendo qual deles deve executar cada sub-tarefa em VMs isoladas, com seus próprios recursos de: rede, automação de navegador e sistema de arquivos (inclusive como memória externa, para contornar os limites da janela de contexto, funcionando como contexto expandido e persistente). Nem tudo são flores Routines rodam em sessões completas de Claude Code na nuvem, sem permission mode e sem prompts de aprovação durante a execução. Ou seja, um --dangerously-skip-permissions por padrão. A documentação oficial é clara: "there is no permission-mode picker and no approval prompts during a run". Ou seja, o agente pode rodar comandos shell, usar skills commitadas no repositório e chamar qualquer conector MCP incluído na configuração. Se a configuração for excessivamente permissiva, o raio de alcance de um erro é potencialmente catastrófico: uma sessão com acesso total ao repositório e a todos os serviços conectados. O Manus usa contenção por isolamento físico. Tem acesso root dentro da sandbox, mas as operações não alcançam dados da conta nem outras sessões. Se alguma coisa quebra, a sandbox é recriada automaticamente. Mas o controle granular é grosseiro tanto quanto nas routines. Nenhum dos dois oferece policies declarativas pra restringir ações específicas dentro do perímetro. Escolhas diferentes de governança, mas com consequências parecidas. O histórico recente do Claude Code reforça a preocupação com as Routines. A Check Point Research publicou duas CVEs em 2025-2026: CVE-2025-59536 (CVSS 4.0: 8.7, execução arbitrária de código via configuração maliciosa em repositórios clonados) e CVE-2026-21852 (CVSS 4.0: 5.3, exfiltração de API keys via override de ANTHROPIC_BASE_URL). Todas corrigidas, mas ilustram que ataques via configuração de projeto operam abaixo do nível de prompt injection, com privilégios de desenvolvedor. Quando se tem agentes clonando repositórios automaticamente a cada execução, a superfície de ataque deste vetor continua relevante. Observabilidade Em janeiro, quando escrevi sobre debugging de agentes em produção, mostrei que o trace que captura apenas entrada e saída de cada chamada ao modelo mostra onde a saída divergiu, mas não por que divergiu. Com Routines o problema se agrava ainda mais porque a execução acontece sem ninguém assistindo. A Anthropic até oferece session URLs inspecionáveis em tempo real durante a execução e depois do fato e Manus mostra o replay com timeline de cada ação. Duas soluções necessárias, mas insuficientes, já que mostram o quê aconteceu, mas não o porquê. Se uma routine de review deixou um falso positivo num PR, você vê o output mas não o raciocínio intermediário que levou àquela decisão. Se o Manus gastou 3.000 créditos numa pesquisa que devolveu resultados irrelevantes (o que infelizmente não é raro), o replay mostra cada passo do browser sem explicar por que o agente decidiu seguir aquele caminho. Um time que precisa rodar 25 routines por dia (que é o limite do plano Team/Enterprise na data deste post) precisa de métricas agregadas: custo por routine, taxa de sucesso por trigger, tempo médio de execução, drift de comportamento. Funcionalidade que continua ausente nativamente nas duas ferramentas. Custo Routines consomem créditos da mesma forma que sessões interativas. No plano Pro (US$ 20/mês), o limite é de 5 routines por dia. No Max (US$ 100-200/mês) sobe pra 15. Os planos Team e Enterprise chegam a 25, com custo adicional pra quem exceder. Pela minha experiência, uma sessão típica de codificação usando técnicas de otimização consome entre 50 e 200 mil tokens de input e 5 a 20 mil de output, o que dá algo entre US$ 0,20 e US$ 4,00 por tarefa dependendo do modelo e da complexidade do contexto. Uma routine noturna rodando contra um monorepo com contexto complexo pode consumir uma fração significativa do orçamento mensal sem que ninguém perceba até o ciclo de billing fechar. O Manus opera por créditos: o plano Pro a US$ 20/mês dá 4.000 créditos mensais, mas uma pesquisa de 30 minutos consome entre 500 e 900, e um workflow autônomo longo passa facilmente de 5.000 (pergunte a qualquer usuário de Manus e assista a um adulto começar a chorar). Uma única tarefa complexa pode consumir o orçamento mensal inteiro de uma só vez. E ainda mais grave: os créditos gastos em tarefas que falham não são reembolsados, a menos que você consiga mostrar que foi um bug da plataforma, confirmado após investigação dos logs de execução. A variância de custo é alta nos dois, mas no Manus é pior porque a duração das sessões é aberta e o modelo de créditos não tem a limitação implícita que a assinatura do Claude impõe. Onde usar O que me interessa como decisão arquitetural é onde cada produto se encaixa no espectro de automação dos times que já operam em produção. A maioria dos times com CI/CD em escala já tem GitHub Actions, tarefas agendadas em infraestrutura própria, hooks customizados, e etc. Routines competem com essa camada. A vantagem é que o agente entende tanto o código como o contexto em linguagem natural. A desvantagem é que ele é estocástico, e a mesma routine pode produzir resultados diferentes em execuções consecutivas com o mesmo input. Pra validação de schema ou lint, um script continua sendo a opção segura. Para triagem de alertas e correlação de stack traces e commits recentes, Routines oferecem algo que scripts não conseguem entregar. Para todo o espaço de tarefas exploratórias eu prefiro o Manus, com seu navegador, dados heterogêneos e entrega fora do repositório: relatório, análise de mercado, protótipo. Routines herdam o que o Claude Code oferece (repositórios Git, skills commitadas, conectores MCP pra Slack, Telegram, Jira, Linear, PRs automáticos) e se limitam ao ecossistema de engenharia. Onde eles competem de fato: relatórios recorrentes que dependem de dados externos e triagem que precisa consultar documentação fora do repositório. Nestes casos, o fator de desempate que eu uso é se o artefato final vai para dentro do repositório (Routines) ou não (Manus). Se você ainda está avaliando qual delas usar, sugiro observar uma questão além dos fatores técnicos, mas que pode pesar na questão da dependência operacional. A China recentemente vetou a aquisição do Manus pela Meta. O acordo de US$ 2 bilhões anunciado em dezembro de 2025 foi bloqueado, mas até a data de publicação deste artigo ainda não sabemos se a reversão vai ocorrer de fato, pois a Meta já integrou funcionários e produto. Isto é um risco de continuidade que não aparece nos benchmarks, mas que deveria ser considerado na sua decisão final. Por outro lado, o projeto Routines ainda está em research preview, e a Anthropic já avisou que "behavior, limits, and the API surface may change". Além disso, o endpoint de API roda com o cabeçalho experimental-cc-routine-2026-04-01, e as duas versões anteriores mantêm compatibilidade temporária pra dar tempo de migração. Ou seja, prepare-se para refatorar tudo que desenvolver neste momento para esta API. Publicado originalmente em https://rcoelho.dev/post?slug=routines-vs-manus

BOLA significa Broken Object Level Authorization. Mas o ponto que importa não é a sigla técnica e sim o que quer dizer. É uma falha em APIs em que o sistema confere se o usuário está logado, mas não verifica se os dados que ele está pedindo são realmente dele. Imagine chegar no seu prédio e, depois de o porteiro confirmar que você é morador e liberar sua entrada, encontrar destrancadas as portas de todos os apartamentos. O caso tem duas narrativas em disputa. O pesquisador @weezerOSINT diz que se trata de um vazamento em massa atingindo todos os projetos criados antes de novembro de 2025, bastando poucas chamadas de API pra explorar. A Lovable nega que houve violação de dados e afirma que este comportamento é intencional pra projetos marcados como públicos, sendo a "documentação ruim" a única falha real. Vale entrar nessa divergência, até porque ela determina o tamanho do problema. A defesa da Lovable se ancora num ponto legítimo. Um projeto marcado como público em uma plataforma de desenvolvimento é, de fato, público. Código, histórico de build, conversas com a IA. Quem marcou a opção e saiu colando credenciais dentro dos prompts tem uma parcela gigante de responsabilidade no que expôs. A empresa admite que a documentação sobre o significado de "público" era ambígua, o que se parece muito com um sopro de honestidade. Mas tem um detalhe que a própria Lovable admitiu e que desmonta centralmente a sua defesa. Em fevereiro de 2026, durante uma unificação de permissões no backend, a empresa afirma que "reativou acidentalmente" acesso a chats em projetos públicos. O ato falho está na escolha da palavra "acidentalmente". Se houve reativação acidental, é porque antes havia restrição. E se havia restrição, o comportamento posterior não é intencional, mas regressão. O argumento de que tudo é "by design" cai no momento em que se reconhece que algo voltou sem querer. A cronologia também pesa contra a versão da empresa. O reporte chegou em 3 de março via HackerOne. Ficou 48 dias parado, classificado como "duplicate submission" sob o entendimento de que ver chats de projeto público era intencional. A divulgação pública só veio em 20 de abril, após quase sete semanas de dados sensíveis permanecerem acessíveis enquanto o canal oficial de bug bounty tratava o report como simples "ruído". A partir daí, mais do que um debate semântico sobre o que é ou não público, o caso evoluiu para uma falha de processo de segurança em cima do que deveria ser só uma falha técnica facilmente sanável. De outro lado, mesmo aceitando o argumento de que projeto público é público, o pesquisador fere de morte a defesa da empresa quando destaca que uma credencial de banco em um histórico de chat com o modelo não chega lá por escolha consciente do usuário. Veja, a própria interface da Lovable convida o desenvolvedor a colar o contexto real do projeto pra obter ajuda contextualizada. Além disso, em nenhum momento da conversa o sistema sinaliza que aquela informação pode ir a público. Quem está certo? Pra mim a Lovable tem razão num ponto secundário: público é público, e parte do conteúdo exposto é fruto de uma configuração que o usuário, em tese, escolheu de forma consciente. Mas o pesquisador tem razão no ponto central: houve BOLA real, com regressão admitida em fevereiro, e com falha clara de escalonamento no canal de bug bounty. Não é um empate. É um 7x1 do @weezerOSINT sobre a Lovable. E por que isso interessa pra quem não é técnico? Ora, segundo o site da própria empresa, usam a sua plataforma clientes como Uber, Zendesk e HubSpot, dos quais você provavelmente é usuário. E ainda que esperemos mais discernimento da equipe técnica de uma empresa deste tamanho, não há nada impedindo um desenvolvedor menos cuidadoso de jogar uma credencial em alguma IA pra pedir uma ajuda eventual e fechar um ticket no prazo, desesperadamente. Basta isto para que esta credencial passe a existir num servidor de terceiros. Se esse servidor expõe o chat por BOLA, o vazamento não atinge só o desenvolvedor, mas a cadeia inteira de empresas que confiam nele. E isto não vale apenas para a Lovable, mas para qualquer plataforma de IA em que a conversa com o modelo pareça privada porque a interface é íntima, enquanto o conteúdo dessa conversa mora num banco de dados que não é seu. A privacidade percebida e a privacidade efetiva são coisas diferentes, e essa diferença só aparece no dia do vazamento. Plataformas que crescem rápido e tratam segurança como algo que podemos "ver depois" surgem na mesma velocidade em que a tecnologia evolui, e essa velocidade só aumenta. A adoção destas ferramentas está se mostrando ainda mais rápida, principalmente pelo número exponencialmente crescente de "desenvolvedores assistidos por IA". E se nenhum destes atores está prestando a devida atenção às questões de segurança, temos nós, os usuários, que tratar cada prompt como o que ele de fato é: uma carta sem envelope, num cofre que não é nosso, com a senha rabiscada a lápis na parede ao lado da porta. publicado originalmente em rcoelho.dev

Tem umas dicas aqui: https://rcoelho.dev/post?slug=quatro-ferramentas-radicalizam-otimizacao-tokens

eu-claudio.mp4

Fala pessoal, dev full stack aqui. Sou também auditor certificado ISO 27001. https://linkedin.com/in/ramcoelho

Se eu te contar que o pi second foi hoje às 1:59 da madrugada? (3.14159…)

Hoje não é apenas o dia do pi (14/03 => 3.14), mas também é aniversário de Albert Einstein e dia do lançamento oficial do kernel Linux 1.0.0. Portanto, happy geek day!

Meus dois melhores contratos fora do Brasil vieram do UpWork. Não se engane, o UpWork é bem m… pra ganhar dinheiro. Leilão mesmo, tipo fim de feira. No entanto, se você aguentar trabalhar quase de graça por 3-4 meses, pode ir pedindo reviews positivas que vão te levar a subir na classificação do site (Rising Talent, Top Rated, Top Rated Plus e Expert-Vetted). A coisa só começa a ficar boa quando você atinge um destes dois últimos badges. É aí que começam os convites realmente interessantes e as propostas de verdade, com retainers ou contratos long-term. Vale um alerta: não é pra todo mundo. Mas se você tiver muita paciência e pouco juízo, tua pegada pode ser essa aí…

Tamo junto. É só marcar de Goianear que a gente Goianeia. Março, Abril, Maio… qualquer mês. Acho que conteúdo tech faz mais sentido. E se precisar de mãos extras na organização pode contar com a gente.

Hoje estou usando Contabilizei + Remessa Online. Mas já catei várias sugestões aqui pra ver se dá pra economizar alguma coisa. Volto aqui pra dizer.