В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.
Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы.
Что касается чистоты кода: использование отступов и понятных названий функций, переменных и классов уже считалось большой аккуратностью. Для первого поколения ПО, в общем-то, и не предполагалось, что можно эффективно и полноценно работать с чужим кодом. Появление специализированных библиотек считалось подспорьем, но предполагало, что программист и сам должен быть способен написать подобное с нуля. Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».
Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
Однако нужно понимать, что это не суть программирования. Программирование — это умение решать любые задачи с помощью ЭВМ, а поддержка кода лишь часть работы. Этот навык востребован лишь локально, исходя из конкретного пула задач (типизированные большие проекты, рассчитанные на конвейерное проектирование).
Сейчас, с появлением языковых моделей, мы видим очередную смену парадигмы: часть процессов кодирования стала беспрецедентно дешёвой. То же самое можно сказать про рефакторинг и анализ кода. Текущее поколение, считающее своим ключевым навыком не креатив и алгоритмизацию (в отличие от их предшественников), а аккуратность, стабильность и софт-скиллы, воспринимает создание ПО с помощью LLM как бы «ненастоящим» (так же, как в 90-х «системные программисты» презрительно относились к «прикладушкам»). Но всё будет решать требования бизнеса и, соответственно, бизнес-процессы.
Сложно сказать, как это будет выглядеть в дальнейшем, но скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием. Понимая скепсис в отношении надёжности такого подхода, можно возразить, что такие проблемы давно решаемы, в том числе с помощью независимых систем.
В каком-то смысле 2020-е — это новые 90-е в IT, когда на сломе старых систем они становятся дорогостоящими, медленными и неэффективными, и снова становятся востребованными «хакеры», которые смогут быстро, дёшево и эффективно строить новые модели IT-систем, в том числе используя интуитивный, креативный подход. На передний план выйдут архитекторы и бизнес-аналитики, причём ключевым навыком будет именно построение самих моделей бизнес-процессов в разработке ПО.
Впрочем, пока не ясно, в какой степени можно будет доверять создание архитектуры LLM. Уже сейчас она справляется с базовыми шаблонами, но где границы — непонятно. С другой стороны, совершенно очевидно, что со снижением цены разработки коммерческое ПО станет в разы сложнее, а нынешние лидеры уйдут со сцены (пример — ABBYY, который резко потерял востребованность и перспективы после появления языковых моделей, особенно опенсорсных).
Можно также предположить, что появятся совершенно новые должности и профессии — что-то вроде совмещённого архитектора и архитектора бизнес-процессов: специалиста, который настраивает системы для автоматического создания и тестирования ПО с одновременным включением в процессы тестирования отделов продаж, дизайна, UI и так далее.
Комментарии (42)
plustilino
01.11.2025 17:26скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием
Чистота кода (хорошо бы точно определить, что это) - это более дешевое его обслуживание в дальнейшем. Говнокодовую функциональность может быть проще переписать заново, чем править. Если нет, то много тестов надо будет. Автоматическое тестирование само себя разрабатывает?
TimReset
01.11.2025 17:26А ещё тесты нужно писать понятными, т.е. вот эту пресловутую "чистоту кода" нужно использовать в тестах. Иначе непонятный код будет покрыт непонятными тестами из которых непонятно будет что они вообще что-то проверяют.
K0styan
01.11.2025 17:26LLM позволяют и переписывать дёшево, так что это становится сильно меньшей проблемой.
С тестированием несколько сложнее. Описывать требуемое поведение, definition of done - так и так человеку. Но дальше... Сгенерировать систему, которая кидает на вход тестируемому нужные данные и сравнивает выход с ожидаемым - тоже решаемая задача. И опять же, эту систему можно хоть под каждую итерацию заново генерировать.
OlegZH
01.11.2025 17:26В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках.
Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки?
Во-первых, когда у Вас есть библиотечная функция, то Вы не знаете до конца, как она работает. У Вас не всегда есть её исходный код. Ситуация с чёрным ящиком суть неизвестность. Тут Вы, хотя бы, насторожитесь и постараетесь проверить работу функции. Если у Вас есть исходный код, то, конечно, Вы можете проверить этот код, но надо всегда делать скидку на компилятор. У Вас никогда не будет того самого компилятора. Да и, вообще, на самом деле, у Вас всегда будет ситуация серого ящика, когда о функции, вроде бы, многое известно, но это всё одно собрание гипотез, приходится верить на слово, а полноценное регрессионное тестирование оказывается невозможным.
Помниться, ещё в книге "Софтостроение изнутри" говорилось о безысходном программировании. Вот было бы здорово, если бы приложение печатало бы свой исходный код! Могла бы и отдельная функция печатать. Для этого надо, чтобы сами функции писались на некотором мета-языке, чтобы в коде явным образом фиксировались принятые предположения, базовые (точнее, базисные, в математическом смысле некоего базиса, из которого можно построить полностью всё пространство). Это и есть чистый код. Код, в котором нет никаких умолчаний. Код, который сам себя документирует. Код, который сам управляет своей дальнейшей трансляцией.
Во-вторых, выбор функции обрекает нас на пребывание в заложниках у её реализации. Выбрали функцию сортировки получили свои варианты работы на различных данных. А был бы использован оператор сортировки, то вопрос выбора способа сортировки можно было бы отложить на потом. Можно было бы в ОС хранить несколько различных конфигураций таких управляющих параметров на разные случаи жизни. Не говоря о такой возможности, как выбор плана выполнения приложения в момент запуска.
В этом смысле, ИИ отчасти решает эту проблему, но ИИ, фактически, работает как кривой "костыль", а для чистоты кода нужно системное решение. Ближе всего к такому системному решению находится аспектное программирование, когда код сопровождается якорями-аннотациями, к которым "прикрепляется" дополнительная функциональность, которая при дальнейшей трансформации (трансляции) программы, может стать частью основного кода. Тут, над кодом надо произвести что-то вроде ортогонализации Грамма-Шмидта, чтобы получить эффективный функциональный базис. Для этого надо будет понять, что такое ортогональность в программировании.
Наконец, в-третьих, что, отчасти, продолжает предыдущее рассуждение, засилие библиотек тормозит развитие самих языков программирования. Языки становятся похожими друг на друга, и вопрос сводится, в итоге, только к выбору определённого синтаксиса, уже готового набора инструментов и развитого сообщества. Между тем, было бы удобнее иметь отельные языки для создания пользовательских интерфейсов, для работы с базами данных, для научных вычислений, для организации тестирования, для документирования и написания компиляторов. Отдельные примеры таких специализированных языков, конечно же, существуют, но у нас до сих пор нет единой парадигмы написания программного кода с соответствующей данной парадигме программной экосистемы.
ИИ пытается заполнить эту нишу, но, за неимением указанной парадигмы, всё что делает ИИ, всегда будет в большей степени суррогатом, хотя, может быть, и имеющим яркую оболочку. Но это, как раз, говорит о засилии в индустрии суррогатного кода, создатели которого мало думают об обоснованности принятых ими решений. В этом смысле, библиотечный подход оказывается, по сути, генератором этого самого программного суррогата...
А всё должно быть наоборот: ИИ должен предложить чёткую, надёжную и достаточно полную классификационную схему алгоритмов вместе с автоматическим выводом допустимых вариантов реализации (на уровне низкоуровневых кодов, форматов хранения данных, сетевых протоколов и обобщённых вычислительных архитектур). И тогда можно будет построить некое пространство программных систем и функцию выбора определённой системы в заданных обстоятельствах и ограничениях.
akod67
01.11.2025 17:26Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки
Мне кажется все эти обсуждения хорошо / плохо происходят на планете ремесленников, которые забывают, что деньги им платит бизнес с другой планеты, которому всё это малость по барабану. Бизнес волнуют косты, а библиотеки - необходимое зло (а может и добро, если написаны более скиловаными людьми, чем собственные гребцы) для сокращения издержек.
Так же и с LLMами будет (да и уже происходит) - их использование будет требовать бизнес, так как они увеличивают скорость разработки в умелых руках. А с неумелыми и упрямыми руками что будет - думаю понятно. Будут скоро примерно в той же роли тётенек из отдела бухгалтерии в начале времён, живущих в своём изолированном мире, а потом вдруг окажется, что этот мир легко аутсорсится куда угодно, достаточно выпилить старые неэффективные, закрученные сами на себя процессы.
Jijiki
01.11.2025 17:26не знаю, главное чтобы было представление того, что вы хотите в коде например
я сделаю подсказку, может вы хотите текстовый редактор, пробуйте не ждите, не бойтесь дизайна, начинайте делать свой текстовый редактор
K0styan
01.11.2025 17:26Не уверен, что вы именно об этом. Но одно точно скажу: у кучи людей есть "страх белого листа" - это не страх в чистом виде, но психологический барьер. И возможность сделать хотя бы первый прототип, сразу пощупать руками то, что пока только в голове - уже очень большое дело.
OlegZH
01.11.2025 17:26Задачей программиста было написание в принципе работающей программы.
Это не так.
Почему появлялись различные языки программирования? Потому, что учёные (а этим тогда занимались учёные) искали способы наиболее ясного выражения вычислительных концепций. Чего, только, стоят алголо-подобные языки (Pascal, Modula, Ada)! Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном. Я бы с интересом посмотрел бы.
Кроме того, некоторые языки сами выросли на определённых концепциях: всё есть список (Лисп), всё есть связка рекурсивных функций (Форт). И, вообще, всё функциональное программирование.
А ещё имеется целая ветвь: доказательное программирование, сигма-программирование (Ю.Л.Ершов этим в Новосибирске занимался)...
Это сейчас царит подход сделать в принципе работающую программу. Гигабайт памяти не жалко. Дали бы старым программам нынешние объёмы памяти (как дисковой, так и оперативной), мы бы, наверное, удивились как они работают, но тогда не пришлось бы писать новые программы, плодить новые ошибки, и снова переписывать (далее — по кругу). Потому ИИ так и "взлетел", потому что сократилось время появления новой версии ПО. В принципе, работает? Да, работает. А теперь, покажите, пожалуйста, полученный таким образом код. Может быть, он, действительно, то, что нам нужно. Тогда его надо вписывать в учебники и делать основой для образовательных курсов. Очень хочется увидеть такой образцовый код. А то нам всякие гуру описывают, каким должен быть хороший ("чистый", "совершенный") код, а его не видно. Был бы такой код, все бы так писали. Как прописи в первом классе. (Хотя, все всё-равно. потом пишут как курица лапой. Особенно те, кто "в аптеке". ) Был бы такой код, можно было бы издать всемирный справочник, что-то вроде, Камке для дифференциальных уравнений, и пользоваться по мере необходимости. Или всё глобально автоматизировать.
SquareRootOfZero
01.11.2025 17:26Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном.
Rosetta code есть.
OlegZH
01.11.2025 17:26Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».
В прежние времена, многое приходилось изобретать самому. Обмен информации не был таким быстрым. Многое, просто объективно, со временем попадает в какую-то библиотеку и становится частью словарного запаса любого мало-мальски профессионального программиста. Сегодня надо знать, что какая-то задача уже имеет некое решение, зато это известное решение с известными свойствами. (Но и не забываем слова, сказанные ранее про "серый ящик". Это суть другая. оборотная сторона проблемы.)
Никто не мешает и сегодня называть постоянного «пользователя» библиотек таким же «ламером». Тогда, правда, придётся называть таковыми довольно много людей, включая и особо продвинутую часть сообщества, включающую т.н. «мид(д)лов» и «сеньоров», которые чрезвычайно глубоко знают целые стеки технологий. Но! Многие ли из них, действительно, способны что-то изобрести поперёк хорошо им знакомого подхода? А как же критическое мышление? Надо же уметь видеть и слабые стороны используемых инструментов! Ведь. отсюда берётся и потребность в создании новых инструментов, включая и новые, более понятные и удобные (в заданных отношениях) языки программирования!
Мы все являемся пользователями ОС. Но ОС не предлагает «из коробки» никакого средства (кроме разве что, командной строки и скриптов) для автоматизации.
Вот, смотрите, текст, который я сейчас пишу, я пишу в специальной форме, которая открывается на сайте. Неосторожное движение мышкой или нажатие не на ту клавишу может заставить браузер "дёрнуться" не в ту сторону, и я потеряю свой текст. Чтобы как-то сохранить этот текст у себя, мне приходится его копировать. Но всё могло бы быть и иначе. Я мог бы писать свой текст в приложении самой ОС, по сути, как текстовое поле локальной базы данных, в которой хранились бы все сообщения, когда-либо мною написанные на всех посещаемых мною в разные годы форумах и площадках. Можно было бы реализовать и такое, но чтобы такое сделать, надо выйти за пределы повседневного использования существующих технологий и изобрести новые протоколы передачи данных и, и, вообще, представить себе интернет без сайтов, как таковых, интернет, который ближе к фидо, бибис и гоферу.
OlegZH
01.11.2025 17:26Требования к программистам поменялись из-за изменения бизнес-требований.
Если быть точным, то эти самые бизнес-требования появились. Изначально, ведь, были только научные задачи. А уже потом подтянулся бизнес. А бизнесу нужна скорость выпуска новой продукции. Хорошо проработанное решение мешает создавать новое: зачем делать чт-то новое, если есть хорошо работающее старое?
Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
Такие требования были всегда. Поменялись сами программисты, и творчества среди них тоже стало меньше. Раньше программист мог задумываться о собственном языке программирования, собственной СУБД или CRM-системе. А сейчас? Некогда даже задуматься об этом.
shornikov
01.11.2025 17:26> А бизнесу нужна скорость выпуска новой продукции.
Разве? А я считал, что хороший бизнес это когда доходы растут быстро, а расходы - медленно.
Новый код - это расходы. Рефакторинг - ВООБЩЕ расходы в пустоту.
Выгодно, это может быть только в одном случае - если вы продаете софт.
youscriptor Автор
01.11.2025 17:26Бизнес думает о прибыли, а не о коде, чистота кода ему вообще до лампочки, это больше для удобства самих программистов.
K0styan
01.11.2025 17:26А тут лучше не гадать, а сходить к чуваку "из бизнеса" у себя же на работе и с ним поговорить)
Скорость, а точнее time to market - очень важная штука. Сделали дополнительную кнопку "продать" на страничке на месяц раньше - получили за этот месяц дополнительную тыщу покупателей.
OlegZH
01.11.2025 17:26Выгодно, это может быть только в одном случае - если вы продаете софт.
Вот компании и продают софт. Для того, чтобы продавать, нужно всегда делать новый. Это может быть и хорошо, если таким образом, методом последовательных приближений делается продукт, который действительно нужен. Но это может быть и плохо, если втюхивается нечто сомнительного качества, а конкуренты медленно затираются, чтобы не было выбора. Каждая компания выбирает сама свой путь.
akod67
01.11.2025 17:26Компании нынче продают не софт, а услугу, причём стараются делать это по подписке. И у услуги понятие "качество кода" прослеживается ещё сложнее, чем у коробки.
akod67
01.11.2025 17:26Достаточно осознать, что в годовом отчёте компании нет слова "код". Хорошо, если он там будет в виде графы IP. Соответственно бизнес такой категорией не думает. Если CTO подумал - ок, но это ДАЛЕКО не везде.
OlegZH
01.11.2025 17:26Сейчас, с появлением языковых моделей, мы видим очередную смену парадигмы: часть процессов кодирования стала беспрецедентно дешёвой. То же самое можно сказать про рефакторинг и анализ кода.
Давайте, вместо общих слов, возьмём какую-нибудь прикладную задачу и рассмотрим её различные решения и сравним их с тем. что предлагает ИИ. Если ИИ предлагает что-то дельное, то весь этот кипишь вокруг ИИ можно расценивать как проявления страха большого числа людей, к которым, наконец, пришёл оценщик (как этот бычок из детской сказки, который всех считал), и сейчас общество узнает реальную цену разработчикам. Если есть какие-то внятные принципы разработки, то почему мы им все не следуем, и не изучаем прямо в школе? Если же ИИ предлагает какую-то лажу, хотя бы и яркой упаковке (когда, на первый взгляд, всё работает, то есть — работает в принципе), то это означает (опять же!), что обучающая выборка содержит множество артефактов, то есть — общепринятым является суррогатное программирование. Куда ни кинь — всюду клин!
Всё это не означает, что настоящее программирование должно быть дорогим. Но оно обязательно должно рождаться в результате приложения определённых усилий на то, чтобы понять задачу, на то, чтобы увидеть различные варианты реализации, и выбрать из них наилучший (или предложить некую комбинацию решений, когда, в зависимости от контекста, выбирается свой вариант).
А что Вы скажете про анализ кода и рефакторинг? Зачем Вы хотите проанализировать код? Для чего Вам нужен рефакторинг?г
akod67
01.11.2025 17:26Берите конкретику. Некоторые кейсы решаются LLMами на раз. В нашей компании был опыт переезда с MSSQL на Postgres за месяц, о чём даже боялись до появления LLM думать - куча легаси хранимок, которые даже понять сложно, не то что переписать. А LLMке в этой субстанции ковыряться не страшно. Берёт и делает. Задачи переведи с одного языка на другой делаются на раз.
OlegZH
01.11.2025 17:26Сложно сказать, как это будет выглядеть в дальнейшем, но скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием.
Подождите! Как это обеспечиваться? Что же такое чистый код? Разве надёжность и чистота — это не две оборотные стороны одной медали?
Допустим, где-то в программе написано:
s = input()Допустим, выбран язык программирования Python. Здесь приведён пример чистого кода? Я, конечно же, утрирую. Но, однако, продолжим. Что мы вводим? Интересный вопрос! Это строка или число? Мы знаем, что функция
input()возвращает символьную строку. Но такая строка может содержать и число! Но мы хотим застраховаться от ошибок. Мы попытаемся написать что-то вроде.s = input() try: i = int(s) except ValueError: ...Это уже чистый код?
А если мы захотим получить число с плавающей запятой? Переделывать код? А может быть, можно переделать саму функцию
input(), чтобы она сразу возвращала значение нужного типа? А (кстати!) а от чего зависит тип возвращаемого значения? Мы могли бы сразу написать, как в Pascal'е:i: integer i = input()Это как? Ещё чище? И где, и какое тестирование здесь проводить?
youscriptor Автор
01.11.2025 17:26надежность - это покрытие тестами, а чистота - это для поддержки людьми. Не обязательно надежный код может быть читым
OlegZH
01.11.2025 17:26Чистый код (если, такой код, вообще, может быть написан) не нуждается в поддержке. В нём всё понятно. Он полностью управляем. И, кстати, полностью покрываем тестами. Мы никогда не сможем проверить все возможные входные данные, но мы мы можем проверить важнейшие классы входных данных.
Хорошим примером чистого кода является математика.
Вспомните школьную математику. Вы хотите решить уравнение или исследовать функцию. Вы понимаете. что у функции есть область определения. Если Вы об этом забудете, то Вы рискуете получить несуществующие корни. И при изложении материала, всегда явно указывается, что из чего и как определяется, разбираются пограничные случаи (например, что у нас в нуле, как расшифровывается неопределённость, вроде 0/0)...
Не стоит делать упор на покрытие тестами. Борьбы за надёжность начинается с самого начала работы над приложением, и покрывать тестами нужно уже сами исходные требования, чтобы устранить основные причины возникновения проблем ещё до начала самого кодирования. Это азы тестирования.
akod67
01.11.2025 17:26Ну вот с какого? Чистым кодом можно реализовать абсолютно неправильный бизнес кейс и именно бизнес кейс нуждается в долговременной поддержке. Меняется кейс - требуется переписывать код, и вот именно там некая "чистота и универсальность" может окупиться. Только вот правда жизни такова, что бизнес кейсы часто меняются с викидыванием кода и программистов вообще с заменой на что-то своё. Например более крупный конкурент покупает менее крупного и постеменно замещает его софт своим. 3 раза на моей практике такое было.
OlegZH
01.11.2025 17:26На передний план выйдут архитекторы и бизнес-аналитики, причём ключевым навыком будет именно построение самих моделей бизнес-процессов в разработке ПО.
Архитекторы никогда не будут на первом плане. Всякая архитектура предполагает строго последовательный способ создания любой системы. Водопадная модель! Сначала составляется полный список требований. он закрывается. Затем, по нему делает проект, где для каждого вопроса предлагается решение (ещё только "на бумаге"). И уже когда на все вопросы получены какие-то ответы, начинается, собственно кодирование. В реальности, бизнес навязывает другую модель разработки, когда, вмешательства оказываются возможны на любом этапе. В результате, полученное "здание" приходится снабжать "костылями", поскольку все элементы оказываются довольно далекими от расчётных значений. Предсказать поведение такой "системы" довольно трудно. Если, вообще, возможно.
С точи зрения архитектуры, чистый код — это такой код, который можно один раз написать и растиражировать везде. А у нас вся история программирования — это история разработи и реализации многочисленных библиотек, которые благополучно отправляются на свалку всемирной истории. Было бы качество — мы бы сейчас, могли бы писать на Хабр, например, при помощи приложения, написанного на Turbo Vision. Текстовый режим... У него были преимущества. И в смысле безопасности тоже. Не говоря о том, сколько проблем не надо было решать (там, с HTML/CSS/JavaScript).
akod67
01.11.2025 17:26Водопадная модель! Сначала составляется полный список требований. он закрывается.
Вы из какого года пишете? Agile появился именно потому, что водопада не существует в реальной жизни проектов крупнее мелкой консольной утилиты, если не рассматривать аквариумы типа NASA с одноразовой выкаткой кода в прод.
OlegZH
01.11.2025 17:26Представим, что чистый код существует. Это значит, что можно в интернете завести сайт, где будет этот самый чистый код храниться. Каждый отдельный алгоритм будет иметь свой уникальный идентификатор. И тогда можно будет формировать свою программу, ссылаясь на это хранилище. Все будут пользоваться общим кодом, а не самописными конструкциями.
Andrey_Gromov
01.11.2025 17:26Время идет, прогресс не остановишь. И с течением времени всегда меняются подходы к разработке. Такова жизнь и с этим ничего не поделаешь.
DarthVictor
01.11.2025 17:26В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.
Неудачный пример, поскольку именно алгоритмы общего назначения, которые так любят на собеседованиях, LLM-ки пишут хорошо. У них проблемы с написанием реального кода, которому приходиться взаимодействовать с остальным проектом.
Вообще LLM-ка — это как раз идеальный проходитель (или проходимец?) алгособесов. И появление LLM-мок как раз показало, что все эти требования к программистам решить задачи на листочке, это как требования к автомеханику поменять колесо при помощи только балонного ключа. И тут резко выяснилось, что андроиды делают это лучше. Хотя в реальной работе для смены колеса и кожаный и электронный автомеханик возьмут домкрат.
youscriptor Автор
01.11.2025 17:26Алгособесы - это тест не фундаментальные знания в IT и больше про умение думать. Сейчас в библиотеках, и нужны массовые исполнители, где больше не про ум, а про усидчивость и аккуратность. Поменяются требования бизнеса (который вам не друг, а инструмент как выжать из вас максимум за минимум денег) - поменяются и требования к работничкам
Arragh
Влажные мечты вайбкодера о том, что когда-нибудь (желательно поскорее) с него перестанут требовать какие-то непонятные фундаментальные знания по языку и будут брать на работу за одно только упоминание ллм.
Ну может когда-нибудь так и будет, но и зарплатой у таких «работничков» будет ветка.
youscriptor Автор
Почему вы так беспокоитесь про доходы программистов? Понятно что всю маржу с LLM заберет бизнес
Arragh
Может быть потому, что я программист и это отразится на мне?
youscriptor Автор
Как на вас отразяться чьи-то "влажные мечты"?
unicodery
сухостью в кошельке
Arragh
Пытаешься так незаметно стрелку перевести? Твой вопрос был не про влажные мечты.
P.S.: Я забыл сразу тебя поправить, что вайбкодер и программист - это 2 абсолютно разные сущности.
youscriptor Автор
Жалко бизнес с тобой не согласен - сейчас все больше компаний требуют вайбкодинг в резюме
Arragh
Ну в моем стеке (.NET) я такого не наблюдаю.
А судьба вайбкодера - работать за миску похлебки. Ибо вас, вайбкодеров, будут орды, и за каждую вакансию будете устраивать мортал комбат.
youscriptor Автор
ты на какой планете живешь? Зайди на HH - джунов типа тебя 3000 человек на вакансию