Сразу предупрежу: я патологически люблю аналогии и метафоры. Некоторые коллеги за это меня недолюбливают — на планировании, где все обсуждают сроки, я могу иногда сообщить, что мы строим не мост, а понтонную переправу. Такая встреча легко продлевается на лишние двадцать минут.
Рад бы исправиться и всегда отвечать, как 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% кода пишет модель, то чем именно заняты те восемь часов, которые человек обязан провести в кресле, — и что мы собираемся с этим делать?
Комментарии (91)
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попытка выцепить архитектора для обсуждения
Вот про это немного выше упоминалось. Того, кому нужен архитектор для принятия или разработки архитектурных решений — того автоматизация вытеснит одним из первых.
Конечно, такая потребность вовсе не означает ограничения собственных способностей. Часто она диктуется культурой организации. Но для профессионального долгосрочного развития это опасно.
xSVPx
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 баксов за потраченные токены
juks Автор
08.08.2026 15:25Вопрос только в том, какая ценность в вашем сервисе, сделанном за 200 долларов? Кому он нужен, если каждый сможет себе сделать такой же
Хороший и правильный вопрос! Ответ: посмотрим, время покажет.
Но у меня есть реальный опыт успеха людей, которых я знаю лично, которые на этих самых 200 долларах стартовали и добились успеха. Без этого у них физически ничего не получилось бы.
Но и личный навык управления в условиях неопределённости и непредсказуемости — важен.JediPhilosopher
08.08.2026 15:25И что они сделали? Я пока наблюдаю что на ИИ хайпе иногда быстро сляпанные агентами проекты хайпуют и взлетают, потому что угадывают момент. Но не становятся стабильным бизнесом, так как они легко повторяемы. Что сделал один за 200 баксов — сделает и другой. В итоге получаем в ИТ ситуацию как в мелком бизнесе с низким порогом входа: все сидят на крохотной марже и едва сводят концы с концами. Так как как только где‑то появляется более прибыльная ниша с большей маржинальностью — в нее тут же устремляется толпа, благодаря низким затратам на вход. И высокой конкуренцией роняют доходность обратно на уровень плинтуса.
Вижу что то же самое постепенно придет и в ИТ (уже приходит).
juks Автор
08.08.2026 15:25https://lolka.app/. На сайте есть ссылки на публикации о проекте.
Я смотрю на многие вещи через призму опыта инженера, который стал руководителем. Не хочу негативить и драматизировать, но:
- Современный ИТ-менеджемент в больших компаниях и коллективах очень схож с агентской разработкой (исторически и давно).
- Менеджер команды инженеров очень похож на менеджера команды агентов, у него для этого лучшая подготовка: он не сдаётся, держит фокус на важном, умеет переключать контекст 80 раз в день, «попинывает» и «допинывает», регулярно уточняет, систематизирует информацию в план, задаёт правильные вопросы, которые рушат текущее понимание, что всё в порядке.
- То, что вожделенно привлекает разработчиков в большие, успешные и сытые ИТ-компании: довольствие, комфорт, стабильность, супер-процессы, отложенный вестинг — в долгосрочной перспективе для большинства (не для всех) является путём деградации. Дорогой в один конец. Просто на физиологическом уровне.
- Сейчас самое время всем инженерам научиться мыслить стратегически, на дальнюю перспективу. Происходит решающий передел реальности, примерно такой же, как с появлением интернета.
Я верю, Яндекс не настолько упростился с уходом основателей. За красочным и местами глуповатым пресс-релизом стоит, возможно, пока только подсознательное понимание экзистенциальной угрозы. Суть её в том, что в самом ближайшем будущем победят команды-«киборги»: объединяющие способности опытных инженерных менеджеров, управляющих очень компактными командами инженеров (5-10 человек), в свою очередь управляющих тысячами агентов.
Раздутым-передутым аналитиками, архитекторами, тестировщиками, продактами, разработчиками всех видов, да кем попало, командам — не жить.
Выход: заранее стать частью коллектива новой формации, либо сделать свой продукт.
SideshowBob
08.08.2026 15:25Тут есть такой момент, что вот этот эффективный менеджмент, который призывает разрабов выдавать в 10 раз больше, ведь "даже я могу", на самом деле вряд ли хочет заниматься этим вместо разрабов. Так шта если такая конструкция наступит, как вы описали, то большей части менеджеров так же придется в утиль, ведь "кмпактной командой инженеров" управлять нужен один компактный менеджер тоже ) много не надо.
juks Автор
08.08.2026 15:25Который призывает разрабов выдавать в 10 раз больше, ведь "даже я могу", на самом деле вряд ли хочет заниматься этим вместо разрабов
Понимаю, разделяю.
Но лично для меня прерспектива создания команды из пяти, которая выдаёт, как команда из ста, так что при этом пропадает вся эта дейлик-рутинна «не мытьём, так катаньем» и вместо неё можно испытать счастье видеть конкретный результат от личного участия в разработке при большей ответственности — просто превосходная.
Уверен, через довольно короткое время команды так или иначе сократятся. И потерявшиеся разработчики будут проситься «пустить их под грибок», как в той детской сказки. А им будут отвечать: самим места мало.
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, например, и запросом на контроль эффективности плана и задела на большой датасет
Freeman_RU
08.08.2026 15:25просто потому что они развиваются примерно одинаково
И почему же я не верю, что вы как-то серьезно использовали ИИ и писали нормальный промт, со всеми ограничениями.
что преобразовал процесс с запросами выполняющийся 2 часа в 20-25секунд
У меня ровно обратная история - ИИ пишет оптимизированные запрос. Важный нюанс - только при учёте, что вы ему дали схема базы, дали версию БД и задали четкие рамки что именно надо оптимизировать.
Попробую сгенерировать пример
Дайте для примера реальную схему ваших данных, мне даже интересно как с ней ИИ справится.
LeVoN_CCCP
08.08.2026 15:25И почему же я не верю, что вы как-то серьезно использовали ИИ и писали нормальный промт, со всеми ограничениями.
Этому может быть много причин. Со своей стороны предположу, что примерно по тому же - я предпочитаю потратить время на то чтобы сделать быстро самому чем описывать-проверять-править-описывать-проверять-править и так по кругу. Промт именно описанный. Для примера у меня немного поднялась бровь, когда я прочитал комментом выше, что “эффективность плана и задел на большой датасет” надо описывать отдельно, то есть когда надо обговаривать “не тяп-ляп на коленке” и это не подразумевается по-умолчанию
У меня ровно обратная история - ИИ пишет оптимизированные запрос.
Важный нюанс - только при учёте, что вы ему дали схема базы, дали версию БД и задали четкие рамки что именно надо оптимизировать.
Наверное я из староверов, кто считает, что сами данные должны храниться исключительно локально в полностью подконтрольном тебе месте, а не где-то в облаках и прочих виртуалках хостера под честным словом агримента. Но нет, пожалуй даже схему данных я не буду шарить ИИ, хотя конечно же я верю честным словам, что мои запросы в ИИ никуда не сохраняются, не обрабатываются и уничтожаются после окончания сессии.
задали четкие рамки что именно надо оптимизировать.
Время выполнения запроса. Вот я без схемы могу сказать почему запрос отвратителен. Если же запрос сам по себе выглядит неплохо или не может быть отвратительным по умолчанию (простой инсерт) я могу предположить, что не так происходит со временем. То есть возвращаясь в ранний пример не нужна совсем схема для того чтоб вырезать темповские таблицы там где не нужны совсем, убрать фильтры функциями, убрать OR таблиц и другие весёлые вещи даже не зная схему.
Дайте для примера реальную схему ваших данных
Ладно, опустим за скобки, что я работаю с очень чувствительными данными (часть из них медицина), но Вы просите у ДБА дать реальную схему данных доступа к которым у Вас нет? :)
Freeman_RU
08.08.2026 15:25дать реальную схему данных
и
схему данных я не буду шарить ИИ
Во-первых, у вас выше было "сгенерировать пример", ни о каких живых данных речи вообще не было (слово "реальные" у меня было в том плане, что настоящую схему, а не на коленке абстрактное описание). Просто от схемы данных зависит вообще всё, если вы DBA, то странно вам такое объяснять. Второе, если схема данных у вас это что-то секретное, то у вас явно что-то не так с этой самой схемой. Ну есть у меня таблица "users" со столбцами "name", "email" и "phone", что из этого NDA?
Время выполнения запроса
не всегда время выполнения это есть цель. Иногда надо и память экономить, иногда диск, иногда сеть. А иногда и кол-во кода и переносимость между версиями SQL (а то и видами баз данных)
Но в общем-то примерно понятно, вы давали ИИ-шке абстрактные данные, и на абстрактных данных она вам давала абстрактные ответы :) Вполне логично :)
“не тяп-ляп на коленке” и это не подразумевается по-умолчанию
Вы удивитесь, но людям это тоже надо ставить как условие. Всегда и обязательно. Ибо человек вообще по умолчанию будет экономить в первую очередь самый важный для него ресурс - потраченное время.
juks Автор
08.08.2026 15:25Вы удивитесь, но людям это тоже надо ставить как условие. Всегда и обязательно. Ибо человек вообще по умолчанию будет экономить в первую очередь самый важный для него ресурс - потраченное время.
100%.
Успех нейронных сетей во много связан с двумя вещами: прорывными достижениями в области исследования физиологии человеческого мозга, анализом гигантского объёма данных вход-выход, полученного по результатам выполнения реальных задач.
juks Автор
08.08.2026 15:25Для примера у меня немного поднялась бровь, когда я прочитал комментом выше, что “эффективность плана и задел на большой датасет” надо описывать отдельно, то есть когда надо обговаривать “не тяп-ляп на коленке” и это не подразумевается по-умолчанию
Мне довелось создавать сотни задач для разработчиков, в разных культурах и трекерах.
Подобные постановки (проверить план, убедиться, что есть индексы под план, предусмотреть режим деградации, сделать инструментирование RED, самые разные «убедиться», «предусмотреть», «проверить») я пишу на автомате в течение многих лет, это не стоит мне видимых усилий, не воспринимается предосудительно и никогда не вызывало негативной реакции у команд. Это проявление уважения к коллегам, пример здоровой инженерной формулировки, несколько даже упрощённой под современную динамику. Я в буквальном смысле могу сам без какой-либо помощи и подготовки сделать с нуля декомпозированную задачу на серьёзный функционал за 10-20 минут. Добавить туда ссылки, источники данных (убедившись, что они валидны) и контакты нужных людей
И пишу я это именно в том буллет-строка формате, который не только удобно воспринимается людьми, в том числе беглым чтением по диагонали, но и идеально подходит и для промта.
Возможно, именно такое восприятие по-умолчанию и делает мой взгляд и оценку результата отличной от других. То есть я привык постоянно и на потоке, в режиме троттлинга внимания, аварий и размытого контекста обеспечивать потоковый результат нужного качества, чего бы это ни стоило.
Вероятно, это и есть преимущество менеджера, которое многократно умножается LLM.
Hlad
08.08.2026 15:25Забавно, что применена метафора с самолётами, хотя корректнее была бы метафора с поездами. Там тоже уже довольно долго есть автоведение. И точно так же основная задача машинистов - нести ответственность. И значительная часть локомотивного оборудования тупо следит, чтобы машинист не спал...
Dhwtj
Пропал Яндекс: теперь доверие к его продуктам упало до нуля
Вопрос без подколки: авиа пилоты теперь эффективнее работают теми же силами? В каких метриках?
Ну и аналог с самолётами так себе. В энтерпрайз да, в менее ответственных секторах нет.
MountainGoat
Собственно да, работа пилота сейчас в том, чтобы быть готовым отреагировать на внештатные ситуации в ту же секунду, а так самолёт практически сам летит. Что интересно, общение с землёй до сих пор происходит голосом, хотя уж выдачу разрешений автоматике по радио куда уж проще организовать. Между собой самолёты общаются уже по цифре, обмениваясь координатами и перепроверяя курсы, а с землёй - голосом. Маршруты тоже задаются вручную, хотя казалось бы автоматизация карт - вопрос давно решённый. И в таких решениях немало политики.
В то же время, пока ещё не было случая, чтобы большой самолёт сам успешно приземлился без пилота или при помощи случайного человека. (Тот случай с Караваном не в счёт: Караван ещё не лайнер, да и человек был не случайный).
Сравните это с лайнерами 60-х, у которых была позитивная обратная связь на уход с курса, то есть чем больше он отклонялся, тем быстрее его дальше отклоняло, и его весь полёт нужно было руками поправлять.
RulenBagdasis
Только тут имеется 2 проблемы:
У пилотов теряются навыки.
Большинство внештатных ситуаций, как следствие, создают сами пилоты.
Современные лайнеры между современными аэропортами должны летать на полном автопилоте. Собственно, они уже пару десятилетий как могут это делать, проблема в страхе и в профсоюзах.
konst90
А современный аэропорт закрылся по метео, и надо уходить на запасной, где системы нет. Или пассажиру стало плохо, и надо срочно садиться. Или птица в двигатель попала, и надо сесть в кукурузу.
Вот ради этих редких случаев пилотов и держат.
xSVPx
Тут надо четко понимать с цифрами в руках.
Скольких спасли верные действия пилотов и не спасла бы автоматика.
Скольктх угробили неверные действия пилотов и спасла бы автоматика.
Без этих цифр оценивать нечего.
juks Автор
Где бы эти цифры ещё взять, так чтобы собирающие их профессионалы не старались угодить заказчику, как это было, например, со статистическими доводами о пользе бокальчика красного вина каждый день
konst90
Я не думаю, что эти цифры в принципе возможно получить.
xSVPx
Ну почему же. Когда компания А перейдет на полный автомат, со временем они наберутся.
Для начала, уверен, переведут транспортники, их не так жалко.
Но, похоже, пока еще рановато. Может и время, но лет пять потребуют только согласования всего этого.
Хотя, я тут скептик, вопрос не в технической плоскости совершенно, а в какой-то адской импотенции современной авиации. Читаешь что они там уже понавертели и волосы на башке шевелятся.
konst90
Неа. Наберётся только статистика по числу инцидентов разного уровня на миллион километров. А вот достоверно определить, смогла бы автоматика или смог бы человек в каждом конкретном инциденте "конкурента", уже не получится. Да и грань между "пилоты спасли" и "автоматика делала бы так, что спасать и не надо было" - и наоборот - весьма тонка. Условно, пилоты молодцы что при посадке в СМУ чудом вытянули самолет на глиссаду после сдвига ветра, а автоматика бы вообще в СМУ не пыталась сажать и увела бы борт на запасной аэродром.
xSVPx
Так эта статистика и даст четкий ответ что из всего этого безопасней.
Но её надо еще как-то набрать, а для этого нужны сотни тысяч полетов.
RulenBagdasis
ILS сегодня в том или ином виде есть в любом аэропорте, способном принять современный лайнер. В самом крайнем случае к борту удалённо может подключиться пилот и управлять им дистанционно.
Борту даётся новое задание и он уходит на посадку в автоматическом режиме, о необходимости посадки принимает решение старший бортпроводник, консультируясь с землёй.
Отлично, что вы про это вспомнили, в курурузу садиться НЕ надо было в том недавнем случае. Посадка в кукурузу, это следствие ошибок пилотов. Современный лайнер способен взлетать на одном двигателе, на птицу во втором ему глубоко наплевать. Вы не в теме.
Вот именно об этом я и говорю, пилоты в кабинах сегодня, это следствие иррационального страха людей, которые не понимают, как всё сегодня работает.
juks Автор
Или это следствие рационального страха людей, которые не могут сделать
так, чтобы несчастный Кубернетс в субботу ночью дежурный не чинилустойчивое к сбоям считывание показателей датчика угла атаки.RulenBagdasis
Современный коптер не может управляться человеком, истребитель и ракета тоже не могут, ракета не может и много что ещё. У человека просто нет такой сорости реакции. Человек может только сказать: лети туда, а дальше оно само. Пульт в руках или большая красная кнопка, это иллюзия контроля. Люди ежедневно доверяют свою жизнь автоматике, даже не подозревая этого. Баба-робот, которая не отвлекется, не устаёт и не даёт порулить сыну, гораздо надёжнее.
juks Автор
Я описал причину конкретных двух катастроф, случившихся по вине автоматики, производственных дефектов, несовершенства процессов разработки автоматики, процессов подготовки инструкций и лётного состава.
Идеализировать то, откуда автоматика появляется, какой путь проходит и чего это стоит — вряд ли хорошая идея. Всему своё время.
Сделать сейчас одним промтом полностью автономный самолёт, так чтобы никто не разбился на нём — невозможно.
juks Автор
В кукурузу, как следствие — без вариантов. Не учитывать фактор шасси при оценке остатка топлива — не надо было.
juks Автор
С вашего позволения, воспользуюсь трибуной и порекомендую хороший фильм по теме, который в том числе (я надеюсь) примирит железнодорожников с авиаторами: «Остановился поезд» режиссёра Вадима Абдрашитова.
В фильме затронута очень глубокая тема того, что во-первых посадивший в кукурузу самолёт командир стал/побыл героем, а во-вторых: такие случаи никогда не создаются одним машинистом/пилотом, но значительно более обширны в своих причинах.
NAI
Кем дается? Стюардессой? т.е. предлагаете API вынести наружу из защищенной (условно) кабины, чтобы им мог воспользоваться любой террорист?
У КВСа чуть больше обязанностей чем у водителя маршрутки - он отвечает за борт и все что происходит на нем. Неадекватный пассажир - он решает не взлетать\сажать борт\дать в морду (сейчас этого нет, но в р-не 90-00 наблюдал как второй пилот вместе с стюардом просто скрутили неадеквата), долгий выпуск - именно КВС е*т мозги наземным службам.
У автоматики тоже есть пучек проблем - АТР-72 борт не скажу чтобы не палить контору, при посадке в Мурманске разводит компаса. На земле норм (все тесты проходят, компоса заменялись на другие), через 5 минут полета норм, 5 минут до глиссады - показывают погоду в Занзибаре. 1.5 года выяснений с заводом - вердикт никто не знает почему, Предположение - магнитные поля в районе крайнего севера складываются как-то не так, не летайте в регион. Хотя АТР сертифицирован на более северную широту. Так вот что ИИ(автоматика) сделает когда вдруг потеряет оба-два датчика в первый раз? Что делать при дребезге датчиков в полете? И главный вопрос - что делать при обесточении самолета как это было с ТУ154 и Ижмой? Кожаный может управлять гидравликой.
А еще у вас (нас) нет статистики по выходу компьютеров и управляющих систем из строя. Потому что ну вышел борт. пк из строя ну и ладно, пилот берет управление на себя долетает до места назначения и отписывается в борт.журнале. После чего самолет еще летает 3 дня. Это даже не инцидент.
В общем, я тут немного с АСУ ТП работаю (они сильно проще) и скажу я вам нет систем (даже резервируемых) которые бы 10-15 лет проработали бы без ручного управления.
А не в недавнем, ну том самом который про Гудзон?
juks Автор
Это один из ключевых вопросов сторонникам «убрать их всех оттуда»: предложите алгоритмическое решение задачи поиска места и способа захода для аварийной посадки.
RulenBagdasis
Идите и посмотрите в глаза всем людям, родные которых погибли в результате ошибок людей. Таких больше на пару порядков, они уже погибли, мы точно знаем почему и точно знаем, что в будущем люди продолжат ошибаться и убивать других людей. Пока популисты будут вспоминать Гудзон, где автоматика также прекрасно могла спланировать без двигателей в наиболее безопасное место.
NAI
а еще мы знаем вагон примеров когда люди не погибли - 15 ноября 2018 года, Усинск. Диспетчер запретил (!) боингу с пассажирами уходить с ВВП, что позволило посадить 4 (!) МиГа у которых топлива оставалось на пару минут полета. Послушайте переговоры дисптчера (10 мин, тот еще блокбастер) ну или разбор полной ситуации.
Какая автоматика смогла бы это разрулить?
Врачи смотрят, виновники ДТП смотрят, военные смотрят. Проблема с самолетом не в том что гибнут люди, а в том что происходит массовая гибель. От ДТП в год гибнут больше, но чет никто не ноет
xSVPx
Любая автоматика смогла бы это разрулить.
Уж не говоря о том, что даже очень тупая автоматика не допустила бы подобной ситуации. Она заранее начала бы верещать, что в некоторых самолетах не хватает топлива и посадила бы их еще час назад куда-то ещё.
С нормальной автоматикой они одновременно все сели и взлетели бы даже на одну полосу. Даже лоб в лоб, разошлись бы по высоте просто и каждый сел на свою часть полосы. В чем вы видите тут проблему ?
Вы видели концепт безсветофорного движения ? Светофоры робомашинам не нужны вообще. Пересекающиеся потоки не останавливаются, автомобили просто проезжают в "отверстия" в перпендикулярном потоке. При необходимости кто-то притормаживает. И это совершенно не чудо - это элементарный маневр. Маневр при котором "робоводитель" спит 99% всего времени.
Но человеку на такой дороге места нет. И это основная проблема. Как всех одномоментно пересадить непонятно.
xSVPx
С этим есть хоть какие-то проблемы ? Ну кроме того, что посчитав риски автомат решит угробить самолет с пассажирами, и оставить в живых всех тех кто там в Гудзоне на паромах плавает, по мостам движется итд итп.
Вас не смущает, что никакие другие пилоты на тренажере не смогли этот "подвиг" повторить ? Что капитан попался для подвига специально подготовленный. Что такую подготовку средний пилот не имеет ?
Там крупно повезло.
В формуле1 как думаете почему запрещена любая автоматика ? Она позволяет оставлять чемпионов мира далеко позади. Даже та автоматика, что была десятки лет назад. Это доказано опытным путем. Команды даже не смотря на запреты продолжали использовать автоматику для старта и были в этом уличены. И не последние команды, а лидеры. И не сегодня, а лет уже двадцать назад. Зачем им это было надо, если еожанные мешки всё делают лучше :)?
Человек никогда не сможет также точно вести автомобиль или сажать самолет как примитивный робот. Робот зачастую подруливает сотни и тысячи раз в секунду. Человек все что длится десятые части секунды вообще толком не воспринимает и сделать ничего не может. Скачайте себе симулятор "ковбойской стрельбы". Средний гражданин показывает задержку в клике после начала проигрывания анимации в пол секунды...
В роботе для пассажира только один фатпльный недостаток. Хороший робот будет минимизировать количество жертв, а не максимизировать шансы пассажира на выживание. Т.е. он не будет выбирать общественно опасные способы спасения. Если бы самолет врезался в паром на гудзоне и погибла пара тысяч человек(ну или сколько там в самолете и пароме в сумме едет), вы тоже считали бы, что это был гениальный мув :)? Если бы он в мост впилился в какой-нибудь автобус школьный?
xSVPx
ЗЫ. И главный вопрос про гудзон. Я нигде не видел на него ответа. Тот же капитан сколько раз сам сумел потом сесть на гудзон на тренажере ? Это кто-то анализировал ?
Проводился ли анализ того, какие жертвы были/могли быть в неудачных попытках ?
RulenBagdasis
Ага, террористы они же каждый день перехватывают садящиеся ракеты, беспилотные поезда метро и т.д. У меня авто дистанционно контроллируется, пока ни один террорист управление не получил.
NAI
Зачем Вам входная дверь и замки на ней?
Ведь статистически(я так, пальцем в небо), сколько квартир обнесли в вашем доме за последние ну скажем 5-10 лет?
RulenBagdasis
Так это вы предлагаете убрать замки и поставить у каждой двери по охраннику, ведь только человек сможет обеспечить безопасность. В вас ведь чоповец в коридоре сидит, правильно? И горничная вместо робота-пылесоса, а то там литий, он ууух как горит, запретить! Времена меняются, луддиты нет…
NAI
В каком месте? Я прекрасно знаю что безопасность это комплекс мер, а не одна какая-то конкретная. А вот вы пишите обратное:
Типа нафиг защиты меняж никто не ломал. По этому вам и вопрос - зачем вам двери с замками если вас никто не обкрадывал?
RulenBagdasis
В том, где вы начали писать, что человек надёжнее автоматики. Полностью игнорируя тот факт, что в авиации именно люди угробили 99% пассажиров.
Типа демагог детектед: Демагогия. Подмена тезиса
xSVPx
Я вам один вещь скажу, вы только не обижайтесь. Есть целые государства, где входные двери у людей зачастую стеклянные...
Freeman_RU
У вас по предмету "Статистика" явно был неуд. Сравнивать надо сравнимое: кол-во взломов ВСЕХ квартир\домов и кол-во взломов ВСЕХ транспортных средств.
Я вам больше скажу, что даже сейчас при взломе современного самолета уровня B747 его можно уронить, и никакой пилот не спасёт. Много вы знаете упавших самолетов от взлома?
juks Автор
И с кукурузой случилась попытка сбить с толку: автор исходного комментария явно имел в виду Жуковский в 2019-м году, когда всё было сделано чётко.
Один двигатель отказал полностью, второй работал нестабильно.
JediPhilosopher
Не должны. Это было долгое время популярная идея, что чем меньше пилоты рулят руками — тем безопаснее. Но ряд катастроф и почти‑катастроф, когда в сравнительно простых нештатных ситуациях при отказе автопилота пилоты гробили самолет, потому что разучились летать руками, показали что это не так. Навык который регулярно не тренируется — атрофируется, и это неизбежно и никакими тренажерами не компенсируется. И в первой же ситуации, когда автоматика отказывает, пилоты (которые ради этого и сидят в кабине) внезапно тоже не справляются.
Поэтому теперь рекомендации ИКАО и многих международных организаций другие — как можно чаще практиковать ручное пилотирование и поддерживать навыки.
У Оканя на эту тему был в блоге хороший пример. Известная катастрофа Суперджета в Шереметьево: попадание молнии, отказ автопилота, пилоты не смогли выполнить посадку в полностью ручном режиме — угробили самолет. После этого были сделаны выводы, те самые, про пользу навыка ручного управления. И были доработаны методики подготовки конкретно на этом типе в российских АК. Несколько лет спустя, Суперджет в Пулково, отказ всех систем автопилота (и основных и резервных), переход в ручной режим. Пилоты благополучно вернулись в аэропорт вылета и посадили самолет без проблем, это даже в новости не попало. Потому что опыт у них уже был благодаря изменившейся методике и подходу.
Как говорится, у любой технически сложной проблемы существует очевидное неправильное решение. Решение максимально исключить ручное управление в авиации ради безопасности похоже как раз из таких.
RulenBagdasis
Читайте комментарий, на который вы отвечаете, весь целиком. Я именно об этом и пишу. Пилотов нужно полностью убирать из кабины, чтобы они не перехватывали управление. А автопилот делать, действительно, автономным, а не как сейчас.
Повторю, это всё страхи от незнания и профсоюзные лобби. Про поезда то же самое говорили, что нельзя автоматику, люди будут скакать на рельсы, отказ угробит пол метро и прочий булшит. И ничего, прекрасно автоматаческие поезда ездят уже кучу лет и перевозят миллионы пассажиров. То же самое будет с самолётами и автомобилями, как бы не сопротивлялись извозчики.
JediPhilosopher
У авиации от ЖД и вообще от любого другого транспорта есть одно фундаментальное отличие — в ней нельзя остановиться и вызвать помощь если что‑то пошло не так.
Если у вас сломался автопилот в поезде — поезд останавливается. На крайний случай пассажир может дернуть стопкран, чисто механический.
Если у вас сломался автопилот в самолете — вам конец. Вы не можете остаться в воздухе навечно, вы не можете в небо вызвать техпомощь, у вас нет стоп‑крана. У вас впереди самый сложный этап полета (посадка), который никак нельзя обойти.
xSVPx
Есть какие-то проблемы с дистанционным управлением самолетом из аэропорта приземления (ну или любой близкой к нему точки) ?
Сломался - подключили пилота и пусть он рулит.
На всякий случай сразу скажу, что без электричества пилот в кабине современного самолета будет просто бесполезно ручки дергать. Т.е. в этом сценарии его наличие ничем не поможет.
Freeman_RU
Вбейте в поисковик "autoland system", удивитесь
MountainGoat
Beechcraft King Air кажется ещё меньше Каравана.
Freeman_RU
Это тут причём?
MountainGoat
При том, что "autoland system" использовалась на практике на нём.
(Если уже в этом году ещё куда -то поставили, то и Икар с ними.)
Freeman_RU
Эта система уже много лет идёт в стандарте для боенгов и эйбасов)) Ютуб завален видуюхами)
juks Автор
Думается, не так просто единоличному или коллективному органу взять на себя ответственность и полностью обрезать эту нить общения.
Могу только предположить: голосовые коммуникации, спокойствие в голосе диспетчера - многое значат для пилотов.
Lizdroz
Нить общения не обрезают просто потому, что переоборудование всех старых диспетчерских вышек стоит космических денег, а вовсе не ради психологического комфорта
juks Автор
В тех же пресловутых видео на Юрубе есть примеры, когда неадекватная кондиция пилота определяется как раз по радиообмену в процессе руления на взлёт.
juks Автор
В случае с автоматизацией работы пилотов, главный постулируемый публичный слоган, все же, — безопасность и жизни пассажиров. Это сильно развязывает руки. История с экономией и экономикой где-то остаётся внутри.
В деле «ускорения» и оптимизации разработчиков всё иначе.
Меня интересует именно проблематика переходного периода, происходящее с людьми, которые 90% смены не управляют и не программируют, но только наблюдают. Выглядит так, что в обоих случаях есть серьёзные проблемы, про которые предпочитают не думать. В разработке — точно.
Тезис про потерю навыков, которая создаёт отрицательную обратную связь, приводящую к авариям — в целом верный, но не всегда. Здесь мы, кроме прочего, не учитываем массу процессов и мероприятий, направленных в авиации на контроль и аттестацию.
И взять, например, истории катастроф Boeing 737 MAX, когда скрытая, незадокументированная автоматика пыталась скрыть конструктивный дефект. Тот самый случай «двух минут», когда лётчики должны были резко перейти из состояния наблюдателей и бороться с автопилотом через штурвал.
Это явным пример обратной логики: бонусная мотивация, требующая костылить ошибки автоматизацией и кодом, убила людей.
Lizdroz
Главный слоган ИИ в разработке - как сделать так, чтобы сеньор делал работу трех мидлов за одну зарплату)
juks Автор
Главный фактор: у сеньора добровольного желания на это нет. Большинство разработчиков думают о двух вещах: как выполнить неделю за день и как самому не платить за подписку на Клод.
Реально и добровольно выигрывают те, кто делает собственный продукт и «программирующие менеджеры».
konst90
Скорее, столь же эффектно работают меньшими силами. Раньше для выполнения одного рейса нужно было пять человек (КВС, второй пилот, штурман, бортинженер, радист), теперь достаточно двух. В принципе, и одного достаточно, но резервирование считается более важным.
juks Автор
Это тоже интересный момент! В контексте видео, приведённого в качестве примера: именно так и решил КВС, видя второго пилота вдрабадан пьяным. И, вероятно, это расхожее мнение.
Ведь он его не сдал (как можно сдать, если и выпивали вместе), сдали пассажиры и кто-то ещё, почуяв запах спиртного.
juks Автор
Кстати, интересно и то, что одного пьяного из двух пилотов автоматического самолёта вытряхивают, проверяют визуально на опьянение и задерживают ровно так же, как достали из-за руля пьяного Джастина Тимберлейка.
Lizdroz
У пилотов эффективность измеряется снижением аварийности на миллион часов налета и экономией топлива за счет идеальных расчетов глиссады автопилотом
juks Автор
Плюс автомат тяги