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

Работа разработчика всё меньше похожа на набор символов в редакторе. Вместо этого — спецификации, тест-сценарии на обычном языке, данные под них и наблюдение за тем, как ИИ-агент выдаёт реализацию. Для одного конкретного разработчика это не гипотеза: за год он не написал вручную ни строчки рабочего кода. Личные проекты, которые раньше съедали недели свободного времени, стали закрываться за одну-две недели по паре часов вечером.

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

Как теперь выглядит рабочий день

Ядро задачи сместилось в текст. Ты пишешь спецификацию, потом тест-сценарии, потом готовишь данные, на которых эти сценарии должны отработать. Сценарии описываются естественным языком, а твоя работа — проследить, чтобы агент сгенерировал их ровно так, как ты задумал. Дальше всё почти механически: запускаешь агента, он пишет код под эти случаи.

Та часть спринта, которая раньше занимала больше всего времени, сжалась до минимума. И вот тут начинается интересное. Удовольствие от того, что «щёлкнуло» после часа гугления и перечитывания документации, никуда не делось — просто источник его другой. Раньше ты переставлял символы, добиваясь читаемости и связности. Теперь ты добиваешься, чтобы формулировка была однозначной. Это другой навык, и он не всем заходит.

Раньше и теперь: где именно сдвиг

Личный проект и командный проект — две разные истории

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

В команде всё иначе. Код стал настолько дешёвым, что каждый может выкатывать сотни строк изменений ежедневно. Умножь на размер команды — и получишь поток, который физически некому осмыслить. Не потому, что люди ленивые, а потому что у человека ограниченная пропускная способность на чтение и удержание контекста. Проблема не в том, чтобы написать, а в том, чтобы понять написанное.

Узкое место переехало, а инструментов под него нет

Часть раздражения — в темпе. Циклы хайпа во фронтенде были бодрые, но то, что происходит вокруг ИИ-инструментов, плагинов и прочих обвязок, — другой масштаб. Однако дело не только в скорости.

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

Пропускная способность ревью не масштабируется вместе с пропускной способностью генерации кода. Это и есть корень большинства проблем.

Чек-лист: собрать свой плейбук вместо ожидания готового

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

Пункт про пересмотр обычно игнорируют. А зря: то, что работало на трёх разработчиках, ломается на восьми.

Когда так работать не стоит

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

Типичные ошибки

• Мерить продуктивность строками кода. В новой схеме это бессмысленная метрика, она растёт сама по себе.
• Заваливать ревью и надеяться, что «как-нибудь разгребётся». Не разгребётся.
• Нанимать людей в узкое место генерации, когда тормозит приёмка.
• Ждать, пока кто-то опубликует готовый плейбук. Его пока нет — ни у вендоров, ни у сообщества.

Что в итоге

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

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