Claude Docs E Slides: O Que Dá Pra Automatizar Na Documentação De Um Time Técnico

Toda sexta-feira de fim de sprint tem um momento que ninguém do time gosta: alguém precisa montar o deck da review. Não é um trabalho difícil, é um trabalho chato. Juntar o que foi entregue, puxar dois ou três números do board, colar um print do dashboard, escrever três bullets de risco e torcer para que o stakeholder não pergunte justamente sobre o item que escorregou. Em quase todo time por onde passei, esse deck é feito na última hora e por quem perdeu a disputa silenciosa de "quem faz dessa vez".

Por isso, quando li a cobertura da VentureBeat sobre o lançamento do Claude Docs e do Claude Slides, a primeira coisa que me veio não foi a narrativa de produto, foi essa sexta-feira. A segunda foi a pilha de documentação que todo time técnico carrega meio atrasada: o ADR que ficou no "depois eu escrevo", o runbook que ainda cita um serviço que foi desligado, o postmortem que tem timeline mas não tem as ações acordadas.

Vale deixar claro desde já: eu não testei os dois produtos. É um beta que começou a ser liberado em 16 de setembro para Pro e Max, com expansão gradual depois, e tudo o que escrevo aqui vem do que a Anthropic descreveu e do que a imprensa especializada reportou. Os cenários que aparecem ao longo do texto são hipotéticos e estão marcados como tal.

O que quero fazer é um exercício de encaixe. Primeiro, o que exatamente foi lançado e como funciona pelo que foi descrito. Depois, onde Docs e Slides se encaixam nos artefatos que um time de engenharia produz de verdade: ADRs, specs, runbooks, postmortems, decks de review e material de onboarding. Por fim, a comparação com docs-as-code, o Markdown versionado no repositório, e a lista honesta do que ainda não se sabe e que deveria pesar antes de qualquer adoção.

O Que A Anthropic Lançou Em 16 De Setembro

O anúncio tem duas metades. A primeira é a que ganhou manchete: o Cowork deixa de existir como modo ou experiência separada dentro do Claude. Quem acompanhou o blog lembra que cobri o lançamento do Cowork em março, quando a Anthropic começou a empurrar o Claude de assistente de chat para agente de trabalho. Agora, segundo a VentureBeat, o próprio Claude decide se a tarefa pede uma resposta, um documento, uma apresentação ou trabalho agêntico contínuo, com conectores, arquivos locais, navegação web, tarefas agendadas e permissões configuráveis. A justificativa da Anthropic citada pela VentureBeat é direta: as pessoas usavam os dois modos e a parte frustrante era decidir onde cada tarefa pertencia. A história de negócio por trás disso é assunto para outro post; aqui me interessa a segunda metade.

A segunda metade são os dois produtos novos. O Claude Docs é um editor de documentos dentro do Claude, em que o modelo e os colegas escrevem juntos. O Claude Slides é a mesma ideia aplicada a apresentações: você pede o deck numa conversa normal, edita slide a slide e apresenta direto do Claude. Os dois vivem em links compartilháveis e, segundo as reportagens, podem ser editados inclusive pelo celular.

A disponibilidade é o primeiro ponto que um tech lead precisa ter claro. Segundo a VentureBeat, os dois saem em beta, primeiro para assinantes Pro e Max em web, desktop e mobile, com Team e Free chegando nas semanas seguintes. A The Next Web acrescenta que administradores Enterprise terão pelo menos 30 dias de aviso antes do rollout, e a Computerworld reporta que o recurso vem desligado por padrão no Enterprise. Na prática, se o seu time está num plano Team, é bem possível que você ainda não tenha nada disso na tela enquanto lê este texto.

Como Docs E Slides Funcionam, Pelo Que Foi Descrito

O fluxo do Docs, pelo que as reportagens descrevem, começa numa conversa. Você pede um documento, o Claude pode fazer perguntas de esclarecimento antes de começar, redige as seções e deixa comentários explicando as escolhas que fez. O documento nasce privado e depois pode ser compartilhado com pessoas nomeadas ou com a organização inteira, segundo a VentureBeat. A partir daí, colegas editam em tempo real, comentam, e o Claude participa da mesma superfície, redigindo seções novas ou comentando decisões.

