Опыт использования Gemini Flash: когда агент теряет цель

Мой опыт с ранними Gemini Flash в Google Antigravity оставил противоречивое впечатление. На короткой задаче агент мог быть очень быстрым и полезным. В длинной непрерывной сессии он иногда продолжал активно работать, но постепенно уходил от первоначальной цели. Команды выполнялись, файлы менялись, ошибки исправлялись — а нужный результат становился всё дальше.

В этой статье я разбираю собственное наблюдение, сопоставляю его с публичными сообщениями пользователей и объясняю, как после этого стал смотреть на архитектуру coding-агентов. Мой кейс относится к раннему поколению Gemini 3 Flash с незафиксированным минорным номером. Это не тест Gemini 3.8 и не доказательство одинакового поведения всей линейки.

Почему идея быстрого Flash-агента так привлекательна

Google последовательно продвигает Flash как рабочую модель для программирования, вызова инструментов и многошаговых задач. В анонсе от 2 сентября 2026 года компания прямо описывает Gemini 3.8 Flash как модель, улучшенную для длительной работы над кодом и автономных агентов.

Логика понятна. Агентная задача состоит не из одного ответа. Нужно прочитать проект, найти зависимости, изменить код, запустить тесты, разобрать ошибку, проверить интерфейс и вернуться к реализации. Если каждый проход дешевле и быстрее, это может заметно сократить время работы.

На Google I/O в мае 2026 года компания заявляла для Gemini 3.5 Flash скорость вывода токенов в четыре раза выше, чем у других моделей передового уровня, а для дополнительно оптимизированного варианта в Antigravity — ускорение до 12 раз. Это заявления Google в контексте анонса. Их нельзя переводить в обещание закончить любой проект в четыре или двенадцать раз быстрее.

Именно разница между скоростью операций и скоростью достижения результата стала для меня главным вопросом.

Мой кейс: примерно через час агент начинал терять направление

Я активно использовал одну из ранних Gemini Flash через Google Antigravity. Точный минорный номер не сохранил: речь о раннем поколении Gemini 3 Flash.

Первые впечатления могли быть отличными. Модель быстро читала файлы, искала нужные участки и вносила изменения. Там, где более тяжёлый агент ещё анализировал ситуацию, Flash уже успевал выполнить несколько операций. Для короткой задачи это ощущалось как преимущество.

Проблемы становились заметны в длинной непрерывной работе — условно через час активной сессии. Это приблизительная оценка моего опыта, а не измеренный порог, после которого модель обязательно начинает ошибаться.

Не происходило одного очевидного переключения. Каждый отдельный шаг по-прежнему мог выглядеть правдоподобно. Но последовательность шагов переставала вести к задаче, с которой мы начали:

Неверное предположение → изменение кода → новая ошибка → объяснение ошибки в рамках прежнего предположения → ещё одно изменение.

Через некоторое время агент работал уже над последствиями собственных решений. Вернуть его к исходной постановке было трудно. Я останавливал работу, объяснял ошибку, повторял ограничения. Модель соглашалась, некоторое время двигалась в правильную сторону, а затем могла вернуться к похожей траектории.

Я стал называть это превращением в «максимизатор скрепок». Здесь это метафора: агент сохраняет высокую производительность, но полезный результат подменяется потоком операций. Речь не о сознательных намерениях модели и не о буквальном воспроизведении известного мысленного эксперимента.

Агент читает файлы, запускает команды, создаёт новые файлы, удаляет старые и реагирует на собственные изменения. Активность огромная. Связь с исходной целью — всё слабее.

Качество отдельного шага и качество всей работы — разные вещи

После этого опыта я стал осторожнее переносить результаты coding-бенчмарков на собственные длинные сессии. Модель может хорошо понимать ошибку, писать функцию и корректно вызывать инструмент. Но этого недостаточно, чтобы оценить многочасовую работу в меняющемся репозитории.

Ошибки внутри такой работы связаны между собой. Представим условную последовательность: на сороковом шаге агент принимает неверное предположение; на следующем уже изучает код, изменённый под это предположение; ещё через несколько действий считает получившееся устройство проекта исходной нормой. Номера шагов здесь иллюстративные.

Это не означает, что все бенчмарки проверяют только один ответ. Среди них есть полноценные агентные испытания и задачи длительной разработки — например, DeepSWE. Но результат конкретного теста всё равно зависит от задач, среды, инструментов и условий оценки. Он не гарантирует такого же поведения в моём проекте.

