Gemini Notebook: навигация в монолитах или иллюзия мгновенного погружения?
Разработчики часто сталкиваются с проблемой быстрой встраиваемости в новые крупные проекты, такие как Terraform-провайдеры. Вадим Гартман из Selectel решил протестировать инструмент Google Gemini Notebook, обещающий анализировать код в контексте до миллиона токенов. Результаты тестирования показывают, что ИИ-ассистент способен дать качественный обзор архитектуры и подсветить ключевые риски, однако требует критического подхода и не заменяет глубокого изучения кода.
# Как быстро влиться в чужой проект: тест Gemini Notebook на коде Terraform
В корпоративной разработке существует негласное правило: новый разработчик должен погружаться в код новой команды с максимальным вниманием, чтобы не «завалить» опытных коллег первичными вопросами. Но как ускорить этот процесс в эпоху мега-монолитов?
Бэкенд-разработчик из Selectel, Вадим Гартман, столкнулся с этой задачей лично. Ему предстояло поддержать terraform-provider для компании, ранее он работал в смежной, но другой области. Чтобы не тратить месяцы на изучение каждого файла вручную, он решил воспользоваться инструментом с громким названием — Gemini Notebook.
Обещания разработчика звучат многообещающе: инструмент способен обрабатывать огромный объем информации, включая структуры монолитов, и работать с контекстом до миллиона токенов. Однако практика, как известно, отличается от теории. Попробуем разобраться, насколько эффективно ИИ справляется с реальными задачами анализа кода.
Доступ и конфиденциальность: первые препятствия
Первый шаг к инструменту превратился в неожиданное испытание на терпение. Гартман столкнулся с тем, что прямой доступ к веб-интерфейсу Gemini Notebook с рабочего компьютера или через стандартное приложение браузера был невозможен. Система выдавала ошибку, указывая на поддержку только специфических платформ. Доступ удалось получить только через мобильное устройство.
Перед началом тестов было важно уточнить юридические моменты. Пользователь внимательно изучил оферту и условия использования. Выяснилось, что политика обработки данных зависит от типа аккаунта:
* Личные аккаунты (бесплатно): Загруженный код отправляется на анализ ассистентам Google. Данные *могут* использоваться для обучения моделей, если пользователь оставит фидбек (лайк/дизлайк). Для корпоративного кода это неприемлемо. * Google Workspace / Education: Google заявляет о полном отказе от использования данных пользователей для обучения. * Enterprise: Данные размещаются в изолированном облаке компании.
Вывод для разработчиков: Использование бесплатной версии для анализа собственного продакшн-кода с личного аккаунта создает реальные риски утечки интеллектуальной собственности. Инструмент подходит только для изучения открытых проектов или при использовании защищенных корпоративных тарифов.
От PDF к пониманию: анализ архитектуры
Для тестирования Гартман выбрал практический путь. Он собрал весь репозиторий terraform-provider в PDF-документ с использованием расширения для VSCode. Этот файл весил внушительно — 1472 страницы. Загрузка и индексиоавние заняли примерно минуту.
Первый запрос был составлен стратегически: попросить модель описать общую логику приложения, детализировать работу по каждому пакету и указать потенциальные проблемы.
Что модель поняла правильно
Gemini Notebook сразу определила ключевые характеристики проекта: язык (Go), назначение (провайдер для Selectel) и точку входа (main.go).
Важным достижением модели стал правильный анализ жизненного цикла ресурсов. Она верно отметила использование вейтеров (waiters) — функций, которые асинхронно опрашивают API до достижения желаемого состояния (например, ACTIVE). Это критически важно для облачных операций, где действия происходят не мгновенно.
Модель также корректно разделила анализ по модулям: 1. DBaaS: Управляет базами данных (PostgreSQL, MySQL и др.), включая сложную логику фаерволов и расширений. 2. MKS: Управление кластерами Kubernetes с нюансами подавления диффов для версий. 3. Dedicated Servers: Самый сложный модуль, ответственный за физическую инфраструктуру, установку ОС и работу с RAID. Здесь модель уже отметила риски.
Где модель ошиблась или была неточной
Несмотря на общую точность, ответ оказался слишком сжатым для запроса на «подробный разбор». Многие мелкие, но важные модули были пропущены. Кроме того, модель иногда находила «проблемы» там, где их не было, либо их важность переоценивалась. Например, некоторые замечания касались настроек CI/CD, которые, хотя и полезны, не являются критическими для понимания логики бизнес-процессов инфраструктуры.
Навигация и ревью кода: сильные и слабые стороны
Следующим этапом стало решение конкретных навигационных задач. Задача: найти все места в коде, где производится переустановка операционной системы.
Инструмент справился блестяще. Он не просто дал ссылку на файл (resource_selectel_dedicated_server_v1.go), но и предоставил детальный контекст: какие параметры инициируют переустановку (ос_id, ssh_key), как формируется загрузка и, что особенно ценно, как работает механизм ожидания (waiters).
Попытка же сделать автоматическое ревью кода после изменений показала обратную картину. Гартман попытался загрузить два PDF-файла (до и после изменений) и попросить сравнить их.
Результат был разочаровывающим. Модель проигнорировала запрос на точечное сравнение и провела полный анализ всего проекта повторно. В ответе было много дублирования предыдущих данных и общих фраз о линтерах. Глубокий анализ именно измененных фрагментов, где часто прячутся баги регрессии, отсутствовал. Такой метод автор рекомендует не использовать для тонкого ревью.
Тем не менее, при глубоком анализе измененного кода модель смогла выделить ряд архитектурных рисков, которые требуют внимания:
* Рассинхронизация времени (Time Drift): Использование time.Now() локально на раннере для проверки валидности токена может привести к тому, что валидный токен будет удален из стейта, если время серверов расхожиться. Это вызовет конфликт имен при попытке создания нового ресурса. * TOCTOU (Time-of-Check to Time-of-Use): Проверка состояния выключения сервера перед переустановкой ОС не гарантирует успех, так как сервер может быть выключен между моментом проверки и вызовом API. * Игнорирование ошибок записи в стейт: Разрешение линтера игнорировать返回值 функции d.Set может привести к рассинхронизации (drift), когда состояние на сервере не совпадает с тем, что записано в файле terraform.tfstate.
Итоги
Gemini Notebook демонстрирует потенциал как мощный ассистент для первичной навигации в сложных проектах. Скорость обработки огромных PDF-файлов и способность быстро сформулировать общую картину архитектуры — это реальные преимущества, которые могут сэкономить часы работы новичка.
Однако инструмент не является «магической кнопкой». Он не умеет проводить точечное сравнение версий файлов так же эффективно, как специализированные diff-инструменты, и его ответы требуют обязательной верификации экспертом. Более того, вопросы конфиденциальности при использовании бесплатных тарифов требуют тщательного изучения перед работой с корпоративным кодом.
ИИ в разработке — это не замена инженеру, а умный проводник, который помогает быстрее найти путь, но карты и компас должен предоставить сам разработчик.