И это ещё с учётом того что AGI каждый год новый выходит ))

Как будто для большинства успех создания сайта через нейронку = успех во всем коде

Хорошее мнение. Печально - да, однако таков современный мир. Остаётся только приспосабливаться.

Да, примерно к этому же прихожу. Как будто навык теперь не только в том, чтобы самому написать реализацию, а ещё и в том, чтобы нормально поставить задачу ИИ: дать контекст, ограничения и потом проверить, что он вообще сделал. Я тоже сейчас экспериментирую с разной степенью детализации промптов - иногда чем меньше диктуешь конкретную реализацию, тем интереснее получается решение. Но контроль всё равно пока оставляю за собой.

я еще пробую разных провайдеров бесплатных.в опенкоде хорош big pickle. открыл вчера pool

Возьму на заметку, спасибо.

Matlab не привел к исчезновению математиков, хотя существует уже 40 лет. Так и с ИИ - инженер не исчезнет.

Согласен, скорее сама роль инженера будет меняться, а не исчезать. И вот здесь мне особенно интересно: что, на ваш взгляд, разработчику стоит изучать и развивать сейчас, чтобы через несколько лет всё ещё оставаться именно инженером, а не просто оператором ИИ?

Инженеру стоит развивать системное и критическое мышление, физику работы железа. Например, задача “отсортировать список” решается ИИ за секунду, но какой алгоритм выбрать и как встроить его в систему, чтобы она не упала при росте данных — это решает только инженер. ИИ никогда не спросит “а что у нас с кэшем и памятью через полгода?”. Это вопрос, который остаётся за человеком. Оператор сдаст код который работает на тестовых данных и может упасть через время на реальных. Инженер сдаст решение, которое работает и на тестовых и на реальных данных долгое время.

Вчера я обсуждал с Клодом выбор железа для бэктестинга, и дело кончилось тем что Клод верно указал на то когда процессов много, NUMA начинает оказывать влияние на то, как процессы читают из памяти, которая shmem. Потом я попросил Клода поправить питоновый скрипт, который массово запускает процессы, чтобы он учитывал NUMA. И он его поправил, даже в комментариях к коду упомянул first touch principle, о котором далеко не все знают. А это уже уровень сениора.

The point is: то, что вы пишите верно, просто это уже более не актуально -- Клод подскажет и это.

Зато матлаб, как и Фортран до него, привел к массовому исчезновению сотрудников, которые занимались расчетами на бумаге. Калькуляторы заменили логарифмические линейки, потом компы заменили калькуляторы, и так далее.

Исчезли бумажные расчётчики — появились системные инженеры. Исчезнут кнопкотыки — появятся архитекторы ИИ.

Глеб, отличный пример. Ты описал, как ИИ помогает инженеру, а не заменяет его. Клод подсказал про NUMA и first-touch, но: · Ты знал, что это может быть проблемой. · Ты сформулировал запрос. · Ты проверил ответ. · Ты интегрировал решение. · Ты отвечаешь за результат. Клод - справочник. Ты - инженер. Без тебя его совет - просто текст. А без него ты бы гуглил два часа. Так что не уровень сениора, а уровень эрудиции. Сеньор - это тот, кто знает, когда применить эту эрудицию. И это сделал ты.

Спасибо за добрые слова. Я действительно знал про то, где именно выделяeтся память (first touch principle), но я не думал об этом в данном конкретном случае – на то, что NUMA тут может влиять меня надоумил Клод. Хотя реальность оказалась куда прозаичнее: Клод поправил скрипт чтобы можно было запускать бэктестинг sweep в разных режимах (аллоцировать shmem на каждом NUMA node или нет, делать taskset или нет), и я измерил время работы в каждом. И обнаружил, что разницы почти нет. Узнав об этом, Клод впал в задумчивость, “Да”, говорит, “все это вероятно из-за того, что файл с данными у тебя маленький - 165 всего. Вероятно на 3-4 ГБ разница станет заметной”.

Я кстати уже не знаю кто тут чей оператор - то ли я оператор Клода, то ли Клод оператор меня. Наверное верно и то, и другое, сначала я руковожу Клодом, потом он меня учит жизни.

Сейчас у нас с ним беседа о том, делать ли TUI для всей этой инфраструктуры что я с ним (под его чутким руководством?) создал, или сразу все в питон-подули зафигачить, чтобы потом дергать из Jupiter Notebook. Клод подталкивает меня к последнему, и наверное я так и сделаю – буду все дергать из Jupiter Notebook. Вернее, это будет делать Клод (он об этом ещё не знает, но, похоже, догадывается), под моим чутким руководством.

