Como usar o NotebookLM (agora Gemini Notebook) para estudar a documentação de uma biblioteca antes de programar com IA

Ilustração de um notebook digital com páginas de documentação de código ao lado de um ícone de inteligência artificial

Fala aí, beleza? Se o agente de código vive te devolvendo função que já foi removida da biblioteca, a saída é estudar a documentação ANTES de codar: cria um notebook no Gemini Notebook (o novo nome do NotebookLM), carrega a doc oficial, o changelog e o guia de migração, e usa prompts pra mapear a API, listar breaking changes e montar um resumo com citações

Esse resumo vira o contexto que tu entrega pro agente, e isso reduz o risco de ele escrever código com API desatualizada. Um aviso sem rodeio: não existe integração direta documentada entre o Gemini Notebook e agentes como Claude Code, Cursor ou Copilot, então o resumo vai na mão mesmo, copiando e colando 🙂

Sobre o nome: o Google anunciou o rebrand em 16/07/2026, com nome e logo novos liberados aos poucos ao longo de algumas semanas. O produto segue o mesmo e independente, e links antigos e notebooks compartilhados são redirecionados automaticamente

O que você precisa antes de começar

Tu precisa de uma conta com acesso ao Gemini Notebook na web e do material da biblioteca num formato que ele aceite

Se liga nos formatos que fazem sentido pra documentação técnica, segundo a Central de Ajuda oficial:

  • URL da web (a página da doc)
  • PDF
  • Markdown (.md) e texto (.txt)
  • Word (.docx) e Google Docs
  • Texto copiado e colado
  • Vídeo público do YouTube com legenda

Agora os limites, que mudam o jeito de montar o notebook:

  • Cada fonte pode ter até 500.000 palavras ou até 200 MB por arquivo, em qualquer plano. Fonte acima disso não é importada
  • O número de fontes por notebook depende do plano: 50 no Standard (grátis), 100 no Plus, 300 no Pro, 500 no Ultra de 20 TB e 600 no Ultra de 30 TB (fonte)
  • Compartilhar o notebook não muda o limite de fontes de ninguém

Tem também a cota de uso: desde 2 de setembro de 2026 ela é baseada em computação, ou seja, pesa a complexidade do prompt, os modelos e recursos usados e o tamanho do chat. A cota se renova a cada 5 horas até bater no teto semanal (fonte)

Pra acompanhar o consumo no computador: canto superior direito, Settings > Usage (fonte)

E o pré-requisito que não é técnico, mas é o mais importante: saber de qual versão da biblioteca tu parte e pra qual tu vai. Sem isso, nenhum prompt salva haha

Passo a passo: da documentação ao contexto do agente

Os prompts abaixo são exemplos didáticos pra tu adaptar, beleza? Troca o que está entre chaves pelos dados da tua biblioteca

1. Adicione as fontes certas

Cria um notebook só pra essa biblioteca e adiciona três tipos de material: a documentação da versão alvo, o changelog e o guia de migração

Por que esses três? A doc diz como a API é AGORA, o changelog diz o que mudou e o guia de migração diz como sair do jeito antigo pro novo. É exatamente a informação que o modelo do agente pode não ter

O erro comum deste passo: colar a URL da página índice da doc achando que o site inteiro vai junto

Não vai! Em fonte de URL, só o texto HTML daquela página é importado. Páginas aninhadas, imagens e vídeos incorporados ficam de fora, e página com paywall não é suportada

Solução: adiciona cada página relevante como uma fonte separada, ou exporta a doc pra PDF ou Markdown e sobe o arquivo

E se a biblioteca tiver um vídeo de lançamento no YouTube, saiba que só a transcrição em texto entra como fonte, e só de vídeo público com legenda (do autor ou automática)

2. Restrinja as fontes no painel Source

No painel Source, marca só as fontes que interessam pra pergunta da vez. Com várias marcadas, citar o nome da fonte no prompt ajuda a restringir a busca, segundo a Central de Ajuda

Usando apenas a fonte "{nome da fonte da doc nova}", responda:
como se inicializa o cliente de {biblioteca} na versão {versão nova}?
Traga citação para cada afirmação

O erro comum deste passo: deixar marcadas juntas a doc da versão antiga e a da nova. Aí a resposta pode misturar as duas e te entregar um híbrido que não existe em nenhuma versão 😛

Confere sempre quais caixinhas estão marcadas antes de perguntar

3. Mapeie a API com um prompt de inventário

Antes de pensar em código, tu quer um mapa: o que existe, como chama e que exemplo a própria doc dá

Com base apenas nas fontes da documentação da versão {versão nova} de {biblioteca},
monte um inventário da API pública:

- módulos ou pacotes principais
- funções e classes de cada um
- assinatura exatamente como aparece na documentação
- um exemplo de uso curto copiado da fonte

Coloque citação em cada item.
Se algo não estiver nas fontes, escreva "não encontrado nas fontes" em vez de completar

O que conferir: se cada item tem citação. Item sem citação é sinal pra desconfiar e ir checar na doc

4. Liste os breaking changes entre versões

Agora marca o changelog e o guia de migração e pede a lista do que quebra

Usando as fontes "{changelog}" e "{guia de migração}", liste todas as mudanças
que quebram compatibilidade entre a versão {versão antiga} e a {versão nova}
de {biblioteca}.

Responda em tabela com as colunas:
| Antes (versão antiga) | Depois (versão nova) | Tipo (removido, renomeado, mudou assinatura, mudou comportamento) | Fonte |

Traga citação em cada linha

O que conferir: se as versões citadas na tabela batem com o intervalo que tu pediu. Changelog costuma cobrir várias versões, e é fácil entrar mudança de fora do teu intervalo

