# Будущее разработки: от написания кода к управлению ИИ-агентами Источник: https://www.youtube.com/watch?v=v0RQiNJ9nhw Канал: Google for Developers Опубликовано: 22.05.2026 --- Будущее разработки программного обеспечения перестает быть вопросом написания строк кода и превращается в управление интеллектуальными агентами. В рамках дискуссии, организованной Google, ведущие эксперты компании обсудили выход новой модели Gemini 1.5 Flash, переход от «vibe coding» к серьезному агентному инжинирингу и новые узкие места, которые возникают, когда скорость написания кода перестает быть ограничением. ## ⚡️ Эволюция моделей: Gemini 1.5 Flash и новые стандарты скорости [[JUMP:00:57]] Центральной темой обсуждения стал запуск Gemini 1.5 Flash — модели, которую Тульси Доши (Tulsi Doshi) назвала «самой способной из когда-либо выпущенных» компанией [00:57]. По её мнению, эта модель демонстрирует качественный скачок в использовании инструментов (tool use), выполнении длительных задач по программированию и решении повседневных задач продуктивности, таких как создание презентаций или финансовый анализ [01:38]. Основные технологические акценты Gemini 1.5 Flash: * **Производительность и скорость:** Модель выдает более 200 токенов в секунду, что значительно быстрее других фронтирных моделей [04:39]. * **Длинный контекст:** Способность обрабатывать огромные объемы данных позволяет использовать её в сложных сценариях, где раньше требовались только Pro-версии [01:24]. * **Агентный потенциал:** Варун (Varun) отметил, что в ходе внутреннего тестирования модель успешно справлялась с задачами, требующими до 15 000 последовательных вызовов (invocations), например, при проектировании операционной системы [03:46]. ## 🛠 От «Vibe Coding» к агентному инжинирингу [[JUMP:08:25]] Логан (Logan) ввел в дискуссию термин «vibe coding» (программирование по наитию), заимствованный у Андрея Карпатого (Andrej Karpathy). Этот подход характеризует новичков, которые создают софт, просто описывая свои желания, в то время как профессионалы переходят к «агентному инжинирингу» [08:37]. Различия этих подходов, по мнению участников: 1. **Сложность систем:** Тульси Доши подчеркнула, что модель может отлично справляться с созданием веб-приложения по одному промпту, но «сломаться» на поддержке легаси-систем с тысячами строк кода [10:11]. 2. **Способность к рассуждению:** Для промышленной разработки недостаточно просто генерировать код; модель должна понимать контекст всей системы и уметь эффективно вызывать внешние инструменты [09:16]. 3. **Автономия:** Майкл (Michael) отметил, что современные инженеры все чаще не пишут код в IDE напрямую, а назначают тикет в Jira ИИ-агенту, который возвращает готовое решение [06:00]. ## 🔄 Маховик «модель — продукт»: роль Anti-gravity [[JUMP:11:02]] Варун рассказал о проекте Anti-gravity — внутреннем инструменте Google, который служит связующим звеном между экосистемой компании и моделями Gemini [00:44]. Это не просто интерфейс, а полноценный полигон для обучения моделей поведению в реальной среде. Ключевые особенности этой симбиотической связи: * **Обучение на сценариях (Harness):** Исследователи обучают модели не просто на текстах, а на успехе или провале выполнения задач в «сбруе» (harness) — среде с доступом к файловой системе и терминалу [12:32]. * **Асинхронность:** Модели Anti-gravity умеют создавать субагентов для выполнения фоновых задач, например, запуска процесса обучения нейросети, не блокируя основной поток общения с пользователем [11:54]. * **Эмпатия исследователей:** Благодаря тому, что сотрудники Google сами используют эти инструменты ежедневно, возникает петля обратной связи: если модель ведет себя «лениво» или странно в продукте, это немедленно исправляется в обучении [13:22]. ## 🚧 Новые узкие места: информация вместо интеллекта [[JUMP:25:03]] Майкл утверждает, что интеллект моделей перестал быть главным ограничением. Основным барьером теперь является проблема извлечения информации (Information Retrieval, IR) и полномочий (authority) [25:03]. По словам Майкла, агент часто сталкивается с ситуациями, когда: * Данные не задокументированы и находятся «в головах» сотрудников или в защищенных базах [06:27]. * Требуется доступ к конфиденциальной информации (например, в банках для KYC-процедур), который сложно предоставить ИИ из соображений безопасности [26:48]. * Агенту нужно авторизовать действие (например, транзакцию), на что у него нет юридического права [25:16]. Тульси Доши добавила, что вторым «узким местом» становится вкус (taste) и выбор того, что именно стоит строить. Когда стоимость создания софта стремится к нулю, критически важным становится умение находить реальные болевые точки пользователей, а не плодить ненужные функции [24:11]. ## 🎙 Будущее интерфейсов: голос, видео и жесты [[JUMP:29:48]] Участники сошлись во мнении, что текстовое поле — это лишь временный интерфейс. Варун выразил уверенность в большом будущем аудио-взаимодействия, хотя признал, что чтение текста все еще остается более быстрым способом потребления информации [39:05]. Прогнозы по интерфейсам: * **Мультимодальность:** Тульси мечтает о модели, помогающей в хореографии, что требует сверхвысокой частоты кадров (FPS) при обработке видео для анализа быстрых движений [34:36]. * **Проактивность:** Майкл считает, что агенты будущего должны сами выбирать способ связи — написать письмо, прийти в Slack или позвонить, в зависимости от срочности задачи [33:15]. * **Жесты:** В ответ на вопрос из зала Варун допустил, что управление агентами с помощью жестов (например, через Pixel Watch) станет реальностью [40:21]. ## 🛡 Борьба с «ИИ-шлаком» (AI Slop) и качеством кода [[JUMP:44:50]] В финальной части дискуссии обсуждался вопрос надежности. Чтобы избежать ситуации, когда ИИ ломает существующий продукт при добавлении новой фичи, Варун предлагает парадигму «агенты тестируют агентов» [46:19]. Его рекомендации по обеспечению качества: * Создавать интеграционные тесты с самого начала проекта (0-to-1) [46:33]. * Использовать агентов для генерации сценариев тестирования (например, Playwright), которые имитируют действия пользователя [46:07]. * Принимать решение о выборе модели (большая или маленькая) в зависимости от критичности участка кода, делегируя рутину более быстрым и дешевым моделям [44:38].