Я — Евгений Сатуров, CTO Mobile в Surf. Год назад я купил команде подписку на Copilot Business, и будущее наступило. Но совсем не то, что ожидали: ручные промты продолжали съедать время разработчиков, а прорыва в продуктивности не произошло.
Показываю, почему так случилось и как Surf и другие компании решают проблему. Больше про воспитание ИИ и применение его в проектах читайте в ТГ-канале нашего CEO Владимира Макеева.
Проклятие идеального промта
Чтобы сгенерировать один production-ready метод, в промт нужно вместить всё, что у опытного разработчика находится в голове:
Логику: что должен делать этот код в контексте конкретной фичи.
Код-стайл, названия классов, принятые в команде паттерны.
Архитектурные ограничения.
Технологический стек.
По-хорошему, нужна полноценная документация. Чтобы сгенерировать нужную фичу, всё это нужно собрать воедино — сделать мастер-промт, описать правила построения архитектуры, добавить implementation plan и чётко обозначить ограничения. И если мы это не делаем, потому что лень не успеваем, то результат работы ИИ нас не устроит.
Мы в Surf выступаем за one-shot подход — идеальный результат с первой попытки. Чтобы добиться этого, недостаточно написать промт наугад: плохо сформулированный запрос почти никогда не дает нужного результата. Поэтому сначала мы разрабатываем подробное техническое задание для агента, и тогда ИИ понимает все с первого раза.
Здесь действует простое правило: чем меньше свободы у модели и богаче контекст, тем лучше результат. На первых порах отладка все равно будет нужна. Приведу пример, как обычно выглядит промт без нормального контекста.
Промт 1: Напиши метод на TypeScript для получения пользователя по ID.
codeTypeScript async function getUser(id: number) { const response = await fetch(`/api/users/${id}`); return await response.json(); }
Промт 2: Это не наш стиль. У нас свой API-клиент. Перепиши, используя наш внутренний apiClient. У него есть метод .request().
import { apiClient } from ‘./api’; import { User } from ‘./types’; /** * Получает данные пользователя по ID через внутренний API-клиент. */ export async function getUser(id: number): Promise<User> { return apiClient.request<User>({ url: `/users/${id}`, method: ‘GET’, }); }
Промт 3: Метод apiClient.request должен принимать тип ответа, например. Также добавь обработку ошибок. В случае ошибки нужно логировать ее через Logger.error и возвращать null.
import { apiClient, ApiError } from ‘./api’; import { Logger } from ‘./logger’; import { User } from ‘./types’; export async function getUser(id: number): Promise<User | null> { try { return await apiClient.request<User>({ url: `/users/${id}`, method: ‘GET’, }); } catch (error) { if (error instanceof ApiError) { Logger.error(‘Failed to fetch user’, { userId: id, error }); } else { Logger.error(‘Unexpected error while fetching user’, { userId: id, error }); } return null; } }
На диалог ушло 5–10 минут. Разработчик написал бы финальный вариант за две. Мы не сэкономили время, а потратили его на промт-дебагинг. Иногда агент перестаёт подчиняться и выдаёт необъяснимый результат, что мы никак не можем исправить.
Выходит, что LLM — почти stateless-функция. На каждый новый вызов ей нужно с нуля передавать полное «состояние мира». Она не помнит, что было 30 секунд назад. Хотя делает вид, что помнит. Такой подход в разработке не масштабируется. И что делать?
Промты не работают без автоматизации: 3 уровня для обучения ИИ
Превращать разработчика в оператора чата, который постоянно переписывает промты — бессмысленно. Нужно дать инструмент, который делает это под капотом, понимает контекст и сам формирует корректный запрос к модели. За время работы мы прошли через три уровня зрелости этого подхода.
Уровень зрелости 1: Золотая библиотека промтов
Самый простой шаг — создать внутренний репозиторий с коллекцией проверенных промтов для Claude 4 / Google Gemini. Этакий Awesome List внутри компании — с готовыми шаблонами, примерами master rules, инструкциями и юзкейсами.
У этого подхода есть предел. Awesome list ускоряет старт и наводит порядок, но не меняет сам процесс. Он снижает когнитивную нагрузку, вводит стандарты, но разработчик все равно вручную ищет, адаптирует и тестирует промты.
Как это решают в Stripe
Инженеры Stripe пошли дальше и встроили ИИ прямо в свой рабочий процесс. Они создали собственный внутренний инструмент AI Assistant и добавили его в Visual Studio Code.
Теперь ассистент становится полноценной частью среды разработки. Он умеет генерировать код, смотреть журналы API-запросов, перенаправлять события, конфигурировать отладку и даже расширять палитру команд редактора. На панели активности появились новые виджеты, где можно быстро вставить сниппеты кода на нужном языке или получить актуальные SDK-конфигурации.
Вместо того чтобы дать разработчикам доступ к LLM, Stripe встроили его глубоко в процессы. Code Assistant знает все о внутренних библиотеках и API компании. Разработчик может задать вопрос вроде: «Как мне создать подписку для клиента с пробным периодом?», и ассистент выдаст конкретный сниппет, использующий актуальные версии сервисов и SDK Stripe.
Уровень зрелости 2: Внутренние CLI-инструменты и IDE-плагины
Второй шаг — автоматизировать использование промтов. Они помогают стандартизировать подход, но пока разработчик вручную копирует их из Confluence, адаптирует и отлаживает, никакой настоящей автоматизации нет. Мы создали свою CLI-утилиту ai-tools. Теперь разработчик пишет в терминале:
$ ai-tools generate-test —file=src/components/UserProfile.tsx
И вот что происходит под капотом:
Парсинг кода через AST. Наша идея — инверсия контроля. Не разработчик готовит данные для ИИ, это делает инструмент. Утилита не читает файл как текст. Она строит из него абстрактное синтаксическое дерево (AST) с помощью парсеров типа esprima (для JS/TS).
Извлечение контекста. Из AST мы вытаскиваем всё: имя компонента (UserProfile), список его props с типами, все импорты (./api, ./hooks), которые нужно будет мокать, названия внутренних функций, которые тестируют отдельно. Инструмент сам понимает структуру кода, зависимости и контекст — без участия разработчика.
Генерация промта на стероидах. Это небольшой RAG. Скрипт извлекает контекст (Retrieve), дополняет им шаблон промта из каталога (Augment) и формирует итоговый запрос (Generate). Получается промт длиной в два-три экрана — настолько подробный, что человек просто не стал бы писать его вручную.
После этого разработчик получает рядом с исходным файлом (UserProfile.test.tsx) готовый на 80–90% тест, который остается лишь слегка подправить. Вместо 10 минут общения с чатом — 10 секунд работы утилиты. Промты больше не нужно придумывать, о них вообще можно не думать. Всё, что делает разработчик — запускает инструмент и получает результат.
Как это делают в Retool
Компания Retool, создатель low-code платформы, использует ИИ для ускорения разработки внутренних инструментов. В 2025 году они встроили ИИ прямо в свой визуальный конструктор, чтобы пользователи могли генерировать формы и компоненты автоматически. Retool Workflows 2.0 добавили больше автоматизации (условную логику, повторные попытки и многоступенчатые потоки). Уровень 1 они тоже прошли — здесь их шаблоны.
Их разработчики используют собственную платформу для создания внутренних утилит. Retool AI встроен прямо в эти процессы. Он помогает писать и править SQL-запросы на естественном языке, подсказывает, как оптимизировать их, а при необходимости — сам создает UI-компоненты и обрабатывает данные.
И это ключевой итог второго уровня зрелости: инструмент берет на себя всю работу с промтами, превращая взаимодействие с LLM в фоновую операцию.
Уровень зрелости 3: Внутренняя платформа разработки с ИИ
На этом уровне ИИ перестает быть вспомогательным инструментом и становится частью внутренней платформы разработки (IDP). Мы сейчас именно на этом этапе — постепенно прикручиваем ИИ к разным фазам SDLC и создаем AI-boosted Delivery Platform: экосистему, которая берет на себя рутину и помогает командам выпускать продукт быстрее и стабильнее. Показываю примеры того, что мы пилотируем, а подробнее пишем в канале нашего CEO.
От тикета в Jira до черновика Merge Request (MR)
Как только задача попадает в работу, ИИ запускает цепочку действий:
Берет описание из Jira.
Создает для него векторное представление (эмбеддинг).
Ищет в нашей векторной базе кода (которую мы обновляем) файлы с наиболее близкими эмбеддингами (косинусное сходство).
Автоматически создает новую ветку, предлагает черновик MR и добавляет в него найденные файлы в качестве наиболее вероятных кандидатов на изменение.
В результате инженер получает черновик MR буквально за минуты — с уже подобранным контекстом и релевантными файлами.
AI Code Reviewer в CI/CD
Разработали бота, который делает ревью каждого MR. Он ищет ошибки линтера и сложные паттерны:
Потенциальные N+1 запросы в коде, работающем с ORM.
Использование useEffect в React без корректного массива зависимостей.
Признаки проблемных циклических зависимостей.
Он не блокирует MR, а оставляет вежливые комментарии с предложениями по улучшению. Это экономит нам до 20% времени на ревью.
Умный деплой
Мы хотим, чтобы ИИ-агент анализировал аномалии в логах и метриках (APM, Prometheus) после выкатки. Он не будет откатывать релиз сам, но мгновенно создает алерт для дежурного инженера, прикладывая к нему саммари проблемы и список коммитов, которые с наибольшей вероятностью её вызвали. Это сократит время реакции с 15 минут до одной.
Результат: сложно и дорого сейчас, дешевле — потом
Почему сложно. Векторная база кода требует постоянной индексации, иначе она быстро устаревает. Сценарий с авто-ревью постоянно рождает ложноположительные срабатывания, и его нужно долго калибровать, чтобы он не превратился в спам-бота, которого все ненавидят. А умный деплой — вообще высший пилотаж, который не реализовать без зрелой культуры observability.
Почему это не бесплатно. Создание инструментов — внутренний проект. Он требует времени и ресурсов. Для этого нужна отдельная platform team, которая занимается разработкой. Их стек: Claude 4, Python, FastAPI, интеграция с GitLab CI и API моделей от OpenAI и Anthropic.
Почему это стоит делать уже сейчас. ROI уже ощущается. 100 разработчиков × 15 мин/день × 240 дней = 360 000 минут (≈ 6 000 часов), то есть около 3 человеко-лет экономии в год. Внутренние инструменты окупаются, если мы возвращаем компании хотя бы эти 15 минут в день.
Вот вам Copilot, разбирайтесь
Внедрение ИИ через «это обязательно», «это ваш новый KPI» и «сами разберётесь» — это провал. Оно порождает недовольство и скрытые временные затраты. Ожидать, что можно дать команде доступ к ChatGPT и получить +50% к продуктивности? Нет, так не бывает.
Нужен трёхуровневый подход, как у нас:
Инвестируем в инструменты, а не в обучение каждого отдельного разработчика искусству промтинга.
ИИ работает по единым, заложенным в него правилам, что (почти всегда) повышает качество и консистентность кодовой базы.
Инженеры занимаются архитектурой и решением сложных бизнес-задач. Выделенная команда — борьбой с нейросетью.
Перестаньте заставлять своих инженеров быть промт-джедаями или превращать их в высокооплачиваемых операторов чата. Начните строить для них тулзы, которые будут встроены в их привычные процессы. Дайте им возможность создавать инструменты, которые масштабируют их экспертизу на всю компанию.
Что может помочь для начала:
Ребята из Cursor опубликовали образовательный курс по использованию AI. Очень рекомендую. Я прошёл его сам полностью примерно за 35 минут.
У Anthropic тоже неплохие курсы, занимают +- час времени.
Мы так пробуем, и это работает. Если хотите обсудить — заходите в гости к нашему CEO — в ТГ-канал «Макеев всё оцифровал и доволен». Что интересно из недавнего — кейс про AI-based пет-проект и применимость Cursor для рефакторинга.
Источник: habr.com
