Компании спускают миллиарды на хайповые инструменты разработки, надеясь купить «волшебную таблетку», но вместо неё получают лишь неконтролируемый хаос в процессах.
Меня зовут Юля, я Head of PM в Surf, и мне надоело верить в сказки про всемогущие нейросети. Мы взяли секундомер и устроили жёсткий тест четырём нашим производственным направлениям: мобилке на Native и Flutter, аналитике и QA. Дали ребятам доступ в Cursor и Claude Code, чтобы вытащить на свет реальные цифры. По итогу — разрыв между цифрами и действительностью оказался шокирующим.
В этой статье я выверну нашу внутреннюю кухню. Вы узнаете:
-
Почему 80% команд выдают желаемое за действительное, когда оценивают потенциал ИИ для своего стека.
-
Как тестировщики внезапно обогнали разработчиков по эффективности использования нейросетей.
-
Три подлых фактора, которые прямо сейчас превращают твой ИИ из драйвера роста в тяжёлую обузу.
Торжественно клянёмся, что замышляем только шалость — давайте разбираться.
Как мы измеряли ускорение
Закономерность по каждому отделу такая: успех зависит не от мощности купленной нейросети, а от того, насколько не стыдно за ваши текущие процессы. Чтобы не мерить эффективность на глаз, мы прогнали показатели всех направлений через единую безжалостную систему координат:
1. Тип деятельности
Мы не стали слепо кидать ИИ в команду в надежде на чудо, а чётко разделили задачи на три трека, избавившись от хаоса. Всю унылую рутину — от сбора тест-кейсов и Use Cases до написания бойлерплейтов — скинули на генерацию, инфраструктурные задачи отдали на автоматизацию, а на десерт оставили умное ассистирование, заставив алгоритмы самостоятельно ковыряться в логах, рефакторить код и делать выжимки из Merge Requests.
2. Диапазон ускорения
Чтобы не обманывать себя и коллег в обсчете метрик, мы внедрили три фильтра: прямое столкновение оценки в Jira с реальностью (что продемонстрировало честные x4 в аналитике), взвешенную оценку спринтов (ведь ИИ пока не умеет сидеть за тебя на созвонах) и правило «чистого времени». Последнее стало самым больным для рынка: мы считаем задачу закрытой, только когда разраб вычистил все галлюцинации нейросети — именно так мы доказали, что на сложной отладке в Native-разработке ИИ не ускоряет процесс, а уводит команду в минус.
3. Условия эффективности
Наш аудит разнёс в щепки иллюзию, что доступ к платному Cursor моментально отправит разработку в космос — нейросети дают буст только при соблюдении трёх жёстких условий. Вам понадобится тотальная шаблонизация (QA и аналитика дали иксы только за счёт строгих структур, а хаос в паттернах Native умножил пользу ИИ на ноль), идеальные спецификации по принципу «мусор на входе — мусор на выходе», и главное — доступ к ИИ только для уверенных мидлов и сеньоров, иначе джуны радостно утащат в прод некачественный код, потратив ваши бюджеты на багфиксы.
4. Красные линии
Мы выделили зоны, куда ИИ пускать нельзя или можно только под строгим надзором.
Риск галлюцинаций в Research & Debug. В iOS/Android разработке попытка делегировать ИИ поиск причин сложных багов или проблем производительности часто ведет к потере времени. ИИ может выдумать несуществующие методы API или причины краша.
Потеря контекста. В анализе детальные ТЗ по экранным формам и интерфейсам быстрее писать вручную. ИИ плохо удерживает визуальный контекст и логику сложных UI-взаимодействий.
У QA же планирование тестирования, приемочное тестирование и функциональные проверки требуют понимания бизнес-контекста и атмосферы на проекте, что недоступно нейросети.
Иллюзия готового решения. Любой артефакт (код, User Story, тест), созданный ИИ, является черновиком. Попытка использовать его без ревью — прямой путь к техническому долгу и багам на проде.
Чтобы не копить техдолг и не вестись на сказки вендоров, заглядывай в наш Телеграм-канал «Директорат Surf обсуждает». Там мы разбираем, как мы строим процессы, где теряем деньги и какие инструменты реально работают.
Сводная таблица готовности по компетенциям
Давайте будем честны: бизнесу не интересно, сколько токенов в секунду генерирует модель. Бизнесу нужен ответ на один вопрос: «где мы реально ускоряем time-to-market, а где просто сжигаем бюджет на эксперименты?».
Мы построили матрицу, которая позволяет четко разделить процессы на две категории:
-
Высокая готовность — направления с подтвержденным ROI, где внедрение ИИ напрямую сокращает себестоимость и сроки.
-
Готовность с оговорками — области, где риски потери качества или времени превышают потенциальную выгоду без жесткого экспертного надзора.
Используйте её для принятия решений о том, какие направления автоматизировать в первую очередь для получения быстрого ROI.
|
Компетенция |
Оценка ускорения на уровне процесса |
Готовность к промышленному использованию |
Условия максимальной эффективности |
Ограничения |
|---|---|---|---|---|
|
QA |
x1.2–x5 по видам; ручное x1.47–1.90, Mobile x2.94–3.00, Web x3.05–3.10 |
Высокая для автоматизации и генеративных задач (написание тестов, настройка CI/CD, API/нагрузочные тесты) |
Шаблоны тест-кейсов, структура Surf/Jira, документация по архитектуре автотестов, спецификации API |
Планирование тестирования, функциональное и приёмочное тестирование, повторное тестирование — без значимого ускорения; выполнение остаётся за человеком |
|
Native (iOS/Android) |
1–5x по задачам; типично 1–3x при наличии шаблонов |
С оговорками: сильная зависимость от шаблонов; отладка и исследование — риск потери времени (-2x…-3x) из‑за галлюцинаций |
Шаблоны в коде, дизайне и ТЗ; согласованные практики команды; Swagger/спецификации для API; стабильные пайплайны |
Boilerplate — не через ИИ, а единоразовой автоматизацией; отладка/исправление багов и поиск решений — от -2x до 4x; исследование производительности — в основном потеря времени |
|
Аналитика |
2–4x для типовых задач; фаза анализа в целом ~2x, до ~4x при благоприятной структуре |
Высокая при наличии шаблонов и систематизации |
Шаблоны артефактов (Use Case, AS-IS), подробная исходная документация, работа через GitLab + Cursor |
Работа с детальными ТЗ по экранным формам и интерфейсу — без ускорения; ручная правка быстрее, чем генерация + проверка + исправление |
|
Flutter |
x1.3–x1.8 на уровне всего цикла; экономия времени 24–43% |
Высокая; предсказуемый эффект при стабильных процессах |
Стабильные процессы и загрузка, полнота ТЗ и дизайна, отработанные шаблоны и cursor rules, стандартизированная архитектура |
Legacy без документации, нестандартная архитектура, неполные/неактуальные ТЗ снижают эффект; доменная экспертиза и код-ревью — умеренное ускорение (x1.2–1.5) |
Из таблицы также можно выделить три закономерности, общие для всех направлений:
-
QA стали абсолютным лидером (до x5) потому, что это направление стало одним из первых, куда мы внедрии ИИ-инструменты. Об этом подробно рассказали в статье На другом полюсе — нативная разработка, где сложная отладка и «творческий поиск» могут из-за галлюцинаций ИИ увести эффективность в минус (до -3x).
-
Столбец «Условия эффективности» везде говорит об одном и том же: дайте нейросети шаблон (тест-кейса, архитектуры, Use Case), и она полетит. Попросите её сделать «что-нибудь красивое» с нуля — и вы потратите время на исправление бреда.
-
Если у вас нестандартная архитектура, нет документации или ТЗ написано «на салфетке» (как видно в блоке Flutter и Native), внедрение ИИ даст минимальный выхлоп. Нейросети нужен контекст, а не интуиция.
Сводная матрица по типам деятельности
Чтобы исключить влияние специфики конкретных стеков, мы провели кросс-функциональный анализ данных. Сгруппировали данные не по отделам, а по типам выполняемых задач. Это позволило выявить устойчивые паттерны эффективности.
Данный разрез критически важен для унификации процессов. Таблица ниже показывает, какие виды работ можно безопасно переводить на «ИИ-рельсы» во всех департаментах одновременно, а где технология требует сохранения ручного контроля вне зависимости от языка программирования.
|
Тип деятельности |
QA |
Native |
Аналитика |
Flutter |
Вывод по готовности |
|---|---|---|---|---|---|
|
Генерация кода, тестов, документации |
x3–x5 (ручные проверки, автотесты, snapshot, API-тесты, настройка инфраструктуры) |
x2–x5 (документация обзорная до 5x, README 3x, интеграция API 2–3x, snapshot-тесты 3x) |
2–4x (Use Case, AS-IS, диаграммы, User Stories ~2x) |
x1.3–x2.5 (unit/golden-тесты x2–2.5, рефакторинг x1.8–2.5, документация x1.5–2.5) |
Высокая готовность; промышленное использование возможно при шаблонах и ревью |
|
Интеграции, API, инфраструктура, CI/CD |
x3–x4 (настройка CI/CD, инфраструктура Web/Backend) |
x2–x3 (API, локальные данные); CI/CD x2; кастомные скрипты 3x и выше |
— |
x1.3–x2 (API-слой, CI/CD x1.5–2) |
Высокая при наличии спецификаций (Swagger) и согласованных правил |
|
Ревью, валидация |
x1.5–x2 (ревью требований, проверок, МРов) |
x1.5–x2 (unit/snapshot-тесты, ревью кода) |
Высокое (консультации и валидация — минуты вместо часов) |
x1.2–x1.5 (код-ревью) |
Средняя; финальное решение и качество — за человеком |
|
Отладка, разбор инцидентов |
x2–x3 (отладка автотестов Web/Mobile) |
от -2x до 4x (crash-логи, баги по Jira); исследование производительности — в основном потеря времени |
— |
x1.4–x1.8 (crash logs, дебаггинг) |
С оговорками; в Native — риск галлюцинаций и потери времени; обязательная верификация человеком |
|
Планирование, приёмка, ручное выполнение |
Нет/минимально (планирование тестирования, функциональное/приёмочное тестирование, повторное тестирование) |
— |
Детальные ТЗ по экранным формам и интерфейсу — без ускорения |
Встречи, планирование x1.3–1.7 |
Низкая готовность к замене ИИ; человек обязателен |
Итоговые показатели по направлениям:
-
Лидеры роста (x3 — x5):
-
QA: специальные доработки для автоматизации (x5), Snapshot-тесты (x4), написание ручных проверок (x3-x5). Автоматизация Web/Mobile в среднем ускоряется в ~3 раза.
-
Документация: создание обзорной документации в Native-разработке (x5).
-
Инфраструктура: настройка сред и CI/CD (x3-x4).
-
-
Уверенный рост (x1.5 — x2.5):
-
Аналитика: в среднем фаза анализа ускоряется в 2 раза (до 4х на типовых задачах). Генерация User Stories — x2.
-
Flutter: Unit и Golden тесты (x2-2.5), рефакторинг (x1.8-2.5).
-
Native: работа с локальными данными и API (x2-3).
-
-
Умеренный эффект (x1.2 — x1.5):
-
Код-ревью, бизнес-логика, требующая глубокого понимания домена. Здесь ИИ лишь слегка помогает человеку.
-
-
Отрицательная зона (от -2x до -3x):
-
Native: сложная отладка и расследование инцидентов (crash logs). Из-за галлюцинаций ИИ разработчик может потратить в 3 раза больше времени, чем если бы искал проблему сам.
-
Операционный стандарт — где мы ставим точку
По итогам мы видим четкий градиент полезности ИИ.
Генерация и инфраструктура
Здесь ИИ — не просто помощник, а полноценный рабочий инструмент. Рынок часто твердит, что сгенерированный код сложно поддерживать, но наши цифры говорят об обратном: при наличии жестких шаблонов мы получаем кратное ускорение.
Автотесты пишутся в 5 раз быстрее, документация и Use Cases — в 4 раза. Поэтому мы переводим создание любой «рыбы» кода, конфигов и черновиков в разряд обязательных ИИ-процессов. Писать такое вручную теперь — неоправданная роскошь и прямой убыток для проекта.
Ревью и отладка
В этой зоне ИИ выступает как ассистент, за которым нужен глаз да глаз. Вендоры продают нам идею автономных агентов, которые сами чинят баги, но реальность суровее. В Native-разработке мы увидели критический риск: пытаясь делегировать ИИ сложную отладку, разработчики тратили в 2–3 раза больше времени на проверку его галлюцинаций.
Поэтому здесь мы внедряем правило «human-in-the-loop»: нейросеть отлично ищет опечатки и сканирует логи, но категорически не допускается к принятию решений при разборе инцидентов. Мы не отдаём ИИ «автоматическую отладку», чтобы не ставить под удар сроки.
Планирование и приёмка
Здесь ИИ пока либо балласт, либо слабый помощник. Нейросети не обладают «бизнес-эмпатией»: они не чувствуют приоритетов релиза, политических рисков или тонкостей UI, которые не описаны в тексте.
Наши замеры показали ноль ускорения в планировании стратегий и финальной приемке. Мы сознательно оставляем эти этапы за людьми.
Общие выводы по готовности
Подводя итоги аудита, мы можем четко разделить задачи на те, где ИИ готов к продакшену, и те, где риски перевешивают профит.
Готовность высокая
Здесь ИИ показывает стабильный результат и реальную экономию часов.
-
Генеративные задачи
Написание кода, автотестов (E2E, API, нагрузочные), создание документации (Use Case, AS-IS, диаграммы). -
Инфраструктура
Настройка CI/CD и сред развертывания — но только при наличии четких спецификаций. -
Типовые сценарии
Любая задача, под которую есть готовый шаблон артефакта, ускоряется в разы.
Критические факторы успеха
Внедрение работает не «из коробки», а только при соблюдении гигиены разработки:
-
Шаблоны — это фундамент
Код, дизайн, ТЗ, тест-кейсы должны быть типизированы. -
Актуальная документация
ИИ не телепат, ему нужна полная техническая база. -
Стабильные процессы
Хаос автоматизировать нельзя, можно только масштабировать.
Риски и стоп-факторы
-
Галлюцинации в отладке
Особенно критично для Native-разработки. Попытка делегировать ИИ сложный дебаг может привести к потере времени (-2x…-3x). Верификация обязательна. -
Задачи без ускорения
Планирование тестирования, функциональное и приемочное тестирование, детальные ТЗ по экранным формам. Эти зоны мы не позиционируем как автоматизируемые.
Вердикт
Мы готовы масштабировать ИИ на весь продакшен, но только там, где он объективно эффективен: в генеративных и инфраструктурных задачах. Никакой магии — нейросети дают результат только при наличии жесткой структуры из шаблонов, обязательного код-ревью и пристального контроля качества.
Мы зафиксировали новый стандарт: строгая модель «ИИ + человек» с четким разделением ответственности. Нейросети забирают себе скоростную генерацию черновиков и базовую рутину. За человеком остается стратегическое планирование, погружение в сложный контекст и финальная приемка результата.
В эту статью не вошла и половина инсайтов из нашего аудита. Детальные разборы пилотов, реальные цифры и неочевидные кейсы ускорения мы публикуем в нашем Telegram-канале «Директорат Surf обсуждает». Подписывайтесь, чтобы внедрять ИИ ради реальных бизнес-показателей, а не ради красивых отчетов.
Автор: Surf_Studio
