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