← Все статьи

Михаил Поляков

Разработчики и аналитики с ИИ: в чём разница в работе и как проверять результат

Уровень: ПростойВремя чтения: 12 мин

Темы: ИИ, Системный анализ

Два рабочих места на тёмном фоне: слева монитор с цветными полосами кода и зелёной галочкой, справа листы со схемой из блоков и стрелок и лупа; над ними светящийся шар, от которого тянутся нити к обоим местам

Короткий ответ: разработчик и аналитик работают с ИИ по-разному, потому что их результат проверяется по-разному. Код можно запустить и прогнать тестами. Это не доказывает, что он верен, но часть ошибок машина находит сама. Поэтому разработчику можно отдавать нейросети больше, вплоть до целых задач. Требования, схемы и выводы из данных так не запустишь. Отдельные места в них можно сверить с источником или пересчитать, но пропущенный сценарий или неверное правило бизнеса до появления кода ищут чтением и вопросами. Задать их может человек, а подсказать и ИИ, если попросить его искать, что может пойти не так. Если пропуск не заметят, он может всплыть позже, при тестировании, в работающей программе или в принятом решении. Поэтому аналитик берёт у ИИ черновики, вопросы и сверку, а за каждое утверждение отвечает сам. Руководителю из этого следует одно: строить для двух ролей разную проверку и мерить пользу цифрами, а не ощущениями.

Я больше 13 лет в ИТ, руководил отделом аналитики, сейчас главный системный аналитик. Свои проекты на этом сайте делаю вместе с ИИ-агентами, которые пишут код. Ниже то, что я вижу с обеих сторон, плюс данные опросов и одного эксперимента. Цифры по разработчикам есть, по аналитикам крупных опросов я не нашёл, поэтому там больше рассуждений и советов, и я это помечаю.

Кто есть кто

Разработчик пишет программу: код, который выполняет компьютер.

Аналитик в этой статье это два близких человека. Системный или бизнес-аналитик решает, что именно должна делать программа, и записывает это в требования: какие данные, какие экраны, что делать при сбое. Аналитик данных достаёт цифры из базы и отвечает на вопросы вроде «сколько клиентов ушло за квартал и почему». В небольшой компании обе роли может совмещать один человек.

Как разработчики уже работают с ИИ

Цифры здесь из опросов, это ответы самих участников. В опросе Stack Overflow участвуют не только профессиональные разработчики, но и, например, учащиеся, поэтому доли ниже относятся ко всем участникам, кроме отдельно оговорённых. В DORA опрошены ИТ-специалисты, от разработчиков до менеджеров продукта.

  • Многие пользуются каждый день. В опросе Stack Overflow 2025 года (49 тысяч ответов) 84% уже пользуются ИИ в работе или собираются начать, в этой цифре обе группы вместе. Среди профессиональных разработчиков 51% пользуются каждый день. В отчёте Google DORA 2025 года (около 5 тысяч специалистов) доля пользователей 90%, медианное время работы с ИИ два часа в день.
  • Пробуют агентов. ИИ-агент это программа, которая сама выполняет задачу по шагам: читает файлы проекта, пишет код, запускает проверки. В опросе Stack Overflow 2025 года агентами регулярно пользовался 31% участников. В отдельном быстром опросе Stack Overflow в апреле 2026 года об использовании агентов сообщили 59% участников, как часто они ими пользуются, в публикации не сказано. Вопросы и выборки у опросов разные, поэтому сравнивать эти доли между собой нельзя.
  • Доверяют мало. В том же опросе 2025 года точности ИИ доверяют 33%, не доверяют 46%. Главная жалоба, её выбрали 66%: ответы «почти правильные, но не совсем». 45% пишут, что отлаживать код от ИИ дольше.
  • Чувствуют пользу. В DORA больше 80% говорят, что ИИ повысил их продуктивность. Это самооценка, и следующий раздел показывает, почему одной самооценки мало.

Ощущение скорости и измеренная скорость

Исследовательская организация METR в первой половине 2025 года провела эксперимент: 16 опытных разработчиков открытых проектов решали 246 реальных задач в своих же проектах. Для каждой задачи случайно решали, можно ли пользоваться ИИ. С ИИ задачи заняли на 19% больше времени. При этом после эксперимента разработчики считали, что ИИ ускорил их на 20%.

Авторы сами ограничивают вывод: это маленькая выборка опытных людей в знакомых проектах, на инструментах начала 2025 года, и результат не значит, что ИИ замедляет всех разработчиков.