Esse detalhe dos comentários é o que mais me chamou atenção. Um assistente que escreve e ainda anota "escolhi estruturar assim por causa disso" muda a dinâmica de revisão. Em vez de receber um bloco de texto pronto e ter que adivinhar o que foi suposição do modelo, o revisor tem um ponto de apoio para discordar. Se isso funciona bem na prática, eu não sei; mas o desenho vai na direção certa para documentação técnica, em que o raciocínio importa tanto quanto a conclusão.

Na exportação, as fontes não batem exatamente, então vale ser preciso. A VentureBeat e a tbreak citam exportação do Docs para Word e Google Docs, com a VentureBeat mencionando que outros destinos estão planejados. A Computerworld lista Word, PDF, Google Docs e Markdown. Para quem trabalha com docs-as-code, a presença de Markdown faz diferença, e eu trataria como algo a confirmar na tela antes de desenhar qualquer fluxo em cima disso. No Slides, as fontes convergem em download como PowerPoint ou PDF.

O Slides, por sua vez, é explicitamente diferente do add-in Claude for PowerPoint que já existia. O add-in trabalha dentro do PowerPoint; o Slides é um deck que mora no Claude, com link próprio, edição por slide e modo de apresentação nativo. A Computerworld nota ainda que o Claude Design, voltado a saídas visuais, também passa a ser invocável na conversa normal, e que os arquivos ficam na aba de Artifacts.

Onde Isso Encaixa Na Documentação De Um Time Técnico

Documentação de engenharia não é um bloco homogêneo. Cada artefato tem um ciclo de vida, um público e um lugar natural para morar, e a pergunta certa não é "Claude Docs serve para documentação?", mas "para qual documento ele serve melhor do que o que já temos?". Vou passar pelos quatro que mais aparecem no dia a dia.

O ADR, Architecture Decision Record, é o caso mais interessante. Um ADR bom tem contexto, opções consideradas, decisão e consequências. O que costuma faltar não é a decisão, é o registro das alternativas descartadas, porque ninguém tem paciência de escrever isso depois da reunião. Imagine um cenário hipotético: o time discute numa call se migra uma fila de RabbitMQ para Kafka, alguém cola as notas soltas numa conversa com o Claude e pede um ADR no template do time. O Claude redige, comenta onde suspeita que falta informação ("não ficou claro qual o volume de mensagens que motivou a discussão") e dois engenheiros editam juntos no mesmo link. O ganho está em transformar notas soltas em estrutura e em explicitar lacunas. O ponto de atrito é que, na maioria dos times que conheço, o ADR aprovado precisa morar no repositório, perto do código que ele justifica.

A spec técnica, ou RFC, é o artefato em que a colaboração em tempo real mais pesa. É um documento vivo durante semanas, com gente de produto, de engenharia e às vezes de segurança comentando. Aqui o modelo de "documento compartilhado com comentários" é exatamente o que times já usam no Google Docs ou no Notion. A diferença que o Claude Docs propõe é o modelo estar dentro dessa superfície, podendo, por exemplo, redigir a seção de rollout depois que a discussão de design fechou, ou apontar inconsistência entre a seção de requisitos e a de API. Num cenário hipotético, o autor da spec pede ao Claude uma seção de riscos e recebe, junto, comentários nos trechos em que a spec promete algo que a seção de capacidade não sustenta.

O runbook é o caso em que eu seria mais cauteloso. Runbook precisa estar certo, atualizado e acessível às três da manhã, de preferência do mesmo lugar onde o alerta aponta. Usar o Claude Docs para gerar o primeiro rascunho de um runbook a partir de um histórico de incidentes ou de notas de plantão parece útil. Deixar o runbook oficial morando num link de um produto beta, sem histórico de versões, é outra conversa. Um runbook alterado silenciosamente, sem saber quem mudou o comando de failover, passa uma confiança que não merece.

O postmortem fica no meio do caminho e talvez seja o encaixe mais natural. É um documento com prazo curto, escrito a várias mãos, com timeline, causa, impacto e ações. A parte mais trabalhosa é consolidar a timeline a partir de mensagens de Slack, logs e anotações de quem estava no incidente. Pense num cenário hipotético: o incident commander cola o export do canal do incidente numa conversa, pede o postmortem no formato blameless do time e depois convida os envolvidos para revisar no mesmo documento. O Claude comenta onde a timeline tem buracos e sugere ações. A versão final pode ser exportada para onde o time guarda seus postmortems. A revisão humana continua sendo o que dá valor ao documento; a automação tira o peso da consolidação.

Slides Para Sprint Review E Onboarding

