Боевой дух инженеров после появления инструментов ИИ: почему команды чувствуют себя хуже

Что меняется после появления ИИ

Первое изменение — скорость. Черновики появляются гораздо быстрее: код, тесты, исправления багов, заметки и даже комментарии в ревью. Ревью не ускоряется так же резко, и между «что‑то есть» и «чему можно доверять» возникает разрыв.

Этот разрыв меняет ощущение работы. Менеджер открывает доску и видит больше коммитов, больше веток и больше pull request‑ов. Легко сделать вывод, что команда может брать больше работы. Даже если никто этого вслух не говорит, инженеры чувствуют это в планировании, более жёстких дедлайнах и тихом давлении не отставать от нового темпа.

Ежедневная работа тоже меняется. Инженеры тратят меньше времени на старт с пустого файла и больше — на построчное чтение вывода машины. Звучит легче, но часто так не бывает. Чтение 400 строк, которые выглядят правдоподобно, и поиск трёх строк, ломающих сервис, требует больше концентрации, чем написание 80 аккуратных строк самому.

Командные нормы тоже размываются. До появления инструментов ИИ у большинства команд было общее понимание, что значит «готово». Один человек писал код, другой его ревьюил, и оба примерно представляли объем работы. После появления ИИ это понимание ослабевает. Является ли сгенерированный черновик реальным прогрессом или просто предложением? Сколько правок нужно сделать до ревью? Кто отвечает за ошибки в сгенерированном коде?

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

Почему большее количество вывода может ощущаться хуже

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

Большой сгенерированный черновик часто скрывает несколько рискованных правок среди массы безобидного кода. Рискованная часть может быть небольшой: изменённое правило повторной попытки, пропущенная проверка прав или слабая обработка null. Когда это находится внутри 600‑строчного диффа, автор идёт быстрее, но ревьюер замедляется и напрягается.

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

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

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

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

Как расплывчатые ожидания повышают стресс

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

Каждый инженер слышит своё. Один использует ИИ для черновиков и тестов. Другой — для генерации больших кусков кода. Третий избегает его, потому что не знает, где проходит граница. Этот разрыв быстро создаёт тихое напряжение.

Когда никто не определяет успех, люди начинают гадать. Значит ли «хорошо» больше закрытых задач, большие диффы, быстрые первые черновики или меньше багов через неделю? Игра в угадайку утомляет.

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

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

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

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

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

Люди лучше работают, когда команда определяет «достаточно» простым языком. Тогда инженеры могут сосредоточиться на хорошем коде, а не на чтении мыслей менеджера.

Почему большие диффы утомляют

Большие диффы быстрее высасывают внимание, чем многие команды ожидают. Одна подсказка может обновить обработчик, тесты, типы, документацию и конфигурацию за один проход. Вывод растёт, но ревью усложняется.

Человеку удобно проследить одну аккуратную правку в двух файлах. Десять файлов с 600 новыми строками — совсем другое. Даже если код выглядит аккуратно, ревьюеру приходится держать в голове больше предположений одновременно. Эта умственная нагрузка быстро утомляет.

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

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

Типичный сценарий прост: одна подсказка меняет ответ API. Инструмент также обновляет frontend‑типы, тесты и документацию. Дифф выглядит завершённым, и ревьюер просматривает его вскользь. Малое несоответствие доходит до продакшна.

Никто не сделал бедственного шага. Просто одна правка попросила одного человека проверить слишком много сразу.

Владение становится неясным. Если ИИ сгенерировал первый черновик, разработчик может понимать цель, но не чувствовать полной уверенности во всех файлах. Ревьюер предполагает, что автор всё проверил. Автор предполагает, что ревьюер поймает странности. Этот разрыв в передаче ответственности создаёт стресс.

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

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

Как частая смена инструментов ломает фокус

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

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

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

Неровная конфигурация в команде усугубляет ситуацию. Один инженер использует Claude в терминале, другой — через плагин IDE, третий автоматизировал поток с двумя моделями и локальным кэшем. Они могут все генерировать код, но не одинаково ревьюить, отлаживать или объяснять его.

Трение проявляется в мелочах. Комментарии в ревью ссылаются на подсказки, которых никто больше не использует. Баг появляется для одной версии модели и не воспроизводится в других. Товарищ по команде не может воспроизвести, как именно был сгенерирован фрагмент. Люди тратят час на отладку подсказки для задачи, на которую при обычном программировании ушло бы 20 минут.

Скрытая стоимость — переключение контекста. Вместо того чтобы думать о продукте, инженеры думают о поведении инструментов. Они сравнивают выводы, тестируют настройки и сомневаются, произошло ли странное поведение из‑за их кода или из‑за молчаливого обновления модели.

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

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