Так и будет, в течение какого-то времени, это уже происходит. Потом и их отменят.

Гений, миллиардер, плейбой, филантроп)

Интересная мысль. Но мне кажется, пока главный ограничитель - legaсу и цена ошибки. Старый код нужно поддерживать, а бизнесу важно понимать риски полной автоматизации. Технически убрать человека можно во многих местах, вопрос - всегда ли это экономически оправдано.

Владимир Галков , интересно узнать, как пришли к такому размышлению?

Я работал в сфере оптимизации кода, рефакторинга, исследования утечек и поведения систем прибольшом количестве факторов. Я мыслю через удаление лишнего оверхеда.

Спасибо, что поделились мнением. Интересно было посмотреть на этот вопрос с другой стороны.

Перелопатить старый код через ии анализ теперь проще, на это уйдет года два… заодно он сильно стандартизируется… Да это текущий этап. Продлится он не долго. Смена отношений в ит отрасли происходит каждые лет 5, как выпускают новых инжереров, которые ничего не знают про старое и не учат это, начиная плодить свое. Таким образом я думаю писателей кода, плохо понимающих как он делается, но достигающих результат будет большинство. И остальных они вытеснят. А если нельзя проверить что производится, то перый шаг - максимальное упрощение. В программировании это возврат к машинному коду... Это же и сейчас просто - пусть асистент сразу делает "exe" шник и нагрузочный тест, отделным бинарником. Ну а что еще надо, если программа описана словами? :)))

Вот эта мысль про большинство, которое будет хуже понимать сам код, но быстрее получать результат с помощью ИИ, мне особенно интересна. Получается, ценность глубокого инженерного понимания может даже вырасти - просто таких специалистов станет меньше.

Вероятно это очень классный рейджбайт, но попробую выразить свое мнение🙂

"ИИ просто надо писать на ассемблере или машинном коде"- как по мне это уже выстрел себе в ногу. Абстракции в виде языков существуют в контексте работы с ИИ не потому что люди пишут код руками, а потому что инженер ответственный за разработку фичи отвечает за результат и должен проверить модуль который сделала та же ИИ. Все в бизнесе измеряется исключительно деньгами => факап ИИ в машинном коде который попал на прод = потерянные деньги, поэтому намного дешевле иметь в команде разработчика, а в помощь дать ему ии которая просто повысит его производительность.

ИИ не просто помогает писать код. Это система поиска и сопоставления, она ничего не придумывает сама. Фактически это система стандартизирует и делает код не связанных между собой программистов одинаковым. Не будет в одинаковом коде каких то непонятных проблем. В каком то смысле там вообще не будет проблем, которые можно осмыслить. Поэтому тратить на это время бессмыслено.

Специалистов станет меньше и лично я сожалею, что нас сразу было бы не много.. Потому что выкидывают по возасту :)) а в описываемой мной системе нужны нк глубокие знания, а способность распорядиться своими имеющимися. Это даже не предполагает больших знаний, но предполагает наличие каких то не подхваченых ии еще алгоритмов мышления :)

Мне кажется, здесь как раз интересная развилка: если ИИ действительно сильно стандартизирует реализацию, что тогда станет главным навыком инженера - глубокое знание того, как всё устроено внутри или способность правильно поставить задачу, выбрать решение и проверить результат?

Про стандартизацию — да, код становится похожим. Но "одинаковый" не равно "безошибочный". Если ИИ нагенерит одинаковый баг в 10 микросервисах, мы получим не стабильность, а единую точку отказа. И когда этот баг выстрелит на проде, разбираться придётся разрабу(а как если иишка сразу в машинном коде генерит?). Поэтому тратить время на проверку и архитектуру не бессмысленно, а критически необходимо. Иначе мы просто автоматизируем создание проблем🙂

Ну и не стоит забывать о том что ответственность за введенные изменения несет разработчик как проф. единица. Ключевое заблуждение здесь это абсолютная вера в гиперэффективность и безошибочность ИИ(гляньте убытки Moonwell из-за бага который нагородил claude).