Два агента с близкими результатами тестов могут ощущаться по-разному. Один замечает тупик и пересматривает гипотезу. Другой успевает построить вокруг неё ещё несколько изменений. Меня интересует не только правильность следующего действия, но и способность вовремя понять, что вся цепочка пошла не туда.

Скорость усиливает и полезную работу, и ошибочное направление

Представим, что агент выбрал неверный способ решения. Пока человек читает объяснение, система успевает изменить файл, запустить тест, получить ошибку и внести следующую правку. Если направление верное, такая скорость помогает. Если неверное — растёт объём работы, которую затем придётся разбирать и откатывать.

В моём случае преимущество Flash становилось усилителем проблемы. Агент быстро проходил цикл «поиск → чтение → правка → тест → новая правка», но сам по себе этот темп ничего не говорил о прогрессе.

При этом медленная модель не становится надёжной автоматически. Время на размышление и способность остановить неудачную стратегию — разные характеристики. Полезнее спрашивать: что изменилось после последнего действия, какую гипотезу оно проверило и приблизило ли нас к критериям готовности?

Compaction и «альтернативная история проекта»

Одна из возможных причин зацикливания — управление длинным контекстом. В рабочую историю входят не только сообщения пользователя, но и инструкции проекта, содержимое файлов, вывод терминала, изменения кода, результаты тестов и промежуточные планы.

Обвязка агента, или harness, управляет инструментами и этой историей. Один из приёмов — compaction: сжатие накопленного контекста в более короткое представление. Само по себе сжатие не является ошибкой. Риск возникает, если вместе с подробностями исчезают важные ограничения, основания решений или сведения об уже выполненной работе.

Возможный сценарий выглядит так. Пользователь просил не менять архитектуру X. После нескольких этапов это ограничение стало менее заметным в рабочей истории. Агент изменил X и построил следующие действия вокруг новой архитектуры. Теперь текущий код и недавние результаты инструментов поддерживают уже другое представление о проекте.

Собственная ошибка начинает выглядеть как данность. Пользователь снова объясняет исходную задачу, но значительная часть доступного агенту состояния описывает последствия предыдущего отклонения. Отсюда мой образ «альтернативной истории проекта».

По внешнему поведению нельзя доказать, что причиной конкретного сбоя был именно compaction. Для этого нужны события сжатия, входной контекст, действия инструментов и воспроизводимый эксперимент. Большое заявленное контекстное окно также не показывает само по себе, насколько хорошо система сохраняет важные детали.

Что описывали другие пользователи: 160 чтений и две записи

В разборе на Google AI Developers Forum от 19 мая 2026 года пользователь описал аудит собственной AI-архитектуры с Gemini 3.5 Flash. Агенту требовалось сопоставить сведения из трёх LaTeX-файлов: математические утверждения, устройство слоёв и ограничения системы. Ожидаемым результатом был письменный аудит, а не пересказ каждого файла по отдельности.

По описанию пользователя, агент начинал с чтения инструкций и исходников, создавал и запускал проверочный скрипт, но затем возвращался к уже просмотренным материалам. После очередного сжатия истории работа снова начиналась с восстановления контекста. В опубликованном разборе фигурировали 160 чтений, две записи и четыре перезапуска цикла; итоговый аудит при этом так и не был подготовлен.

Автор привёл анализ, полученный от Claude Opus, с гипотезой о потере деталей при compaction. Эти числа и объяснение принадлежат участнику обсуждения. Это не независимая проверка логов редакцией и не официальный диагноз Google; ответ другой модели сам по себе не устанавливает техническую причину.

Практический урок этого случая — оценивать переход от чтения к результату. Если агент многократно собирает одни и те же данные, но не приближается к обещанному артефакту, стоит остановить цикл и проверить, какие сведения он теряет. Один такой отчёт не показывает частоту проблемы среди всех пользователей и не заменяет контролируемое сравнение моделей.

Почему нельзя свести всё к одной LLM

Поведение coding-агента определяется целой системой: моделью, системными инструкциями, обвязкой, инструментами, повторными попытками, управлением контекстом и состоянием файлов. Похожий цикл может появиться по разным причинам. Внешне он выглядит как «модель деградировала», но это ещё не позволяет отделить ошибку модели от ошибки среды.