Простой пример из команды

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

Потом бэкенд‑инженер открывает pull request для, казалось бы, небольшой правки: добавить одно правило биллинга и обновить админ‑страницу. Дифф — 1200 строк. Инструмент затронул файлы, которые инженер не планировал править: переписал вспомогательные функции, поменял нейминг в нескольких модулях и добавил тесты, которые никто не просил.

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

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

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

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

К концу недели коммитов стало больше. Уверенности — нет.

Как сбалансировать рабочий процесс

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

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

Установите мягкий лимит на диффы с большим количеством ИИ‑генераций. Многие команды хорошо работают с 300–500 изменёнными строками или одним очевидным юнитом работы. Попросите автора добавить короткую заметку простым языком: что изменено, почему это изменено и что ревьюеру проверить в первую очередь. Отслеживайте время ревью, частоту багов после мержа и послематчевые работы вроде поздних сообщений, коммитов или хотфиксов. Через две недели пересмотрите правила и оставьте только те, которые снизили стресс.

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

Заметка автора тоже важна. Ревьюеру не нужно гадать намерение по сгенерированному коду. Две‑три ясные фразы экономят 20 минут и убирают много трения.

Это работает только если кто‑то владеет процессом. В небольшой команде это может быть техлид, основатель или Fractional CTO. Владеть не значит строить большой процесс — достаточно проверять метрики, выяснять, где проявляется стресс, и менять по одному параметру.

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

Ошибки, которые всё усугубляют

Команды чаще всего попадают в беду, когда начинают измерять самое простое вместо того, что важно. Если менеджеры хвалят количество строк, огромные pull request'ы или объём закрытых тикетов, люди быстро учатся неправильному уроку: сгенерированный код выглядит как прогресс.

Большие диффы — яркий пример. 2000 строк за 20 минут всё ещё требуют часов на ревью. Автор чувствует давление идти быстрее, ревьюер тонет в деталях. Через пару итераций люди перестают чувствовать себя продуктивными и начинают застревать.

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

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

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

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

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

Еженедельная проверка

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

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

Заканчивают ли ревьюеры большинство диффов за один присест? Если нет, возможно, команда шипит слишком много сгенерированного кода одновременно. Знают ли инженеры, когда писать код вручную? Если ответы отличаются у разных людей, ожидания всё ещё туманны. Появляются ли баги после мержа там, где вчера казалось «готово»? Это часто указывает на поспешное ревью или излишнее доверие к сгенерированному выводу. Делают ли люди больше послерыночной работы, чем раньше? Если да, выигрыш в скорости может стоить дороже, чем кажется.

Вам не нужен тяжёлый инструмент опроса. Короткий еженедельный чек‑ин на встрече команды зачастую достаточен. Смысл — сделать скрытые усилия видимыми до того, как люди перестанут говорить прямо.

Что делать дальше

Начните с малого. Полный ребут обычно утомляет больше, чем помогает. Выберите одну проблему на этой неделе и решите только её.

Если ревью тяжелеют, временно введите лимит на AI‑генерированные pull request'ы. Попросите людей разбивать работу на меньшие диффы или добавлять короткую заметку, объясняющую, что изменилось, что нужно проверить и где инструмент мог ошибиться.

Запишите правила, чтобы никто не гадал. Держите их короткими. Определите, насколько может быть велик PR до того, как его нужно разбить, какие проверки делает автор перед запросом ревью, когда стоит избегать использования ИИ, какие части всегда требуют человеческого решения и как быстро команда ожидает ревью.

Эта одна страница убирает много тихого стресса. Люди перестают волноваться, медлят они или отстают, когда реальная проблема в том, что никто не согласовал правила.

Затем спросите команду два прямых вопроса: «Где ИИ экономит вам время?» и «Где он вас тратит?» Обычно ответы будут смешанными. Кто‑то быстрее справляется с рутинным кодом, а кто‑то тратит лишний час на проверку больших диффов и поиск ошибок инструментов.

Используйте эти ответы, чтобы на следующей неделе внести ещё одно небольшое изменение. Оставляйте то, что помогает. Убирайте то, что создаёт шум.

Если команда застряла, внешний обзор может помочь. Oleg Sotnikov на oleg.is работает со стартапами и малыми командами по AI‑первым инженерным рабочим процессам, инфраструктуре и поддержке Fractional CTO. Короткий обзор вашего потока pull request'ов, настроек инструментов и нагрузки на ревью может выявить проблемы, которые команда перестала замечать.