Gemini 2.5 Pro Experimental (2/2), личные впечатления
Что тут сказать - Google наконец-то смог, эта модель вполне на уровне текущих флагманов для разработки.
Что меняет появление этой модели?
● Открывается возможность работы с намного большими по объему проектами.
● Стало можно делать cross-cutting изменения во многих местах проекта, глобальные рефакторинги.
● Не так важно становится держать документацию для проектов, которые целиком лезут в контекст (собственно, практика хранения документации рядом с кодом для нейронок - это, по сути, сжатие контекста).
● Качественный ризонинг по такому длинному контексту - вообще уникальное явление.
Для чего я сам успел её попробовать
Я задался целью проверить длинный контекст и ризонинг - главные преимущества модели, исходя из этого и выбрал задачи.
В одном из проектов недавно прошли архитектурные изменения и сопутствующий рефакторинг: нужно было распилить Next.js приложение на Next.js + NestJS + background workers и сделать монорепу.
Эти изменения в основном делались руками, т.к. нейронки с таким не очень справляются.
Но из-за этого документация отстала от актуального состояния проекта и нужно было ее обновить - не самое интересное занятие, в отличие от того же рефакторинга, где бывают креативные моменты.
Проект небольшой, примерно на 350к токенов, но это уже за пределами возможностей Sonnet 3.7.
Так как единственным местом, где модель нормально работала, была AI Studio, решил тряхнуть стариной и взял для этого Repomix - эта штука собирает указанные файлы в проекте в один мега-файл, который можно скинуть в чат модели (спустился до 2-го уровня согласно этой классификации :)).
1. Документация
В рамках чата в AI Studio попросил сделать markdown для обновления файлов документации (порядка 10 штук по разным частям и слоям системы), и потом руками их перенес в проект.
А так как у модели лимит на output 65k токенов, то генерил по нескольку документов за раз.
Результат на 4.5 - актуальное состояние проекта передано очень точно, но были некоторые стилистические правки.
2. Рефакторинг
Ещё одна задача, хорошо подходящая для такой модели - планирование "широких" рефакторингов.
Тут я решил выделить React-компоненты, инкапсулирующие в себе повторяющиеся элементы, которые встречались много где в коде фронтенда и при этом таскали за собой портянку tailwind-классов (нагенерились в процессе вайб-кодинга ;))
● задача была поставлена в виде "проанализируй весь код фронтенда и предложи, какие элементы можно выделить в компоненты";
● получил список компонентов, штук 10, которые можно выделить, с обоснованием того, почему их стоит выделять и примеры, откуда;
● попросил сгенерить код для каждого из них, перенес в проект;
● по каждому из компонентов попросил предоставить список мест в проекте, где его можно использовать - скажем, для Button вышел список из примерно 30 файлов и 50 кнопок, которые можно заменить базовым компонентом;
● ну а с готовым списком уже пошел в Cursor Agent + Sonnet 3.7 для изменения существующего кода на использование компонентов (показательно, что у него иногда контекст кончался в процессе работы и приходилось переключаться на MAX).
Общий результат тоже на 4.5 - были вопросы к списку выделенных компонентов в плане уровня генерализации, их размеров и количества, но это вкусовщина и мы быстро "договорились".
Ни одной ошибки в сгенерённом коде модель не сделала.
Как видите, обе задачи довольно широкие и заставляют модель смотреть в много разных мест проекта и уметь их между собой связывать.
Всё это было в рамках одного чата, контекст в котором в процессе общения распух до 400к, и модель всё ещё хорошо с ним справлялась.
И, кстати, при этом довольно шустро как думала, так и генерила ответы.
Если оно до 1м и потом до 2м токенов так же будет работать - для многих проектов я бы предпочел Gemini 2.5 всем остальным существующим моделям.
Остаются лишь вопросы тулинга и цены :)
—
Прошлые посты по связанным темам:
● Уровни внедрения ИИ в разработку
● Инициативность Sonnet 3.7
● Инициативность Sonnet 3.7 и MCP
● Claude 3.7 Sonnet MAX
● OpenAI o3-mini
#ai #development #model
Что тут сказать - Google наконец-то смог, эта модель вполне на уровне текущих флагманов для разработки.
Что меняет появление этой модели?
● Открывается возможность работы с намного большими по объему проектами.
● Стало можно делать cross-cutting изменения во многих местах проекта, глобальные рефакторинги.
● Не так важно становится держать документацию для проектов, которые целиком лезут в контекст (собственно, практика хранения документации рядом с кодом для нейронок - это, по сути, сжатие контекста).
● Качественный ризонинг по такому длинному контексту - вообще уникальное явление.
Для чего я сам успел её попробовать
Я задался целью проверить длинный контекст и ризонинг - главные преимущества модели, исходя из этого и выбрал задачи.
В одном из проектов недавно прошли архитектурные изменения и сопутствующий рефакторинг: нужно было распилить Next.js приложение на Next.js + NestJS + background workers и сделать монорепу.
Эти изменения в основном делались руками, т.к. нейронки с таким не очень справляются.
Но из-за этого документация отстала от актуального состояния проекта и нужно было ее обновить - не самое интересное занятие, в отличие от того же рефакторинга, где бывают креативные моменты.
Проект небольшой, примерно на 350к токенов, но это уже за пределами возможностей Sonnet 3.7.
Так как единственным местом, где модель нормально работала, была AI Studio, решил тряхнуть стариной и взял для этого Repomix - эта штука собирает указанные файлы в проекте в один мега-файл, который можно скинуть в чат модели (спустился до 2-го уровня согласно этой классификации :)).
1. Документация
В рамках чата в AI Studio попросил сделать markdown для обновления файлов документации (порядка 10 штук по разным частям и слоям системы), и потом руками их перенес в проект.
А так как у модели лимит на output 65k токенов, то генерил по нескольку документов за раз.
Результат на 4.5 - актуальное состояние проекта передано очень точно, но были некоторые стилистические правки.
2. Рефакторинг
Ещё одна задача, хорошо подходящая для такой модели - планирование "широких" рефакторингов.
Тут я решил выделить React-компоненты, инкапсулирующие в себе повторяющиеся элементы, которые встречались много где в коде фронтенда и при этом таскали за собой портянку tailwind-классов (нагенерились в процессе вайб-кодинга ;))
● задача была поставлена в виде "проанализируй весь код фронтенда и предложи, какие элементы можно выделить в компоненты";
● получил список компонентов, штук 10, которые можно выделить, с обоснованием того, почему их стоит выделять и примеры, откуда;
● попросил сгенерить код для каждого из них, перенес в проект;
● по каждому из компонентов попросил предоставить список мест в проекте, где его можно использовать - скажем, для Button вышел список из примерно 30 файлов и 50 кнопок, которые можно заменить базовым компонентом;
● ну а с готовым списком уже пошел в Cursor Agent + Sonnet 3.7 для изменения существующего кода на использование компонентов (показательно, что у него иногда контекст кончался в процессе работы и приходилось переключаться на MAX).
Общий результат тоже на 4.5 - были вопросы к списку выделенных компонентов в плане уровня генерализации, их размеров и количества, но это вкусовщина и мы быстро "договорились".
Ни одной ошибки в сгенерённом коде модель не сделала.
Как видите, обе задачи довольно широкие и заставляют модель смотреть в много разных мест проекта и уметь их между собой связывать.
Всё это было в рамках одного чата, контекст в котором в процессе общения распух до 400к, и модель всё ещё хорошо с ним справлялась.
И, кстати, при этом довольно шустро как думала, так и генерила ответы.
Если оно до 1м и потом до 2м токенов так же будет работать - для многих проектов я бы предпочел Gemini 2.5 всем остальным существующим моделям.
Остаются лишь вопросы тулинга и цены :)
—
Прошлые посты по связанным темам:
● Уровни внедрения ИИ в разработку
● Инициативность Sonnet 3.7
● Инициативность Sonnet 3.7 и MCP
● Claude 3.7 Sonnet MAX
● OpenAI o3-mini
#ai #development #model