Voltando à sexta-feira do começo do post. O deck de sprint review é, na minha leitura, o caso de uso mais óbvio do Claude Slides para um time técnico. É um artefato descartável, que ninguém quer produzir, cujo conteúdo já existe espalhado em outros lugares e cujo público é misto. Tudo o que um gerador de slides precisa para ser útil está ali.

O ponto que torna isso mais interessante do que um gerador de slides qualquer é a convergência com o trabalho agêntico dentro do mesmo Claude. Com a incorporação do Cowork, a conversa que monta o deck é a mesma que tem acesso a conectores e ferramentas. Num cenário hipotético, o tech lead pede "monte o deck da review da sprint 42 com o que foi fechado no board, os dois incidentes da quinzena e os riscos que discutimos na daily", e o Claude busca o que tem acesso, monta os slides e deixa o link para o time ajustar antes da reunião. Se os conectores do seu ambiente cobrem o board e o canal de incidentes, isso é plausível; se não cobrem, você volta a colar contexto na mão. Vale lembrar que isso conversa com a lógica de delegar tarefas de forma assíncrona que discuti no post sobre o Dispatch: o valor aparece quando você não precisa ficar sentado acompanhando a geração.

O onboarding é o segundo encaixe natural, e aqui Docs e Slides trabalham juntos. Todo time tem um material de onboarding que alguém escreveu com muito carinho dois anos atrás e ninguém atualizou. Imagine um time que usa o Claude para gerar um deck de visão geral da arquitetura para novos membros, a partir do documento de arquitetura existente, e um Doc de "primeira semana" com os passos práticos. O deck é apresentado na primeira reunião com a pessoa nova, direto do Claude, e o Doc fica no link compartilhado. A pessoa nova pode, inclusive, comentar onde ficou perdida, e esses comentários viram insumo para a próxima versão.

Docs-As-Code Ou Claude Docs: Quando Cada Um Faz Sentido

Muito time técnico maduro já resolveu boa parte da documentação com docs-as-code: Markdown no repositório, revisado por pull request, publicado por pipeline com MkDocs, Docusaurus ou similar. É um modelo que tem vantagens que nenhum editor colaborativo substitui com facilidade: histórico completo no Git, review com o mesmo rigor do código, documentação que muda no mesmo PR que muda o comportamento, e uma fonte de verdade que agentes de coding também leem.

Esse último ponto merece atenção. Nos posts sobre CLAUDE.md, AGENTS.md e steering files e sobre instruções compartilhadas e curadas para times que usam coding agents, o argumento central era que o contexto do projeto precisa morar em arquivo versionado, revisável e herdado. Um ADR que mora só num link do Claude Docs não é lido pelo agente que está refatorando o módulo que aquele ADR justifica. Documentação fora do repositório, para agentes de coding, simplesmente não existe, a menos que alguém faça a ponte.

Isso não torna o Claude Docs irrelevante para times com docs-as-code. Torna ele uma etapa do fluxo, não o destino. A tabela abaixo resume como eu enxergo a divisão, com a ressalva de que ela reflete o que foi divulgado sobre o beta, não uso real.

O fluxo híbrido que me parece mais sensato, e aqui estou especulando sobre como eu desenharia se fosse adotar, é usar o Claude Docs como área de rascunho colaborativo e o repositório como área de publicação. A spec nasce no Claude Docs porque precisa de comentários de produto e de engenharia ao mesmo tempo. Quando ela fecha, a decisão vira um ADR em Markdown num PR. O postmortem é consolidado no Claude Docs e a versão final vai para o repositório de postmortems. A condição para esse fluxo funcionar sem retrabalho é a exportação para Markdown ser boa, e é por isso que eu trataria esse ponto como o primeiro teste a fazer quando o recurso chegar.

Um esboço de como isso poderia aparecer num guia interno do time, apenas como ilustração:

Onde cada documento mora:

- Rascunho de spec/RFC: Claude Docs (link no ticket do épico)
- Spec aprovada: exportar para Markdown -> docs/specs/ via PR
- ADR: sempre em docs/adr/NNNN-titulo.md, revisado por PR
- Postmortem: rascunho no Claude Docs; versão final em docs/postmortems/
- Runbook: somente no repositório, nunca apenas em link externo
- Deck de sprint review: Claude Slides, sem obrigação de versionar

Os Limites Que Importam Antes De Adotar

