ИИ частично ускорил разработку. А что насчёт всего остального?

Разработчик раньше тратил на задачу три дня, а с ИИ справляется за день. Кажется, производительность выросла втрое. Но после разработки задача всё ещё должна пройти ревью, тестирование, интеграцию и выкатку. Если эти этапы не ускорились вместе с написанием кода, быстрее стал только один участок системы.

За последние годы ИИ заметно изменил мою работу. Больше не пишу вручную очередной mapper, простой CRUD или разбираться несколько часов с незнакомым API. Могу быстро собрать прототип, попробовать новую библиотеку или проверить гипотезу. Это действительно ускоряет разработку.

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

Ускорили один участок конвейера

Представим простую команду. Раньше разработчик делал задачу три дня, после чего ещё день уходил на проверку.

Раньше:

Разработка  ████████████  3 дня
Тестирование            ████  1 день

С ИИ разработчик справляется за день:

С ИИ:

Разработка  ████  1 день
Тестирование    ████  1 день

На одной задаче всё выглядит хорошо: вместо четырёх дней получилось два.

Но теперь представим несколько разработчиков, которые постоянно отправляют новые задачи на следующий этап. Они стали писать код в два-три раза быстрее, а возможности тестирования почти не изменились. Очень скоро очередь просто переместится. Раньше узким местом была разработка. Теперь им становится ревью, тестирование, аналитика, согласование требований или выкладка.

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

Код стал дешевле, проверка — не настолько

Особенно хорошо это видно на code review. Ещё несколько лет назад pull request на несколько тысяч строк обычно означал несколько дней работы автора. Сейчас агент способен за короткую сессию изменить десятки файлов.

Сгенерировать две тысячи строк кода стало значительно дешевле. Доказать, что эти две тысячи строк работают правильно — нет.

Ревьюер всё ещё должен понять, что именно изменилось, проверить архитектурные решения, найти пропущенные сценарии и убедиться, что новая логика не ломает старую. PR на 60 изменённых файлов может занять у автора пару часов работы с агентом. Но человеку на другой стороне всё равно приходится восстанавливать контекст изменений.

Конечно, ревью тоже можно отдать ИИ. Тогда получается такая система:

AI #1 пишет код
       ↓
AI #2 делает ревью
       ↓
AI #3 генерирует и запускает тесты
       ↓
Разработчик нажимает Approve

И здесь возникает вопрос: что именно человек подтвердил своим Approve? Если один агент написал реализацию, другой проверил её, а третий исправил найденные проблемы, разработчик всё меньше взаимодействует с самим кодом. На короткой дистанции это может быть быстрее. На длинной появляется риск потерять понимание системы.

Как говорит мой коллега:

Чрезмерное использование ИИ ведёт к деградации.

Речь не про инструмент, а про меру. Разбираться в чужом коде — навык, который слабеет без практики.

Тестирование тоже не исчезло

ИИ уже хорошо помогает с тестированием: может предложить тест-кейсы, написать unit-тесты, найти очевидные граничные случаи или подготовить данные. Но генерация тестов и независимая проверка продукта — не одно и то же.

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

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

Вместе с кодом стало дешевле производить идеи

ИИ ускоряет не только разработку. Раньше даже простой прототип мог потребовать нескольких дней. Теперь человек может вечером придумать идею, а утром уже получить работающий интерфейс и backend. Это огромная возможность. Больше людей могут экспериментировать, делать собственные продукты и проверять гипотезы. Но здесь возникает та же проблема.

Идея
  ↓
Прототип          ← сильно ускорился
  ↓
Проверка гипотезы
  ↓
Тестирование
  ↓
Безопасность
  ↓
Эксплуатация
  ↓
Поддержка
  ↓
Пользовательская ценность

Создать продукт стало дешевле. Сделать его хорошим — не настолько. Поэтому снижение стоимости разработки неизбежно означает не только больше хороших продуктов, но и больше сырых.

Когда приложение можно собрать за выходные, появляется соблазн сразу попробовать его монетизировать. При этом безопасность, обработка ошибок, поддержка, нормальное тестирование и даже сама пользовательская проблема могут остаться на потом.

В результате количество произведённого софта растёт быстрее, чем способность пользователей понять, чему из этого можно доверять.

Мы снова измеряем output вместо outcome

Отдельный вопрос — как вообще понять, что внедрение ИИ в компании работает. Самые доступные показатели измерить легко:

• сколько сотрудников используют AI-инструменты;

• сколько запросов они отправили;

• сколько токенов потратили;

• сколько строк кода сгенерировали;

• сколько задач закрыли.

Все эти показатели могут быть полезны для оценки использования инструмента. Но сами по себе они почти ничего не говорят о его ценности. Команда может начать тратить в десять раз больше токенов. Это доказывает только то, что команда стала тратить в десять раз больше токенов.

Количество использованных токенов — это activity, а не результат.

Даже количество закрытых задач ещё не обязательно показывает эффект. Представим:

Использование AI
       ↓
Время разработки ↓ 30%
       ↓
Время review ↑ 40%
       ↓
Количество возвратов ↑
       ↓
Lead time до production ≈ без изменений

На уровне разработчика AI работает прекрасно. На уровне всей системы выигрыш уже неочевиден.