Берем ученого А и ученого Б их одинаковое исследование настолько эзотерично, что требует огромной группы людей, которые общаясь между собой поддерживают научное исследование а и б, сами приходят к численным упрощениям исследований типа e=m*c "квадрат"., постоянным планка и поддержке вычисления пи каждый своими средствами. Вброс в эту среду ии сначала стандартизирует вычисление общих моментов типа Пи и научных констант, потом никто и не будет задумываться и проверять как они вычисляются. Но заказчики - ученые а и б знают. И не часто это придется делать заново. Просто уменьшается задействование людей в процессе. И в этой схеме не нужны внутренние проверки... Они бессмыслены, как бессмыслено рпюазбирать каменный нож или колесо и искать там баг. :) Результат и его реальность сопоставляют и корректируют с исследуеиыми данными А и В... Увы. Изобретено что то вроде колеса или огня или каменного ножа. Просто все, что помогало раньше, помогало не голове, а физическим возможностям. А теперь инструмент для головы.

Каменный топор или копье или колесо не имеют понятных багов, только сравнительные недостатки… потому что ими пользовались десятки тысяч лет миллионы людей. Со стандартизированными кусками кода или даже программными комплексами (от ИИ) то же самое.

Разрешите вклиниться к вам из соседней ветки.

С софтом полностью аналогично. Баг становится сравнительным недостатком. Софта без багов не бывает в принципе. Это аксиома. Где-то больше, где-то меньше – естественный отбор будет делать свое дело. Это раз.

Два. Исправить баг можно будет без его понимания. Вот примерно так: “система сейчас работает вот так, дает такой результат, а надо, чтоб давала сякой. Напиши тесты на эти случаи и скорректируй систему так, чтобы она давала все зелёные тесты (и старые, и вновь добавленные)”. Зачем тут глубокое понимание системы и инженерии? ИИ все сделает.

Мне всё же хочется думать, что финальный контроль останется за человеком. Хотя чем дальше развивается ИИ, тем меньше я в этом уверен.

А вот в том, что роли внутри команд станут более размытыми, а сами команды - меньше, я почти не сомневаюсь. Один инженер сможет закрывать гораздо больший кусок пути от постановки задачи до результата.

Да, вот с два я полностью согласен. Это и имел ввиду. А вот про баги. Хм.. Баги и недостатки алгоритма вещи разные. Баг не дает системе работать как заказано, а недостаток вставляет палки в колеса, но "машина" едет. :) перых не будет встандартизированом коде они все будут доведены до вида вторых.

Кода на асме меньше, чем на жсе, поэтому нейросеть хуже на нем пишет

Но там и учиться для начала не придется, - есть же компиляторы. Все равно с начала система обучится языкам высокого уровня.

Согласен. У себя уже замечаю похожий сдвиг: всё больше времени уходит не на само написание кода, а на то, что происходит до него. Подключаешься ещё на этапе проработки задачи, обсуждаешь бизнес-сценарии, ограничения, возможные решения, декомпозируешь реализацию - и только потом садишься писать код.

При этом сама реализация постепенно занимает всё меньшую долю времени. Поэтому граница между "кодером" и инженером действительно становится всё заметнее.

Кирилл Маканков , тут, кстати, интересен ещё один момент - как в этой модели будет меняться роль аналитика? У нас, например, разработчик нередко подключается к задаче ещё до того, как техническая аналитика полностью готова: вместе обсуждаем сценарии, ограничения и будущую реализацию.

Получается, часть технического анализа постепенно смещается в сторону инженера. Интересно, как вы видите разделение ответственности аналитика и разработчика в такой модели?

А как думаете, где это остановится? С чем ИИ не справится и чем придется заниматься инженерам? И будут ли это все еще инженеры?

Думаю, инженеров действительно может становиться меньше, а сами роли внутри команд будут заметно меняться. Всё меньше ценности будет в человеке, который просто умеет хорошо переводить готовое ТЗ в код. И всё больше - в инженере, который понимает, зачем вообще делается задача, какую проблему бизнеса она решает и какой результат должна принести.

То есть фокус постепенно смещается от "написать реализацию" к "помочь бизнесу получить нужный результат": придумать решение, оценить риски, выбрать компромиссы, использовать ИИ там, где это ускоряет работу и отвечать за итог.

Поэтому, думаю, инженер никуда не исчезнет. Скорее сама профессия станет шире: меньше чистого кодинга и больше инженерного и продуктового мышления.

Я вижу, что никакого разделения не будет. ИИ успешно справится с тем, что сейчас делают обе роли.

Мой вопрос как раз о том, как высоко придется подняться, чтобы оставить себе то, с чем ИИ не справится. Лично я пока не вижу этого предела...

Да, сейчас этот предел вообще сложно представить. Будет интересно посмотреть, где он окажется через пару лет и какие задачи в итоге останутся за человеком.

Похоже, нам в любом случае остаётся одно - адаптироваться и развиваться шире, а не только глубже в написании кода.