Я — Евгений Сатуров, 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

И вот что происходит под капотом:

1. Парсинг кода через AST. Наша идея — инверсия контроля. Не разработчик готовит данные для ИИ, это делает инструмент. Утилита не читает файл как текст. Она строит из него абстрактное синтаксическое дерево (AST) с помощью парсеров типа esprima (для JS/TS).

2. Извлечение контекста. Из AST мы вытаскиваем всё: имя компонента (UserProfile), список его props с типами, все импорты (./api, ./hooks), которые нужно будет мокать, названия внутренних функций, которые тестируют отдельно. Инструмент сам понимает структуру кода, зависимости и контекст — без участия разработчика.

3. Генерация промта на стероидах. Это небольшой 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)

Как только задача попадает в работу, ИИ запускает цепочку действий:

1. Берет описание из Jira.

2. Создает для него векторное представление (эмбеддинг).

3. Ищет в нашей векторной базе кода (которую мы обновляем) файлы с наиболее близкими эмбеддингами (косинусное сходство).

4. Автоматически создает новую ветку, предлагает черновик 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 для рефакторинга.