В феврале 2026 года METR опубликовал обновление. Новый эксперимент дал ненадёжные данные: от 30% до 50% участников признались, что не отдавали в эксперимент часть задач, потому что не хотели делать их без ИИ. Сами авторы считают, что в начале 2026 года разработчики, скорее всего, ускоряются сильнее, чем в 2025-м, но признают, что их данные это подтверждают очень слабо.

Вывод для руководителя: ощущение «с ИИ быстрее» не измерение. Даже у разработчиков, у которых есть тесты и проверка кода, пользу нужно считать по задачам и срокам.

Почему ошибку в коде найти проще, чем в требованиях

Это главное отличие, и дальше всё из него следует. Здесь мой вывод из практики, а не данные исследования.

У разработчика после ИИ остаются проверки, которые не зависят от того, кто писал код:

  • код запускается или нет;
  • тесты (маленькие программы, которые проверяют заранее заданные случаи: при таких данных должен получиться такой результат) проходят или падают;
  • коллега смотрит изменения перед тем, как они попадут в рабочую версию.

Ни одна из них не гарантирует, что код правильный: код может запуститься и выдать неверный результат, а тесты ловят только те случаи, которые в них заложены. Но «почти правильный» код может сломать тест или упасть при запуске, и тогда при этом запуске видно, что ошибка есть, хотя её причину ещё может понадобиться искать.

У аналитика результат это текст. Требование «при повторном нажатии кнопки оплаты показать клиенту сообщение» звучит разумно. Но оно ничего не говорит о том, что делать, если деньги уже списались дважды. Пока кода нет, запускать нечего, и такой пропуск ищут чтением: разработчик, тестировщик, второй аналитик или ИИ, которого попросили перечислить сценарии сбоев, спрашивает: «а если списалось дважды?». Позже его может поймать тестировщик, если проверит этот сценарий сам, независимо от требований. Если не поймает никто, пропуск может всплыть уже в работающей программе. Пример условный.

У аналитика данных похожая ловушка. ИИ пишет запрос к базе (SQL-запрос, команду, которая достаёт данные), запрос выполняется и выдаёт число. Но выполнился не значит посчитал верно: например, запрос мог учесть отменённые заказы вместе с оплаченными. Число выглядит правдоподобно. Ошибку можно найти, если перечитать условия запроса или сверить число с другим источником.

Что давать ИИ в каждой роли

Разработчик Аналитик
Что хорошо отдать ИИ Типовой код, тесты, разбор чужого кода, перевод с одного языка программирования на другой, целые задачи через агента Черновик требований по записи встречи, список вопросов и сценариев сбоев, сверка двух документов, черновик запроса к базе
Чем проверить Запуск, тесты, проверка кода коллегой Ссылка на источник у каждого утверждения, чтение требований разработчиком, сверка цифры вторым способом
Когда видна ошибка Если её ловит запуск или тест, при этом запуске Может всплыть позже, в коде или в решении
Что ИИ нужно знать Код проекта, ему можно дать доступ к файлам Договорённости, правила бизнеса, законы. Бывает, что они есть только в головах людей и в переписке
Главный риск «Почти правильный» код, который проходит проверки, но ломает редкий случай Правдоподобный текст или число без опоры

Что сделать руководителю

Для разработчиков.

  1. Оставить обязательными тесты и проверку кода коллегой для всего, что написано с ИИ. Кто делает: ведущий разработчик. Чем проверить: в трекере задач (программе, где ведутся задачи) у каждой задачи есть отметка о проверке.
  2. Отдавать агенту сначала задачи, где результат легко проверить: тесты, мелкие правки, разбор ошибок. Кто решает: ведущий разработчик.
  3. Мерить пользу по задачам, а не по ощущениям. Кто делает: руководитель команды. Чем проверить: сравнить за месяц до и месяц после время на сопоставимые задачи и число возвратов на исправление, порядок в разделе об окупаемости ниже.

Для аналитиков.

  1. Просить у ИИ вопросы и сценарии сбоев, а не готовые ответы: «вот описание функции, перечисли, что может пойти не так». Решение по каждому пункту принимает аналитик.
  2. Требовать у каждого утверждения в требованиях ссылку: на встречу, письмо, закон, правило компании. Кто проверяет: руководитель аналитика или второй аналитик выборочно. Утверждение без ссылки стоит перепроверить: его мог додумать ИИ.
  3. Перед началом работы разработчик читает требования и задаёт вопросы. Кто делает: разработчик, который будет писать код. Чем проверить: список его вопросов прикреплён к задаче.
  4. Любую цифру, которую ИИ помог посчитать, сверять вторым способом: с отчётом из другой системы или ручным подсчётом на маленькой выборке. Кто делает: аналитик данных, до того как цифра попадёт к руководству.
  5. Не вставлять персональные данные клиентов и закрытые договорённости в общедоступный чат-бот. Какой сервис можно использовать в компании, решает руководитель вместе с юристом.

