Компании спускают миллиарды на хайповые инструменты разработки, надеясь купить «волшебную таблетку», но вместо неё получают лишь неконтролируемый хаос в процессах.
Меня зовут Юля, я 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 обсуждает». Подписывайтесь, чтобы внедрять ИИ ради реальных бизнес-показателей, а не ради красивых отчетов.
Комментарии (10)

Dr_Kireeva
16.03.2026 12:51Обычно компании надеются усилить джунов иишкой. А по факту LLM, кажется, сильнее бустит людей с хорошим фильтром качества, чем людей с дефицитом фундаменталки. Было бы очень интересно увидеть отдельный разрез по seniority: у вас эффект реально рос вместе с уровнем исполнителя или это пока скорее качественное наблюдение?

soulkoden
16.03.2026 12:51В целом, всю историю разработки такая корреляция соблюдается.
Когда придумали ассемблер, разработчики переживали: "о, теперь домохозяйки будут код писать". В итоге порог входа стал сложнее, повысились требования к компетенциям.
Когда придумали языки программирования высокого уровня, разработчики переживали: "о, а вот в этот раз домохозяйки точно будут писать код за нас". В итоге порог входа стал еще выше, материалы для обучения стали кратно сложнее.
Когда придумали фреймворки, разработчики снова переживали: "о, в этот раз точно код любой чайник сможет писать". В итоге порог входа стал еще выше, помимо знаний языков программирования пришлось изучать фреймворки, и появились аж специалисты одного фреймворка (ярко выражено в питоне), которые непригодны для работы даже на том же языке, но с другими фреймворками.
Когда придумали нейросети, снова мы проходим стадию переживания: "а может быть в этот раз нас заменят". Нет. Нет никаких оснований считать, что что-то в этой логике изменится. Исходя из предыдущего опыта - порог входа станет еще выше, требования к навыкам станут еще больше, что как раз говорит о прямой корреляции с вводным уровнем компетенции для использования этого инструмента.
Информация, как и любое явление - требует равновесной среды (где-то убыло, где-то прибыло). То есть есть парадокс: чем проще инструмент, тем он сложнее. Потому что надо уметь отвечать на вопросы: "а что такое правильно?", "а что такое эффективно?", "как отличить вообще галлюцинацию от истины?". В этой связи, для использования "простого" ИИ инструмента требуются БОЛЬШИЕ компетенции на старте внедрения, нежели ранее без его использования. Это вроде бы называется "Парадокс автоматизации", если правильно помню - здесь он тоже применим в полной мере.
Но сразу видно, где у них слабое звено в команде. Это QA (ИИ очень любит запечатывать баги в проектах, или предлагать неоптимальные решения, потому что фокус смещен на покрытие тестами - а не на соответствие логики кода изначальным требованиям) и DevOps (ни разу на моей практике ИИ не смог написать правильную конфигурацию без лишних/неоптимальных инструкций, то есть ИИ действует как джун девопс - не строит оптимальную конфигурацию, а раз за разом тянет "из закромов" её с лишними записями, в итоге где в тех же k8s чартах или docker файлах до 90% лишнего кода, не говоря уж о шагах CI).

Erkina_Elena
16.03.2026 12:51Есть ощущение, что ИИ опять же работает тогда, когда у команды уже есть натренированность - а когда ее нет, то сначала пару месяцев провисания и только потом буст. Интересно, как это у вас)

vikulyalinina
16.03.2026 12:51Сразу видно, что вы реально тестируете, а не гоняетесь за хайпом. Особенно интересно про галлюцинации в Native, теперь понятно, почему нельзя слепо доверять ИИ.

dzzd_cnffsd
16.03.2026 12:51Короче, прочитал за вас, смотрите, если у вас порядок в процессах — ИИ ускоряет процессы. Если у вас бардак в процессах — ИИ ускоряет бардак. Cпасибо за внимание ;)
Так-то самый сильный вывод статьи — «хаос автоматизировать нельзя». Многие как раз почему-то сначала внедряют ИИ, а уже потом думают о процессах.

akardapolov
16.03.2026 12:51Потеря контекста. В анализе детальные ТЗ по экранным формам и интерфейсам быстрее писать вручную. ИИ плохо удерживает визуальный контекст и логику сложных UI-взаимодействий.
Claude Code неплохо справился с генерацией UI-форм на Qt. Исходник - скриншот приложения в jpeg. Сложной логики не было, но сам факт - на входе скриншот, а на выходе готовая форма (почти) - далее мелкие правки уже готового, созданного ИИ Qt приложения.

Frisian
16.03.2026 12:51Не представляю как у вас так получается всех, я сколько не кормил скринов дизайна клоду, у меня вообще получаеться адовая дичь..

akardapolov
16.03.2026 12:51Ставил в режим рассуждения и на максимум потребление токенов (не помню как настройка называется), и пыхтел он где-то примерно один час - но выдал таки работающий результат.

amcured
16.03.2026 12:51У Dart и Swift — худшие показатели в AutoCodeBench, что в принципе искусственная метрика, но как бы подсказывает, что обобщать на «ПО» ваши выводы — тоже так себе идея.
rezsoseres
Очень зацепило, что вы считаете не «грязное ускорение», а закрываете задачу только после вычищения галлюцинаций. Это, по сути, самый честный кусок методологии, потому что рынок обычно меряет до первого happy path, а не до production-ready результата.
Но тут сразу вопрос: как вы нормализовали quality cost между командами? Потому что у одних ревьюер жёсткий и разворачивает ползадачи, а у других — «ну вроде ок». Отсюда разброс от -2x до 4x по дебагу?