De tempos a tempos, reservo uma manhã para ler. Não o código Rasepi, não os problemas do GitHub. Blogs de concorrentes, relatórios do setor, anúncios de palestras, pesquisas com desenvolvedores. O que quer que tenha sido lançado no último trimestre e que tenha a ver com documentação, gestão do conhecimento ou fluxos de trabalho assistidos por IA.
Fiz isso na semana passada, e a imagem que surgiu foi mais nítida do que eu esperava. Não porque um único anúncio tenha sido inovador, mas porque cinco tendências distintas estão a convergir e, quando as alinhamos, elas traçam um quadro muito claro do que as plataformas de documentação terão de fazer nos próximos dois anos.
Eis o que descobri.
1. A IA é o principal leitor agora. Não os humanos.
O GitBook publicou um número impressionante em seu [relatório de dados de documentos de IA] (https://www.gitbook.com/blog/ai-docs-data-2025): A leitura de documentação por IA aumentou mais de 500% em 2025. Quinhentos por cento. Isso não é um erro de arredondamento.
Enquanto isso, o [2024 Developer Survey] do Stack Overflow (https://survey.stackoverflow.co/2024/) mostrou que 61% dos desenvolvedores gastam mais de 30 minutos por dia procurando respostas. Mas a forma como eles pesquisam mudou. A própria pesquisa do GitHub descobriu que 97% dos desenvolvedores corporativos usaram ferramentas de codificação de IA. Até 2026, 84% dos desenvolvedores usam ferramentas de IA diariamente, com 41% do código agora gerado por IA. Estas pessoas não estão a navegar na barra lateral do seu wiki. Estão a perguntar ao Claude ou ao Copilot, e a IA está a ler os seus documentos em nome delas.
A implicação é difícil de exagerar. O seu consumidor mais frequente de documentação já não é uma pessoa com um separador do browser aberto. É um modelo de linguagem que faz chamadas de recuperação. E esse modelo não tem capacidade para olhar para uma página e pensar "hmm, isto parece desatualizado".
O GitBook apercebeu-se disso cedo e respondeu com o seu relatório State of Docs 2026 e um impulso para formatos legíveis por máquinas. Também lançaram o skill.md, uma convenção para estruturar informações sobre produtos especificamente para agentes de IA. A Google foi mais longe com o seu Gemini API Docs MCP, que liga os agentes de codificação à documentação atual através do Protocolo de Contexto de Modelo. O seu raciocínio foi explícito: os agentes geram código desatualizado porque os seus dados de treino têm uma data limite. A correção do MCP elevou a taxa de aprovação da avaliação para 96,3%.
Portanto, a primeira tendência está estabelecida. A IA é o leitor principal. As plataformas que tratarem este facto como uma restrição de conceção fundamental, e não como uma funcionalidade a acrescentar mais tarde, terão uma vantagem estrutural.
2. A frescura e os metadados de confiança estão a tornar-se obrigatórios
A Anthropic entrevistou 81.000 utilizadores do Claude em dezembro de 2025 e publicou os resultados em março de 2026. É o maior estudo qualitativo de utilizadores de IA alguma vez realizado (159 países, 70 línguas). A preocupação mais citada? A falta de fiabilidade. 27% dos inquiridos indicaram-na como a sua principal preocupação, e 79% dessas pessoas tinham-na experimentado em primeira mão.
Este número deveria deixar qualquer equipa de documentação acordada à noite.
Quando as respostas da IA não são fiáveis, o problema nem sempre é o modelo. Muitas vezes, o modelo está a reproduzir fielmente o que encontrou num documento obsoleto. O modelo não alucinou. Os seus documentos estavam simplesmente errados e ninguém os assinalou.
Os dados do Stack Overflow reforçam isso de um ângulo diferente: 81% dos programadores esperam que a IA seja mais integrada na forma como documentam o código no próximo ano. Se 81% dos seus utilizadores estão a fornecer documentos à IA, e 27% dos utilizadores de IA dizem que a falta de fiabilidade é o maior problema, tem um problema de confiança que nenhuma quantidade de engenharia rápida resolve. A correção está na fonte.
É por isso que os metadados de atualidade são importantes. Não os carimbos de data/hora da "última edição" (estes dizem-nos quando alguém tocou no ficheiro, não se o conteúdo ainda está correto). Frescura real: estado da revisão, saúde da ligação, alinhamento da tradução, sinais de leitura, deteção de desvios de conteúdo. Metadados que uma máquina pode ler e utilizar para decidir se um documento é seguro para citar.
Estou sempre a voltar a um enquadramento simples. A sua documentação precisa de uma pontuação de crédito. Não um registo de data e hora. Uma pontuação de crédito. (Temos estado a construir exatamente isto com o [sistema de pontuação de frescura] do Rasepi(/features/freshness) e, honestamente, ver os dados da indústria só me deixa mais convencido de que é a decisão certa).
3. A tradução está a passar de "projeto" para "pipeline"
DeepL publicou um artigo em fevereiro intitulado ["The 6 Translation Transformations Global Businesses Can't Afford to Miss"] (https://www.deepl.com/en/blog/six-translation-transformations). O seu argumento: a tradução está a tornar-se um desafio operacional contínuo e não um projeto de lote que se realiza trimestralmente.
Isto está de acordo com tudo o que vejo.
O modelo antigo era simples. Escrever em inglês. Quando se tem orçamento, contrata-se um tradutor ou recorre-se a um serviço. Receber as traduções. Carregue-as. Está feito até à próxima vez. O problema é que a "próxima vez" chega cada vez mais depressa quando o seu produto é enviado semanalmente e os seus documentos são actualizados constantemente. Na altura em que a versão alemã volta da revisão, a versão inglesa já foi alterada duas vezes.
O [Customization Hub] (https://www.deepl.com/customization-hub) do próprio DeepL agora oferece glossários, regras de estilo e configurações de formalidade, o que é ótimo. Mas se essas ferramentas estiverem fora da sua plataforma de documentação, está a gerir uma cadeia de ferramentas de tradução: editor, exportar, traduzir, rever, reimportar, repetir. Cada passo é uma oportunidade para se desviar.
O Notion não tem suporte multilingue nativo. O Confluence oferece-o através de plugins do mercado. O GitBook adicionou a tradução automática em agosto de 2025, que é um passo, mas funciona ao nível da página.
A verdadeira mudança é do nível da página para o nível do bloco. Quando se controlam as traduções ao nível do parágrafo, só se retraduz o que realmente mudou. Uma edição típica afecta talvez dois parágrafos em quarenta. Isso representa 94% menos trabalho de tradução. (Esta é a arquitetura de tradução principal do Rasepi e, honestamente, a coisa de que mais me orgulho no produto. Mas mesmo deixando-nos de lado, a direção da indústria é clara: tradução contínua, incremental e incorporada é para onde isto se dirige).
4. Os agentes de IA precisam de conteúdo estruturado, não de páginas wiki
Esta questão cristalizou-se para mim quando a Notion anunciou [Custom Agents] (https://www.notion.com/blog/introducing-custom-agents) em fevereiro. 21.000 agentes construídos durante o acesso antecipado. Agentes que respondem a perguntas de bases de conhecimento, encaminham tarefas, compilam relatórios de estado. Só o Ramp tem mais de 300 agentes.
A Atlassian seguiu uma direção semelhante. A Rovo AI in Confluence extrai contexto de toda a Atlassian e de aplicações de terceiros para gerar conteúdo. A sua proposta: "conteúdo rico em contexto e de alta qualidade baseado no trabalho existente da sua equipa".
E depois a Anthropic lançou equipas de agentes no Claude Code, onde vários agentes de IA se coordenam autonomamente em tarefas complexas. O Opus 4.6 tem uma pontuação de 76% no benchmark MRCR de 1M com 8 agulhas (acima dos 18,5% do modelo anterior), o que significa que pode realmente recuperar informações enterradas em grandes conjuntos de documentos sem perder o rasto.
As três empresas estão a criar agentes que consomem documentação. Nenhuma delas resolveu o problema da qualidade da fonte.
A documentação dos agentes personalizados da Notion reconhece explicitamente o [risco de injeção imediata] (https://www.notion.com/blog/introducing-custom-agents) quando os agentes lêem conteúdo não confiável. O Rovo da Atlassian pega tudo o que encontra no seu Confluence. Se esse conteúdo estiver três meses desatualizado, o Rovo não sabe. Ele se baseia nele de qualquer maneira.
Para que os agentes trabalhem de forma confiável, eles precisam de mais do que páginas de texto. Precisam de conteúdo estruturado com identificadores estáveis, sinais de atualização explícitos, metadados de classificação claros e a capacidade de distinguir "isto é atual e revisto" de "isto existe mas ninguém lhe toca há um ano". As páginas Wiki não oferecem isso. O conteúdo estruturado ao nível do bloco com metadados de confiança fornece-o.
5. O código aberto e a auto-hospedagem estão a regressar
Este último é mais um pressentimento apoiado por dados do que um anúncio único.
GitBook open-sourced sua documentação publicada no final de 2024 e lançou um fundo OSS. O seu raciocínio: os projectos de código aberto merecem ferramentas de documentação gratuitas e de alta qualidade. Mas o movimento também sinaliza algo mais amplo.
O Notion é apenas na nuvem. Não há opção de auto-hospedagem. O Confluence Data Center existe, mas requer uma licença. Quando a sua plataforma de documentação contém o seu conhecimento operacional mais sensível (manuais de incidentes, procedimentos de conformidade, decisões de arquitetura), a questão de "quem controla estes dados?" não é abstrata.
O post do Anthropic "Claude is a space to think" de fevereiro apresentou um argumento interessante sobre confiança e modelos de negócio. A sua alegação principal: os incentivos publicitários são incompatíveis com um assistente de IA genuinamente útil. Optaram por não ter publicidade para que os utilizadores possam confiar na ferramenta.
Penso que existe um paralelo para as plataformas de documentação. Se o seu sistema de documentação é de código fechado e apenas na nuvem, não pode verificar o que alimenta a IA. Não é possível auditar os cálculos de atualização. Não pode garantir que os seus dados permaneçam sob o seu controlo. Para as equipas que estão a implementar assistentes de IA sobre a sua base de conhecimentos (e cada vez mais, todos o fazem), a auditabilidade é importante.
Esta não é uma polémica sobre o código aberto ser moralmente superior. Os produtos de código fechado podem ser absolutamente fiáveis. Mas quando se está a construir fluxos de trabalho com IA em cima da documentação interna, a capacidade de inspecionar e verificar o sistema é uma vantagem prática. Para nós, o licenciamento do Rasepi pelo MIT não foi uma reflexão tardia. Foi uma decisão de design baseada na mesma lógica: a infraestrutura de documentação deve ser auditável.
O que estas cinco tendências significam em conjunto
Individualmente, cada uma dessas tendências é gerenciável. A IA lê os seus documentos? Muito bem, adicione alguns metadados legíveis por máquina. A atualidade é importante? Ótimo, adicione datas de revisão. A tradução precisa de ser contínua? Claro, integre DeepL. Os agentes precisam de estrutura? É justo, melhore o seu modelo de conteúdos. A soberania é importante? Ótimo, ofereça uma opção auto-hospedada.
Mas, em conjunto, descrevem uma plataforma que é fundamentalmente diferente da que a maioria das equipas utiliza atualmente.
A diferença é arquitetónica. Não se trata de cinco funcionalidades que se acrescentam. São cinco pressupostos que precisam de ser incorporados na base. Como o conteúdo é armazenado (a nível de bloco, não a nível de página). Como a confiança é modelada (pontuações de frescura, não carimbos de data/hora). Como funciona a tradução (incremental, incorporada, por parágrafo). Como é que os agentes de IA acedem ao conteúdo (APIs estruturadas com metadados, e não scrapes de páginas). Como é que os dados são controlados (abertos, auditáveis, auto-hospedados).
Nenhuma plataforma estabelecida foi concebida em torno de todos estes cinco aspectos em simultâneo. Algumas estão a adicioná-los peça a peça. O GitBook está a avançar mais rapidamente na frente da legibilidade da IA. A Notion está a construir uma infraestrutura de agentes. A Atlassian tem uma distribuição empresarial.
Mas projetar para todos os cinco desde o primeiro dia? Essa é a vantagem de começar do zero quando o terreno muda.
Sei que estou a ser parcial. Construímos o Rasepi especificamente porque vimos estas tendências a convergir e queríamos uma plataforma que assumisse todas elas desde o início. Tradução ao nível do bloco, expiração forçada, pontuação de frescura, conteúdo estruturado pronto para IA, código aberto. É a tese de todo o projeto.
Mas mesmo que não existíssemos, penso que qualquer leitura honesta do que aconteceu no primeiro trimestre de 2026 aponta na mesma direção. A documentação está a tornar-se infraestrutura. E as infra-estruturas têm requisitos diferentes das páginas wiki.
As equipas que descobrirem isto primeiro não terão apenas melhores documentos. Terão agentes de IA mais fiáveis, custos de tradução mais baixos, menos surpresas de conformidade e bases de conhecimento que se mantêm fiáveis ao longo do tempo.
Esse é o estado dos documentos em 2026. A questão não é se essas tendências são reais. É saber se a sua plataforma foi concebida para elas.
Cinco tendências. Uma questão de arquitetura: a sua plataforma de documentação foi concebida para 2026 ou continua a servir pressupostos de 2016?
Fontes: GitBook AI docs data report, GitBook State of Docs 2026, GitBook skill.md, Google Gemini API Docs MCP, Stack Overflow 2024 Developer Survey, GitHub 2024 developer survey, Index.dev developer productivity statistics, Anthropic "What 81,000 People Want from AI", Anthropic "Claude is a space to think", Claude Opus 4.6, Notion Custom Agents, Atlassian Rovo in Confluence, DeepL "6 Translation Transformations", DeepL Customization Hub, GitBook open source documentation, GitBook auto-translate.