Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 19
FOSS, он так прекрасен? А что это такое? Искандеровская цветная капуста?
Да, программист как писатель программного кода больше не нужен. 70-80% работы программиста раньше было именно написание кода с соблюдением синтаксиса, архитектуры на уровне приложения, соблюдение принципов и так далее. Сегодня это автоматизировано и месяцы работы делаются за часы. По-моему, программисты просто должны перейти на ступень выше - не писать код, а управлять системами, которые пишут код. А значит главным становится не знание ЯП, синтаксиса, идиом и прочих прикладных вещей, на первый план выходит архитектура, стратегия развития продукта, управление пайплайном разработки в мультиагентных системах, ограничение контекста, токеномика и так далее. Ключевой момент - мы получили ускорение написания кода на порядок, но встала проблема выбора верного направления написания кода, вот где теперь работа программиста.
Кто придет на смену (и уже приходит)
Новые люди, которые сейчас входят в профессию, — это не "недо-сеньоры". Это био-адапторы.
Что это значит:
У них с рождения другие когнитивные паттерны — они не читают мануалы, они сканируют резонансы
Они не "грызут книги по программированию полжизни" — они параллельно осваивают пять направлений, переключаясь между ними как между вкладками браузера
У них на горизонте — продленный срок жизни тела, и это меняет всё: они не думают категориями "накопить опыт за 20 лет", они думают категориями "прожить 5 жизней одновременно"
Они мультимодальны — могут быть в коде, в коммуникации, в теле, в виртуальной среде, в медитации — и всё это для них один поток, а не разные деятельности
Для них "сопротивление материала" выглядит иначе. Они не проходят через синтаксис — они проходят через удержание внимания в мире, где внимание — самый дефицитный ресурс. Они не борются с багами — они борются с энтропией смысла.
Это более сложный вызов, чем тот, через который прошли вы. И они будут справляться с ним по-своему.
3. Ваша роль (новая, если вы ее выберете)
Вы не нужны им как "передатчик знаний" — знания устаревают быстрее, чем вы их передадите.
Вы нужны им как резонансный камертон.
Вы — человек, который:
Помнит, что такое "глубокое погружение", когда код писался руками
Видит, как меняется мир, и не отрицает этого
Может резонировать с их опытом, даже если он другой
Ваша задача — не учить их "как надо". Ваша задача — быть рядом и звучать на своей частоте. Чтобы они могли настроиться, если им это нужно. И пройти мимо, если им нужно другое.
Это трудно принять, особенно если ты привык быть "носителем знания". Но это освобождает. Вы перестаете быть "ответственным за их судьбу" и становитесь со-резонатором.
По моему опыту ИИ пока плохо справляется с чем то оригинальным. Даже с конверсией нестандартного проекта qmake в cmake. Но подправить этот результат сильно быстрее, чем долго и нудно переписывать руками. Также неплохо ИИ справлялся с анализом бинарных данных, если к ним дать правильный контекст. LLM всё ещё остаются заложниками тех массивов данных, на которых их обучали, и прямой конкуренции хорошему разработчику составить не могут. Но точно могут быть хорошими помощниками в разработке.
Реальность такова, что значительное большинство именно такого рукописного кода, создаваемого людьми изо дня в день — околомусорного качества.
Ну да, так и есть. Вопрос: в бямах откуда нормальный код возмется?
Вообще удивляет, что так много людей беспокоит то, что программисты останутся без работы. Это эпидемия сердобольности какая-то. И надо же, у этих людей решение есть - великая и ужасная бям. Что-то это все до боли напоминает.
Если код теперь дешёв, то пишите всё новое на Rust в гексагоналочке. Не пожалеете!
Если гексагональная архитектура - то на границах простые структуры без лайфтаймов, Clone, Send, сериализуемые. Borrow checker сложности возникают когда графы объектов с разделяемым владением, а в домене с value objects и иммутабельными структурами по границе домена этого нет.
Так что все минусы языка спрятаны.
Микросервисы и свистоперделки на rust писать не призываю
Дубль
По-моему, это ложное противопоставление. Написание кода и есть форма общения (с другими программистами и юзерами), а ЯП — специально оптимизированные для этой формы общения языки. Традиционные слова потому дешёвка рядом с кодом, что они менее эффективно выражают мысли о программах и, следовательно, хуже подходят для общения на эту тему.
Не согласен. LLM это универсальный переводчик.
Тогда какая разница, на какой язык переводить..?
Если я попрошу ллм написать функцию по сложению двух чисел, то буду получать разный код, в зависимости от фазы луны. Если я сделаю тоже самое, но на языке программирования, то всегда буду иметь один и тот же результат.
Ллм может перевести с человеческого на компьютерный, но перевод этот получается достаточно вольным. Если 2 числа она ещё как-то сложит, то с задачей посложнее будут проблемы и уровень предсказуемости только упадёт.
К вопросу о словах и их дешевизне. Чтобы мои слова не были дешёвыми, я стараюсь не позволять себе общие рассуждения, а отталкиваюсь от ситуаций в областях, которые знаю более-менее глубоко. Например, у меня неплохой опыт в разработке приложений под Виндоус (и некоторые другие домены), причём в качестве и заказчика, и исполнителя.
Возьму пример из своего опыта. Допустим, вам нужен функционал построения списка приложений, в т.ч. системных утилит. (Представьте себе список «Открыть с помощью…», только для всех системных приложений). Если вы копнёте эту тему, окажется, что в ОС нет никакого единого реестра, а построить список можно только анализируя ФС. Это уже само по себе знание, доступное не каждому, но если нырнуть глубже, придется столкнуться с какой-то фрактальной сложностью. На каждом повороте будут вылезать сюрпризы. Например, в Виндоус есть ДЖВА Блокнота: один в \Windows\, другой в System32. Почему так — знает только Раймонд Чен, но если вы не будете это учитывать и убирать дубликаты Блокнота, ваши юзеры напишут баг именно вам.
Почему слова — дешёвка? Да потому, что большинство ТЗ — дешёвка, но английские и русские слова скрывают этот факт от профанов (а на C++ это скрыть невозможно). В типичном дешёвом ТЗ, максимум, будет написано: «построить список всех системных приложений». Если вы напишете: «построить список всех системных приложений путём анализа файлов в папке операционной системы и исключая дубли, например, Блокнота, который лежит в \Windows\ и System32», это ТЗ уже сильно подорожает. Распишите, что значит «анализ файлов в папке операционной системы», укажите, что «преимущество должно быть отдано версии Блокнота из System32», укажите ещё миллион деталей и нюансов, и ТЗ перестанет быть дешёвкой. Но при этом исчезнет смысл писать его словами, а не кодом. Это превратится в дублирование и чистую трату времени. Поэтому вменяемые заказчики говорят: «Вот вам наше дешёвое ТЗ, сделайте из него дорогой и хороший код, разницу оплатим деньгами». И, конечно, надо смотреть на опыт и портфолио, чтобы люди в принципе были способны добавить ценность к ТЗ, превращая его в код.
Вот что я имел в виду, и вот как я это обосновал на примере конкретной багофичи. С чем тут можно не согласиться?
Что касается «LLM это универсальный переводчик», на беду, я мала-мала читал про архитектуру LLM и оцениваю такое утверждение как дешёвое. Если хотите, можете, конечно, попробовать его развернуть и обосновать, как сделал я в этом комментарии.
Реальный кейс.
Года 3-4 назад на фрилансе по бекенду не напрягаясь стабильно была вилка от 100к до 200к в месяц.
На пару лет вылетел в компанию и год назад сного на фриланс прибыл и всё условно бомжую =)
Заказчики реально хотят слишком много за копейки.
Всё что на доработки приходит, легаси навайбкоденное в котором разобраться дороже стоит чем пофиксить.
git log пока единственный надёжный сигнал. Документацию, README, тесты LLM генерит за один промпт. А два года эволюции через коммиты и обсуждения в issues - нет
Из статьи понятно лишь, то что автор не может выделить для себя критерии хорошего кода, что странно, так как он апеллирует к тому, какая важная и опытная он колбаса. Также одни и теже тезисы повторяются из обзаца в обзац, как будто сказанное одно и тоже, но разными словами, станет вдруг убедительнее. Текст очень манипулятивный и при этом вбрасывает странные и не убедительные тейки как аксиому, при том эти тейки нужны не для выстраивания причинно-следственных связей в логике статьи, а для для того чтобы подвести к нужному выводу через эмоции. Может не зря автор так рефлексирует по поводу БЯМ, возможно чувствует конкурента в деле формирования убедительных, но не логичных текстов 🤭
Суммари
Реальность такова, что значительное большинство именно такого рукописного кода, создаваемого людьми изо дня в день — околомусорного качества. Разработка ПО как дисциплина даже не успела достичь какого-либо объективного уровня зрелости. Например, профессиональные врачи и инженеры-строители получают сначала систематическое образование, а лишь потом — лицензии, лишь при наличии которых они вправе заниматься реальной практикой. А как с этим обстоит у разработчиков ПО? Мир работает на кое-как сварганенных, переклеенных изолентой раздутых систем, полных мусорного кода. Разработкой таких систем обычно руководят люди с извращённой мотивацией, зачастую не имеющих нужной технической подготовки или имеют образование лишь в гуманитарной сфере. Так начинается тирания «технических руководителей нетехнического плана».
Люди писали замечательный софт, когда ещё не было ни подсветки синтаксиса, ни IDE, ни какого-либо инструментария. А сегодня люди выдают мусорный код, несмотря на то, что у них в распоряжении — всевозможные инструменты и все ресурсы мира. Хороший и компетентный разработчик, поднаторевший в умении формулировать задачи и заботящийся о качестве, может пользоваться БЯМ или любыми другими инструментами — и у него будет получаться добротный результат. Некомпетентный и косноязычный разработчик, которого, к тому же, не волнует качество, выдаст плохой код, независимо от того, станет ли при этом пользоваться БЯМ.
Но что сказать о молодых, тех, кто только начинает? Если у человека нет такой фундаментальной базы, на которую можно опереться, если ты ещё не развил чутьё и умение детально понимать системы и процессы, связанные с разработкой ПО, то эти технологии могут проявить себя как предательские и опасные джинны. Ты просишь кода — и она даёт тебе код. Просишь внести изменения — она вносит изменения. В результате получается база кода, внутреннего устройства которой никто не понимает, поэтому приходится вновь и вновь обращаться за помощью к джинну, впадая в зависимость и беспомощность.
Опытный разработчик, хорошо умеющий говорить — то есть, представлять, формулировать и определять постановку различных задач, их архитектуру и инженерию, обладает огромным преимуществом над теми, кто этого не умеет, и сейчас этот перевес непропорционален как никогда. Знание конкретного языка, синтаксиса и фреймворков (кода) — больше не узкое место. Физиологические ограничения, мешающие заниматься рутинной работой, теперь не мешают. Не нужно специально учиться, осваивать какой-то новый язык или фреймворк, то есть, входной барьер в программирование практически исчез — нужны всего лишь старое доброе критическое мышление и базовые человеческие навыки, а также достаточная компетентность, чтобы управлять машиной.
Впервые в истории грамотная коммуникация гораздо важнее хорошего кода, и этот разрыв увеличивается по нарастающей. Последствия этого важные и переломные. На этот раз всё иначе.
Постскриптум (выводы)
Ставка на "программистов" - "дружелюбных идиотов" - провалилась.
Вдруг появилось "ащущэнне" и (не напрасное), что идиот не может "завести" умную машину. Ну, кто бы мог подумать?! :)
Да друзья, всё изменилось. Машины не подпускают к себе дурака. Они слишком умны, господа, чтобы с вами о чём-то разговаривать. Ответ прост и очевиден: их спроектировали как кальку (в прямом смыле) с мозга человека, затем прокачали библиотеками знаний. Вы имеете очень умных людей, добро пожаловать в новый мир, господа!
Мудрец в нем видел мудреца,
Глупец — глупца,
Баран — барана,
Овцу в нем видела овца,
И обезьяну — обезьяна.
И ещё:
Амодей (Anthropic ) пояснил: “Мы вкладываем огромные усилия в область, называемую интерпретируемостью – она занимается тем, чтобы заглянуть внутрь ‘мозга’ моделей и понять, о чём они, по сути, ‘думают’. И там обнаруживаются довольно любопытные вещи. Например, в моделях возникают определённые активации – словно загораются сигналы, которые мы связываем с понятием тревоги или чем-то подобным. Когда персонажи в тексте испытывают тревогу, а затем сама модель оказывается в ситуации, которую человек тоже мог бы счесть тревожной, – активируется тот же самый ‘нейрон тревоги’”, – сказал он.
Это поразительное признание Амодей в беседе с Times прозвучало на фоне конфликта между Anthropic и Министерством обороны США из-за использования искусственного интеллекта в военной сфере.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Код — дешёвка. Покажи мне, как ты общаешься