Em julho de 2026, no evento AI Engineer World’s Fair, eu acompanhei com atenção um bate-papo que ajuda muito a entender como as rotinas com agentes de código estão mudando por dentro de uma empresa de IA. A conversa reuniu Cat Wu e Thariq Shihipar, ambos da equipe Claude Code da Anthropic, com moderação de Simon Willison. O valor desse encontro, para mim, está no tom direto. Eles não falaram só de promessa. Falaram de rotina, falha, revisão, confiança e adaptação humana.
Logo no começo, um ponto chamou minha atenção. O lançamento do Claude Tag não foi apresentado como um simples atalho de chat, mas como uma integração colaborativa com o Slack que ganhou espaço real dentro da empresa.
O Claude Tag já era responsável por 65% dos PRs da equipe de engenharia de produtos da Anthropic.
Esse número, por si só, já muda a conversa. Não estamos falando de algo lateral. Estamos falando de uma peça de trabalho diário, conectada ao fluxo do time, com comportamento proativo, memória de equipe e capacidade de agir sem que alguém precise pedir tudo do zero a cada vez.
O que mudou com o Claude Tag
Quando eu vejo ferramentas assim sendo descritas, costumo procurar a diferença entre “ajuda pontual” e “presença operacional”. No caso do Claude Tag, a segunda definição parece bem mais fiel. Ele é usado em colaboração proativa e nas rotinas de bugs. Isso inclui monitorar problemas, puxar PRs para correção e até conectar informações de métricas sem uma demanda manual explícita.
Na prática, o Claude Tag funciona como um colega de time que lembra preferências passadas e volta a aplicá-las em interações futuras.
Essa memória de equipe é um detalhe grande. Se um canal já estabeleceu formato de resposta, padrão de correção, preferência de linguagem ou processo para triagem, isso não precisa ser reensinado toda hora. Eu vejo aqui um dos pontos mais fortes dessa nova fase dos agentes. O ganho não vem só da geração de código, mas da continuidade contextual.
Na Replitfy, eu noto que esse tipo de leitura é muito útil para quem está entrando no AI-Building. Muita gente ainda imagina IA apenas como resposta sob demanda. Só que o valor real aparece quando o agente passa a compor o sistema de trabalho.
Claude Tag e Claude Code não são a mesma coisa
Essa distinção apareceu de forma bem clara no bate-papo. O Claude Tag foi pensado para colaboração proativa e rotina de bugs, com forte presença em canais e processos recorrentes. Já o Claude Code fica mais voltado a tarefas complexas, interativas e mais profundas, nas quais o engenheiro quer conduzir uma sessão de construção, ajuste, teste ou reescrita.
Eu resumiria assim:
Claude Tag acompanha o trabalho em grupo e entra no fluxo do time.
Claude Code apoia tarefas maiores, com interação mais longa e mais contexto técnico.
Claude Tag opera muito bem em manutenção, acompanhamento e resposta contínua.
Claude Code aparece mais quando há uma meta de construção ou alteração de maior porte.
Claude Tag é rotina compartilhada. Claude Code é sessão de construção guiada.
Quando eu ensino ou escrevo sobre fluxos com IA, essa diferença ajuda bastante. Nem toda ferramenta precisa fazer tudo. Aliás, um dos aprendizados do próprio time foi buscar poucas ferramentas com funções bem distintas, removendo redundâncias como grep e glob quando isso confundia mais do que ajudava. Algumas ferramentas, como edição de arquivo, seguem presentes porque também servem à interface com o usuário.
Menos sobreposição. Mais clareza.
Ant fooding e o filtro antes do lançamento
Outro conceito interno que eu achei muito bom foi o de “ant fooding”. A ideia é simples: o time usa seus próprios produtos antes do lançamento público. Eu gosto dessa postura porque ela reduz a distância entre discurso e prática.
Na Anthropic, só recursos com retenção e engajamento interno, além de adoção por clientes selecionados, avançam para lançamento mais amplo.
Isso cria um filtro forte. Não basta o recurso parecer bom em demo. Ele precisa sobreviver ao uso real. E isso explica por que certas funções, como o auto mode, passaram um bom tempo em contexto interno antes de ganhar forma pública. Pelo que foi relatado, o auto mode já era padrão interno e só foi tornado público em março de 2026.
Esse modo de testar primeiro dentro de casa se conecta com algo que eu vejo com frequência em times maduros: confiança não nasce do anúncio, mas da repetição.
Engenheiros mais perto do produto
Talvez a parte mais humana e prática de toda a conversa tenha sido a mudança no dia a dia da engenharia. Com agentes de código mais presentes, o foco saiu um pouco da execução bruta e foi para senso de produto e negócio. O ciclo entre ideia e entrega de recurso caiu de meses para uma semana ou menos.
Isso muda muita coisa. Muda o tipo de pergunta feita no planejamento. Muda o peso da priorização. Muda o que se espera de um engenheiro.
Eu diria que o novo cenário exige mais destas capacidades:
Entender melhor o problema do usuário;
Formular escopo com mais clareza;
Julgar qualidade e risco;
Perceber impacto de negócio mais cedo.
Na prática, há menos tempo gasto com tarefas mecânicas e mais necessidade de visão. Para quem aprende com a Replitfy, isso conversa muito com a ideia de vibe coding com responsabilidade arquitetural. Não basta pedir para a IA “fazer algo”. É preciso saber o que pedir, como avaliar e como encaixar isso num produto que vai continuar vivo.
Casos que ninguém esperava
Uma das partes mais curiosas foi o relato sobre o sucesso inesperado do remote control, que permite controlar sessões do Claude Code pelo celular. Eu confesso que, num primeiro momento, isso soa quase como acessório. Mas justamente por isso ele surpreende. O recurso encontrou uso real e mostrou que conveniência, continuidade e presença fora da mesa de trabalho também contam.
Também apareceram exemplos mais criativos. Thariq fez um jogo de luta em estilo Street Fighter. Cat montou um app para acompanhar projetos de escalada, usando Claude Code e workflows para pesquisa e planejamento automáticos. Esses casos parecem até excêntricos à primeira vista, só que servem para mostrar amplitude.
Quando a barreira entre ideia e protótipo cai, usos improváveis passam a ser sinais de maturidade da ferramenta.
Automação não eliminou revisão humana
Esse ponto foi tratado com bastante franqueza. Mesmo com alto grau de automação, revisões manuais ainda ocorrem nos núcleos críticos do código por meio de code owners. Já áreas mais “externas” caminham para revisão automática com bots mais robustos.
O detalhe que eu mais gostei foi o processo gradual de confiança. Quando surgem PRs problemáticos, o time os insere em conjuntos de avaliação para evitar regressos no futuro. Isso mostra um modelo de aprendizado operacional. O erro não vira só correção pontual. Vira material de teste.
A confiança em revisão automática não é dada de uma vez. Ela é construída com avaliação contínua e memória de falhas.
Eu considero essa postura bem madura. Não existe salto cego para automação total. Existe segmentação do risco. O que é mais sensível recebe mais revisão humana. O que é mais periférico pode avançar antes com bots.
Rewrites deixaram de ser tabu
Outro tema que, anos atrás, geraria resistência, hoje aparece com mais naturalidade: reescrever código. Desde que haja boas test suites, rewrites passaram a ser vistos como boa prática em vários casos. A lógica é forte. Se o código atual funciona como especificação viva, ele pode ser destilado, reorganizado ou portado para outra base com mais segurança.
Foi citado, por exemplo, o caso do Bun reescrito em Rust. O exemplo ajuda a ilustrar essa visão de portabilidade guiada por comportamento validado.
Com testes sólidos, o código deixa de ser uma peça intocável e passa a ser uma fonte confiável para reescrita.
Eu acho essa mudança muito relevante para quem está aprendendo a construir com IA. Muita gente ainda se prende demais à primeira versão gerada. Só que, em fluxos melhores, a primeira versão é só o começo.
Prompts menores, mais contexto e menos proibições
Uma virada bem interessante apareceu no design de prompts para modelos mais recentes, como Fable e Opus 4.8. Segundo o relato, exemplos excessivos e listas longas de restrições do tipo “não faça x, não faça y” podem atrapalhar o resultado. Por isso, o time reduziu o system prompt em 80% nesses modelos.
Nos modelos mais novos, menos restrições e mais contexto podem funcionar melhor do que prompts longos e cheios de exceções.
Isso vai contra muita intuição antiga. Antes, parecia natural tentar cercar o modelo por todos os lados. Agora, a ideia é ajustar prompts para sempre estarem corretos, sem criar confusão entre regra e exceção. Em vez de empilhar avisos, o time prefere instruções mais limpas e diferentes conforme a versão do modelo.
Para mim, esse é um dos aprendizados mais úteis do encontro. Prompt bom não é prompt mais comprido. É prompt mais coerente com o comportamento do modelo em questão.
Quem acompanha os conteúdos da Replitfy sobre AI-Building tende a perceber essa mesma direção: contexto certo, ferramenta certa e menos ruído no processo.
Produto e treinamento trabalhando juntos
Eu achei valioso o fato de as equipes de produto e as de treinamento de modelos trabalharem de forma próxima. Essa relação ajuda a alinhar capacidades técnicas e comportamentos desejados. Em vez de produto pedir algo abstrato e treino responder depois, há colaboração mais direta.
Isso também aparece nos processos de avaliações, as chamadas evals, tanto internas quanto externas. Esses testes incluem red teaming para segurança e robustez contra ataques como prompt injection e exfiltração de dados. Em modos mais autônomos, isso pesa ainda mais.
As evals servem para medir comportamento real do agente, incluindo segurança, robustez e aderência ao que o produto espera.
Como o auto mode funciona
O auto mode é um dos pontos mais sensíveis do sistema, justamente por permitir mais autonomia. Pelo que foi explicado, um classificador Sonnet avalia cada comando com base no contexto e em permissões dinâmicas. Isso não acontece isoladamente. Há integração com sandboxing e gestão de credenciais por credential injection.
Na prática, o modelo não recebe acesso irrestrito. O sistema controla e audita acessos sem expor credenciais diretamente. Isso reduz superfície de risco e melhora rastreabilidade.
Eu vejo esse desenho como uma combinação de três camadas:
Classificação do comando e do contexto;
Isolamento operacional com sandbox;
Credenciais injetadas e auditáveis, sem exposição aberta.
O auto mode busca autonomia com controle, e não autonomia sem limite.
Para quem está levando agentes ao fluxo real, esse ponto faz muita diferença. Nos materiais da Replitfy sobre como aplicar AI-Building em projetos reais usando Replit, eu vejo uma preocupação parecida: construir rápido, mas sem abrir mão de estrutura.
O impacto humano continua no centro
Nem tudo é técnico. Um aspecto bem honesto da conversa foi a sensação de perda de papel, associada à imagem de “Deep Blue”. Muita gente sente que parte do trabalho que definia seu valor mudou de lugar. Essa reação é compreensível.
Mas a resposta interna sugerida foi outra: aumentar ambição e criatividade. Propor metas novas. Tentar projetos mais ousados. Adaptar funções. Um exemplo forte disso é o papel dos PMs, que vai ficando mais multifuncional e mais voltado a automatizar e conectar etapas antes travadas por decisão, fila ou silo.
Se a execução encurta, a ambição precisa crescer.
Eu gosto dessa leitura porque ela não nega o desconforto, mas também não o trata como ponto final.
Memória organizacional e desenho de ferramentas
A memória organizacional hoje ainda é baseada em arquivos markdown específicos por canal, embora existam testes para evoluir esse sistema. Isso mostra que nem tudo está fechado. Há muito trabalho em aberto sobre como preservar contexto coletivo sem gerar bagunça.
No desenho de ferramentas, o princípio é simples: poucas ferramentas, funções distintas. Isso ajuda o Claude a escolher melhor e reduz sobreposição. Eu vejo aqui uma lição bem prática para qualquer time que monta seus próprios workflows. Quanto mais redundância, maior a chance de decisão ruim ou de rota confusa.
Se o tema fizer sentido para sua rotina, vale acompanhar também conteúdos mais práticos em dicas e atualizações em novidades do Replit, porque esse tipo de mudança costuma aparecer primeiro no jeito de trabalhar, não só nas interfaces.
Aprendizados culturais que ficam
No fim da conversa, alguns aprendizados culturais ficaram bem nítidos. Eu resumiria em três frentes.
Trabalho em público. Canais públicos aumentam o contexto disponível para o Claude Tag.
Não negociar consigo mesmo. O time evita reduzir a ambição antes de ter evidência concreta de trade-offs reais.
Experimentação direta com feedback rigoroso. Em vez de longas teorias, o grupo testa, mede e ajusta.
A cultura molda o resultado dos agentes tanto quanto o modelo ou a interface.
Isso conversa bastante com a ideia de vibe coding bem feito. Não é improviso. É velocidade com critério. Se você quiser amadurecer essa visão, eu sugiro ler também o conteúdo sobre vibe coding para acelerar aprendizado em 2026, porque ele ajuda a ligar prática, formação e mudança de mentalidade.
Conclusão
Depois de acompanhar esse bate-papo, eu fiquei com uma impressão clara: as rotinas na Anthropic estão menos centradas em “pedir código” e mais em montar sistemas de trabalho com memória, avaliação, revisão graduada, segurança e adaptação humana. Claude Tag, Claude Code e auto mode representam camadas diferentes de uma mesma mudança. Uma cuida da colaboração proativa. Outra apoia sessões mais profundas. A terceira amplia autonomia com controle.
Não é um cenário sem tensão. Ainda há revisão manual em áreas sensíveis, medo de perda de papel, testes constantes contra falhas e muito ajuste de prompt, ferramenta e processo. Mas talvez seja justamente isso que torne esse caso tão útil. Eu não vejo ali uma automação mágica. Vejo um método.
Se você quer entender como aplicar essa lógica no seu próprio aprendizado e transformar ideias em software com ajuda de IA, eu recomendo conhecer melhor a Replitfy e ver como nossos cursos e mentorias podem apoiar sua formação em AI-Building na prática.
Perguntas frequentes
O que é o Claude Tag?
O Claude Tag é uma integração colaborativa com o Slack usada para acompanhar rotinas de equipe, agir de forma proativa em bugs, puxar PRs, conectar métricas e lembrar preferências passadas do time. Ele atua como uma memória operacional compartilhada, voltada ao fluxo coletivo.
Como funciona o modo auto code?
O auto mode funciona com um classificador Sonnet que avalia cada comando com base no contexto e nas permissões disponíveis. Esse processo é combinado com sandboxing e credential injection, o que permite controlar acessos, auditar ações e evitar exposição direta de credenciais.
Para que servem as rotinas na Anthropic?
As rotinas servem para reduzir trabalho repetitivo, acelerar correções, apoiar entrega de recursos em menos tempo e manter segurança, memória e revisão dentro do fluxo. Elas ajudam a deslocar a atenção da execução mecânica para decisões de produto, qualidade e negócio.
Vale a pena usar auto mode?
Vale a pena quando há necessidade de autonomia maior com controles bem definidos. O ganho aparece mais em fluxos frequentes e com boa governança. Em contextos sensíveis, ele funciona melhor quando combinado com revisão humana, evals e limites claros de acesso.
Onde encontrar exemplos de uso prático?
Exemplos práticos aparecem em casos como rotinas de bugs com Claude Tag, sessões complexas com Claude Code, controle remoto pelo celular, criação de jogos e apps pessoais, além de conteúdos aplicados sobre AI-Building e Replit publicados pela Replitfy em seu ecossistema de aprendizagem.