Поэтому мне интереснее не вопрос «сколько кода компания пишет с помощью ИИ», а то, что происходит дальше:

• сократился ли lead time от задачи до production;

• изменилось ли время review;

• сколько изменений возвращается на доработку;

• изменилось ли количество дефектов;

• чаще ли команда выкатывает изменения;

• сократилось ли время проверки гипотез;

• и в конечном счёте изменился ли продуктовый результат.

Использование инструмента и польза от инструмента — разные метрики.

Если простой код пишет ИИ, откуда возьмутся опытные разработчики

Есть ещё одна проблема, последствия которой станут заметны не сразу. Большая часть моей насмотренности появилась не из книг. Я писал плохой код. Делал неудачные абстракции. Видел запросы без нужных индексов, читал explain analyze, чтобы понять, как работает запрос (поверьте, раньше это было непросто). Наблюдал, как решение, которое казалось красивым сегодня, через год становилось сложно поддерживать. Какие-то ошибки приводили к переделке кода. Какие-то — к проблемам в production. Иногда последствия ошибки довольно быстро объясняли, почему определённая практика существует. Так постепенно появляется насмотренность.

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

Пока функциональности было мало, это не мешало. Через год почти любое изменение задевало оба сервиса, на простой вопрос поддержки приходилось смотреть в две базы, а согласованность мы держали руками. Сначала это терпели, потом границу всё равно пришлось переносить вместе с накопленными данными. Про то, где проводить границы, написано много, но понял я это только тогда.

Раньше путь выглядел примерно так:

Простые задачи
      ↓
Первая самостоятельная задача
      ↓
Ошибки
      ↓
Production
      ↓
Последствия собственных решений
      ↓
Более сложные задачи
      ↓
Насмотренность

Сейчас именно нижняя часть этого пути автоматизируется быстрее всего. Компании всё меньше заинтересованы платить человеку за простой CRUD, mapper или очередную интеграцию, если большую часть этой работы способен сделать агент.

Для бизнеса это рационально. Но возникает вопрос: если junior больше не пишет простой код, откуда через несколько лет возьмётся middle (впоследствии — senior), который способен понять, что ИИ написал сложный код неправильно?

Оператор ИИ тоже должен откуда-то взяться

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

Почему один разработчик смотрит на запрос и сразу думает о размере данных в таблице и об индексе, а другой нет? Почему один замечает потенциальную гонку, а другой спокойно принимает PR? Почему один видит, что новая абстракция через полгода станет проблемой?

Не потому, что первый лучше пишет промпты, а потому, что он уже видел похожие ситуации. Насмотренность появляется из собственных ошибок и их последствий.

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

Если большую часть таких решений принимает агент, возникает вопрос, где будущий инженер получит этот опыт. И здесь проблема джунов становится не только социальной. Да, человеку после университета становится сложнее получить первую работу. Но для индустрии важнее другое: junior — это не дешёвый senior. Это одна из стадий появления будущего senior. Если убрать эту стадию, последствия проявятся только через несколько лет.

AI создаёт долг понимания

В разработке давно существует понятие технического долга. Мы принимаем компромисс сейчас и понимаем, что когда-нибудь за него придётся заплатить: переделать архитектуру, убрать временное решение или переписать сложный участок. С AI всё чаще появляется другой вид долга — долг понимания (comprehension debt).

Система работает, тесты проходят, код уже находится в production, но команда не до конца понимает, почему он устроен именно так. Например, агент изменил 30 файлов, добавил кеширование, несколько индексов в БД и новую абстракцию. После нескольких итераций тесты зелёные. PR проверил другой агент, человек посмотрел основные изменения и нажал Approve. Казалось, все счастливы.

Через три месяца возникает проблема в production. Теперь команде всё равно придётся разбираться в этих 30 файлах. Только делать это она будет уже во время инцидента и, возможно, не один день.

Стоимость понимания никуда не исчезла, её просто отложили. Это особенно опасно для кода, где цена ошибки выше обычной: платежи, персональные данные, инфраструктура. Не удивлюсь, если часть современных продуктов уже содержит решения, авторы которых не смогут быстро ответить, где именно сохраняются чувствительные данные, какие поля попадают в логи и кто имеет к ним доступ.

Кажется, что код станет crafted

Однажды у меня возникла бредовая мысль: а что, если через 10 лет «написано человеком» будет восприниматься примерно как ручная сборка автомобиля?

Звучит как снобизм разработчика, но нет особой ценности в том, чтобы человек вручную написал mapper, который агент способен корректно сгенерировать за пять секунд. Но за этой шуткой есть другой вопрос: если производство кода становится практически бесплатным, в чём тогда ценность инженера?

Ценностью становится способность сказать:

Я понимаю, почему эта система работает именно так. Я знаю её ограничения. Я могу объяснить принятое решение. И я готов отвечать за его последствия.

Тогда хороший инженер действительно может писать меньше кода, чем сегодня. Но понимать ему придётся не меньше.

ИИ всё равно полезен

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

Проблема начинается не тогда, когда разработчик использует ИИ. Она начинается, когда скорость генерации начинают путать со скоростью создания ценности.

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

Чем дешевле становится создание кода, тем дороже становится способность его проверять, понимать и отвечать за него.