Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Топ-менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 105
компания «Яндекс» объявила программу «75/75/75» (пресс-релиз). Цели на конец 2026 года: не менее 75% разработчиков регулярно применяют ИИ при написании кода. ИИ участвует в подготовке не менее 75% изменений
Пропал Яндекс: теперь доверие к его продуктам упало до нуля
Вопрос без подколки: авиа пилоты теперь эффективнее работают теми же силами? В каких метриках?
Ну и аналог с самолётами так себе. В энтерпрайз да, в менее ответственных секторах нет.
Собственно да, работа пилота сейчас в том, чтобы быть готовым отреагировать на внештатные ситуации в ту же секунду, а так самолёт практически сам летит. Что интересно, общение с землёй до сих пор происходит голосом, хотя уж выдачу разрешений автоматике по радио куда уж проще организовать. Между собой самолёты общаются уже по цифре, обмениваясь координатами и перепроверяя курсы, а с землёй - голосом. Маршруты тоже задаются вручную, хотя казалось бы автоматизация карт - вопрос давно решённый. И в таких решениях немало политики.
В то же время, пока ещё не было случая, чтобы большой самолёт сам успешно приземлился без пилота или при помощи случайного человека. (Тот случай с Караваном не в счёт: Караван ещё не лайнер, да и человек был не случайный).
Сравните это с лайнерами 60-х, у которых была позитивная обратная связь на уход с курса, то есть чем больше он отклонялся, тем быстрее его дальше отклоняло, и его весь полёт нужно было руками поправлять.
работа пилота сейчас в том, чтобы быть готовым отреагировать на внештатные ситуации в ту же секунду
Только тут имеется 2 проблемы:
У пилотов теряются навыки.
Большинство внештатных ситуаций, как следствие, создают сами пилоты.
Современные лайнеры между современными аэропортами должны летать на полном автопилоте. Собственно, они уже пару десятилетий как могут это делать, проблема в страхе и в профсоюзах.
А современный аэропорт закрылся по метео, и надо уходить на запасной, где системы нет. Или пассажиру стало плохо, и надо срочно садиться. Или птица в двигатель попала, и надо сесть в кукурузу.
Вот ради этих редких случаев пилотов и держат.
Тут надо четко понимать с цифрами в руках.
Скольких спасли верные действия пилотов и не спасла бы автоматика.
Скольктх угробили неверные действия пилотов и спасла бы автоматика.
Без этих цифр оценивать нечего.
Где бы эти цифры ещё взять, так чтобы собирающие их профессионалы не старались угодить заказчику, как это было, например, со статистическими доводами о пользе бокальчика красного вина каждый день
Я не думаю, что эти цифры в принципе возможно получить.
Ну почему же. Когда компания А перейдет на полный автомат, со временем они наберутся.
Для начала, уверен, переведут транспортники, их не так жалко.
Но, похоже, пока еще рановато. Может и время, но лет пять потребуют только согласования всего этого.
Хотя, я тут скептик, вопрос не в технической плоскости совершенно, а в какой-то адской импотенции современной авиации. Читаешь что они там уже понавертели и волосы на башке шевелятся.
Неа. Наберётся только статистика по числу инцидентов разного уровня на миллион километров. А вот достоверно определить, смогла бы автоматика или смог бы человек в каждом конкретном инциденте "конкурента", уже не получится. Да и грань между "пилоты спасли" и "автоматика делала бы так, что спасать и не надо было" - и наоборот - весьма тонка. Условно, пилоты молодцы что при посадке в СМУ чудом вытянули самолет на глиссаду после сдвига ветра, а автоматика бы вообще в СМУ не пыталась сажать и увела бы борт на запасной аэродром.
А современный аэропорт закрылся по метео, и надо уходить на запасной, где системы нет.
ILS сегодня в том или ином виде есть в любом аэропорте, способном принять современный лайнер. В самом крайнем случае к борту удалённо может подключиться пилот и управлять им дистанционно.
Или пассажиру стало плохо, и надо срочно садиться.
Борту даётся новое задание и он уходит на посадку в автоматическом режиме, о необходимости посадки принимает решение старший бортпроводник, консультируясь с землёй.
Или птица в двигатель попала, и надо сесть в кукурузу.
Отлично, что вы про это вспомнили, в курурузу садиться НЕ надо было в том недавнем случае. Посадка в кукурузу, это следствие ошибок пилотов. Современный лайнер способен взлетать на одном двигателе, на птицу во втором ему глубоко наплевать. Вы не в теме.
Вот именно об этом я и говорю, пилоты в кабинах сегодня, это следствие иррационального страха людей, которые не понимают, как всё сегодня работает.
это следствие иррационального страха людей, которые не понимают, как всё сегодня работает
Или это следствие рационального страха людей, которые не могут сделать так, чтобы несчастный Кубернетс в субботу ночью дежурный не чинил устойчивое к сбоям считывание показателей датчика угла атаки.
Современный коптер не может управляться человеком, истребитель и ракета тоже не могут, ракета не может и много что ещё. У человека просто нет такой сорости реакции. Человек может только сказать: лети туда, а дальше оно само. Пульт в руках или большая красная кнопка, это иллюзия контроля. Люди ежедневно доверяют свою жизнь автоматике, даже не подозревая этого. Баба-робот, которая не отвлекется, не устаёт и не даёт порулить сыну, гораздо надёжнее.
Я описал причину конкретных двух катастроф, случившихся по вине автоматики, производственных дефектов, несовершенства процессов разработки автоматики, процессов подготовки инструкций и лётного состава.
Идеализировать то, откуда автоматика появляется, какой путь проходит и чего это стоит — вряд ли хорошая идея. Всему своё время.
Сделать сейчас одним промтом полностью автономный самолёт, так чтобы никто не разбился на нём — невозможно.
в курурузу садиться НЕ надо было
В кукурузу, как следствие — без вариантов. Не учитывать фактор шасси при оценке остатка топлива — не надо было.
С вашего позволения, воспользуюсь трибуной и порекомендую хороший фильм по теме, который в том числе (я надеюсь) примирит железнодорожников с авиаторами: «Остановился поезд» режиссёра Вадима Абдрашитова.
В фильме затронута очень глубокая тема того, что во-первых посадивший в кукурузу самолёт командир стал/побыл героем, а во-вторых: такие случаи никогда не создаются одним машинистом/пилотом, но значительно более обширны в своих причинах.
Борту даётся новое задание и он уходит на посадку в автоматическом режиме
Кем дается? Стюардессой? т.е. предлагаете API вынести наружу из защищенной (условно) кабины, чтобы им мог воспользоваться любой террорист?
У КВСа чуть больше обязанностей чем у водителя маршрутки - он отвечает за борт и все что происходит на нем. Неадекватный пассажир - он решает не взлетать\сажать борт\дать в морду (сейчас этого нет, но в р-не 90-00 наблюдал как второй пилот вместе с стюардом просто скрутили неадеквата), долгий выпуск - именно КВС е*т мозги наземным службам.
У автоматики тоже есть пучек проблем - АТР-72 борт не скажу чтобы не палить контору, при посадке в Мурманске разводит компаса. На земле норм (все тесты проходят, компоса заменялись на другие), через 5 минут полета норм, 5 минут до глиссады - показывают погоду в Занзибаре. 1.5 года выяснений с заводом - вердикт никто не знает почему, Предположение - магнитные поля в районе крайнего севера складываются как-то не так, не летайте в регион. Хотя АТР сертифицирован на более северную широту. Так вот что ИИ(автоматика) сделает когда вдруг потеряет оба-два датчика в первый раз? Что делать при дребезге датчиков в полете? И главный вопрос - что делать при обесточении самолета как это было с ТУ154 и Ижмой? Кожаный может управлять гидравликой.
А еще у вас (нас) нет статистики по выходу компьютеров и управляющих систем из строя. Потому что ну вышел борт. пк из строя ну и ладно, пилот берет управление на себя долетает до места назначения и отписывается в борт.журнале. После чего самолет еще летает 3 дня. Это даже не инцидент.
В общем, я тут немного с АСУ ТП работаю (они сильно проще) и скажу я вам нет систем (даже резервируемых) которые бы 10-15 лет проработали бы без ручного управления.
в курурузу садиться НЕ надо было в том недавнем случае
А не в недавнем, ну том самом который про Гудзон?
А не в недавнем, ну том самом который про Гудзон?
Это один из ключевых вопросов сторонникам «убрать их всех оттуда»: предложите алгоритмическое решение задачи поиска места и способа захода для аварийной посадки.
Идите и посмотрите в глаза всем людям, родные которых погибли в результате ошибок людей. Таких больше на пару порядков, они уже погибли, мы точно знаем почему и точно знаем, что в будущем люди продолжат ошибаться и убивать других людей. Пока популисты будут вспоминать Гудзон, где автоматика также прекрасно могла спланировать без двигателей в наиболее безопасное место.
точно знаем, что в будущем люди продолжат ошибаться и убивать других людей
а еще мы знаем вагон примеров когда люди не погибли - 15 ноября 2018 года, Усинск. Диспетчер запретил (!) боингу с пассажирами уходить с ВВП, что позволило посадить 4 (!) МиГа у которых топлива оставалось на пару минут полета. Послушайте переговоры дисптчера (10 мин, тот еще блокбастер) ну или разбор полной ситуации.
Какая автоматика смогла бы это разрулить?
(2, 3 борт)
- Уходите на второй круг, полоса занята боингом
- Возможности уйти на второй круг нет
...
- Разворачивайтесь на 180 в конце полосы
- У вас тягач есть? А то я по топливу сейчас выключусь
...
(4, 5 борта)
- С курсом 314 заходите?
- Так точно
- Набирайте высоту
- Не могу по топливу
- Вы лоб в лоб идете, выполните вираж
- Топлива не хватитИдите и посмотрите в глаза всем людям, родные которых погибли в результате ошибок людей.
Врачи смотрят, виновники ДТП смотрят, военные смотрят. Проблема с самолетом не в том что гибнут люди, а в том что происходит массовая гибель. От ДТП в год гибнут больше, но чет никто не ноет
Любая автоматика смогла бы это разрулить.
Уж не говоря о том, что даже очень тупая автоматика не допустила бы подобной ситуации. Она заранее начала бы верещать, что в некоторых самолетах не хватает топлива и посадила бы их еще час назад куда-то ещё.
С нормальной автоматикой они одновременно все сели и взлетели бы даже на одну полосу. Даже лоб в лоб, разошлись бы по высоте просто и каждый сел на свою часть полосы. В чем вы видите тут проблему ?
Вы видели концепт безсветофорного движения ? Светофоры робомашинам не нужны вообще. Пересекающиеся потоки не останавливаются, автомобили просто проезжают в "отверстия" в перпендикулярном потоке. При необходимости кто-то притормаживает. И это совершенно не чудо - это элементарный маневр. Маневр при котором "робоводитель" спит 99% всего времени.
Но человеку на такой дороге места нет. И это основная проблема. Как всех одномоментно пересадить непонятно.
Она заранее начала бы верещать, что в некоторых самолетах не хватает топлива и посадила бы их еще час назад куда-то ещё.
Куда? Там всё было по метео закрыто. Они сделали несколько попыток сесть в Воркуте, а потом ушли на Усинск. Всё, что могла бы сделать автоматика - это попытаться посадить их в Воркуте. Получилось бы у неё это или нет - неизвестно.
С нормальной автоматикой они одновременно все сели и взлетели бы даже на одну полосу. Даже лоб в лоб, разошлись бы по высоте просто и каждый сел на свою часть полосы. В чем вы видите тут проблему ?
В том, что такой автоматики не существует. Её легко придумать (концепт, да-да), её теоретически можно воплотить в железе, но на практике её нет. И когда будет - неизвестно.
В смысле "куда"? Откуда вылетели - туда. Закрылось что-то по метео, мы видим, что через час прилетят самолеты с пустыми баками - мы заранее готовим аэропорт в аварийном режиме, а не в последний момент разруливаем. Кто-то мог и вернуться или свернуть... Если что-то понадобилось срочно - это показатель того, что у кого-то что-то не так на этапе планирования. Заменен должен быть не только пилот, но и тот кто планирует всё движение.
Да совершенно нет никакой проблемы в такой автоматике. Она везде. Уже в чайниках на кухне она. Если вы немного изучите матчасть, то поймете, что в любом обрабатывающем центре она тоже. Ныне они умеют с микронной точностью двигаться ОДНОВРЕМЕННО по 3-5 координатам. И очень стремительно, ускорения больше чем при старте ракеты, чуть ли не такие как при выстреле из пушки. При этом зачастую реалтайм в милли или даже наносекундах измеряется. Что такое наносекунда ? При скорости 1000км в час это подруливание каждые... что-то у меня получается 0.002 мм.... Понимаете ;)? Можно на каждый миллиметр пути самолета подруливать 500 раз.... На миллиметр.
Человек подруливает каждые 0.3с приблизительно, робот может каждые 0.000000001...
Не в курсе про оц?, на современные 3д принтеры посмотрите, они не столь точны, но ускорения там зачастую побольше даже. И при этом даже миллиметровая ошибка - бракованная деталь. И они справляются.
На этом фоне разрулить два снижающихся самолёта по высоте и добиться, чтобы один из них не догнал другой и сел на полосу с зазором метров в сто - задача для студента. Они и с зазором в метр могли бы сесть, если бы не было переменных погодных условий и их не мотыляло.
Нет воли. Автоматика есть. И сейчас речь о детерменированной автоматике, не о каких-то там нейросетях. Все эти маневры можно предварительно обкатать. И если эта автоматика зайдет в тупик, она попросит помощи у человека, где-нибудь за час до того, как помощь понадобится. Не порулить помощи, а решить, что делать когда самолеты со всей страны летят в один аэропорт на северном полюсе и там может оказаться, что будет нельзя сесть. И эту проблему решат за час до ее возникновения, пока баки полные.
Когда наблюдается подвиг - это всегда ощибки планирования. Давно пора к каждой звезде героя прикреплять смертный приговор тому, кто накосячил и довел до того, что разрулить только герой смог.
Описывать мир, предназначенный для техноутопизма, в котором некоторая транспортная отрасль на 100% самообслуживается идеальными роботами, произведёнными другими роботами и перевозящая роботов — можно.
Но постоянные переходы на личности и упрёки в невежестве такие доводы никак не красят.
Почему бы не начать с простого: перевести какое-нибудь небольшое ООО, торгующее кондиционерами или делающее софт на заказ, на автоматику и написать про это статью? Там точно никого не убьёт.
Вы приписываете другим то, чего они не писали - это нехорошо.
Не знаю как сейчас, а лет 10 назад в москве движение УЖЕ регулировалось автоматически. Т.е. "ваше будущее" "на земле" уже наступило декаду назад. Уже автомат лучше людей управлял дорожным движением.
В мире есть дофига метрополитенов, где люди не водят поезда совершенно - они автоматические, и они безопаснее чем те, где водят люди.
Нет никаких технических проблем управлять движением и в воздухе. Кроме одной: все участники движения должны слушаться.
Собственно и с москвой были проблемы (и огромные, и есть до сих пор вероятно, впрочем тут тоже не уверен, возможно допилили), когда для пропуска кортежа часть светофоров переводят на ручное управление.
Безусловно придется доказывать, что роботизация делает самолет безопаснее. Я всячески приветствую подобные проверки и у меня в целом нет никаких причин думать, что они не будут пройдены.
Нет ничего эдакого в том, как управляется поезд, автомобиль или самолет. А если говорить об условиях, то робоавтомобиль штука ГОРАЗДО более сложная, чем робосамолет.
С этим есть хоть какие-то проблемы ? Ну кроме того, что посчитав риски автомат решит угробить самолет с пассажирами, и оставить в живых всех тех кто там в Гудзоне на паромах плавает, по мостам движется итд итп.
Вас не смущает, что никакие другие пилоты на тренажере не смогли этот "подвиг" повторить ? Что капитан попался для подвига специально подготовленный. Что такую подготовку средний пилот не имеет ?
Там крупно повезло.
В формуле1 как думаете почему запрещена любая автоматика ? Она позволяет оставлять чемпионов мира далеко позади. Даже та автоматика, что была десятки лет назад. Это доказано опытным путем. Команды даже не смотря на запреты продолжали использовать автоматику для старта и были в этом уличены. И не последние команды, а лидеры. И не сегодня, а лет уже двадцать назад. Зачем им это было надо, если еожанные мешки всё делают лучше :)?
Человек никогда не сможет также точно вести автомобиль или сажать самолет как примитивный робот. Робот зачастую подруливает сотни и тысячи раз в секунду. Человек все что длится десятые части секунды вообще толком не воспринимает и сделать ничего не может. Скачайте себе симулятор "ковбойской стрельбы". Средний гражданин показывает задержку в клике после начала проигрывания анимации в пол секунды...
В роботе для пассажира только один фатпльный недостаток. Хороший робот будет минимизировать количество жертв, а не максимизировать шансы пассажира на выживание. Т.е. он не будет выбирать общественно опасные способы спасения. Если бы самолет врезался в паром на гудзоне и погибла пара тысяч человек(ну или сколько там в самолете и пароме в сумме едет), вы тоже считали бы, что это был гениальный мув :)? Если бы он в мост впилился в какой-нибудь автобус школьный?
Ага, террористы они же каждый день перехватывают садящиеся ракеты, беспилотные поезда метро и т.д. У меня авто дистанционно контроллируется, пока ни один террорист управление не получил.
Зачем Вам входная дверь и замки на ней?
Ведь статистически(я так, пальцем в небо), сколько квартир обнесли в вашем доме за последние ну скажем 5-10 лет?
Так это вы предлагаете убрать замки и поставить у каждой двери по охраннику, ведь только человек сможет обеспечить безопасность. В вас ведь чоповец в коридоре сидит, правильно? И горничная вместо робота-пылесоса, а то там литий, он ууух как горит, запретить! Времена меняются, луддиты нет…
Так это вы предлагаете убрать замки и поставить у каждой двери по охраннику
В каком месте? Я прекрасно знаю что безопасность это комплекс мер, а не одна какая-то конкретная. А вот вы пишите обратное:
У меня авто дистанционно контроллируется, пока ни один террорист управление не получил.
Типа нафиг защиты меняж никто не ломал. По этому вам и вопрос - зачем вам двери с замками если вас никто не обкрадывал?
В каком месте?
В том, где вы начали писать, что человек надёжнее автоматики. Полностью игнорируя тот факт, что в авиации именно люди угробили 99% пассажиров.
Типа нафиг защиты меняж никто не ломал.
Типа демагог детектед: Демагогия. Подмена тезиса
Я вам один вещь скажу, вы только не обижайтесь. Есть целые государства, где входные двери у людей зачастую стеклянные...
У вас по предмету "Статистика" явно был неуд. Сравнивать надо сравнимое: кол-во взломов ВСЕХ квартир\домов и кол-во взломов ВСЕХ транспортных средств.
Я вам больше скажу, что даже сейчас при взломе современного самолета уровня B747 его можно уронить, и никакой пилот не спасёт. Много вы знаете упавших самолетов от взлома?
И с кукурузой случилась попытка сбить с толку: автор исходного комментария явно имел в виду Жуковский в 2019-м году, когда всё было сделано чётко.
Один двигатель отказал полностью, второй работал нестабильно.
Не должны. Это было долгое время популярная идея, что чем меньше пилоты рулят руками — тем безопаснее. Но ряд катастроф и почти‑катастроф, когда в сравнительно простых нештатных ситуациях при отказе автопилота пилоты гробили самолет, потому что разучились летать руками, показали что это не так. Навык который регулярно не тренируется — атрофируется, и это неизбежно и никакими тренажерами не компенсируется. И в первой же ситуации, когда автоматика отказывает, пилоты (которые ради этого и сидят в кабине) внезапно тоже не справляются.
Поэтому теперь рекомендации ИКАО и многих международных организаций другие — как можно чаще практиковать ручное пилотирование и поддерживать навыки.
У Оканя на эту тему был в блоге хороший пример. Известная катастрофа Суперджета в Шереметьево: попадание молнии, отказ автопилота, пилоты не смогли выполнить посадку в полностью ручном режиме — угробили самолет. После этого были сделаны выводы, те самые, про пользу навыка ручного управления. И были доработаны методики подготовки конкретно на этом типе в российских АК. Несколько лет спустя, Суперджет в Пулково, отказ всех систем автопилота (и основных и резервных), переход в ручной режим. Пилоты благополучно вернулись в аэропорт вылета и посадили самолет без проблем, это даже в новости не попало. Потому что опыт у них уже был благодаря изменившейся методике и подходу.
Как говорится, у любой технически сложной проблемы существует очевидное неправильное решение. Решение максимально исключить ручное управление в авиации ради безопасности похоже как раз из таких.
Это было долгое время популярная идея, что чем меньше пилоты рулят руками — тем безопаснее. Но ряд катастроф и почти‑катастроф, когда в сравнительно простых нештатных ситуациях при отказе автопилота пилоты гробили самолет, потому что разучились летать руками, показали что это не так
Читайте комментарий, на который вы отвечаете, весь целиком. Я именно об этом и пишу. Пилотов нужно полностью убирать из кабины, чтобы они не перехватывали управление. А автопилот делать, действительно, автономным, а не как сейчас.
Решение максимально исключить ручное управление в авиации ради безопасности похоже как раз из таких.
Повторю, это всё страхи от незнания и профсоюзные лобби. Про поезда то же самое говорили, что нельзя автоматику, люди будут скакать на рельсы, отказ угробит пол метро и прочий булшит. И ничего, прекрасно автоматаческие поезда ездят уже кучу лет и перевозят миллионы пассажиров. То же самое будет с самолётами и автомобилями, как бы не сопротивлялись извозчики.
У авиации от ЖД и вообще от любого другого транспорта есть одно фундаментальное отличие — в ней нельзя остановиться и вызвать помощь если что‑то пошло не так.
Если у вас сломался автопилот в поезде — поезд останавливается. На крайний случай пассажир может дернуть стопкран, чисто механический.
Если у вас сломался автопилот в самолете — вам конец. Вы не можете остаться в воздухе навечно, вы не можете в небо вызвать техпомощь, у вас нет стоп‑крана. У вас впереди самый сложный этап полета (посадка), который никак нельзя обойти.
Есть какие-то проблемы с дистанционным управлением самолетом из аэропорта приземления (ну или любой близкой к нему точки) ?
Сломался - подключили пилота и пусть он рулит.
На всякий случай сразу скажу, что без электричества пилот в кабине современного самолета будет просто бесполезно ручки дергать. Т.е. в этом сценарии его наличие ничем не поможет.
Требует сложной системы дистанционного управления и телеметрии? Если у вас она работает, то и автопилот скорее всего работает.
Без электричества у пилота современного самолета остается кучи опций. От прямого механического управления, только тяжелого при отказе гидросистем (Боинг-стайл и самолеты постарше или поменьше) до аварийных турбин, питающих минимальный комплект нужных приборов. Также часть приборов по-прежнему механическая (до сих пор ставят аварийный механический авиагоризонт на гироскопах, работающий независимо от бортового компьютера).
То есть даже при отказе всей сложной электроники, двигателей, гидросистем, питания, побороться за жизнь вполне возможно, и случаев успешных посадок достаточно. Садились даже с полным отказом управления, управляя тягой двигателей напрямую, хоть и с жертвами (но в такой ситуации даже половина выживших на борту это уже успех).
Я пока не вижу как сделать такую систему достаточно надежной и резервируемой для удовлетворения авиационных стандартов безопасности.
Что такого сложного в дистанционной системе управления и телеметрии ? Она УЖЕ такова. Нет, вы верно пишите, кое-что осталось кое где аналоговым, но в целом пилоты фактически смотрят в результаты телеметрии в основном. Им незачем с этой телеметрией летать, могли бы оставаться и на земле.
Чтобы не было нужды сажать что-то при отказе электроники надо просто уменьшить аварийность без отказа настолько, чтобы потеря самолетов при отказе статистику не портила. Уверен это вполне реально.
Нет. Всех не спасти. Придется выбирать, спасти 1000 человек поменяв кожаный мешок на робота, который не будет давать порулить ребенку(но погибнет 100 человек в самолете, который потеряет где-то всё электричество), либо спасти 100 при отказе этого робота, но тысячу угробить.
Про авиационные стандарты безопасности я много что мог бы сказать если бы можно было матом. Пожалуй это основная проблема. Доверия к "бойнгам" особого нету, к сожалению.
пока ещё не было случая, чтобы большой самолёт сам успешно приземлился без пилота
Вбейте в поисковик "autoland system", удивитесь
Думается, не так просто единоличному или коллективному органу взять на себя ответственность и полностью обрезать эту нить общения.
Могу только предположить: голосовые коммуникации, спокойствие в голосе диспетчера - многое значат для пилотов.
В тех же пресловутых видео на Юрубе есть примеры, когда неадекватная кондиция пилота определяется как раз по радиообмену в процессе руления на взлёт.
В случае с автоматизацией работы пилотов, главный постулируемый публичный слоган, все же, — безопасность и жизни пассажиров. Это сильно развязывает руки. История с экономией и экономикой где-то остаётся внутри.
В деле «ускорения» и оптимизации разработчиков всё иначе.
Меня интересует именно проблематика переходного периода, происходящее с людьми, которые 90% смены не управляют и не программируют, но только наблюдают. Выглядит так, что в обоих случаях есть серьёзные проблемы, про которые предпочитают не думать. В разработке — точно.
Тезис про потерю навыков, которая создаёт отрицательную обратную связь, приводящую к авариям — в целом верный, но не всегда. Здесь мы, кроме прочего, не учитываем массу процессов и мероприятий, направленных в авиации на контроль и аттестацию.
И взять, например, истории катастроф Boeing 737 MAX, когда скрытая, незадокументированная автоматика пыталась скрыть конструктивный дефект. Тот самый случай «двух минут», когда лётчики должны были резко перейти из состояния наблюдателей и бороться с автопилотом через штурвал.
Это явным пример обратной логики: бонусная мотивация, требующая костылить ошибки автоматизацией и кодом, убила людей.
авиа пилоты теперь эффективнее работают теми же силами? В каких метриках?
Скорее, столь же эффектно работают меньшими силами. Раньше для выполнения одного рейса нужно было пять человек (КВС, второй пилот, штурман, бортинженер, радист), теперь достаточно двух. В принципе, и одного достаточно, но резервирование считается более важным.
В принципе, и одного достаточно
Это тоже интересный момент! В контексте видео, приведённого в качестве примера: именно так и решил КВС, видя второго пилота вдрабадан пьяным. И, вероятно, это расхожее мнение.
Ведь он его не сдал (как можно сдать, если и выпивали вместе), сдали пассажиры и кто-то ещё, почуяв запах спиртного.
Кстати, интересно и то, что одного пьяного из двух пилотов автоматического самолёта вытряхивают, проверяют визуально на опьянение и задерживают ровно так же, как достали из-за руля пьяного Джастина Тимберлейка.
У пилотов эффективность измеряется снижением аварийности на миллион часов налета и экономией топлива за счет идеальных расчетов глиссады автопилотом
Да, писать код руками уже не нужно, но читать сгенерированный код намного труднее, особенно, учитывая объем и скорость генерации новых вариантов. Плюс "в декомпозицию, архитектуру, постановку задач", так что когнитивная нагрузка выросла очень сильно. В какой-то мере удовольствия от работы стало меньше, а ответственность никто не отменял. Работа меняется, конечно, и я не уверен, что в лучшую сторону для самих разработчиков.
Лично мне представляется так, что любой код, который написал не сам, в целом читать непросто. Читать код, про который известно, что он «бездонный» — ещё сложнее.
Я уверен, что способность понимать чужой код в принципе — одна из лучших демонстраций высоких когнитивных способностей разработчика. Могут это в реальности далеко не все, неумение можно плюс-минус умело скрывать. На реальное понимание чужого кода расходуется много энергии. Выполнение такой задачи можно считать одной из характеристик внутреннего «контекстного окна» конкретного инженера.
Но и про чтение кода, кстати, уже было: https://habr.com/ru/news/1062634.
Статья правильная и я бы мог наверно добавить пару мыслей, но воздержусь по двум причинам: 1. Они не полностью оформились. 2. На всякий изложенный аргумент эксплуататор со временем найдёт удобный контраргумент.
Какая-то метафора слишком уж упрощающая. Есть риск уверовать в то, что каждое "подруливание" ИИ в разработке так же просто и верифицируемо как сверка курса по приборам. В разработке зачастую ни измерений четких нет, ни курса, многое нужно придумывать первый раз и обратная связь будет не пойми какая и когда. Короче, имхо метафорой творческой работы не должна быть механическая.
Метафора упрощающая, да. Но я предлагаю сфокусироваться именно вокруг «ожидания» результата автоматизированного процесса и оценки результативности. Можно упростить ещё больше, до максимума и предложить пример «до LLM»: огромный релизный пайплайн, который порой может работать часами. Все зависит от конкретного психотипа человека, но далеко не каждый способен в такое время «шедулить» себе другую задачу и переключаться на неё. Большинство людей, как мне видится, начинают как бы маяться.
Мотивации описать всё это добавила та самая разработка с Клодом. При составлении плана он, хоть я его и не просил, выдал оценку сложности выполнения задачи. Вместо реальной для себя оценки в один час, он выдал «социально приемлемые» 10-15 дней.
"пилоты, рядом с автопилотами" (людишки - "операторы", рядом с AI - "Разработчиками") - принято.
А вот "Что делать" - не понравилось ("что делать на сидячей работе". Т.е. только о деградации разработчика).
1. Автопилот - для надежности полетов (пассажиров - в гражданской авиации; и в военной - для повышения дальности, ...).
Т.е. пилот - знает, на что идет (я про ответственность. Она, через нормы, заставляет включать автопилот, на ровном участке).
Как и местный врач-терапевт (кучу лет - проучившийся, набравшийся практики) - знает, что "изо дня, в день ...".
2. Вот у них - есть многолетние наработки "Как поддерживать форму" (фраза не подходит к врачам, но парна предыдущей).
Но и у них - "позаботься о себе сам".
3. Если предположить, что ("в дАлекой-дАлекой галактике") программисты (как "прослойка") станут не нужны. То и "вопрос - снят".
Программисты - останутся, но не в виде прослойки (пользователь - сам сможет договориться с AI. я не про современную LLM).
Прикольное сравнение с авиацией, но забыто главное отличие : пилот не может переписывать архитектуру самолета прямо в полете, а разработчик именно это и делает, пока ИИ пишет бойлерплейт
Да, и еще раз - да! Мы ровно идем по тому пути как коммерческая авиация. Сейчас у нас фаза когда рекомендацией является достижение максимальной автоматизации на всех этапах полета. Надо очень больно несколько раз убиться об стену, чтобы пришло понимание что нельзя сидеть на двух стульях:
Либо вы перекладываете ответственность за код в продакшене на LLM - и тогда можете автоматизировать все как хотите, но в случае падения - не тыркайте разработчиков, а пишите жалобу авторам модели: Антропик, OpenAI, а лучше сразу в спортлото. Ибо антропику и OpenAI ваш продакшен нахрен не сдался...
Либо вы сохраняете ответственность за код на разработчиках, но тогда вся цепочка SDLC должна быть выстроена вокруг человека в контуре, чтобы он сохранял situational awareness.
Ровно из авиционного опыта я категорически не рекомендую сколько-нибудь значимую и критичную систему разрабатывать методами SDD, вайб-кодинга, и проч. Потому что итогом будет штопор и полный рот земли. Этот запрет, кстати, не препятствует использованию ИИ и получению выгод от его использования - но разработчик должен его использовать как инструмент. А менеджмент - принимать меры чтобы ИИ не выходил за разумные рамки использования.
К сожалению, средний менеджер глуп и ленив. Он спит и видит - как бы установить какие-нибудь KPI, и потом уже ничего не делать, а только получать бонусы за результат. Отсюда вся вот эта ересь 75/75/75... :-(
Из положительного - отметим оплату за токены которую ввели уже почти все. В эпоху почти-бесплатных токенов менеджеры были невыносимы! Сейчас хотя бы на языке денег можно им объяснить какую глупость они совершают...
Отдельно, кстати, интересна мотивация анонсирования 75/75/75 наружу.
Можно снова провести параллель с авиакомпаниями, для которых это прежде всего заверение пассажирам о повышении уровня безопасности и снижения человеческого фактора. Конечно, говорят и про снижение нагрузки на пилотов. Но что тут хочет сказать ИТ-компания?
В 2020 году Airbus сообщил о завершении проекта Autonomous Taxi, Take-Off & Landing (ATTOL).
Один из анонсов Boeing: Key 737 MAX upgrade to ease pilot workload
Тщеславие менеджерам тоже не чуждо! :-) Их распирает похвастаться чем-то на публику. Мы же ходим на инженерские конференции, и там вещаем про свои инженерские достижения... А у этих еще и акционеры, которых надо впечатлить!
Вообще мы должны благодарить создателя за то, что у нас головной болью является Antropic и OpenAI вместе с матрицами на GPU! Потому что на их месте мог быть какой-нибудь биохакинг-стартап, который внезапно обнаружил что съевший утром ложку говна разработчик работает 10x быстрее! И я вас уверяю, что дальше бы последовала та же самая рыночная шиза - неизбежно появились бы те, у кого эффект, к сожалению, чисто статистически подтвердился. Потом менеджеры начали бы кормить разрабов говном просто из боязни остать от прогресса. А вокруг них бы собрался круг подпевал, которые вообще поддерживают любую дурь начальника если это обещает рост по службе и бонусы... Потом инвесторы встрепенулись: все уже едят говно ложками, а наши разработчики - еще нет!
И в этой параллельной вселенной лозунг Яндекса: 75% разработчиков будут съедать 75% говна чтобы работать на 75% быстрее - мне нравится сильно меньше...
Задача, которая стоила десять дней, по-прежнему стоит десять дней, но внутри этих десяти дней у человека появились паузы: ютуб, сигареты, восемь походов на кофепоинт, да что угодно — в ожидании, когда агент допишет большую фичу и прогонит тесты.
Удивительное совпадение. Как так совпало, что автоматическая разработка оказалась по скорости равна ручной? Коллективный сговор на всех уровнях?
В авиации все понятно - скорость соответствует оптимальному режиму эксплуатации самолета, и не связана с ограниченными возможностями живого пилота. Замена человека на автоматику не влияет на скорость и время полета.
Все всегда знали (но почему-то забыли), что в реальной разработке написание кода никогда и не являлось узким горлышком.
Вот цепочка релизов у разных подразделений, разбор инцидентов, попытка выцепить архитектора для обсуждения (и даже не согласования) какой-нибудь нетипичной штуки...
попытка выцепить архитектора для обсуждения
Вот про это немного выше упоминалось. Того, кому нужен архитектор для принятия или разработки архитектурных решений — того автоматизация вытеснит одним из первых.
Конечно, такая потребность вовсе не означает ограничения собственных способностей. Часто она диктуется культурой организации. Но для профессионального долгосрочного развития это опасно.
Есть такой анектот про электрический стул и «мотивации нет».
У наёмного разработчика в большинстве случаев нет мотивации обрабатывать x10 контекстных сигналов и принимать x10 решений. У него чаще мотивация: сделать работу проще и быстрее, не платить за подписку, но чтобы заплатила компания. Это путь в никуда.
Думаю, сейчас такое время, когда особенно крепко стоит подумать: тянуть лямку 1000 неподъёмных легаси микро-сервисов в полуживой компании за зарплату или рискнуть сделать что-то своё?
В руках человека с опытом стратегического мышления, переключения и работы в режиме постоянной неопределённости без непосредственного контроля — LLM дают совершенно другой результат.
Упрощу ещё: реально существует такой сценарий, при котором нет (условных) 5 миллионов в месяц на ФОТ, чтобы нанять десять разработчиков, но есть 200 долларов, чтобы нанять 10 агентов.
Так вот в определённых руках, приделанных к определённым умам, при создании новых проектов это работает просто отлично.
Вопрос только в том, какая ценность в вашем сервисе, сделанном за 200 долларов? Кому он нужен, если каждый сможет себе сделать такой же?
Польза раньше пряталась или в экспертизе (вы обладаете уникальным знанием и умеете делать то, что другие не умеют), или в масштабах (вы вкладывали в код и набитые шишки годы времени и вагоны денег, невозможно сделать конкурента не вложив столько же). С приходом ИИ оба этих пункта обесцениваются. Проекты станет легче создавать, но именно поэтому и ценность их будет падать, как и возможность с них заработать что-то большее чем вернуть те самые 200 баксов за потраченные токены
Вопрос только в том, какая ценность в вашем сервисе, сделанном за 200 долларов? Кому он нужен, если каждый сможет себе сделать такой же
Хороший и правильный вопрос! Ответ: посмотрим, время покажет.
Но у меня есть реальный опыт успеха людей, которых я знаю лично, которые на этих самых 200 долларах стартовали и добились успеха. Без этого у них физически ничего не получилось бы.
Но и личный навык управления в условиях неопределённости и непредсказуемости — важен.
И что они сделали? Я пока наблюдаю что на ИИ хайпе иногда быстро сляпанные агентами проекты хайпуют и взлетают, потому что угадывают момент. Но не становятся стабильным бизнесом, так как они легко повторяемы. Что сделал один за 200 баксов — сделает и другой. В итоге получаем в ИТ ситуацию как в мелком бизнесе с низким порогом входа: все сидят на крохотной марже и едва сводят концы с концами. Так как как только где‑то появляется более прибыльная ниша с большей маржинальностью — в нее тут же устремляется толпа, благодаря низким затратам на вход. И высокой конкуренцией роняют доходность обратно на уровень плинтуса.
Вижу что то же самое постепенно придет и в ИТ (уже приходит).
https://lolka.app/. На сайте есть ссылки на публикации о проекте.
Я смотрю на многие вещи через призму опыта инженера, который стал руководителем. Не хочу негативить и драматизировать, но:
- Современный ИТ-менеджемент в больших компаниях и коллективах очень схож с агентской разработкой (исторически и давно).
- Менеджер команды инженеров очень похож на менеджера команды агентов, у него для этого лучшая подготовка: он не сдаётся, держит фокус на важном, умеет переключать контекст 80 раз в день, «попинывает» и «допинывает», регулярно уточняет, систематизирует информацию в план, задаёт правильные вопросы, которые рушат текущее понимание, что всё в порядке.
- То, что вожделенно привлекает разработчиков в большие, успешные и сытые ИТ-компании: довольствие, комфорт, стабильность, супер-процессы, отложенный вестинг — в долгосрочной перспективе для большинства (не для всех) является путём деградации. Дорогой в один конец. Просто на физиологическом уровне.
- Сейчас самое время всем инженерам научиться мыслить стратегически, на дальнюю перспективу. Происходит решающий передел реальности, примерно такой же, как с появлением интернета.
Я верю, Яндекс не настолько упростился с уходом основателей. За красочным и местами глуповатым пресс-релизом стоит, возможно, пока только подсознательное понимание экзистенциальной угрозы. Суть её в том, что в самом ближайшем будущем победят команды-«киборги»: объединяющие способности опытных инженерных менеджеров, управляющих очень компактными командами инженеров (5-10 человек), в свою очередь управляющих тысячами агентов.
Раздутым-передутым аналитиками, архитекторами, тестировщиками, продактами, разработчиками всех видов, да кем попало, командам — не жить.
Выход: заранее стать частью коллектива новой формации, либо сделать свой продукт.
Тут есть такой момент, что вот этот эффективный менеджмент, который призывает разрабов выдавать в 10 раз больше, ведь "даже я могу", на самом деле вряд ли хочет заниматься этим вместо разрабов. Так шта если такая конструкция наступит, как вы описали, то большей части менеджеров так же придется в утиль, ведь "кмпактной командой инженеров" управлять нужен один компактный менеджер тоже ) много не надо.
Который призывает разрабов выдавать в 10 раз больше, ведь "даже я могу", на самом деле вряд ли хочет заниматься этим вместо разрабов
Понимаю, разделяю.
Но лично для меня прерспектива создания команды из пяти, которая выдаёт, как команда из ста, так что при этом пропадает вся эта дейлик-рутинна «не мытьём, так катаньем» и вместо неё можно испытать счастье видеть конкретный результат от личного участия в разработке при большей ответственности — просто превосходная.
Уверен, через довольно короткое время команды так или иначе сократятся. И потерявшиеся разработчики будут проситься «пустить их под грибок», как в той детской сказки. А им будут отвечать: самим места мало.
Вы описали какого-то достаточно ленивого разработчика, которому на самом деле не очень то интересно писать код. Такому разработчику лучше стоит задуматься о том, а чем ему на самом деле интересно заниматься.
У разработчиков же, которым правда нравится быть инженерами, проблема иного характера: они становятся по сути руководителями группы агентов, которые не ноют и готовы работать без перерывов и сна, пока есть квота. И вот у таких сильных разработчиков как раз противоположная проблема: AI-горячка. Они начинают постоянно смотреть, как там агенты, не надо ли им дровишекзадач подкинуть новых, используют всякие claude remote, и т.д., ну и начинают выгорать. У них, естественно, производительность становится кратно выше.
Вы описали какого-то достаточно ленивого разработчика
Это собирательный образ из реального опыта взаимодействия и руководства. В нём есть ещё такое явление, как «слева IDE, справа Youtube». Проблематику «уволился из Яндекса, вышел в другую компанию, а там подписку не оплачивают. Самому что ли покупать придётся?» тоже доводится слышать.
И вот у таких сильных разработчиков как раз противоположная проблема: AI-горячка. Они начинают постоянно смотреть, как там агенты, не надо ли им
дровишекзадач подкинуть новых, используют всякие claude remote, и т.д., ну и начинают выгорать
Полностью поддерживаю. Возможно, у меня плохой кругозор или кривая выборка, но таких в моём представлении единицы.
Своего рода эффект: я вкладываю силы — оно едет, вкладываю ещё больше — едет ещё быстрее, вкладываю сколько есть.
Достаточно поиграв в dwarf fortress я вполне осознаю, что быть нянькой смотрящей за толпой имбецилов с суициидальными наклонностями - совершенно не то, чем лично мне хотелось бы заниматься.
И не только мне.
И это со временем перерастет для бизнеса в огромную проблему.
Нельзя просто так взять и заставить инженеров менять подгузники, можете легко без инженеров вовсе остаться.
в буквальном смысле пишет за разработчика код, разрабатывает архитектуру решений — и делает это невероятно быстро и чуть ли не с каждым месяцем всё более точно
Я регулярно пытаюсь посмотреть, что всякие ИИ пишут с т.з. SQL, и могу сказать, что более точно не становится - всё та же шляпа, которая работать будет, но плохо. Так что я бы сказал, что это не ИИ развивается для тех кто её постянно использует, свалив всё на неё.
Тут лучше привести примеры: какие конкретно модели, какие задачи и каков критерий «плохо».
Есть некоторые сомнения, что в деле «перекладывания джейсонов», одной из ключевых задач большинства интернет-проектов, модели справляются очень неплохо.
Раньше смотрел чатжпт, дипсик, копилот и ещё что-то редкое, со временем количество уменьшил просто потому что они развиваются примерно одинаково.
Критерии… С этим мне будет сложней объяснить, потому что когда видишь код, видно где и почему будет работать плохо (исключение когда возможно объяснить почему именно так сделали). Это примерно как я смотрел 1С работает с МС СКЛ.
Попробую сгенерировать пример - нужно для пользователя сгенерировать все его задачи, всё дерево подчинённых с их задачами, посчитать среднее время выполнения при определённом статусе, количество текущих открытых, и ближайший срок выполнения одной из задач. Это фактически один запрос, который оптимизатор МС ещё в 2014 научился справляться как лучше строить план, в котором будет пяток оконных функций и группировка с небольшим деревом. Что сделает ИИ - как минимум 3-4 темповских таблицы куда сложит нужное и скорее всего пятую куда сложит результат, который потом покажет.
Не могу оценить “перекладывание джейсонов” с т.з. программирования, только знаю что это “ширпотреб”. Однако и в “ширпотребе” SQL можно таких дров нарубить, с чем ИИ справляется по умолчанию. Если раньше я мог сказать ускорил запрос с 4-х минут до 1.5 на 2ТБ базе (основано на реальном случае), то теперь я говорю, что преобразовал процесс с запросами выполняющийся 2 часа в 20-25секунд, или запрос выполняющийся 3.5 часа в 1м15-30сек. Правда первый процесс не был написан ИИ (просто потому что древний), но уши опознаются, а второй точно был написан с использованием.
Что сделает ИИ - как минимум 3-4 темповских таблицы куда сложит нужное и скорее всего пятую куда сложит результат, который потом покажет
Думаю, это заслуживает свежего эксперимента с Opus 5, например, и запросом на контроль эффективности плана и задела на большой датасет
просто потому что они развиваются примерно одинаково
И почему же я не верю, что вы как-то серьезно использовали ИИ и писали нормальный промт, со всеми ограничениями.
что преобразовал процесс с запросами выполняющийся 2 часа в 20-25секунд
У меня ровно обратная история - ИИ пишет оптимизированные запрос. Важный нюанс - только при учёте, что вы ему дали схема базы, дали версию БД и задали четкие рамки что именно надо оптимизировать.
Попробую сгенерировать пример
Дайте для примера реальную схему ваших данных, мне даже интересно как с ней ИИ справится.
И почему же я не верю, что вы как-то серьезно использовали ИИ и писали нормальный промт, со всеми ограничениями.
Этому может быть много причин. Со своей стороны предположу, что примерно по тому же - я предпочитаю потратить время на то чтобы сделать быстро самому чем описывать-проверять-править-описывать-проверять-править и так по кругу. Промт именно описанный. Для примера у меня немного поднялась бровь, когда я прочитал комментом выше, что “эффективность плана и задел на большой датасет” надо описывать отдельно, то есть когда надо обговаривать “не тяп-ляп на коленке” и это не подразумевается по-умолчанию
У меня ровно обратная история - ИИ пишет оптимизированные запрос.
Важный нюанс - только при учёте, что вы ему дали схема базы, дали версию БД и задали четкие рамки что именно надо оптимизировать.
Наверное я из староверов, кто считает, что сами данные должны храниться исключительно локально в полностью подконтрольном тебе месте, а не где-то в облаках и прочих виртуалках хостера под честным словом агримента. Но нет, пожалуй даже схему данных я не буду шарить ИИ, хотя конечно же я верю честным словам, что мои запросы в ИИ никуда не сохраняются, не обрабатываются и уничтожаются после окончания сессии.
задали четкие рамки что именно надо оптимизировать.
Время выполнения запроса. Вот я без схемы могу сказать почему запрос отвратителен. Если же запрос сам по себе выглядит неплохо или не может быть отвратительным по умолчанию (простой инсерт) я могу предположить, что не так происходит со временем. То есть возвращаясь в ранний пример не нужна совсем схема для того чтоб вырезать темповские таблицы там где не нужны совсем, убрать фильтры функциями, убрать OR таблиц и другие весёлые вещи даже не зная схему.
Дайте для примера реальную схему ваших данных
Ладно, опустим за скобки, что я работаю с очень чувствительными данными (часть из них медицина), но Вы просите у ДБА дать реальную схему данных доступа к которым у Вас нет? :)
дать реальную схему данных
и
схему данных я не буду шарить ИИ
Во-первых, у вас выше было "сгенерировать пример", ни о каких живых данных речи вообще не было (слово "реальные" у меня было в том плане, что настоящую схему, а не на коленке абстрактное описание). Просто от схемы данных зависит вообще всё, если вы DBA, то странно вам такое объяснять. Второе, если схема данных у вас это что-то секретное, то у вас явно что-то не так с этой самой схемой. Ну есть у меня таблица "users" со столбцами "name", "email" и "phone", что из этого NDA?
Время выполнения запроса
не всегда время выполнения это есть цель. Иногда надо и память экономить, иногда диск, иногда сеть. А иногда и кол-во кода и переносимость между версиями SQL (а то и видами баз данных)
Но в общем-то примерно понятно, вы давали ИИ-шке абстрактные данные, и на абстрактных данных она вам давала абстрактные ответы :) Вполне логично :)
“не тяп-ляп на коленке” и это не подразумевается по-умолчанию
Вы удивитесь, но людям это тоже надо ставить как условие. Всегда и обязательно. Ибо человек вообще по умолчанию будет экономить в первую очередь самый важный для него ресурс - потраченное время.
Вы удивитесь, но людям это тоже надо ставить как условие. Всегда и обязательно. Ибо человек вообще по умолчанию будет экономить в первую очередь самый важный для него ресурс - потраченное время.
100%.
Успех нейронных сетей во много связан с двумя вещами: прорывными достижениями в области исследования физиологии человеческого мозга, анализом гигантского объёма данных вход-выход, полученного по результатам выполнения реальных задач.
Во-первых, у вас выше было “сгенерировать пример”, ни о каких живых данных речи вообще не было (слово “реальные” у меня было в том плане, что настоящую схему, а не на коленке абстрактное описание). Просто от схемы данных зависит вообще всё, если вы DBA, то странно вам такое объяснять.
Очень странно такое слышать, когда видишь объективно хреновый код, который понятно почему хреновый и без схемы. Это примерно как не надо пробовать какахи, чтобы осознавать что это такое и неважно что было съедено для их производства.
Второе, если схема данных у вас это что-то секретное, то у вас явно что-то не так с этой самой схемой.
Если вы не знаете, что можно сделать со схемой зная схему, то я не буду показывать направления атаки. Но вы могли потренироваться на том же сдэке, чтобы понять почему не стоило шарить схему открыто.
не всегда время выполнения это есть цель.
Объясните это бизнесу, ага.
Иногда надо и память экономить, иногда диск, иногда сеть. А иногда и кол-во кода и переносимость между версиями SQL (а то и видами баз данных)
диск - я не буду в пятисотый раз говорить про темпдб и тем более не буду объяснять как влияет диск, но 1С милые ребята, говорят что у некоторых стоит чуть ли не жидкостное охлаждение кто их решение использует.
сеть - технические данные, если юзер хочет их это проблема менеджера, консёрн можно выразить, но не более. Ах да, из запроса это тоже может быть видно, а также из-за количества, но это уже статистика, а не конкретный запрос и этот вопрос уж точно не к ИИ.
память - технические данные. Да, по запросу можно увидеть, но я не предскажу, что если запрос хреновый, то он будет из-за памяти. Конечно если фильтр стоит в конце, очевидно что запрос хреновый, верно? Ну и смотреть план, может запрос хороший, а нужен тюнинг.
Но в общем-то примерно понятно, вы давали ИИ-шке абстрактные данные, и на абстрактных данных она вам давала абстрактные ответы :) Вполне логично :)
нет. Я абстрактный пример привожу сюда, с аналогом которого я сталкивался и скармливал. Где-то мясяца 4-5 назад я конкретный пример брал с рабочего места немного его обфусцировав, убрав поля (которые не влияют на суть) и т.п. Всё было тоже самое, вместо технического решения на двойной partition by (я потом сам дошёл) они мне всё ещё пихали темповские таблицы.
Вы удивитесь, но людям это тоже надо ставить как условие. Всегда и обязательно. Ибо человек вообще по умолчанию будет экономить в первую очередь самый важный для него ресурс - потраченное время.
Да, я удивлюсь, потому что человек обучаем. Есть люди которым раз покажешь и они сразу потом начнут делать нормально, что ты просто задашь уточняющие вопросы, есть люди которые каждый раз переделывают, но это уже вопрос менеджера. Если и менеджер деревянный, то у тебя есть подтверждение, что ты выразил своё несогласие, в случае разбора необходимо просто дойти до адекватного менеджера выше.
То есть можно сделать на коленке, если у тебя разовое исправление (но опять же если научился на нормальное, то даже на коленке будет выходить ок), но в релиз тащить стабильную шляпу… Хотя убедить адептов “срочно фичу в прод” у меня никогда не получится.
потому что человек обучаем.
Вы не поверите - memory.md
Остальные откровенные глупости даже комментировать не буду, просто потому, что я вам пытаюсь объяснить, что ИИ это инстурмент, и его надо правильно использовать, а вы мне философию, удачи там в вашем 99м году.
Вы не поверите - memory.md
Нет, не поверю. Стабильно из 10-15 человек 2-3 обучаемы очень хорошо (на раз-два), человек 5-7 необходимо пару раз повторить/переучить. И остальные только через люля.
ИИ это инстурмент, и его надо правильно использовать
А я с этим не спорю, т.к. сам использую ИИ. Вот только я говорю, что там где необходим хороший результат его использовать нельзя. А там где неважно и сэкономить ТВОЁ время вполне можно. Оплачиваемое работодателем - не твоё время. И да, используйте его на SQL, мне несложно объяснить потом начальству что и почему сделано не так.
удачи там в вашем 99м году.
Спасибо, удачи вам с вашими новыми проектами в новых местах.
Для примера у меня немного поднялась бровь, когда я прочитал комментом выше, что “эффективность плана и задел на большой датасет” надо описывать отдельно, то есть когда надо обговаривать “не тяп-ляп на коленке” и это не подразумевается по-умолчанию
Мне довелось создавать сотни задач для разработчиков, в разных культурах и трекерах.
Подобные постановки (проверить план, убедиться, что есть индексы под план, предусмотреть режим деградации, сделать инструментирование RED, самые разные «убедиться», «предусмотреть», «проверить») я пишу на автомате в течение многих лет, это не стоит мне видимых усилий, не воспринимается предосудительно и никогда не вызывало негативной реакции у команд. Это проявление уважения к коллегам, пример здоровой инженерной формулировки, несколько даже упрощённой под современную динамику. Я в буквальном смысле могу сам без какой-либо помощи и подготовки сделать с нуля декомпозированную задачу на серьёзный функционал за 10-20 минут. Добавить туда ссылки, источники данных (убедившись, что они валидны) и контакты нужных людей
И пишу я это именно в том буллет-строка формате, который не только удобно воспринимается людьми, в том числе беглым чтением по диагонали, но и идеально подходит и для промта.
Возможно, именно такое восприятие по-умолчанию и делает мой взгляд и оценку результата отличной от других. То есть я привык постоянно и на потоке, в режиме троттлинга внимания, аварий и размытого контекста обеспечивать потоковый результат нужного качества, чего бы это ни стоило.
Вероятно, это и есть преимущество менеджера, которое многократно умножается LLM.
убедиться, что есть индексы под план
Моё мнение - нельзя давать разработчикам отвечать за индексы, только если таблица данна под специфичную задачу конкретному человеку. Потому что иначе потом разбирать Авгиевы конюшни. Реальный пример - почистка индексов из 2.5ТБ базы сделала 2ТБ, просто удалены и оптимизированы дубли.
проверить план, убедиться, что есть индексы под план, предусмотреть режим деградации, сделать инструментирование RED, самые разные «убедиться», «предусмотреть», «проверить»
Да, я поступал тут по-другому, есть инструкция (буллет-строка), аналогия с чек-листом, и каждый раз когда делать нужно проходить по ней, о чём при онбординге и в процессах расписано. То есть я писал один раз и потом ссылался вместо описывать каждый раз.
Вот что я имею в виду по-умолчанию. Каждый раз всё это расписывая с нуля и не забыть случайный штрих… Быстрее сделать самому, потому что даже чек-лист выше не подходит для каждой ситуации, в одном надо выкинуть одно, в другом другое (кстати как с резюме под конкретную вакансию).
Если же мне надо что-то другое от конкретного человека, я пишу что мне надо, когда мне надо и в каком виде. Остальной микроменеджмент это на его усмотрение (все взрослые люди). А мне лично пользоваться результатом. И если результат не такой, я опишу, что не так. Всё-таки он спец в своей области (или нет?).
И пишу я это именно в том буллет-строка формате, который не только удобно воспринимается людьми, в том числе беглым чтением по диагонали, но и идеально подходит и для промта.
Вам повезло не сталкиваться с людьми читающими или через строку или только первый пункт. Пока я был менеджером, я очень много таких повидал и даже если ты пишешь чёткие шаги с нулевой водой, процентов 40 людей не прочитают какую-то часть. И приходилось в голове держать с десяток процессов и проектов, что на какой стадии, в ком затык и чего ожидаем, чтоб всегда можно было ответить на вопросы выше или рассказать о сроках как продвигается. Но это я предпочитал держать процессы под контролем а не действия людей и предпочитаю поменьше общения, иначе оно растягивается и уходит.
Забавно, что применена метафора с самолётами, хотя корректнее была бы метафора с поездами. Там тоже уже довольно долго есть автоведение. И точно так же основная задача машинистов - нести ответственность. И значительная часть локомотивного оборудования тупо следит, чтобы машинист не спал...
Автор попал в самую боль. Аналогия с автопилотом и complacency это просто стопроцентное описание того, в какой тупик мы сейчас катимся.
Расскажу свою историю с другой стороны баррикад. со стороны найма. Последние пару лет я как раз существовал в режиме такого "вайбкодера на автопилоте": писал код через ИИ-агентов в 10 раз быстрее. Думать самому стало просто экономически невыгодно. А полгода назад меня сократили.
И вот я вышел на реальный потяжелевший рынок со своими красивыми, чистыми репозиториями. И на первом же интервью мне задают тот самый вопрос: "А что конкретно из этого написали лично вы, без подсказок?". И тут наступает тот самый бэээм и тотальный тупняк. Навык ручного пилотирования ушел. Мозг атрофировался настолько, что базу, которую раньше щелкал как орехи, вспомнить без чата не можешь. В итоге: 1000+ откликов, стена отказов и игнора. Мы действительно превратились в операторов, но рынок внезапно снова захотел инженеров.
Накипело так, что я записал видео-выговор про этот замкнутый круг, деградацию мозгов и фейлы на собесах. Если кто-то сейчас тоже проходит через этот ад - то приглашаю на чай https://youtu.be/hXNLuCg5irA . Автору огромный респект за разбор, это лучшая статья на Хабре за последнее время. (без шуток)
У меня противоположная ситуация.
За последние 2 года вижу следующую тенденцию: СТО больше не одобряет такси в джире длиной более 2 дней. Не важно какого она объёма технически.
Да, аналитикам бывает нужно и неделю и две походить по кабинетам, но когда бизнес логика понятна - на решение 1-2 дня. И в целом разработчики успевают.
На баги - в течении дня катится хотфиксом, включая поиск решения, тестирование и деплой.
ФОТ не вырос. Уже год никто не увольняется и никого не принимаем. Любые возрастающие хотелки бизнеса успевает решать текущая команда.
Компания среднего уровня, разработчиков несколько десятков. ИИ используют все, у многих есть свои локальные сервера. Но ответственность за качество кода пока на разработчике.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Размышление: куда прилетят разработчики «на автопилоте»?