Окупается ли подписка

По данным Хабр Карьеры за первое полугодие 2026 года, медианная зарплата (половина специалистов получает меньше, половина больше) бэкенд-разработчика, то есть того, кто пишет серверную часть программы, 251 тысяча рублей в месяц, системного аналитика 222 тысячи. Пусть подписка на ИИ-сервис стоит 2 тысячи рублей в месяц: это условная цена, подставьте свой тариф.

2 тысячи от 251 тысячи это 0,8% зарплаты разработчика, от 222 тысяч это 0,9% зарплаты аналитика. То есть подписка стоит меньше, чем 1% рабочего времени сотрудника с медианной зарплатой, без учёта налогов и взносов. Это предварительный ориентир, а не доказательство окупаемости. Окупаемость решает чистая экономия: сэкономленное время минус время на проверку того, что сделал ИИ, и на переделки. И сэкономленное время даёт пользу, только если его потратили на другую полезную работу.

Обе вычитаемые статьи легко недооценить. Время на проверку не видно в отчётах, если его отдельно не отмечать. Ошибку, пропущенную при проверке, у разработчика ещё может поймать тест. У аналитика ошибка в требованиях может потребовать переделки у всей команды: и кода, и тестов, и самих требований. Такая переделка может оказаться дороже всей экономии от подписки. Поэтому для аналитиков считать нужно вместе с переделками.

Как проверить через месяц. Кто делает: руководитель команды.

  1. Возьмите один вид типовых задач, например мелкие правки у разработчика или описание одной функции у аналитика.
  2. По трекеру посмотрите, сколько часов такие задачи занимали в месяц до ИИ, и сколько их было.
  3. В месяц с ИИ попросите команду отмечать в трекере отдельно время на саму задачу, на проверку результата ИИ и на переделки.
  4. Посчитайте среднее время на одну задачу до и после, причём после вместе с проверкой и переделками. Разница, умноженная на число таких задач в месяце с ИИ, это чистая экономия в часах за этот месяц.
  5. Умножьте её на стоимость часа сотрудника (месячные расходы компании на него, делённые на число его рабочих часов в месяце) и сравните с ценой подписки.

Сравнение грубое: задачи не бывают одинаковыми, поэтому доверяйте заметной разнице, а не долям процента. Дополнительно стоит смотреть:

  • Разработчики: число задач, вернувшихся на исправление, до и после.
  • Аналитики: число вопросов и переделок от разработчиков по требованиям. Если требования готовятся быстрее, а переделок стало больше, выигрыш мог уйти на переделки.

Если цифры не изменились или стали хуже, не спешите отказываться: посмотрите, на каких задачах ИИ используют. Возможно, проще сузить задачи, чем отключить инструмент.

Когда это не подходит

  • В команде нет тестов и проверки кода. Тогда ИИ у разработчиков может ускорить и появление ошибок: «почти правильный» код остаётся проверять запуском и чтением. Отчёт DORA называет ИИ зеркалом и усилителем: в слаженной организации он повышает эффективность, в разрозненной высвечивает слабые места. Сначала проверки, потом агенты.
  • Правила бизнеса нигде не записаны. ИИ у аналитика может додумывать их сам, и текст получится гладким, но неверным там, где он додумал. Сначала записать правила, потом просить черновики.
  • Работа с особо чувствительными данными, а договора с ИИ-сервисом нет. Здесь вопрос к юристу, а не к выбору модели.

Итог

Разработчик может отдать ИИ много, потому что у кода есть проверки, которые не зависят от автора: запуск, тесты, проверка коллегой. У аналитика отдельные места можно сверить с источником или пересчитать, но пропущенный сценарий или неверное правило бизнеса до появления кода ищут чтением и вопросами, и решение по каждому найденному пункту принимает человек. Поэтому ИИ для аналитика помощник по черновикам и вопросам, а опора каждого утверждения остаётся на человеке. Подписка по сравнению с зарплатой стоит немного, но окупаемость решает чистая экономия: сэкономленное время минус проверка и переделки. Для аналитиков переделки особенно важно учитывать. Через месяц сравните время на сопоставимые задачи вместе с проверкой и переделками, до и после, это покажет больше, чем ощущения команды: эксперимент METR показал, насколько ощущение может расходиться с замером.

Про то, что вообще делает системный аналитик и когда его нанимать в небольшую команду, у меня есть отдельный разбор: нужен ли стартапу системный аналитик.

Я занимаюсь системной аналитикой, ИИ-агентами и автоматизацией. Если хотите посмотреть мои проекты или обсудить свою задачу, загляните в портфолио.

Источники