Кстати, интересно и то, что одного пьяного из двух пилотов автоматического самолёта вытряхивают, проверяют визуально на опьянение и задерживают ровно так же, как достали из-за руля пьяного Джастина Тимберлейка.
Вот про это немного выше упоминалось. Того, кому нужен архитектор для принятия или разработки архитектурных решений — того автоматизация вытеснит одним из первых.
Конечно, такая потребность вовсе не означает ограничения собственных способностей. Часто она диктуется культурой организации. Но для профессионального долгосрочного развития это опасно.
Упрощу ещё: реально существует такой сценарий, при котором нет (условных) 5 миллионов в месяц на ФОТ, чтобы нанять десять разработчиков, но есть 200 долларов, чтобы нанять 10 агентов.
Так вот в определённых руках, приделанных к определённым умам, при создании новых проектов это работает просто отлично.
Это тоже интересный момент! В контексте видео, приведённого в качестве примера: именно так и решил КВС, видя второго пилота вдрабадан пьяным. И, вероятно, это расхожее мнение.
Ведь он его не сдал (как можно сдать, если и выпивали вместе), сдали пассажиры и кто-то ещё, почуяв запах спиртного.
Есть такой анектот про электрический стул и «мотивации нет».
У наёмного разработчика в большинстве случаев нет мотивации обрабатывать x10 контекстных сигналов и принимать x10 решений. У него чаще мотивация: сделать работу проще и быстрее, не платить за подписку, но чтобы заплатила компания. Это путь в никуда.
Думаю, сейчас такое время, когда особенно крепко стоит подумать: тянуть лямку 1000 неподъёмных легаси микро-сервисов в полуживой компании за зарплату или рискнуть сделать что-то своё?
В руках человека с опытом стратегического мышления, переключения и работы в режиме постоянной неопределённости без непосредственного контроля — LLM дают совершенно другой результат.
Можно снова провести параллель с авиакомпаниями, для которых это прежде всего заверение пассажирам о повышении уровня безопасности и снижения человеческого фактора. Конечно, говорят и про снижение нагрузки на пилотов. Но что тут хочет сказать ИТ-компания?
Главный фактор: у сеньора добровольного желания на это нет. Большинство разработчиков думают о двух вещах: как выполнить неделю за день и как самому не платить за подписку на Клод.
Реально и добровольно выигрывают те, кто делает собственный продукт и «программирующие менеджеры».
Не могу, к сожалению, разобрать и ответить на все пункты.
Но могу поделиться мнением по одному: c работы, где нет реального импакта, развития, но есть только эмуляция, «сидение в кабине встреч», тягомотина и перетягивание каната — лучше уходить.
Лично мне представляется так, что любой код, который написал не сам, в целом читать непросто. Читать код, про который известно, что он «бездонный» — ещё сложнее.
Я уверен, что способность понимать чужой код в принципе — одна из лучших демонстраций высоких когнитивных способностей разработчика. Могут это в реальности далеко не все, неумение можно плюс-минус умело скрывать. На реальное понимание чужого кода расходуется много энергии. Выполнение такой задачи можно считать одной из характеристик внутреннего «контекстного окна» конкретного инженера.
Метафора упрощающая, да. Но я предлагаю сфокусироваться именно вокруг «ожидания» результата автоматизированного процесса и оценки результативности. Можно упростить ещё больше, до максимума и предложить пример «до LLM»: огромный релизный пайплайн, который порой может работать часами. Все зависит от конкретного психотипа человека, но далеко не каждый способен в такое время «шедулить» себе другую задачу и переключаться на неё. Большинство людей, как мне видится, начинают как бы маяться.
Мотивации описать всё это добавила та самая разработка с Клодом. При составлении плана он, хоть я его и не просил, выдал оценку сложности выполнения задачи. Вместо реальной для себя оценки в один час, он выдал «социально приемлемые» 10-15 дней.
В случае с автоматизацией работы пилотов, главный постулируемый публичный слоган, все же, — безопасность и жизни пассажиров. Это сильно развязывает руки. История с экономией и экономикой где-то остаётся внутри.
В деле «ускорения» и оптимизации разработчиков всё иначе.
Меня интересует именно проблематика переходного периода, происходящее с людьми, которые 90% смены не управляют и не программируют, но только наблюдают. Выглядит так, что в обоих случаях есть серьёзные проблемы, про которые предпочитают не думать. В разработке — точно.
Тезис про потерю навыков, которая создаёт отрицательную обратную связь, приводящую к авариям — в целом верный, но не всегда. Здесь мы, кроме прочего, не учитываем массу процессов и мероприятий, направленных в авиации на контроль и аттестацию.
И взять, например, истории катастроф Boeing 737 MAX, когда скрытая, незадокументированная автоматика пыталась скрыть конструктивный дефект. Тот самый случай «двух минут», когда лётчики должны были резко перейти из состояния наблюдателей и бороться с автопилотом через штурвал.
Это явным пример обратной логики: бонусная мотивация, требующая костылить ошибки автоматизацией и кодом, убила людей.
Пример хороший, но, слово за слово — и в обсуждении уже появился уточняющий контекст, без которого выбор варианта перевода во многих случаях не представляется возможным.
Думаю, оценка качества перевода на 200 языков в формате «один к одному» (всегда нужно выбрать самый распространённый вариант, даже если вариантов перевода десять) — практически лишена смысла.
Google использует статистические методы перевода. Когда нет непосредственной пары значений исходный язык -> язык назначения, вместо того, чтобы сказать «я не знаю», он «проходит» через промежуточный язык с возможной потерей смысла. Тем более, если этот язык со сравнительно скудным набором слов, такой как английский, где одно слово может быть и глаголом и существительным.
Попробуйте перевести «муху» с латинского на английский.
Да и столь высокие требования к качеству перевода едва уместны в конкретно этой реализации, где для каждого перевода выбирается только один вариант и отсутствует контекст.
Но я готов принять в дар токен для API, которое решит эту задачу лучше Google.
Google даёт описательный перевод «олений мох», а не словарное jäkälä . Коэффициент связи с этим вариантом получается примерно в два раза выше чем с «оленим мхом».
Тестовые запросы этимологической связи:
ягель ↔ jäkälä ≈ 0.11
ягель ↔ sammal ≈ 0.12 (ягель ↔ мох)
ягель ↔ poron sammal ≈ 0.06
Но все эти варианты ниже порога 0.5 — поэтому в этимологический кластер с RU Финляндия в автоматическом режиме не попадает.
Кстати, интересно и то, что одного пьяного из двух пилотов автоматического самолёта вытряхивают, проверяют визуально на опьянение и задерживают ровно так же, как достали из-за руля пьяного Джастина Тимберлейка.
Вот про это немного выше упоминалось. Того, кому нужен архитектор для принятия или разработки архитектурных решений — того автоматизация вытеснит одним из первых.
Конечно, такая потребность вовсе не означает ограничения собственных способностей. Часто она диктуется культурой организации. Но для профессионального долгосрочного развития это опасно.
В этом направлении работает наш коллега, Илон Маск.
Упрощу ещё: реально существует такой сценарий, при котором нет (условных) 5 миллионов в месяц на ФОТ, чтобы нанять десять разработчиков, но есть 200 долларов, чтобы нанять 10 агентов.
Так вот в определённых руках, приделанных к определённым умам, при создании новых проектов это работает просто отлично.
Это тоже интересный момент! В контексте видео, приведённого в качестве примера: именно так и решил КВС, видя второго пилота вдрабадан пьяным. И, вероятно, это расхожее мнение.
Ведь он его не сдал (как можно сдать, если и выпивали вместе), сдали пассажиры и кто-то ещё, почуяв запах спиртного.
Есть такой анектот про электрический стул и «мотивации нет».
У наёмного разработчика в большинстве случаев нет мотивации обрабатывать x10 контекстных сигналов и принимать x10 решений. У него чаще мотивация: сделать работу проще и быстрее, не платить за подписку, но чтобы заплатила компания. Это путь в никуда.
Думаю, сейчас такое время, когда особенно крепко стоит подумать: тянуть лямку 1000 неподъёмных легаси микро-сервисов в полуживой компании за зарплату или рискнуть сделать что-то своё?
В руках человека с опытом стратегического мышления, переключения и работы в режиме постоянной неопределённости без непосредственного контроля — LLM дают совершенно другой результат.
Отдельно, кстати, интересна мотивация анонсирования 75/75/75 наружу.
Можно снова провести параллель с авиакомпаниями, для которых это прежде всего заверение пассажирам о повышении уровня безопасности и снижения человеческого фактора. Конечно, говорят и про снижение нагрузки на пилотов. Но что тут хочет сказать ИТ-компания?
Спасибо за напоминание!
А то только и слышно: «тут нужно архитектора нанимать», «я не архитектор» и «это пусть тестировщики тестируют».
Плюс автомат тяги
Главный фактор: у сеньора добровольного желания на это нет. Большинство разработчиков думают о двух вещах: как выполнить неделю за день и как самому не платить за подписку на Клод.
Реально и добровольно выигрывают те, кто делает собственный продукт и «программирующие менеджеры».
Не могу, к сожалению, разобрать и ответить на все пункты.
Но могу поделиться мнением по одному: c работы, где нет реального импакта, развития, но есть только эмуляция, «сидение в кабине встреч», тягомотина и перетягивание каната — лучше уходить.
Лично мне представляется так, что любой код, который написал не сам, в целом читать непросто. Читать код, про который известно, что он «бездонный» — ещё сложнее.
Я уверен, что способность понимать чужой код в принципе — одна из лучших демонстраций высоких когнитивных способностей разработчика. Могут это в реальности далеко не все, неумение можно плюс-минус умело скрывать. На реальное понимание чужого кода расходуется много энергии. Выполнение такой задачи можно считать одной из характеристик внутреннего «контекстного окна» конкретного инженера.
Но и про чтение кода, кстати, уже было: https://habr.com/ru/news/1062634.
Метафора упрощающая, да. Но я предлагаю сфокусироваться именно вокруг «ожидания» результата автоматизированного процесса и оценки результативности. Можно упростить ещё больше, до максимума и предложить пример «до LLM»: огромный релизный пайплайн, который порой может работать часами. Все зависит от конкретного психотипа человека, но далеко не каждый способен в такое время «шедулить» себе другую задачу и переключаться на неё. Большинство людей, как мне видится, начинают как бы маяться.
Мотивации описать всё это добавила та самая разработка с Клодом. При составлении плана он, хоть я его и не просил, выдал оценку сложности выполнения задачи. Вместо реальной для себя оценки в один час, он выдал «социально приемлемые» 10-15 дней.
В тех же пресловутых видео на Юрубе есть примеры, когда неадекватная кондиция пилота определяется как раз по радиообмену в процессе руления на взлёт.
В случае с автоматизацией работы пилотов, главный постулируемый публичный слоган, все же, — безопасность и жизни пассажиров. Это сильно развязывает руки. История с экономией и экономикой где-то остаётся внутри.
В деле «ускорения» и оптимизации разработчиков всё иначе.
Меня интересует именно проблематика переходного периода, происходящее с людьми, которые 90% смены не управляют и не программируют, но только наблюдают. Выглядит так, что в обоих случаях есть серьёзные проблемы, про которые предпочитают не думать. В разработке — точно.
Тезис про потерю навыков, которая создаёт отрицательную обратную связь, приводящую к авариям — в целом верный, но не всегда. Здесь мы, кроме прочего, не учитываем массу процессов и мероприятий, направленных в авиации на контроль и аттестацию.
И взять, например, истории катастроф Boeing 737 MAX, когда скрытая, незадокументированная автоматика пыталась скрыть конструктивный дефект. Тот самый случай «двух минут», когда лётчики должны были резко перейти из состояния наблюдателей и бороться с автопилотом через штурвал.
Это явным пример обратной логики: бонусная мотивация, требующая костылить ошибки автоматизацией и кодом, убила людей.
Думается, не так просто единоличному или коллективному органу взять на себя ответственность и полностью обрезать эту нить общения.
Могу только предположить: голосовые коммуникации, спокойствие в голосе диспетчера - многое значат для пилотов.
Пример хороший, но, слово за слово — и в обсуждении уже появился уточняющий контекст, без которого выбор варианта перевода во многих случаях не представляется возможным.
Думаю, оценка качества перевода на 200 языков в формате «один к одному» (всегда нужно выбрать самый распространённый вариант, даже если вариантов перевода десять) — практически лишена смысла.
Google использует статистические методы перевода. Когда нет непосредственной пары значений исходный язык -> язык назначения, вместо того, чтобы сказать «я не знаю», он «проходит» через промежуточный язык с возможной потерей смысла. Тем более, если этот язык со сравнительно скудным набором слов, такой как английский, где одно слово может быть и глаголом и существительным.
Попробуйте перевести «муху» с латинского на английский.
Да и столь высокие требования к качеству перевода едва уместны в конкретно этой реализации, где для каждого перевода выбирается только один вариант и отсутствует контекст.
Но я готов принять в дар токен для API, которое решит эту задачу лучше Google.
Google даёт описательный перевод «олений мох», а не словарное
jäkälä. Коэффициент связи с этим вариантом получается примерно в два раза выше чем с «оленим мхом».Тестовые запросы этимологической связи:
ягель↔jäkälä≈ 0.11ягель↔sammal≈ 0.12 (ягель ↔ мох)ягель↔poron sammal≈ 0.06Но все эти варианты ниже порога 0.5 — поэтому в этимологический кластер с RU Финляндия в автоматическом режиме не попадает.
Это в точку, спасибо! Задебажу, расскажу