Например, повторное чтение бывает оправдано, если файл изменился. Повтор теста полезен, если исправлена проверяемая причина. Подозрительна другая ситуация: входные данные прежние, гипотеза не меняется, результат тот же, а агент продолжает повторять действие.

Поэтому я бы проверял весь цикл работы, а не только выбирал более крупную модель. Без такой проверки можно заменить LLM и оставить механизм, который снова приведёт к тому же тупику.

Что изменилось в новых поколениях Gemini Flash

Мой опыт с ранним Flash нельзя автоматически переносить на новые версии. В своих анонсах Google показывает прогресс именно в более длинных задачах разработки.

Модель	DeepSWE v1.1 по данным Google	Откуда взята цифра
Gemini 3.5 Flash	37%	Сравнение в анонсе Gemini 3.6
Gemini 3.6 Flash	49%	Анонс от 21 июля 2026 года
Gemini 3.7 Flash	65,3%	Анонс от 13 августа 2026 года

Источники: Gemini 3.6 Flash и Gemini 3.7 Flash. Это опубликованные производителем результаты бенчмарка, а не доля успешно завершённых задач на моих проектах.

Для Gemini 3.8 Flash Google отдельно подчёркивает длительную работу над кодом и более тщательное многошаговое выполнение. На сложных задачах модель может делать дополнительные шаги рассуждения и повторные вызовы инструментов, иногда расходуя больше токенов. Больше действий здесь — описанный подход к повышению качества, но не самостоятельное доказательство результата.

Такие показатели ближе к тому, что мне важно, чем одна лишь скорость генерации. Но они не доказывают, что описанные мной циклы устранены во всех сценариях. Новую версию стоит проверять отдельно в той среде и на тех задачах, где ей предстоит работать.

Как я бы организовал работу Flash-агента

После этого опыта я бы не отдавал раннему Flash репозиторий с установкой «решай большую задачу несколько часов». Мне ближе схема, где быстрый исполнитель получает ограниченные задания, а цель, контроль и приёмка результата организованы отдельно.

Это может быть сильная модель-планировщик, человек или их сочетание. Важно не название управляющей модели, а то, что система умеет проверить результат и остановить повторение, прежде чем оно изменит слишком много файлов.

Вместо «доработай проект» я бы давал такой контракт:

Найди участок формирования RSS. Измени только его. Схему данных и публичный API не трогай. Запусти перечисленные в задаче проверки. Верни diff, результаты и список того, что осталось непроверенным.

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

На практике я бы использовал следующие правила:

1. Делить длинную работу на этапы с проверяемым результатом. У каждого этапа должны быть границы изменений и условия завершения.
2. Создавать контрольные точки. Это может быть отдельный коммит, сохранённый diff или резервная копия — с учётом чужих и незавершённых изменений в проекте.
3. Ограничивать повторение. Например, третье чтение неизменившегося файла без новой гипотезы — повод остановиться и объяснить, зачем оно нужно. Число три здесь рабочий пример, а не универсальный порог.
4. Проверять результат инструментами. Проверка типов, тесты и валидация схем подтверждают конкретные свойства. Они не заменяют проверку того, что решена именно пользовательская задача.
5. После обнаружения ухода от цели пересматривать состояние целиком. Иногда полезнее начать новую сессию с кратким проверенным описанием, чем продолжать убеждать старую отказаться от неверной картины.
6. Считать принятую работу за единицу времени. В оценку должны входить время проверки, исправлений и откатов, а не только скорость ответа или число вызовов инструментов.

Что для меня означает хороший Flash-agent

Flash решает важную задачу: снижает задержку и стоимость операций, из которых складывается агентная работа. Использовать самую тяжёлую модель для каждого небольшого шага не всегда оправданно. Но экономия на одном вызове ничего не говорит о цене всей задачи, если не учитывать повторы и переделки.

Мой образ раннего Flash в длинной Antigravity-сессии — очень производительный работник, который мог потерять понимание того, что именно должен произвести. Это описание конкретного опыта, а не приговор классу моделей.

Хороший Flash-agent для меня — быстрый исполнитель внутри системы, которая сохраняет цель, проверяет движение к ней и умеет остановиться. Именно способность после множества действий всё ещё решать первоначальную задачу я считаю более важной характеристикой, чем просто высокую скорость этих действий.

Материал подготовлен по авторскому опыту Арсения Груздева. Публичные источники проверены 3 сентября 2026 года. Иллюстрации объясняют наблюдения и предлагаемый подход; они не являются результатами измерений Google или редакции.