Сразу предупрежу: я патологически люблю аналогии и метафоры. Некоторые коллеги за это меня недолюбливают — на планировании, где все обсуждают сроки, я могу иногда сообщить, что мы строим не мост, а понтонную переправу. Такая встреча легко продлевается на лишние двадцать минут.
Рад бы исправиться и всегда отвечать, как 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% кода пишет модель, то чем именно заняты те восемь часов, которые человек обязан провести в кресле, — и что мы собираемся с этим делать?
Комментарии (52)
2tlin
08.08.2026 15:25Да, писать код руками уже не нужно, но читать сгенерированный код намного труднее, особенно, учитывая объем и скорость генерации новых вариантов. Плюс "в декомпозицию, архитектуру, постановку задач", так что когнитивная нагрузка выросла очень сильно. В какой-то мере удовольствия от работы стало меньше, а ответственность никто не отменял. Работа меняется, конечно, и я не уверен, что в лучшую сторону для самих разработчиков.
juks Автор
08.08.2026 15:25Лично мне представляется так, что любой код, который написал не сам, в целом читать непросто. Читать код, про который известно, что он «бездонный» — ещё сложнее.
Я уверен, что способность понимать чужой код в принципе — одна из лучших демонстраций высоких когнитивных способностей разработчика. Могут это в реальности далеко не все, неумение можно плюс-минус умело скрывать. На реальное понимание чужого кода расходуется много энергии. Выполнение такой задачи можно считать одной из характеристик внутреннего «контекстного окна» конкретного инженера.
Но и про чтение кода, кстати, уже было: https://habr.com/ru/news/1062634.
wiki7979
08.08.2026 15:25Статья правильная и я бы мог наверно добавить пару мыслей, но воздержусь по двум причинам: 1. Они не полностью оформились. 2. На всякий изложенный аргумент эксплуататор со временем найдёт удобный контраргумент.
Oeaoo
08.08.2026 15:25Какая-то метафора слишком уж упрощающая. Есть риск уверовать в то, что каждое "подруливание" ИИ в разработке так же просто и верифицируемо как сверка курса по приборам. В разработке зачастую ни измерений четких нет, ни курса, многое нужно придумывать первый раз и обратная связь будет не пойми какая и когда. Короче, имхо метафорой творческой работы не должна быть механическая.
juks Автор
08.08.2026 15:25Метафора упрощающая, да. Но я предлагаю сфокусироваться именно вокруг «ожидания» результата автоматизированного процесса и оценки результативности. Можно упростить ещё больше, до максимума и предложить пример «до LLM»: огромный релизный пайплайн, который порой может работать часами. Все зависит от конкретного психотипа человека, но далеко не каждый способен в такое время «шедулить» себе другую задачу и переключаться на неё. Большинство людей, как мне видится, начинают как бы маяться.
Мотивации описать всё это добавила та самая разработка с Клодом. При составлении плана он, хоть я его и не просил, выдал оценку сложности выполнения задачи. Вместо реальной для себя оценки в один час, он выдал «социально приемлемые» 10-15 дней.
ShIV03
08.08.2026 15:25"пилоты, рядом с автопилотами" (людишки - "операторы", рядом с AI - "Разработчиками") - принято.
А вот "Что делать" - не понравилось ("что делать на сидячей работе". Т.е. только о деградации разработчика).
1. Автопилот - для надежности полетов (пассажиров - в гражданской авиации; и в военной - для повышения дальности, ...).Т.е. пилот - знает, на что идет (я про ответственность. Она, через нормы, заставляет включать автопилот, на ровном участке).
Как и местный врач-терапевт (кучу лет - проучившийся, набравшийся практики) - знает, что "изо дня, в день ...".
2. Вот у них - есть многолетние наработки "Как поддерживать форму" (фраза не подходит к врачам, но парна предыдущей).
Но и у них - "позаботься о себе сам".
3. Если предположить, что ("в дАлекой-дАлекой галактике") программисты (как "прослойка") станут не нужны. То и "вопрос - снят".
Программисты - останутся, но не в виде прослойки (пользователь - сам сможет договориться с AI. я не про современную LLM).juks Автор
08.08.2026 15:25Не могу, к сожалению, разобрать и ответить на все пункты.
Но могу поделиться мнением по одному: c работы, где нет реального импакта, развития, но есть только эмуляция, «сидение в кабине встреч», тягомотина и перетягивание каната — лучше уходить.
Lizdroz
08.08.2026 15:25Прикольное сравнение с авиацией, но забыто главное отличие : пилот не может переписывать архитектуру самолета прямо в полете, а разработчик именно это и делает, пока ИИ пишет бойлерплейт
juks Автор
08.08.2026 15:25Спасибо за напоминание!
А то только и слышно: «тут нужно архитектора нанимать», «я не архитектор» и «это пусть тестировщики тестируют».
ruomserg
08.08.2026 15:25Да, и еще раз - да! Мы ровно идем по тому пути как коммерческая авиация. Сейчас у нас фаза когда рекомендацией является достижение максимальной автоматизации на всех этапах полета. Надо очень больно несколько раз убиться об стену, чтобы пришло понимание что нельзя сидеть на двух стульях:
Либо вы перекладываете ответственность за код в продакшене на LLM - и тогда можете автоматизировать все как хотите, но в случае падения - не тыркайте разработчиков, а пишите жалобу авторам модели: Антропик, OpenAI, а лучше сразу в спортлото. Ибо антропику и OpenAI ваш продакшен нахрен не сдался...
Либо вы сохраняете ответственность за код на разработчиках, но тогда вся цепочка SDLC должна быть выстроена вокруг человека в контуре, чтобы он сохранял situational awareness.
Ровно из авиционного опыта я категорически не рекомендую сколько-нибудь значимую и критичную систему разрабатывать методами SDD, вайб-кодинга, и проч. Потому что итогом будет штопор и полный рот земли. Этот запрет, кстати, не препятствует использованию ИИ и получению выгод от его использования - но разработчик должен его использовать как инструмент. А менеджмент - принимать меры чтобы ИИ не выходил за разумные рамки использования.
К сожалению, средний менеджер глуп и ленив. Он спит и видит - как бы установить какие-нибудь KPI, и потом уже ничего не делать, а только получать бонусы за результат. Отсюда вся вот эта ересь 75/75/75... :-(
Из положительного - отметим оплату за токены которую ввели уже почти все. В эпоху почти-бесплатных токенов менеджеры были невыносимы! Сейчас хотя бы на языке денег можно им объяснить какую глупость они совершают...
juks Автор
08.08.2026 15:25Отдельно, кстати, интересна мотивация анонсирования 75/75/75 наружу.
Можно снова провести параллель с авиакомпаниями, для которых это прежде всего заверение пассажирам о повышении уровня безопасности и снижения человеческого фактора. Конечно, говорят и про снижение нагрузки на пилотов. Но что тут хочет сказать ИТ-компания?В 2020 году Airbus сообщил о завершении проекта Autonomous Taxi, Take-Off & Landing (ATTOL).
Один из анонсов Boeing: Key 737 MAX upgrade to ease pilot workload
ruomserg
08.08.2026 15:25Тщеславие менеджерам тоже не чуждо! :-) Их распирает похвастаться чем-то на публику. Мы же ходим на инженерские конференции, и там вещаем про свои инженерские достижения... А у этих еще и акционеры, которых надо впечатлить!
Вообще мы должны благодарить создателя за то, что у нас головной болью является Antropic и OpenAI вместе с матрицами на GPU! Потому что на их месте мог быть какой-нибудь биохакинг-стартап, который внезапно обнаружил что съевший утром ложку говна разработчик работает 10x быстрее! И я вас уверяю, что дальше бы последовала та же самая рыночная шиза - неизбежно появились бы те, у кого эффект, к сожалению, чисто статистически подтвердился. Потом менеджеры начали бы кормить разрабов говном просто из боязни остать от прогресса. А вокруг них бы собрался круг подпевал, которые вообще поддерживают любую дурь начальника если это обещает рост по службе и бонусы... Потом инвесторы встрепенулись: все уже едят говно ложками, а наши разработчики - еще нет!
И в этой параллельной вселенной лозунг Яндекса: 75% разработчиков будут съедать 75% говна чтобы работать на 75% быстрее - мне нравится сильно меньше...
LinkToOS
08.08.2026 15:25Задача, которая стоила десять дней, по-прежнему стоит десять дней, но внутри этих десяти дней у человека появились паузы: ютуб, сигареты, восемь походов на кофепоинт, да что угодно — в ожидании, когда агент допишет большую фичу и прогонит тесты.
Удивительное совпадение. Как так совпало, что автоматическая разработка оказалась по скорости равна ручной? Коллективный сговор на всех уровнях?
В авиации все понятно - скорость соответствует оптимальному режиму эксплуатации самолета, и не связана с ограниченными возможностями живого пилота. Замена человека на автоматику не влияет на скорость и время полета.
cArmius
08.08.2026 15:25Все всегда знали (но почему-то забыли), что в реальной разработке написание кода никогда и не являлось узким горлышком.
Вот цепочка релизов у разных подразделений, разбор инцидентов, попытка выцепить архитектора для обсуждения (и даже не согласования) какой-нибудь нетипичной штуки...
juks Автор
08.08.2026 15:25попытка выцепить архитектора для обсуждения
Вот про это немного выше упоминалось. Того, кому нужен архитектор для принятия или разработки архитектурных решений — того автоматизация вытеснит одним из первых.
Конечно, такая потребность вовсе не означает ограничения собственных способностей. Часто она диктуется культурой организации. Но для профессионального долгосрочного развития это опасно.
juks Автор
08.08.2026 15:25Есть такой анектот про электрический стул и «мотивации нет».
У наёмного разработчика в большинстве случаев нет мотивации обрабатывать x10 контекстных сигналов и принимать x10 решений. У него чаще мотивация: сделать работу проще и быстрее, не платить за подписку, но чтобы заплатила компания. Это путь в никуда.
Думаю, сейчас такое время, когда особенно крепко стоит подумать: тянуть лямку 1000 неподъёмных легаси микро-сервисов в полуживой компании за зарплату или рискнуть сделать что-то своё?
В руках человека с опытом стратегического мышления, переключения и работы в режиме постоянной неопределённости без непосредственного контроля — LLM дают совершенно другой результат.
juks Автор
08.08.2026 15:25Упрощу ещё: реально существует такой сценарий, при котором нет (условных) 5 миллионов в месяц на ФОТ, чтобы нанять десять разработчиков, но есть 200 долларов, чтобы нанять 10 агентов.
Так вот в определённых руках, приделанных к определённым умам, при создании новых проектов это работает просто отлично.
JediPhilosopher
08.08.2026 15:25Вопрос только в том, какая ценность в вашем сервисе, сделанном за 200 долларов? Кому он нужен, если каждый сможет себе сделать такой же?
Польза раньше пряталась или в экспертизе (вы обладаете уникальным знанием и умеете делать то, что другие не умеют), или в масштабах (вы вкладывали в код и набитые шишки годы времени и вагоны денег, невозможно сделать конкурента не вложив столько же). С приходом ИИ оба этих пункта обесцениваются. Проекты станет легче создавать, но именно поэтому и ценность их будет падать, как и возможность с них заработать что-то большее чем вернуть те самые 200 баксов за потраченные токены
ToSHiC
08.08.2026 15:25Вы описали какого-то достаточно ленивого разработчика, которому на самом деле не очень то интересно писать код. Такому разработчику лучше стоит задуматься о том, а чем ему на самом деле интересно заниматься.
У разработчиков же, которым правда нравится быть инженерами, проблема иного характера: они становятся по сути руководителями группы агентов, которые не ноют и готовы работать без перерывов и сна, пока есть квота. И вот у таких сильных разработчиков как раз противоположная проблема: AI-горячка. Они начинают постоянно смотреть, как там агенты, не надо ли им
дровишекзадач подкинуть новых, используют всякие claude remote, и т.д., ну и начинают выгорать. У них, естественно, производительность становится кратно выше.juks Автор
08.08.2026 15:25Вы описали какого-то достаточно ленивого разработчика
Это собирательный образ из реального опыта взаимодействия и руководства. В нём есть ещё такое явление, как «слева IDE, справа Youtube». Проблематику «уволился из Яндекса, вышел в другую компанию, а там подписку не оплачивают. Самому что ли покупать придётся?» тоже доводится слышать.
И вот у таких сильных разработчиков как раз противоположная проблема: AI-горячка. Они начинают постоянно смотреть, как там агенты, не надо ли им
дровишекзадач подкинуть новых, используют всякие claude remote, и т.д., ну и начинают выгоратьПолностью поддерживаю. Возможно, у меня плохой кругозор или кривая выборка, но таких в моём представлении единицы.
Своего рода эффект: я вкладываю силы — оно едет, вкладываю ещё больше — едет ещё быстрее, вкладываю сколько есть.
xSVPx
08.08.2026 15:25Достаточно поиграв в dwarf fortress я вполне осознаю, что быть нянькой смотрящей за толпой имбецилов с суициидальными наклонностями - совершенно не то, чем лично мне хотелось бы заниматься.
И не только мне.
И это со временем перерастет для бизнеса в огромную проблему.
Нельзя просто так взять и заставить инженеров менять подгузники, можете легко без инженеров вовсе остаться.
LeVoN_CCCP
08.08.2026 15:25в буквальном смысле пишет за разработчика код, разрабатывает архитектуру решений — и делает это невероятно быстро и чуть ли не с каждым месяцем всё более точно
Я регулярно пытаюсь посмотреть, что всякие ИИ пишут с т.з. SQL, и могу сказать, что более точно не становится - всё та же шляпа, которая работать будет, но плохо. Так что я бы сказал, что это не ИИ развивается для тех кто её постянно использует, свалив всё на неё.
juks Автор
08.08.2026 15:25Тут лучше привести примеры: какие конкретно модели, какие задачи и каков критерий «плохо».
Есть некоторые сомнения, что в деле «перекладывания джейсонов», одной из ключевых задач большинства интернет-проектов, модели справляются очень неплохо.LeVoN_CCCP
08.08.2026 15:25Раньше смотрел чатжпт, дипсик, копилот и ещё что-то редкое, со временем количество уменьшил просто потому что они развиваются примерно одинаково.
Критерии… С этим мне будет сложней объяснить, потому что когда видишь код, видно где и почему будет работать плохо (исключение когда возможно объяснить почему именно так сделали). Это примерно как я смотрел 1С работает с МС СКЛ.
Попробую сгенерировать пример - нужно для пользователя сгенерировать все его задачи, всё дерево подчинённых с их задачами, посчитать среднее время выполнения при определённом статусе, количество текущих открытых, и ближайший срок выполнения одной из задач. Это фактически один запрос, который оптимизатор МС ещё в 2014 научился справляться как лучше строить план, в котором будет пяток оконных функций и группировка с небольшим деревом. Что сделает ИИ - как минимум 3-4 темповских таблицы куда сложит нужное и скорее всего пятую куда сложит результат, который потом покажет.
Не могу оценить “перекладывание джейсонов” с т.з. программирования, только знаю что это “ширпотреб”. Однако и в “ширпотребе” SQL можно таких дров нарубить, с чем ИИ справляется по умолчанию. Если раньше я мог сказать ускорил запрос с 4-х минут до 1.5 на 2ТБ базе (основано на реальном случае), то теперь я говорю, что преобразовал процесс с запросами выполняющийся 2 часа в 20-25секунд, или запрос выполняющийся 3.5 часа в 1м15-30сек. Правда первый процесс не был написан ИИ (просто потому что древний), но уши опознаются, а второй точно был написан с использованием.
juks Автор
08.08.2026 15:25Что сделает ИИ - как минимум 3-4 темповских таблицы куда сложит нужное и скорее всего пятую куда сложит результат, который потом покажет
Думаю, это заслуживает свежего эксперимента с Opus 5, например, и запросом на контроль эффективности плана и задела на большой датасет
Hlad
08.08.2026 15:25Забавно, что применена метафора с самолётами, хотя корректнее была бы метафора с поездами. Там тоже уже довольно долго есть автоведение. И точно так же основная задача машинистов - нести ответственность. И значительная часть локомотивного оборудования тупо следит, чтобы машинист не спал...
Dhwtj
Пропал Яндекс: теперь доверие к его продуктам упало до нуля
Вопрос без подколки: авиа пилоты теперь эффективнее работают теми же силами? В каких метриках?
Ну и аналог с самолётами так себе. В энтерпрайз да, в менее ответственных секторах нет.
MountainGoat
Собственно да, работа пилота сейчас в том, чтобы быть готовым отреагировать на внештатные ситуации в ту же секунду, а так самолёт практически сам летит. Что интересно, общение с землёй до сих пор происходит голосом, хотя уж выдачу разрешений автоматике по радио куда уж проще организовать. Между собой самолёты общаются уже по цифре, обмениваясь координатами и перепроверяя курсы, а с землёй - голосом. Маршруты тоже задаются вручную, хотя казалось бы автоматизация карт - вопрос давно решённый. И в таких решениях немало политики.
В то же время, пока ещё не было случая, чтобы большой самолёт сам успешно приземлился без пилота или при помощи случайного человека. (Тот случай с Караваном не в счёт: Караван ещё не лайнер, да и человек был не случайный).
Сравните это с лайнерами 60-х, у которых была позитивная обратная связь на уход с курса, то есть чем больше он отклонялся, тем быстрее его дальше отклоняло, и его весь полёт нужно было руками поправлять.
RulenBagdasis
Только тут имеется 2 проблемы:
У пилотов теряются навыки.
Большинство внештатных ситуаций, как следствие, создают сами пилоты.
Современные лайнеры между современными аэропортами должны летать на полном автопилоте. Собственно, они уже пару десятилетий как могут это делать, проблема в страхе и в профсоюзах.
konst90
А современный аэропорт закрылся по метео, и надо уходить на запасной, где системы нет. Или пассажиру стало плохо, и надо срочно садиться. Или птица в двигатель попала, и надо сесть в кукурузу.
Вот ради этих редких случаев пилотов и держат.
xSVPx
Тут надо четко понимать с цифрами в руках.
Скольких спасли верные действия пилотов и не спасла бы автоматика.
Скольктх угробили неверные действия пилотов и спасла бы автоматика.
Без этих цифр оценивать нечего.
juks Автор
Где бы эти цифры ещё взять, так чтобы собирающие их профессионалы не старались угодить заказчику, как это было, например, со статистическими доводами о пользе бокальчика красного вина каждый день
konst90
Я не думаю, что эти цифры в принципе возможно получить.
xSVPx
Ну почему же. Когда компания А перейдет на полный автомат, со временем они наберутся.
Для начала, уверен, переведут транспортники, их не так жалко.
Но, похоже, пока еще рановато. Может и время, но лет пять потребуют только согласования всего этого.
Хотя, я тут скептик, вопрос не в технической плоскости совершенно, а в какой-то адской импотенции современной авиации. Читаешь что они там уже понавертели и волосы на башке шевелятся.
konst90
Неа. Наберётся только статистика по числу инцидентов разного уровня на миллион километров. А вот достоверно определить, смогла бы автоматика или смог бы человек в каждом конкретном инциденте "конкурента", уже не получится. Да и грань между "пилоты спасли" и "автоматика делала бы так, что спасать и не надо было" - и наоборот - весьма тонка. Условно, пилоты молодцы что при посадке в СМУ чудом вытянули самолет на глиссаду после сдвига ветра, а автоматика бы вообще в СМУ не пыталась сажать и увела бы борт на запасной аэродром.
xSVPx
Так эта статистика и даст четкий ответ что из всего этого безопасней.
Но её надо еще как-то набрать, а для этого нужны сотни тысяч полетов.
JediPhilosopher
Не должны. Это было долгое время популярная идея, что чем меньше пилоты рулят руками — тем безопаснее. Но ряд катастроф и почти‑катастроф, когда в сравнительно простых нештатных ситуациях при отказе автопилота пилоты гробили самолет, потому что разучились летать руками, показали что это не так. Навык который регулярно не тренируется — атрофируется, и это неизбежно и никакими тренажерами не компенсируется. И в первой же ситуации, когда автоматика отказывает, пилоты (которые ради этого и сидят в кабине) внезапно тоже не справляются.
Поэтому теперь рекомендации ИКАО и многих международных организаций другие — как можно чаще практиковать ручное пилотирование и поддерживать навыки.
У Оканя на эту тему был в блоге хороший пример. Известная катастрофа Суперджета в Шереметьево: попадание молнии, отказ автопилота, пилоты не смогли выполнить посадку в полностью ручном режиме — угробили самолет. После этого были сделаны выводы, те самые, про пользу навыка ручного управления. И были доработаны методики подготовки конкретно на этом типе в российских АК. Несколько лет спустя, Суперджет в Пулково, отказ всех систем автопилота (и основных и резервных), переход в ручной режим. Пилоты благополучно вернулись в аэропорт вылета и посадили самолет без проблем, это даже в новости не попало. Потому что опыт у них уже был благодаря изменившейся методике и подходу.
Как говорится, у любой технически сложной проблемы существует очевидное неправильное решение. Решение максимально исключить ручное управление в авиации ради безопасности похоже как раз из таких.
Freeman_RU
Вбейте в поисковик "autoland system", удивитесь
MountainGoat
Beechcraft King Air кажется ещё меньше Каравана.
juks Автор
Думается, не так просто единоличному или коллективному органу взять на себя ответственность и полностью обрезать эту нить общения.
Могу только предположить: голосовые коммуникации, спокойствие в голосе диспетчера - многое значат для пилотов.
Lizdroz
Нить общения не обрезают просто потому, что переоборудование всех старых диспетчерских вышек стоит космических денег, а вовсе не ради психологического комфорта
juks Автор
В тех же пресловутых видео на Юрубе есть примеры, когда неадекватная кондиция пилота определяется как раз по радиообмену в процессе руления на взлёт.
juks Автор
В случае с автоматизацией работы пилотов, главный постулируемый публичный слоган, все же, — безопасность и жизни пассажиров. Это сильно развязывает руки. История с экономией и экономикой где-то остаётся внутри.
В деле «ускорения» и оптимизации разработчиков всё иначе.
Меня интересует именно проблематика переходного периода, происходящее с людьми, которые 90% смены не управляют и не программируют, но только наблюдают. Выглядит так, что в обоих случаях есть серьёзные проблемы, про которые предпочитают не думать. В разработке — точно.
Тезис про потерю навыков, которая создаёт отрицательную обратную связь, приводящую к авариям — в целом верный, но не всегда. Здесь мы, кроме прочего, не учитываем массу процессов и мероприятий, направленных в авиации на контроль и аттестацию.
И взять, например, истории катастроф Boeing 737 MAX, когда скрытая, незадокументированная автоматика пыталась скрыть конструктивный дефект. Тот самый случай «двух минут», когда лётчики должны были резко перейти из состояния наблюдателей и бороться с автопилотом через штурвал.
Это явным пример обратной логики: бонусная мотивация, требующая костылить ошибки автоматизацией и кодом, убила людей.
Lizdroz
Главный слоган ИИ в разработке - как сделать так, чтобы сеньор делал работу трех мидлов за одну зарплату)
juks Автор
Главный фактор: у сеньора добровольного желания на это нет. Большинство разработчиков думают о двух вещах: как выполнить неделю за день и как самому не платить за подписку на Клод.
Реально и добровольно выигрывают те, кто делает собственный продукт и «программирующие менеджеры».
konst90
Скорее, столь же эффектно работают меньшими силами. Раньше для выполнения одного рейса нужно было пять человек (КВС, второй пилот, штурман, бортинженер, радист), теперь достаточно двух. В принципе, и одного достаточно, но резервирование считается более важным.
juks Автор
Это тоже интересный момент! В контексте видео, приведённого в качестве примера: именно так и решил КВС, видя второго пилота вдрабадан пьяным. И, вероятно, это расхожее мнение.
Ведь он его не сдал (как можно сдать, если и выпивали вместе), сдали пассажиры и кто-то ещё, почуяв запах спиртного.
juks Автор
Кстати, интересно и то, что одного пьяного из двух пилотов автоматического самолёта вытряхивают, проверяют визуально на опьянение и задерживают ровно так же, как достали из-за руля пьяного Джастина Тимберлейка.
Lizdroz
У пилотов эффективность измеряется снижением аварийности на миллион часов налета и экономией топлива за счет идеальных расчетов глиссады автопилотом
juks Автор
Плюс автомат тяги