O primeiro limite é o óbvio: é beta, com rollout gradual. Durante algumas semanas parte do time pode ter o recurso e parte não, o que por si só já inviabiliza padronizar qualquer processo em cima dele.

O segundo limite é o que a Computerworld listou e que, para documentação técnica, pesa mais do que qualquer funcionalidade: no beta não há histórico de versões, não há controles de nível de acesso e não há compartilhamento externo nos planos Team e Enterprise. A reportagem diz ainda que o recurso não está disponível para contas com chaves de criptografia gerenciadas pelo cliente, zero data retention ou configurações HIPAA, e que o uso conta para os limites de tokens do Claude. Qualquer um desses itens sozinho já tira runbooks e ADRs oficiais da mesa por enquanto. Todos juntos deixam claro que o produto, hoje, é para rascunho e colaboração, não para registro.

O terceiro limite é o que simplesmente não se sabe. Não encontrei nas fontes nada sobre integração com repositórios Git, sobre API para criar ou atualizar documentos programaticamente, sobre templates de organização, sobre retenção ou sobre busca entre documentos. A The Next Web lista como desconhecidos os controles detalhados de permissão e compartilhamento e o prazo para sair do beta. A tbreak fecha com a pergunta que eu também faria: quão bem os arquivos gerados sobrevivem fora do Claude, e quanto controle os times terão sobre compartilhamento e administração.

O quarto ponto é de governança, e é mais sobre o time do que sobre o produto. Quando o Claude redige uma seção de um ADR, quem é o autor da decisão? O ADR existe para que alguém daqui a dois anos saiba por que a decisão foi tomada e quem pode explicar. Um documento em que o modelo escreveu o raciocínio e os humanos só aprovaram corre o risco de registrar uma justificativa que ninguém no time de fato sustentou. A regra que eu adotaria é simples: o Claude pode estruturar, redigir e apontar lacunas, mas as opções consideradas e o motivo da escolha precisam vir de quem estava na discussão.

Por fim, a questão competitiva, que afeta a decisão de adoção mais do que parece. Microsoft e Google já embutem IA nas suítes que as empresas usam, e a Computerworld registra o ceticismo de analistas sobre a disposição de usuários trocarem hábitos consolidados. Arun Chandrasekaran, do Gartner, disse à Computerworld que o movimento sinaliza o Claude passando de assistente para uma plataforma agêntica "para o ciclo de vida completo do trabalho do conhecimento". Já comparei esse tipo de disputa em ChatGPT Work versus Claude Cowork, e a lição daquele post vale aqui: a escolha raramente é pela melhor funcionalidade isolada, e sim pelo que se integra ao lugar onde o time já trabalha.

Conclusão

Olhando o que foi descrito, o Claude Docs e o Claude Slides resolvem bem uma categoria específica de documentação técnica: a colaborativa, de vida curta e de público misto. Rascunho de spec, consolidação de postmortem, deck de sprint review, material de onboarding. São exatamente os documentos que os times produzem atrasados e com má vontade, e onde ter o modelo presente depois do primeiro rascunho, comentando e ajustando, pode tirar um peso real da semana.

Para a documentação que é fonte de verdade, como ADR aprovado, runbook e referência de arquitetura, o beta ainda não tem o que seria necessário: histórico de versões, controle de acesso, integração com o repositório onde o código e os agentes de coding vivem. Minha aposta, e é aposta, é que o fluxo que faz sentido para times com docs-as-code é o híbrido, com rascunho no Claude e publicação no Git. E a condição para isso funcionar é uma exportação para Markdown confiável, que eu ainda trataria como algo a validar e não como fato.

Não sei se a sexta-feira do deck de review vai ficar mais leve. Depende de conectores, de template, de o time confiar nos números que o modelo puxou. Mas é a primeira vez que a pergunta "dá pra automatizar isso?" tem uma resposta concreta dentro da mesma ferramenta que o time já usa para escrever código e conversar sobre ele. Quando o recurso chegar aos planos Team, vale reservar uma sprint para testar com um documento de baixo risco antes de mudar qualquer processo.

Fontes:

• VentureBeat — Anthropic is killing off Cowork and folding it into Claude, launching Claude Docs and Claude Slides
• Computerworld — Anthropic tries to make Claude stickier with launch of Docs and Slides
• The Next Web — Anthropic merges Claude Cowork into Claude, adds Docs and Slides
• tbreak — Claude Docs and Slides: one Claude