5. Gere perguntas de verificação e confira cada citação

Esse é o passo que separa estudo de verdade de "a IA falou, tá falado"

Com base nas fontes marcadas, crie 10 perguntas de verificação sobre a migração
de {biblioteca} da versão {versão antiga} para a {versão nova}.
Foque em pontos onde é fácil errar (nomes renomeados, parâmetros que mudaram,
funções removidas). Responda cada pergunta com citação da fonte

As respostas do chat trazem citações inline com trechos diretos das fontes. Passa o mouse na citação pra ver o trecho completo, e clica nela pra ir até o trecho dentro da fonte, no contexto

O erro comum deste passo: confiar em citação de fonte curta demais

Quando a fonte é muito curta, o Gemini Notebook cita o documento inteiro, sem apontar um trecho específico. Parece checado, mas não é, porque tu não sabe qual frase sustenta a resposta. Nesse caso, lê a fonte na mão

6. Salve como nota e monte o resumo para o agente

Gostou da tabela de breaking changes? Clica em Save to note. A nota preserva o formato, incluindo tabelas e as citações inline clicáveis (fonte)

Detalhe útil: nota marcada no painel Sources entra no contexto do chat, e a desmarcada fica de fora das perguntas e da geração de artefatos (fonte). Então dá pra usar as notas dos passos anteriores como base do resumo final

Com base nas notas de inventário da API e de breaking changes, escreva um resumo
para ser usado como contexto por um agente de código. Estrutura:

1. Versão alvo: {biblioteca} {versão nova}
2. APIs válidas nesta versão (com assinatura)
3. APIs removidas ou renomeadas (antigo -> novo)
4. Padrões recomendados pela documentação
5. O que NÃO usar

Seja direto, em lista, sem texto de introdução

Agora a parte manual: copia o texto do resumo e leva pro agente. Pode colar direto no prompt ou num arquivo de instruções do projeto, do jeito que a tua ferramenta trabalha

Se a ideia de automatizar esse vai e vem por código te coçar, vale entender o que é o pacote Python notebooklm-py e quando ele faz sentido. Só não confunda com integração oficial com agentes, que não está documentada

Checagem final: pede pro agente um trecho de código usando a biblioteca e confere cada chamada contra a tua tabela de breaking changes. Apareceu função da coluna "Antes"? O contexto não pegou, e é hora de reforçar no prompt

Quando esse fluxo vale a pena (e quando não)

Esse é o uso de NotebookLM para programadores que mais compensa quando o risco de API velha é alto

Onde ele brilha:

  • Migração de major version: é onde o changelog e o guia de migração mais pesam, e onde o agente mais tende a escrever no jeito antigo
  • Biblioteca lançada ou alterada depois do treino do modelo: o modelo simplesmente não conhece a versão nova, então a doc carregada faz o papel de memória atualizada
  • Onboarding em SDK interno documentado no Google Docs: fontes do Drive sincronizam sozinhas a cada poucos minutos, e pra forçar é só abrir a fonte no notebook e clicar em Click to sync with Google Drive. Docs com várias abas entram como uma única fonte

Se o teu caso é aprender um framework do zero, e não migrar versão, tem um fluxo focado nisso em estudar a documentação de um framework 😀

Agora os limites, sem maquiagem:

  • A resposta só é tão atual quanto as fontes que tu carregou. Saiu versão nova? Troca as fontes
  • URL importa só aquela página, não o site
  • O fluxo não substitui ler o código da biblioteca nem rodar os testes do teu projeto. Ele prepara o terreno, não garante que o código funciona

E tem um recurso que pode confundir: cada notebook ganhou um computador seguro na nuvem que escreve e executa código, mas ele é voltado pra análise de dados baseada nas fontes. No anúncio de 16/07/2026, ficou disponível de imediato pra assinantes Google AI Ultra e clientes Workspace com AI Ultra Access e AI Expanded Access, com liberação na web pra todos os usuários Pro nas semanas seguintes. Não é um ambiente pra programar com a biblioteca, beleza?

Vídeo: 8 dicas pra usar o NotebookLM do jeito certo

Esse vídeo é de antes do rebrand, então ainda fala em NotebookLM, e cobre 8 recursos gerais da ferramenta, como criar notebooks e extrair conteúdo das fontes

Vídeo trata de 8 recursos gerais de uso do NotebookLM (criação de notebooks, extração de conteúdo das fontes): útil como contexto de funcionalidades da ferramenta, mas não aborda especificamente o fluxo de carregar documentação técnica de biblioteca, changelog e guia de migração para mapear API e detectar breaking changes antes de codar com IA, que é o foco exato da pauta.

Próximo passo

Escolhe a próxima biblioteca que tu vai atualizar no teu projeto

Monta o notebook com a doc da versão alvo, o changelog e o guia de migração, e gera a nota de breaking changes ANTES de abrir o agente. Depois pede um trecho de código e confere as chamadas contra a tabela

E guarda esse notebook: a cada versão nova, é só trocar as fontes e rodar os mesmos prompts de novo

Até o próximo post!

Perguntas frequentes

Dá pra montar esse fluxo de estudo de documentação no plano grátis do Gemini Notebook?

Dá sim. O plano Standard (grátis) permite até 50 fontes por notebook, e o fluxo de doc, changelog e guia de migração usa poucas fontes, então cabe tranquilo nesse limite.

Posso subir um arquivo de código fonte, tipo .py, como fonte do notebook?

Não tem .py na lista de formatos aceitos, mas texto copiado e colado é um formato aceito, então o jeito é colar o trecho de código direto como texto.


Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.

Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Formações

Formação Vibe Coding

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 30min

Blog | Mais populares