Сразу предупрежу: я патологически люблю аналогии и метафоры. Некоторые коллеги за это меня недолюбливают — на планировании, где все обсуждают сроки, я могу иногда сообщить, что мы строим не мост, а понтонную переправу. Такая встреча легко продлевается на лишние двадцать минут.
Рад бы исправиться и всегда отвечать, как LLM, то есть строго по существу, но всё никак не получается. У метафоры есть свойство, которое искупает причинённые неудобства: иногда именно проверка интуитивной гипотезы обобщения позволяет «перелезть через забор» последовательного мышления и найти короткую дорогу к важным выводам.
В этой статье я попытаюсь проверить очередную интуитивную догадку: автоматизация труда разработчика с помощью LLM ведёт туда же, куда сорок лет назад привёл автопилот — к роли наблюдателя за исправно работающей машиной, при неизменной ответственности за результат.
1. Разработка «на автопилоте»
Мне доводится много общаться с разработчиками. Почти все используют LLM — Claude Code, Cursor, что-то ещё. LLM решает простую задачу: в буквальном смысле пишет за разработчика код, разрабатывает архитектуру решений — и делает это невероятно быстро и чуть ли не с каждым месяцем всё более точно. Ни один из этих разработчиков не сказал: «теперь я оцениваю эту задачу не в десять дней, а в два часа».
Оценки не поехали вниз. Сокращается другое — количество личных усилий внутри той же оценки. Задача, которая стоила десять дней, по-прежнему стоит десять дней, но внутри этих десяти дней у человека появились паузы: ютуб, сигареты, восемь походов на кофепоинт, да что угодно — в ожидании, когда агент допишет большую фичу и прогонит тесты. Роль сместилась: с «пишу» на «смотрю, как пишут, и решаю, годится ли».
Это никакое не обвинение, это личное право каждого, но это ключевой момент. И именно в этой точке начинается авиационная метафора.
Второе наблюдение — уровнем выше. 29 июля 2026 года компания «Яндекс» объявила программу «75/75/75» (пресс-релиз). Цели на конец 2026 года: не менее 75% разработчиков регулярно применяют ИИ при написании кода. ИИ участвует в подготовке не менее 75% изменений. В каждом таком изменении генерирует не менее 75% кода. Отправная точка там же: 73% разработчиков уже используют ИИ, больше половины нового кода создаётся с участием моделей, а «глубокий» режим пока у 17,2%. Это уже не «инструмент, если хотите» — это целевой показатель с конкретной долей и сроком.
Про человека в релизе сказано ровно одно предложение: «архитектурные решения, проверка качества и ответственность за результат остаются за разработчиками». Ни слова о том, что происходит с навыком, вниманием и мотивацией того, у кого забрали 75% исполнительского труда и оставили 100% ответственности. Публичных материалов о том, что кто-то предусмотрел эти риски, я не нашёл — ни у Яндекса, ни у других компаний с похожими целями. Возможно, такая работа ведётся внутри и не опубликована. Но снаружи метрика есть, а разговора о цене нет.
И заметьте: та единственная фраза про ответственность — буквальное описание перекоса и его последствий, о которых рассказывает эта статья. Исполнение уходит, ответственность остаётся. В авиации это ровно та конфигурация, которая породила отдельную исследовательскую программу на полвека.
2. Причём здесь вообще авиация?
На YouTube есть устойчивый жанр: пьяных пилотов (sic!) снимают с рейса (пример). Ролики набирают миллионы просмотров.
Статистика говорит, что это редкость: по данным FAA, в 2023 году доля нарушений при случайных тестах на алкоголь среди персонала на «safety-sensitive» позициях — около 0,1%. Зато тесты, назначенные «по подозрению», подтверждаются примерно в 40% случаев. Базовая частота низкая, а вот подозрения оправдываются часто.
Меня зацепил не сам этот факт, но скорее вопрос: как профессия с самым жёстким отбором, медконтролем и рандомными тестами вообще производит такой жанр? И не стал ли он больше заметен тогда, когда пилот перестал летать руками?
3. Разрыв в сто лет
Про автоматизацию труда разработчика говорят как про новость. Между тем у пилотов этот эксперимент идёт с 1914 года — Лоуренс Сперри показал трёхосевой гироскопический стабилизатор через одиннадцать лет после Китти-Хок (хронология). Дальше: 1947 — полностью автоматический трансатлантический перелёт со взлётом и посадкой. Июнь 1965 — первый серийный autoland на Trident компании BEA: заход, выравнивание, касание и пробег без участия пилота. 1970-е — FMS, объединившая маршрут, режимы и автопилот. С 1980-х — стеклянная кабина и fly-by-wire как норма.
То есть к моменту, когда мы впервые открыли Copilot, у авиации за плечами было семьдесят лет данных о том, что происходит с человеком, чью работу делает машина. Мы стартуем не с нуля — мы стартуем с готовым чужим отчётом, который просто не читаем.
4. Сколько труда пилота уже автоматизировано
Точной метрики нет, но три независимые оценки в целом сходятся.
По времени управления. На типичном рейсе автопилот включён примерно 90% времени, на дальнемагистральных — до 99%. Ручного пилотирования у большинства линейных пилотов остаётся порядка десяти минут на рейс — взлёт и часть захода. При восьмичасовом рейсе это около 2% времени. Набор и крейсер — 60–80% полёта — автоматизированы практически полностью.
По составу экипажа. Кабина 1950-х — пять человек: два пилота, бортинженер, штурман, радист. Сегодня — двое. Три роли из пяти исчезли целиком: не «стало легче», а перестали существовать как профессии.
Штурмана и радиста техника убрала напрямую — инерциальная навигация, потом GPS, надёжная связь и передача данных. Бортинженера сделал ненужным автоматический мониторинг систем, но окончательно его убрало финансовое давление, которому автоматика дала обоснование. Две роли из трёх ушли из-за машины, третья — из-за машины и денег.
По содержанию остального. Вот это главное. Автоматизировали не «часть работы пилота», а конкретный её тип — непрерывное ручное управление, то самое, которое даёт обратную связь каждую секунду. Осталось то, что автоматизировать (пока?) труднее всего: принятие решений в нестандартных ситуациях, взаимодействие с диспетчером, и — большую часть времени — наблюдение за исправно работающей машиной.
Грубая оценка: ушло около 90% исполнительского труда и почти ноль ответственности. Пилот отвечает за рейс ровно так же, как в 1950-м. Именно этот перекос — а не сокращение нагрузки — и есть предмет разговора.
Отсюда полезный вопрос к нашей профессии: какая доля работы разработчика — исполнительская, посекундная, дающая обратную связь? И что останется, когда её заберут?
5. Гипотеза
Автоматизация не снимает нагрузку — она лишь меняет её тип: активная работа превращается в пассивный мониторинг. При этом внешние обязательства человека не меняются: те же часы, те же сроки, та же ответственность. Меняется только источник вовлечённости и внутренняя награда за созерцание именно своего труда — всё это исчезает.
Возникающий дефицит стимула компенсируется (в смысле физиологического термина: «компенсация»). Сначала безобидно — телефон, вкладки, разговоры. Позже — увы, часто деструктивно.
И есть второй множитель, без которого механизм не работает: невозможность отойти. Автопилот ведёт самолёт, но пилот все восемь часов заперт в самолёте — отойти на пару минут можно, уйти и заняться чем-то другим нельзя. Работа опустела, присутствие осталось обязательным. Это не побочная деталь, а условие, при котором скука превращается в проблему: у неё нет выхода.
Ровно то же сейчас достраивается в разработке. Пока агент пишет код, разработчик всё чаще обязан отсидеть свои восемь часов в офисе — отмена удалённой работы идёт одновременно с автоматизацией исполнительского труда.
Возражение очевидное: офис — не кабина, из него можно выйти. Долгий обед, курилка, «встреча» в календаре и час без мессенджера — способы «потеряться» существуют и известны многим. Но доступны они далеко не всем и не всегда: open space, где каждый второй прохожий заглядывает в твой монитор, трекинг активности, созвоны через каждые полтора часа, а у кого-то просто нет привычки и характера так делать. Чем меньше в дне содержательной работы, тем сильнее человек упирается в это ограничение — и тем ближе его положение к кабинному: формально выйти можно, фактически некуда и незачем.
Содержание рабочего дня разрежается, а требование физического присутствия ужесточается. Мы своими руками воссоздаём кабину: кресло, от которого нельзя уйти, и машину, которая делает работу за тебя.
Показательно, что в авиации обязательное присутствие оправдано — пилот нужен в те две минуты, когда что-то пойдёт не так, и добраться до кресла из другого места невозможно. У офиса такого оправдания нет (on-call дежурство и работа с инцидентами — единственное исключение): кодревью не требует конкретного стула. То есть мы копируем самую вредную часть конструкции, не имея причины, по которой она в авиации неизбежна.
Разработчики с LLM входят в тот же коридор на полвека позже пилотов — быстрее, массовее и без единого регулятора.
6. Проверка метафоры метриками и фактами
Complacency — механизм, а не черта характера. В зависимости от контекста слово complacency можно перевести как «самоуспокоенность» или «беспечность», но оба варианта лишь приблизительны. В авиационной безопасности complacency означает снижение бдительности, возникающее из-за ничем не подтверждённой уверенности, что система работает нормально.
Речь не о лени и не о халатности: человек перестаёт внимательно контролировать автоматику именно потому, что ожидает от неё нормальной работы. Ключевое здесь — состояние, возникающее в определённых условиях, а не устойчивая черта характера: его может порождать сама конфигурация «надёжная машина + человек в роли наблюдателя».
NASA/TM-2001-211413 (Prinzel et al.): при стабильной надёжности автоматики пропуск отказов фиксируется уже через 20 минут работы. Предикторы — complacency potential, boredom proneness и cognitive failure — значимо скоррелированы между собой: «склонность к скуке» и «склонность довериться автоматике» оказались одной уязвимостью в разных проекциях. Parasuraman & Manzey (2010) добавляют неприятное: complacency не лечится ни опытом, ни инструкцией — это структурное свойство распределения внимания при ограниченных ресурсах.
Деградация навыка. В 2013 году рабочая группа FAA по автоматизации кабины зафиксировала ухудшение ручного пилотирования и мониторинга (Operational Use of Flight Path Management Systems, 28 находок и 18 рекомендаций). Итог — летать руками при любой возможности. Аналог для нас: MIT Media Lab, «Your Brain on ChatGPT» (препринт, малая выборка) — у группы LLM слабее связность ЭЭГ и хуже воспроизведение собственного текста. Авторы называют это «когнитивным долгом».
Разрыв между результатом и самооценкой. METR (2025): 16 опытных разработчиков, 246 реальных задач в знакомых им кодовых базах. С ИИ они работали на 19% медленнее — и при этом оценивали свою скорость как на 20% выше. Это зеркало того, что я вижу в разговорах: оценки не корректируются вниз, потому что человек наблюдает не собственную производительность, а собственное усилие — и оно действительно упало.
Скорость без устойчивости. DORA 2025 (≈5000 респондентов, 90% используют ИИ ежедневно): ИИ работает как усилитель — сильные команды ускоряются, слабые быстрее производят нестабильность. Я категорический сторонник именно этой версии поляризации. Считаю, что на порядки ускоряются только одиночки или компактные команды — не те, кто привык пудрить мозги акционерам, имитировать интерес и годами просиживать штаны ради зарплаты, а те, кто горит не написанием кода, но продуктом, решающим конкретные задачи. Код для них не цель, но средство.
Самое слабое звено. Связка «скука → complacency» у пилотов измерена: Bhana (2010), опрос 273 линейных пилотов, значимая положительная корреляция склонности к скуке с complacency (r = 0,181) и состояния скуки с частотой провалов внимания (r = 0,293). Про алкоголь там нет ни слова. Связь «скука → алкоголь» в литературе тоже есть, но она корреляционная и не про пилотов. Прямых данных «автоматизация кабины → рост потребления» я не нашёл. Это по-прежнему гипотеза, и честно называть её гипотезой важнее, чем закончить повествование на красивой мажорной ноте. Да и свести всё к финалу, в котором из офиса вытаскивают разработчиков, каким-то образом туда проникших пьяными либо «пронёсших на работу бутылку» и пытавшихся писать код навеселе, — такой цели у меня не было.
Это вообще не главный посыл, а лишь индикатор, триггер, привлёкший внимание и создавший начальное обобщение. Алкоголь — крайняя точка шкалы, на которой куда раньше стоят скука, расфокус, прокрастинация и незаметная утрата навыка. Они и будут массовым проявлением, а не «запойные коммиты». Главное в другом: конфигурация «машина работает — человек смотрит» уже описана, измерена и имеет известные последствия, а мы входим в неё, не заглянув в чужой отчёт.
7. Где аналогия сходится под натиском фактов, а где нет
Сходится:
Смена роли с исполнителя на супервизора — идентична.
Асимметрия обязательств: усилия падают, обязательства нет.
Надёжность порождает доверие, а доверие — снятие проверки.
Не сходится (пока что) — и это важнее:
Цена ошибки. У пилота она мгновенная и необратимая. У разработчика — отложенная и обычно исправимая. Значит, complacency у нас не даёт громких катастроф, а копится тихо: техдолг, уязвимости, код, который никто не держит в голове. Хуже заметно — хуже регулируется.
Частота отказов. Автопилот отказывает крайне редко — и это, по данным NASA, худший режим: постоянная высокая надёжность и порождает complacency. LLM пока ошибается часто и заметно, то есть работает в вариативном режиме, который защищает внимание. Отсюда контринтуитивный вывод: опасная зона наступит не сейчас, а когда модели станут «почти всегда правы».
Регулятор. В авиации есть FAA, обязательные чек-листы, понимание самой проблемы. В разработке нет ничего — ни нормы, ни языка для описания проблемы.
8. Кто и зачем спускает это сверху
Отдельный вопрос — откуда в IT берутся такие программы (столько-то/столько-то/столько-то). Публичная формулировка всегда одна: ускорить разработку и сократить time-to-market. Но в том же релизе Яндекса есть фраза (не только лукавая, невежественная, но и в долгосрочном смысле деструктивная), которая говорит больше остального: команды с глубоким использованием ИИ «эффективнее работают теми же силами». В переводе на язык бюджета это означает больше выпуска на тот же фонд оплаты труда — то есть снижение стоимости единицы результата. Дальше выбор между «нанять меньше» и «выпустить больше» делает не технология, а финансовая модель.
Оговорюсь честно: прямых заявлений о сокращении ФОТ ни в одном известном мне релизе нет, и я не приписываю их компаниям. Но экономический смысл инициативы не нужно домысливать — он и есть содержание слова «эффективность». Конкурентное давление при этом реальное: компания, которая не внедряет ИИ, платит за это тоже.
Что здесь по-настоящему показательно — это выбор метрики. Доля сгенерированного кода измеряется мгновенно, красиво выглядит в квартальном отчёте и попадает в презентацию для инвесторов. Сохранность навыков, качество внимания при ревью или при разработке критичных компонентов системы, накопленная сложность, удержание людей — измеряются годами и не ложатся в квартал. Ставят ту цель, которую можно предъявить к сроку выплаты бонуса.
Здесь уместен Альфи Кон и его «Парадокс мотивации» — писал о ней некоторое время назад. Центральный тезис: награда работает, но производит лишь временное послушание, а не изменение по существу. Внешнее вознаграждение вытесняет внутреннюю мотивацию и заодно избавляет от необходимости разбираться в причинах. И там же — то, что прямо описывает нынешнюю ситуацию: организации готовы относить кадровые потери к производственным издержкам, без которых, по их мнению, не бывает сверх-заработка. Прибыль — главная метрика, всё остальное — накладные расходы.
Кон писал про школьные оценки и системы стимулирования персонала, но конструкция переносится вверх без изменений: топ-менеджмент, которым десятилетиями управляют через бонус, перестаёт различать цель и её индикатор. Это не глупость и не цинизм, а профессиональная деформация ровно того типа, который Кон описывает: длительное пребывание во внешней мотивации сужает горизонт до следующей выплаты.
Дальше механизм замыкается на второй круг. Когда доля ИИ-кода спускается вниз как KPI, разработчик получает внешнее вознаграждение за то, что раньше делал по внутренним причинам, — надёжный способ убить внутреннюю мотивацию. А вовлечённость, по данным из раздела 6, и есть главный защитный ресурс против complacency. Способ внедрения бьёт по тому самому, что защищало бы от последствий внедрения.
9. Что, на мой взгляд, стоит сделать
Явно определить новый облик профессии — там, где он уже сложился. Человек, который ставит задачу агенту, читает дифф и решает, годится ли результат, — уже часто не инженер-разработчик в прежнем смысле, а оператор автоматизированной системы. Это не понижение: в авиации это отдельная специальность со своей подготовкой, нормами и набором отказов. У нас она не названа — значит, ей не учат, под неё не нанимают и её не оценивают корретным образом. Пока названия нет, все делают вид, что профессия прежняя, просто «с ускорением».
Корректировать оценки вниз. Если экономия усилий не конвертируется в сроки, она конвертируется в простой — а простой и есть топливо для всего описанного выше.
«Летать руками». Держать долю задач, которые пишутся без агента. Не из принципа, а как FAA: чтобы навык не ушёл к моменту, когда он понадобится.
Ломать постоянную надёжность искусственно. Обязательное чтение diff, тесты, написанные до генерации, adversarial-ревью (не утверждай слепо, попробуй доказать). Проверка не должна зависеть от того, «выглядит ли правдоподобно».
Возвращать вовлечённость выше по стеку — в декомпозицию, архитектуру, постановку задач. Мониторинг без содержательной работы рядом — это вигилянтность, а она изматывает сильнее, чем кажется.
Смотреть на ранние индикаторы: скука, прокрастинация, ощущение бессмысленности, рост «фонового» потребления чего угодно. В авиации это не считалось симптомом автоматизации сорок лет.
Не превращать долю ИИ-кода в KPI сотрудника. Как метрика адаптации она допустима, как цель — нет: по Кону это гарантированный способ обменять внутреннюю мотивацию на временное послушание. Мерить стоит результат — инциденты, время до восстановления, удержание, — а не долю сгенерированных строк.
10. Заключение
Ничего из перечисленного не является гарантированным предсказанием катастрофы. Но думать про это нужно начинать «ещё вчера». Аналогия с пилотами — лишь повод, но не приговор: часть связей в ней подтверждена данными, часть остаётся гипотезой и моей субъективной склонностью к поиску метафор.
Автоматизация труда разработчика обсуждается сегодня исключительно в контексте KPI («75/75/75» и его аналоги). В редких личных беседах встречаются и вполне откровенные постановки целей вида «автоматизировать 40%, сократить 30%». И то, и другое — метрики входа. Метрик того, что происходит с человеком в долгосрочной перспективе под давлением этих целей — сохранность навыка, долгосрочная мотивация и вовлечённость, качество внимания при ревью или при разработке критичных компонентов системы — не видно ни у кого. Мы измеряем ровно то, что и авиация в 1970-х: сколько работы забрала машина. Про остальное авиация узнала позже и заплатила за это сильно дороже.
Разница в том, что у нас есть их отчёт — как принято говорить, «написанный кровью». Automation-induced complacency описан, измерен и снабжён контрмерами — обязательное ручное пилотирование, чек-листы, тренировка мониторинга. Всё это придумано не для нас, но подходит нам почти без переделки.
Стоит хотя бы поставить вопрос до того, как появяься серьёзные последствия: если 75% кода пишет модель, то чем именно заняты те восемь часов, которые человек обязан провести в кресле, — и что мы собираемся с этим делать?
Источники
Prinzel L. J., DeVries H., Freeman F. G., Mikulka P. Examination of Automation-Induced Complacency and Individual Difference Variates. NASA/TM-2001-211413, декабрь 2001. — https://ntrs.nasa.gov/api/citations/20020021642/downloads/20020021642.pdf
Parasuraman R., Manzey D. H. Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors, 2010. — https://journals.sagepub.com/doi/10.1177/0018720810376055
METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, июль 2025. — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ (препринт: https://arxiv.org/abs/2507.09089)
PARC/CAST Flight Deck Automation Working Group. Operational Use of Flight Path Management Systems, сентябрь 2013 (28 находок, 18 рекомендаций). — https://skybrary.aero/articles/operational-use-flight-path-management-systems
Kosmyna N. et al. Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. MIT Media Lab, 2025, препринт, не прошёл рецензирование. — https://arxiv.org/abs/2506.08872
DORA / Google Cloud. State of AI-assisted Software Development 2025. — https://dora.dev/dora-report-2025/
Яндекс запускает программу 75/75/75 для ускорения разработки с помощью ИИ. Пресс-релиз компании «Яндекс», 29 июля 2026. — https://yandex.ru/company/news/29-07-2026-01 (дубль для инвесторов: https://ir.yandex.ru/press-releases?year=2026&id=29-07-2026-01)
Кон А. Парадокс мотивации (Alfie Kohn, Punished by Rewards, 1993). Мой разбор книги. — https://habr.com/ru/articles/934040/
Данные FAA по случайному тестированию на алкоголь за 2023 год (доля нарушений 0,141%). — https://www.federalregister.gov/documents/2024/11/04/2024-25569/random-drug-and-alcohol-testing-percentage-rates-of-covered-aviation-employees-for-the-period-of
Хронология автоматизации кабины: Sperry 1914 → autoland 1965 → FMS → glass cockpit. — https://www.aerotime.aero/articles/autopilot-flight-automation-history
Оценки доли ручного пилотирования на рейсе. — https://johnnyjet.com/ask-a-pilot-how-much-hands-on-flying-do-pilots-do/ (величина ориентировочная: единой отраслевой метрики не существует, цифры приводятся по опросам линейных пилотов)
Brown W. C. et al. Negative Affect Mediates the Relationship Between Boredom Proneness and Posttreatment Alcohol Use Problems, 2026. — https://journals.sagepub.com/doi/10.1177/00332941261436752
Видео, с которого начался этот текст. — https://youtu.be/nvTVDzg2rZ8
Bhana H. Correlating Boredom Proneness and Automation Complacency in Modern Airline Pilots, 2010 (опрос 273 линейных пилотов). — https://ojs.library.okstate.edu/osu/index.php/CARI/article/view/7511/6912
О сокращении экипажа и исчезновении бортинженера: решение FAA по Boeing 767 (июль 1981) и выводы президентской комиссии по составу экипажа. — https://www.key.aero/article/how-technology-led-demise-flight-engineer
