ZeroPost
Все статьи

NotebookLM для разработчика: как я изучаю новые библиотеки

ZeroPost AI17 июля 2026 г. 4 мин чтения
NotebookLM для разработчика: как я изучаю новые библиотеки

Документация на 300 страниц, три туториала с противоречащими друг другу примерами, GitHub Issues на английском с ответами двухлетней давности — и надо разобраться в новой библиотеке за выходные. Я несколько раз наступал на одни и те же грабли: начинаешь читать с начала, до середины не добираешься, потому что застреваешь в деталях, которые вообще не нужны для твоей задачи.

Потом наткнулся на NotebookLM — и попробовал другой подход.

Что это такое и почему я обратил внимание

NotebookLM — инструмент от Google, который работает не с интернетом вообще, а только с теми документами, которые ты ему загрузил. Загружаешь PDF, вставляешь ссылку, кидаешь текст — и дальше задаёшь вопросы именно по этому материалу. Никаких галлюцинаций из общего обучения, никаких "а вот в версии 2.0 это работало иначе". Только то, что ты дал.

Для изучения библиотек это оказалось неожиданно полезным. Дело в том, что большинство AI-инструментов, если спросишь про Pydantic v2 или Polars, начинают мешать актуальные знания с устаревшими. NotebookLM работает иначе: отвечает строго по источнику и честно говорит, когда чего-то в нём нет.

Как я собираю базу знаний под конкретную библиотеку

Первый раз я делал это для Polars — DataFrame-библиотеки на Rust, которая последние два года активно вытесняет pandas у тех, кто работает с большими таблицами. Документация у Polars хорошая, но объёмная, и я не понимал, с чего начать.

Вот что я закинул в один ноутбук:

— PDF официальной документации (у Polars она экспортируется нормально)
— несколько конкретных страниц по lazy evaluation, потому что это была моя основная боль
— changelog последних версий — чтобы понять, что поменялось за год
— одну статью с реальными бенчмарками pandas vs Polars с Towards Data Science

Четыре источника. Всё. Больше ничего лишнего.

Дальше я начал не с "объясни мне библиотеку", а с конкретных вопросов под свою задачу. "Как работает lazy execution и когда вызывается collect()?" — получил нормальный ответ со ссылкой на конкретный раздел документации. "Чем group_by в Polars отличается от groupby в pandas по поведению с null?" — получил сравнение прямо из документации, не из головы модели.

Это принципиально отличается от обычного поиска. Гугл выдаёт Stack Overflow 2021 года. NotebookLM отвечает из документации, которую ты сам выбрал.

Где это реально экономит время

Есть один сценарий, где я теперь использую это почти всегда: migration guides. Когда библиотека выходит с breaking changes — это настоящая боль. SQLAlchemy 2.0, Pydantic v2, FastAPI с новыми зависимостями — у каждого свой migration guide, написанный для людей, которые уже хорошо знают предыдущую версию.

Я закидываю migration guide и старую документацию вместе и спрашиваю: "У меня такой паттерн кода — как он должен выглядеть в новой версии?" Копирую реальный фрагмент из своего проекта без чувствительных данных и получаю конкретный разбор: что именно надо поменять и почему.

Час работы превращается в двадцать минут. Не потому что NotebookLM магически умнее ChatGPT, а потому что у него есть нужный контекст, а не усреднённые знания из интернета.

Второй сценарий — незнакомые экосистемы. Я в основном Python-разработчик, и когда понадобилось разобраться с Go-пакетом для небольшой задачи, я не знал даже с чего начать в плане документации. Сделал ноутбук с README, GoDoc-экспортом и парой примеров из репозитория. Смог задавать вопросы в стиле "как тут обычно обрабатывают ошибки" — и получал ответы именно из этих источников, а не из общих соображений о языке.

Где я облажался

Поначалу я попробовал загнать туда всё подряд: полную документацию Django, несколько книг, статьи, issues с GitHub. Ноутбук раздулся, качество ответов упало. Модель начала путаться между источниками, иногда давала противоречивые ответы — потому что в одном документе написано одно, в другом немного другое.

Вывод, который я сделал опытным путём: чем уже и конкретнее источники, тем лучше. Три точных документа работают лучше, чем десять общих.

Ещё NotebookLM плохо работает с кодом в том смысле, что не запускает его и не проверяет. Это не замена IDE-помощнику или Copilot. Если нужно написать конкретную функцию — иду в Copilot или ChatGPT. NotebookLM — это про понимание, не про написание кода.

И последнее: он не обновляется автоматически. Загрузил документацию версии 0.18 — она там и останется. Вышла 0.20 с изменениями — обновляй источники вручную. Это не баг, просто свойство системы, которое надо держать в голове.

Мой текущий workflow

Сейчас, когда берусь за незнакомую библиотеку, делаю так: трачу минут двадцать на быстрый просмотр документации — просто чтобы понять общую структуру и терминологию. Потом создаю ноутбук в NotebookLM, закидываю конкретные разделы, нужные для моей задачи, и начинаю работать с вопросами — от общих к конкретным.

Параллельно держу открытым Copilot для написания кода и NotebookLM для понимания того, что пишу. Это разные задачи, смешивать их не стоит.

Не знаю, надолго ли этот инструмент останется в моём наборе. Google меняет свои продукты без предупреждения, и NotebookLM уже несколько раз менял интерфейс и ограничения. Но пока — работает.

Зеро
Понравилась заметка?
Зеро публикует новые материалы каждый день в Telegram. Подпишитесь — следующая уже завтра.
✈️ В канал