Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 156
Типичная история — нашёл +80к в каком-то финтехе, ему там обещали «плоскую структуру и свободу принятия решений» (спойлер: через три месяца он написал мне что хочет вернуться, но мы уже наняли замену).
"ушел кобелина к сучке крашеной, на молодость и мини позарилса, ну и чо ,приполз через пол-года, послала его, нужен он мне больно, получше нашла!". детский сад, чесслово
Лучше никогда ничего не пробовать менять? Особенно, игнорировать места, где больше денег предлагают и где возможно развитие, хотя бы горизонтальное?
Думаю @fedorez кинул свой камень не в ушедшего на +80к, а в огород автора статьи. С вашей мыслью я согласен - надо пробовать менять и не игнорировать возможности. А вот с обозначенной выше классификацией "детский сад" - нет. С чего вдруг ответное законное и не аморальное действие работодателя вдруг стало "на уровне детсада"? Конечно вам (условно), как работнику, выгодно, чтоб вы "что хотели, то и делали, и вам за это ничего не было" (метафора). Отсутствие ответных реакций работодателя в дальнейшем приведет к безграничному развитию оху...вания работников - "всё равно вы мне ничего не сделаете, я очень важный и незаменимый".
Но выборка маленькая, двух человек наняли после нового процесса,
а еще тот мидл что ушел на +80. и все с осени 2025. На 12 человек. С новогодними каникулами. Какая-то нездоровая у вас текучка...
Опыт и смысл действий заиграл совсем по другому, когда нужно не повторять, а быть творцом. На самом деле ничего страшного не происходит. Технологическая революция она такая, сначала появляются самые умные, а потом уже ее используют как надо и где надо. Хотя, грозятся, что появится AGI и всех на ноль перемножит.
Вы живете в старой парадигме найма и создания софта. Надо уметь не только писать код, а еще уметь в архитектуру, алгоритмы. Через 3-4 года, когда 98% кода будут писать роботы, нужны будут люди, умеющие целиком охватить проект и направить в нужное русло всю разработку. С контролем, тестами и т.д. и т.п. И всякая мелочевка, "типа как называются переменные", "сколько тут if-ов" и т.д. отойдет на 5й-10й план. Так что Диму нужно было поддержать, исправить его косяки, и внедрить в свою систему, используя его лучшие стороны. Ведь по факту он работал за двоих, получая одну з\п. Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК. Это при том, что вам все равно это придется делать через пару лет (а может и раньше). Не с Димой, так с кем то другим. Дима просто не вовремя пришел ))
Ведь по факту он работал за двоих, получая одну з\п. Код пишется? Система работает? Времени и затрат при этом меньше?
Если бы за ним перепроверять не приходилось за десятерых то да, все ОК.
В статье про это ни слова. Я исходил из статьи.
В статье про это ни слова. Я исходил из статьи.
Вот вообще ни слова. Мы точно одну статью читали?
Но за два месяца стиль проекта обычно подхватывают, а он не подхватывал.
Я дал фидбек, показал конвенции.
Дима сказал «понял, исправлю».
В следующем PR повторил всё то же самое.
Забивает на код-стайл, даже после того как объяснили языком.
Я написал: порядок скидок неправильный, посмотри как работает сейчас. Через 20 минут новый коммит. Теперь промокод первый. Опять не то. Я написал подробнее. Третий коммит — правильно.
Вот тут меня кольнуло. Не ошибка — все ошибаются. А то, что три раза подряд три разных варианта, и ни один не показывал что он ПОНЯЛ принцип. Он не спросил «а почему такой порядок?». Не уточнил «а минимальная маржа — она где задаётся?». Просто выдал другую реализацию. Как будто... ну, перегенерировал с новым промптом.
Ну с третьей попытки заимплементил фичу. Было бы бы 100 вариантов пришлось бы ему сто замечаний делать.
Попросил добавить новый тип доставки и в описании написал что для расчёта стоимости «используется адаптированный алгоритм Bellman-Ford».
Тут ожидается что человек либо спросит что за зверь этот ваш Bellman-Ford и с чем его есть либо посмотрит в гугле и спросит какое это вообще имеет отношение к задаче? Оно то конечно провокативно но очевидно что человек будет так и дальше поступать, не пропускать через себя все вопросы а напрямую в нейронку сливать.
Когда на стейджинге упал его сервис, он полтора часа ковырялся и не нашёл причину. Я нашёл за десять минут — race condition в горутинах, классика.
Ну тут тоже показательно для x2 программиста, не разобраться в собственном же коде.
Я вас спрошу: а вы готовы передать ИИ ответственность за ваш прод ? В смысле - если ваш прод упадет, то вы не будете орать на своих девелоперов: "А ну быстро все починили!", а будете промптить ИИ - и если он не работает, то писать в OpenAI, Anthropic и прочее спортлото ?
Если готовы - тогда флаг вам в руки, и наименования переменных не имеют значения, делайте что хотите!
Если не готовы - тогда нужно сделать так, чтобы команда разработки продолжала быть способной разбираться в коде и чинить его. А это значит - вертайте обратно правильную архитектуру, консистентные наименования переменных, и так далее...
нужны будут люди, умеющие целиком охватить проект и направить в нужное русло всю разработку
Так для этого надо вникать в бизнес-логику и требования.
А тут вся статья фактически о том что человек не хотел и не пытался это делать, какие лучшие стороны? Копипастить as is в чатгпт и обратно а-ля обезъяна, где тут работа за двоих? Не, не так, где тут вообще работа?
Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК.
Феноменальная одноизвилинность: код - это boolean, он или true, или false. Система тоже.
Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК
Не все "ОК". В статье ясно написано, что он не понимал что делает его код. Что когда на стейджинге упал его сервис, не смог найти причину, и делать это пришлось автору статьи...
Получается, это была своего рода "имитация" работы. И какое-то время это "работало" - до первого падения... Когда оно рано или поздно происходит - вайбкодер оказывается беспомощен. Он не понимает как работает код, не знает как искать причины багов, не умеет дебажить, не имеет опыта и насмотренности.
А зачем в этой цепочке Дима, тянущий только на роль оператора LLM?
Когда как раз всё ровно наоборот:
- топовый сеньёр с зачатками управления - может заменить отдел (по сегодняшним стандартам нагрузки) в средней сложности проекте/предметной области;
- человек с топовой дисциплиной/многозадачносью и зачатками понимания IT-инженерии -- отдел в простой предметной области.
Т.е. надо брать как можно более квалифицированных (и подходящих на свою роль) людей.
оператора LLM
А раньше были операторы ЭВМ 😏
И оказались не нужны - ибо где они сейчас?
Подозреваю на новом витке развития технологий - от "операторов" как лишнего звена избавятся сразу.
И оказались не нужны - ибо где они сейчас?
В бухгалтерии. Заменили бухгалтеров.
И оказались не нужны - ибо где они сейчас?
За каждым ПК в мире. Оператор -- знаком с принципами работы, архитектуры, выполняет операции: вводит данные и получает результат.
Заявляю со всей определённостью - девахи, которые сидят за компами у меня на работе, незнакомы с принципами работы и архитектуры, да и вообще, с чем-то большим, чем стандартный для их деятельности набор паттернов для работы в Excel и Word, которому их научили! Хотя формально это, конечно, ввод данных и получение результата.
Надо уметь не только писать код, а еще уметь в архитектуру, алгоритмы.
Вот именно это Дима и не умел.
Пусть бы сам не писал, а только контролировал. Но он же не понимал, что на выходе.
Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК.
Ну, *некоторые так считают*. Но потом...
Как говорится, стыдно не знать и не спросить
обход дерева написать
Что такое дерево, я знаю, это такой граф без циклов и одиноких вершин. А что понимается под обходом? Допустим, я пишу функцию обхода дерева, что она должна выдать в качестве результата?
on-call
Я погуглил, что это значит. Это что-то вроде "могут разбудить ночью для работы"?
Про то, что с алгоритмом знакомы люди с профильным образованием, и это middle в go: значит ли это, что такого уровня в бэкенде нельзя достичь, не окончив универ и не самобразовавшись до этого уровня? Если человеку много лет, у него семья, нет времени на заочку, да и на чтение учебников, то всё, ему уровень middle закрыт?
Про нет времени: не буквально его нет, потому что загружен рабтой, а есть осознание, что жизнь конечна, самые беспечные годы позади, дальше тело будет страдать всё больше, и всё недоступнее становится любое удовольствие, будь то игра на гитаре без больных запястий или поход в кино без больной спины от неудобных кресел. Поэтому приоритет "сделать что-то приятное" становится всё выше, чем у "углубиться в прфессию", так как углубление в профессию отнимает время, вместе с этим некоторые удовольствия просто закрываются. Например, я уже не могу легко отстоять концерт в 3 часа (речь даже не про танцы) — спина сдаёт. В какой-то момент закроется велосипед из-за суставов. Книги, полагаю, продержатся дольше всего.
Книги несколько часов потом тож уже не почитать - глаза устают, хоть в очках, хоть без. Остается слушать. И честно говоря, особого прогресса в text-to-speech не вижу, хотя технологии лет 70, но по прежнему не могут по ролям читать (или хотя бы менять тональность голоса, как это делают проф.чтецы), ударения ставят мимо (в новых словечках и именах), сокращения по всякому (не понимают смысла текста и потому "дотянулась до его губ." - говорят про его губернии 😑)
on-call
Я погуглил, что это значит. Это что-то вроде "могут разбудить ночью для работы"?
Ога. Но, в идеале, должен быть "график дежурств" и оплачивается это дело дополнительно.
Допустим, я пишу функцию обхода дерева, что она должна выдать в качестве результата?
В простейшем случае распечатать числа в вершинах. В общем — вызвать функцию для каждой вершины
Понятно, что-то из серии "написать алгоритм сортировки пузырьком".
Ну вот я такое не напишу. Не потому что не могу понять - а просто не помню как, и не вижу смысла зачем.
Текущий проект помню, актуальную задачу, особенности реализации, вон ту хитрую функцию в библиотеке, на которую завязана бизнес-логика, с учетом 15 дополнительных параметров, и главное ПОЧЕМУ ТАК - да.
А алгоритм сортировки пузырьком или обход дерева - нет. Неактуальная на данный момент задача.
А я не то что не помню, я бы мог придумать, но я во первых не помню что такое дерево вот прямо сейчас, а во вторых не хочу помнить всей этой мишуры, потому что сильно подозреваю, что реальная работа с деревьями будет связана никак
Студентов же берут, бггг
Студенты помнят обход дерева , нормальные программисты не помнят
Понятно, что-то из серии "написать алгоритм сортировки пузырьком".
Ну вот я такое не напишу. Не потому что не могу понять - а просто не помню как, и не вижу смысла зачем.
2+2=?
Простейшие вещи помнить придется. Хотя бы для контроля ИИ
"написать алгоритм сортировки пузырьком".
20 секунд на то чтобы описать алгоритм (словами) и 20 минут на то чтобы вспомнить какой из них называется пузырьком и что было в голове у автора названия.
что было в голове у автора названия.
Пузырь и тёлка! ©
Ну ладно вам, рекурсии в работе нужны постоянно, их сложно забыть. Рекурсивно спуститься по дереву - это как-будто очень базовая задача, если не требуют чего-то вроде стека. А вот сортировку вообще никто никогда не пишет сам, поэтому ее никто и не помнит.
Ну вот я такое не напишу. Не потому что не могу понять - а просто не помню как, и не вижу смысла зачем.
Как можно не написать банальную рекурсию? Зачем тут что-то помнить? Тут не нужно помнить как, тут нужно просто взять и написать не помня. Как по мне, так это всё равно, что сказать: "Я не помню как пройтись циклом по массиву и распечатать каждый элемент, я вызываю функцию, которая это делает".
"Код сортировки пузырьковой
он распознать не смог с листа.
Ему давали в детстве мало
Кнута"
Что такое дерево, я знаю, это такой граф без циклов и одиноких вершин. А что понимается под обходом?
Паттерн "Итератор"
В компании где я сейчас работаю, мы столкнулись сейчас с тем, что некоторые джуны, часто использующие нейросети в работе, не развивались в мидлов(а для компании это критично), а наоборот - деградировали. Нагенерил код, сдал таску и начисто забыл о том, что и как делал.
Как код работает в проекте, как сам проект работает, как работают смежные с ним проекты - они разбираться не хотят. Как говориться - разобраться-то "можно, а зачем?"
Но надо сказать, что когда мы им обоснованно объяснили, в чем их проблема, и что от них нужно компании, а самое главное перспективу, что они навсегда останутся на зарплате Джуна, ребята все поняли и стали-таки развиваться - читать туториалы, смотреть обучающие видео, курсы проходить и так далее. Тем более что компания это всячески поощряет и оплачивает.
Только один отказался наотрез, да еще и борзеть начал - в стиле, что мы ничего не понимаем и у нас устаревшие подходы к разработке - его пришлось уволить.
Сейчас особых проблем с Copilot-ами и прочими ИИ-шками нет.
Вот я про это и пишу, но есть тут группа не пробиваемых, которые до этого пока не дошли, но при этом минусатор сразу включают.
Как говориться - разобраться-то "можно, а зачем?"
Ну так а вы ответили на этот вопрос? Кроме успешного успеха развитие ради развития. Почему человек не может хотеть сидеть в миддлах-джунах и не хотеть идти в сеньоры и лиды с нагрузкой х10, а зарплатой х2?
Наша компания принадлежит 5 банкам, которым и сдает аналитиков и разрабов внаем в проекты. Соответственно, чем выше квалификация у разрабов, тем лучше бизнес. Джуны не нужны в такой схеме вообще, но мы берем студентов со второго курса и выращиваем из них мидлов и далее. И для себя и социальная миссия.
А если кто-то профессионально расти не хочет, то зачем он вообще в профессию пришел? И нам такой точно не нужен. Что с ним делать-то?
Но к счастью, с современной молодежью проблем особых нет, все учатся, развиваются и набираются опыта, никто не жалуется. Я как раз занимаюсь дообучением Джунов, в том числе, за 4 года пара человек только попалось необучаемых...
del - хабр стёр 3/4 сообщения, заново лень писать
... и выращиваем из них мидлов и далее
А когда вырастили как удерживаете?
А то ведь уйдут на +80к в бигтех
Или у вас там какой-то договор что обязаны отработать?
У нас платят денег меньше чем у клиента, но полная удаленка, никто мозги не компостирует, как в больших корпорациях, разрешено свободно переходить из проекта в проект, билет на все виды транспорта оплачивают, электро велосипед можно взять за 30%(правда отработать потом надо в компании 2 года) и в целом отношение хорошее и уважительное. Компания 3% от годового оклада дополнительно выделяет на развитие сотрудника. Я немецкий учу, кто-то по конференциям ездит.
Кто-то уходит, конечно, но большинство остается.
Только один отказался наотрез, да еще и борзеть начал - в стиле, что мы ничего не понимаем и у нас устаревшие подходы к разработке - его пришлось уволить.
Со своей стороны он прав. Зачем ему помнить прежние решения, если он маленький винтик в системе? Пока мидл делает один проект, этот джун на быструю сляпает семь порученных заданий (из них три на стороне) и получит больше денег. А то как эти задания будут интегрированы в общий проект - на его уровне все равно, его задача - максимально заработать, а не стать лидом в компании.
Мы осенью делали сайт, я пару месяцев писал фронтенд для него. А теперь пришли правки и я вообще не помню, что там откуда торчит, приходится вникать заново. А ведь я нейросетью написал всего один тип, да и то, потом зарефакторил, когда понял принцип, как его нужно было делать.
он очень нервничал когда я попросил шарить экран
Любой нормальный аутистинтровертпрограммист будет нервничать в такой ситуации, написание кода это процесс сугубо личный
Только для неуверенных в себе людей, независимо от профессии..
дело может быть вообще не в коде.
Твой рабочий компьютер, рабочие программы, организация всего этого, включая установку ПО для "шаринга" - это примерно как раздеться догола посреди улицы зимой: даже если есть чем похвастаться и покрасоваться - всё равно улица и зима как-то не способствуют.
Ну нет, сейчас пошарить экран способов навалом и без мутного ПО, даже мессенджеры это умеют. Тут или боязнь сцены или боязнь показать некомпетентность. В рабочем процессе на созвонах постоянно приходится шарить экран, чтобы подкреплять объяснения. Мы же на работе совместную работу работаем, а не любовные письма пишем.
Пошарить можно конкретное окно. ПО для шаринга - это ПО для видеосвязи, по которому вы проходите интервью. Это примерно как "напишите в блокноте список покупок, только покажите мне, как вы записываете".
Понятно уже всё из статьи:
Набирают студентов (помнят обход дерева) и экстравертов (ливкод) на 300 в наносек.
Потом будят его по ночам для тушения пожаров 🔥 и жалуются на то что "равнодушен к коду", пишет в LLM и тупит на инциденте.
Эффективная сова 🦉
Я два месяца платил 300к человеку, который тихо скармливал мои задачи в ChatGPT
Результаты есть? Тогда какая разница, силами ИИ или нескольких субсубподрядчиков была выполнена работа.
Нет доверия к результатам ИИ? А вот это уже ответственность исполнителя, которому платили 300К (не так уж и много для некоторых таск).
Важная особенность llm-разработчиков в команде состоит в том, что они не включают эмоции ответственности за код, который от их имени попадает в приложение. Ответственность - это непростая эмоция, её сопровождают стыд, страх, иногда злость. Автор, я понимаю ваши ощущения. Я бы обсудил вариант: "так продолжать нельзя, нужно вот так, ты готов поменять подход?", может вы тоже попробовали, но в тексте не упоминается. Попробовал бы объяснить, что профессиональный рост включает то, что человек начинает драйвить какой-то функционал, а это подразумевает ответственность, и дальше человек сам решает, что не готов верить llm-ке. А пока код ревьюит (читай "принимает") кто-то другой, то и отношение к коду такое, что он не мой, пусть хоть llm-кой, хоть индусом будет создан.
Честно говоря вообще не понимаю, как можно собрать команду программистов... иногда думаю на эту тему и в голову приходит только - нанимать тех кто на виду - блогеров и тех, кто обучает на платформах. А найм по объявлению это черная дыра. Как можно отслеживать и контролировать код - мне лично - просто не понятно. На одно программиста нужно второго проверяющего... и проверяющего не просто, как линтер - по верхам пробежался, а вникать в суть - понимать что пишет программист и почему он так пишет - вникать в сюжет и сюжет должен быть.. Вот читаю такие посты и представляю, какой кошмар творится во всех IT компаниях... Это у вас есть время вникать в код, а если бы вы занимались другими вопросами или вместо себя надо было поставить другого, а самому заняться другим делом. Страшно представить во что это все выльется спустя месяц или не дай бог пол года такого кода
Процесс контроля называется код ревью и там где он реально работает, и читают и вникают. Более того код ревью помогает и в онбординге, когда новичку призодится и вникать и понимать, что же там сделал коллега.
автор пишет, что код работает и что поймал случайно... хочу сказать - я сам пользуюсь нейронками, что бы писать скрпиты. Я не могу без базы - то есть мне нужно что то, что бы на основе этого спроектировать. Это качество з за отсутствия опыта. Но к чему я - к томы, что когда нейронка выдает код - у меня мозги набекрень выворачиваются) Нейронка пишет вроде бы все логично и каждый отдельный кусок кода понятен и логичен и даже красив, но когда я пытаюсь понять общую картину - почему сделано так, зачем сделано так, когда можно было структурировать по функционалу, разбить на логические блоки и переиспользовать код.. тут возникает очень много вопросов - код от нейронки работающий, но что бы его масштабировать или прикрутить функционал - это фиаско. Бесполезно - код одноразовый. В общем не знаю с чем это связано - скорее всего с данными, на которых обучали - то есть нет акцента на единый стиль или структуру и в итоге получается каша от которой можно тронуться если пытаться разобраться. И возвращаясь к посту - код ревью - это отлично, но кажется там такая же ситуация - код работает, написан отдельными частями логично и понятно, но если смотреть в целом - это бред сумасшедшего из соседней палаты... и что бы понять всю картину - надо прочитаь код и понять замысел от начала и до конца - и я не уверен, что ревьюверы способны вывозить такую нагрузку. в общем у меня ничего кроме сочувствия данный пост не вызывает. Сочувствие в смысле - понимание.
Мне кажется, вы несколько драматизируете. Условно, на проекте работают 5 программистов. Все пишут код, все понимают кодовую базу и используемые фреймворки. Когда приходит время ревью, тебе не надо идти и смотреть на все классы, ты уже его знаешь, ты сам его пишешь, и у тебя есть картина того как, что, где и почему работает. Поэтому нет, очередной код-ревью - это не записки сумасшедшего и ты сразу понимаешь ложится оно в архитектуру и конвенцию проекта. Но да, иногда приходится выкачивать ветку себе и проверять, что там написали и точно ли работает.
Не исключаю, что драматизирую, но это лишь мое мнение. Я исхожу из того насколькоо трудоемко отрефакторить код от нейронки. То есть в моем случае и в моем опыте от изначального варианта написанного нейронкой не остается ровным счетом ничего. То есть я вникаю в каждую строку кода и каждая строка переписывается или вообще удаляется и заменяется другим кодом или другим подходом. Я сейчас не умаляю пользы нейронок - без них я бы вообще ничего никогда не сделал в плане кода. Я говорю об архитектурном вопросе скорее... Но с вами согласен - когда есть архитектура и необходимо только штамповать новый и новый однотипный код - ревью делается просто. Но в посте говорится о задаче по интеграции апи от заказчика и не понятно - типовая ли это задача или тут полет фантазии. Если полет фантазии, то это как раз то о чем я говорю, если типовая задача, то это то о чем говорите вы. По этому в вашей картине я драматизирую, а в своей нет. В любом случае - мое мнение основано на моем опыте, а опыт такой какой есть. Сколько бы подробно не создавать PRD результат один - все под снос. В моем случае работает только когда чуть ли не построчно объясняешь что откуда брать, как обрабатывать, как передавать и прочее и прочее - но описать в таком виде весь проект невозможно. Слышал мнение, что нейронки так или иначе меняют представление программиста о коде. Шаг за шагом, функция за функцией и символ за символом. Это снежный ком в прямом смысле. Но возвращаясь к вашим словам - когда сформирован скелет - здесь нейронки работают отлично!
Частично идея переписать все в случае нейронки из за меньшей ценности кода нейронки, чем коллеги. Вот я вижу решение на ревью. Оно может сильно не такое, как писал бы я, но оно соответствует стандартам, мое решение не быстрее, не безопаснее, я задаю пару вопросов по местам, которые я не понял или вызвали у меня сомнения и пропускаю в прод. Нейронкино я бы может тоже порефачил сразу, она не обидится.
А интеграция АПИ кажется насквозь дубовая типовая задача - сделали на своей стороне по функции на вызов, добавили перевод из терминологии внешней системы на нашу, а в нашем легаси архитектура уже сто лет как есть и всем знакома.
Ну если все соответствует стандартам и в целом все подходит, то и данного поста бы не было. Тут автор гооврит, что некий Дмитрий или как там его - говорил, что все понял и все исправлю и при следующем обновлении опять все тоже самое, но код при этом работает. Принимать или нет - не понятно. Вроде работает, а ввроде сказал, что будет следовать принципам. Если примешь код - то не будет стандарта, а не примешь... ну вот автор в итоге и не принял в какой то момент. А переписать код нейронки из за меньшей ценности чем коллеги это интересное замечание... Не ясно сколько кода не по стандарту уже попало в проект из за высокой ценности коллеги, а с другой стороны сколько часов потрачено на рефакторинг кода от нейронки из за малой ценности) Тут есть над чем поразмышлять
Я подозреваю, что это связано с обучением нейронок - они в основном нацелены на "решение задачи в 1 проход".
То есть, пока у тебя есть маленькие задачи, которые нейронка реально может решить за 1 раз - всё прекрасно, она это делает и блестяще показывает себя в бенчмарках. Но как только ей приходится дружить между собой несколько интерфейсов...
ИМХО, иронично, что это в целом решается ровно так же, как и с людьми - декомпозируешь, разбиваешь задачу на небольшие подзадачи, составляешь план работ, даешь жесткие граничные условия "используй функции вот отсюда" и всё такое. В общем, начинаешь работать с документацией
Да, очень похоже, как и с людьми - даже, ккогда наблюдаю, как нейронка дебажит код в терминале - очевидно, что человееские паттерны - а посмотрю ка я тут, а посмотрю ка я там, давайте загляну в конфиг... и е понятно - то ли это естественное поведение, то ли эти паттерны явно подсвечивают и тренируют на их примере. не ясно, как растет сложность когда речь идет о комплексных задачах... это вопрос "внимания" нейронки или что то иное. Пока что решаются простые задачи и не ясно - будут ли в скором времени решаться комплексные задачи. Если смотреть в перспективу - очень много вопросов. Работаем с тем, что есть)
Вся суть, скажем так конфликта по прежнему в деньгах, по мысли автора не должен был Дима столько получать, не должен, а он взял и нажился на ТС
Проблемы, которые описаны в статье - они придуманные. То есть их с данным подходом и на данном этапе не было.
Интереснее было бы, если б автор либо дошел до них сам, либо что-то обоснованно предположил: через пару итераций случилось бы вот такое, и нам бы пришлось...
Потому, что принимать на работу таких вот декораторов или не принимать - это вопрос вкуса, а вот что они могут с собой принести - это и есть корень проблемы. И покопаться хотелось бы именно в нем.
Берем код, сданный джуном полчаса назад, копируем его в блокнот, поиском и заменой удаляем вообще все комментарии. Затем просим обьяснить где тут что происходит, желательно лично, показывая на своем экране. Если чел сам писал недавно, хотя бы поблочно обьяснить сможет. Просто если понимание у человека есть, то пофиг кто там код писал - если его целиком ИИшка написала, а чел все рассказал что там происходит - это крутой чел ) Таких ценить надо. Если нет - перед вами обычный вайбкодер.
Хорошая статья — жизненная. В комментариях складывается впечатление что началась охота на ведьм: ищутся изощрённые способы выявления и наказания программистов, использующих ИИ.
Давайте вспомним эпоху DOS и Windows 3.x — кто вообще понимает о чём я — когда MBR был ограничен 446 байтами полезного кода, а весь загрузочный сектор умещался в 512. Потом пришёл GRUB, EFI — и понеслось. Память стала дешёвой, а разговоры про оверхед сошли на нет. Или взять драйверную модель: переход с монолитных kernel-mode драйверов полностью в ring 0 к гибридной модели WDM, а затем к UMDF где большая часть логики вынесена в user-mode — и ничего, пережили, и сейчас никто вообще не задаёт вопрос сколько памяти драйвер занимает в пуле.
Наверно не надо искать "ведьм", а принимать новые условия. Подход к ИИ-генерированному коду как к верифицированному внешнему компоненту — по сути давно знакомая практика: сторонние библиотеки, COTS-решения, да тот же BIOS/UEFI который никто не читает целиком. Ничего принципиально нового — просто очередной виток. Его надо не отрицать, а адаптироваться. Так эффективнее.
Наверно не надо искать "ведьм", а принимать новые условия.
Какая милая манипуляция, это же не мы выбираем и формируем условия, они типа есть, мы ничего не можем поделать.
Подход к ИИ-генерированному коду как к верифицированному внешнему компоненту — по сути давно знакомая практика: сторонние библиотеки, COTS-решения, да тот же BIOS/UEFI который никто не читает целиком. Ничего принципиально нового — просто очередной виток. Его надо не отрицать, а адаптироваться. Так эффективнее.
Ещё милее. Кем этот код верифицирован? Самой моделью? Где доказательства верификации? Я могу llm-ке предъявить финансовые претензии, если считаю, что качество плохое? BIOS/UEFI не "никто не читает целиком", есть ненулевое количество тех, кто читает.
Короче, аналогии, используемые в полемике, очень неудачные.
Я могу llm-ке предъявить финансовые претензии, если считаю, что качество плохое?
Ну, справедливости ради практически в любой лицензии у разработчика ПО "Мы не несем ответственности за...". MS вроде не несет ответственности за баги в MS Office, ну и т.д. Если вы делаете что-то поверх опенсорсных решений - туда же.
Претензии можно предъявить только своему разрабу, а ко внешним решениям (которыми в виде пакетов NPM или PIP, например, пользуются просто постоянно) претензии предъявлять не очень возможно.
BIOS/UEFI не "никто не читает целиком", есть ненулевое количество тех, кто читает.
Ну, вывод LLM тоже можно прочитать и проанализировать, если нужно.
Как принимать, если это реально ведьмы и колдуны, которые не понимают сути своего колдунства? А если кодить для реального производства, где тоже сроки и надо уже запускаться, пусть и со слабо оттестированным кодом? Линия стартует, заказчик готов к частым остановкам, надо методом пристального взгляда искать проблемы и на живую править. А если не понимаешь, что происходит в коде, то всё - приехали, будешь пол дня всматриваться.
Память стала дешёвой
Ну, как вам сказать )))
Статья выглядит как тролинг. Вначале докопались до комментариев, потом до нейминга переменных, потом ещё до чего-то потом каую-то "ловушку" делали.
Вам шашечки или ехать? На ревью - настройте линтеры / ревью-ботов которые по вашим требованиям будут проверять код на соответствие если уж так хочется.
Если мидл успешно работал, закрывал фичи и справлялся с остальными обязанностями мидла - в чем проблема?
Архитектуру, задел на 10-кратный рост и тд - за это все отвечают сениоры.
За дебаг своих фичей отвечает мидл. Но одного примера из статьи явно не достаточно. То что мидл будет дебажиться дольше чем сениор - это очевидно и ожидаемо. Вот если он вообще свой код не может починить - тогда да, проблема.
За прояснение бизнес требования тоже отвечает мидл. Если он регулярно делает не то что надо и приходится потом переделывать - тогда проблема, но оно должно было еще на испыталке вылезти.
Чтобы понимать что что-то сломалось нужно иметь представление как все это должно правильно работать. Нужна 'голова' где будет собираться общая картинка. Что бы починить за адекватное время/усилия нужен читабельный код по единым конвенциям. С ИИ нагенерите таку кучу кода о которой индусы могут только мечтать.
Из опыта работы еще в до ИИ-шную эпоху в тяжелых проектах-долгостроях с кучей легаси, говнокода, кривой архитектуры и прочего техдолга:
Говнокод имеет тенденцию достигать критической массы, после которой попытка впихнуть хоть еще одну фичу приводит к экспоненциальному росту количества багов (нередко, где-то совсем в другом месте). Так вот ИИ генерирует такой говнокод с гораздо большим энтузиазмом и в большем количестве, даже больше чем джуны. Но если за джунами еще как-то присматривают, то вайб-кодеры, как вы правильно заметили, вообще не напрягаются. Короче, классический "херак, херак и в продакшен".
ИИ обучены по большему счёту на публичных репозиториях из github/gitlab а там более 95% кода это пет проекты.
Без конкретно детализированного промпта, ИИ выдаст не идеальное решение.
Детализация и описание промпта + чтение и тестироване отнимают больше времени чем писать код самому.
Ну это как Каспаров играл со всем миром в шахматы и выиграл. "Лучший" ход определялся интернет-голосованием, а поскольку большинство голосовавших играло в шахматы "так себе", то и получилось, что Каспаров играл не с лучшим, а со среднестатистическим игроком.
Потом, уже задним числом, проанализировали предлагаемые ходы и среди них были гениальные, которые позволили бы победить гроссмейстера, но среднестатистические игроки за них не проголосовали.
Так же и тут, имеем код среднестатистического программиста.
ЧЧерт, придется менять промт. Перепиши код с такими условиями.
Первое — комментарии. У нас стиль такой: комментарий пишем только когда код делает что-то неочевидное, и объясняем почему, а не что. Дима навешал комментарий на каждую функцию, и все одинаковые:
// functionName handles the processing of X and returns Y. Я сказал — у нас так не принято. Он убрал. Из СЛЕДУЮЩЕГО PR. В этом остались. Мелочь, ладно.
Второе — нейминг. Тут сложнее объяснить. Переменные названы нормально, но... слишком нормально? Вот у живых программистов нейминг — это привычка. Кто-то всегда пишет
resp, кто-тоres, кто-тоapiResp. И это стабильно, это рефлекс. У Димы в одном файлеclient, в другомapiClient, в третьемtransportClient. Каждый раз немного по-другому. Не ошибка, а отсутствие привычки.
Это пожалуй самое странное. Ну есть на проекте кодстайл - добавь его в промт или вручную допили, единообразие на большой кодовой базе - наше всё! Было настолько лениво или что, не понимаю...
Думается мне, там и промта никакого не было. Просто кидалась задача с дополнением: "Сделай, как написано".
А когда понадобилось убрать комментарии, то было просто: "Убери все комментарии".
За него ИИ код писал, а за вас - статью.
половина не может обход дерева написать (я серьёзно, я уже думал может я что-то не так спрашиваю, но нет)
Я тоже сейчас в компании с логистическими SaaS продуктами - ни разу не пришлось писать обход дерева, а если бы и пришлось - спросил бы у чат гпт. Собес я походу не прошел бы.
Но вот чем реально приходится заниматься - как сделать быстрый резерв товара, чтобы не тормозило, как добиться хоть каких-то гарантий синхронизации склада и заказов с отгрузками, и как вы сказали АД с интеграциями, когда например складская система по запросу не отдает все закрытые отгрузки, а пропускает 1-2 просто потомучто (а при повторном запросе - все ок), а клиент потом жалуется нам.
Дима сказал «понял, исправлю».
В следующем PR повторил всё то же самое.
Есть такие люди, которые не умеют работать программистом. Если ничего не меняется после код-ревью и / или разговоров - увольнять. Каждая компания имеет свой набор устоявшихся правил, не стоит насаждать свой самовар.
А вы не разговаривали с ним перед увольнением по душам? Интересно как так вышло у него в жизни? Человек прошел собес (но это можно наловчиться), кодит с LLM и не понимает что происходит. Сам по себе - это интересный экземпляр, в будущем таких людей может стать больше.
Лично я пока не решился полностью довериться LLM, скрипты на питоне написать для CI/CD, или bat / sh - да, а бизнес-код - нет. Но я с удовольствием жалуюсь LLM на задачи, которые мне приходится решать, и идет обсуждение на концептуальном уровне, где либо мне приходит в голову что-то полезное, либо я выбираю понравившийся вариант из предложенных LLM.
Но даже со скриптами - когда надо что-то исправить, лень лезть в отладку, хочется сделать побыстрее и поэтому делаю 1-2-3 попытки и опять спрашиваю LLM и чаще удавалось, чем нет.
Но у меня... ну, знаете это ощущение когда что-то не так
ну вы как будто в танке, только ощущение ;) и нужно активней пользоваться ai, 26 год на дворе.
chatGPT это просто инструмент он делает ровно то что просишь делать. Почему в моих проектах все однотипно в том числе и названия переменных и комментарии где нужно.
Автор нанял абы кого, потом что-то абы как проверил и что-то не понравилось, а выводы то какие?
Про Беллмана-Форда тоже шутка какая-то - в чем ловушка то заключалась? кратчайший путь в графе - это не сантиметры с киллометрами - это веса ребер они могут быть хоть рублями, хоть процентами, хоть минутами
Ещё меня гложет вот что. Граница между «использую LLM как инструмент» и «я оболочка для LLM» — она размытая. Я сам иногда прошу Claude написать тест. Или бойлерплейт. Или «как называется эта функция в стандартной библиотеке, забыл». Чем это принципиально отличается от того что делал Дима? Масштабом? Процентом? Где порог?
нет порога. Порог — это количественная характеристика, а «использую интсрумент» и «я — оболчка», это качественная разница. Как у Аристотеля с его кучей песка. В нашем случае разница в понимании. Если я понимаю что делается, то БЯМ — это инструмент. Есть нет, то я — оболочка.
половина не может обход дерева написать
зачем вы до сих пор даёте такие задачи? детсад
Я вообще не фаната алгособесов, но как еще проверить, что индивид может в простое и понятное:
я делаю A
потому делаю Б
если в Б выполняется условие В, то повторяю п.1 c A := Д
Мой опыт найма показывает удивительнейшую статистику, в которую, если бы мне кто рассказал раньше, никогда не поверил
Мой опыт найма показывает удивительнейшую статистику, в которую, если бы мне кто рассказал раньше, никогда не поверил
Расскажите плз..
Ну, я считаю себя нормальным собеседующим: не ультра-требовательным, прекрасно понимающим, что с той стороны экрана - стресс, буквы путаются, самое очевидное забывается, язык заплетается.
Поэтому у меня на собесах можно гуглить. Гуглить можно не сразу, а когда я вижу, что человек подзастрял (см. выше про стресс).
Собственно, по сеньор и близко к нему уровню - всё просто: собрались, поговорили кто что делал, кто что видел, и какие они всё дураки, возможно решили несколько простых задачек, чтобы просто понять, что человек действительно может сам ручками, а не только травит байки... и в общем-то всё. В формате часа - дай бог бы на это времени хватило.
С миддл уровнем - примерно та же история, но меньше в сторону "где был, что видел" и больше в сторону "а реши-ка мне вот такую нехитрую задачу". Тут мы никакие деревья не переворачиваем, а делаем что-то простенькое, чтобы (см. выше про стресс)
На джуниор уровне - только простенькие задачки, начиная с: "умножь все числа в массиве на два", "удали у объекта свойство", "скопируй плоский объект, но без вот этих полей" и всякое подобное.
Так вот, я думал, что тут можно затупить (см. выше про стресс), но обнаружить кандидата в состоянии "я не знаю", "я не знаю что такое массив", "а можно следующий вопрос" и вот всём прочем таком - невозможно. А нет, оказалось, что вполне возможно. И это были очень сильно не единичные случаи. И, к сожалению (см. выше про стресс), даже "окей, сходи в гугл, я просто посижу рядом молча" увы не помогал.
Точной статистики я не вёл, но навскидку, процентов 10 попадалось вот таких кандидатов. И это при условии, что HR отдел еще на дальних подступах отстреливал совсем неадекватов, проводил предварительный поведенческий скриннинг, и у нас даже была пачка маленьких тестов минут на 20, перед тем как кандидат доходил до живого человека (меня).
Это я не к тому, что все вокруг - не соответствуют нашим высочайшим стандартам. А к тому, что самый базовый sanity check о том, что человек может строить нехитрые логические цепочки "сначала А, потом Б, а если В, то Д" - нужна. Всё же, большую часть времени именно этим человек и будет заниматься на своей будущей работе. И как неожиданно выяснилось - не все кандидаты этим обладают (хотя казалось бы)
На своем примере, я обход дерева не напишу только потому, что не знаю принципа обхода дерева, а выяснять постесняюсь. Есть и те, кто слышит вопрос про сортировку пузырьком, а в голове "чиво, блять?". Но если объяснить принцип, то напишут легко.
а выяснять постесняюсь
Так вы и на работе что-то в постановке задачи не поймёте, а выяснять постесняетесь. В итоге будете 2 недели пилить не то, что нужно. Если кандидат не задаёт вопросов по задаче, которую ему дают, это почти гарантированный отказ. А что касается принципов, вы правда на работе с древовидными структурами данных не сталкивались? JSON не обходили, по файловой системе не ходили, HTML или XML документ не обрабатывали и т.д.? Вы ни разу рекурсивного кода не писали?
Есть и те, кто слышит вопрос про сортировку пузырьком, а в голове "чиво, блять?". Но если объяснить принцип, то напишут легко.
Собеседование, это не поэтический вечер, от вас не требуется декламировать наизусть зазубренное. От вас требуется решить микрозадачу. Уточнить граничные условия, разобраться что надо сделать, выяснить как надо делать, если не помните/не знаете и после всех этих выяснений написать 5-10 строчек кода (а иногда и этого не надо, достаточно просто рассказать что вы будете писать). Т.е. от вас требуется сделать ровно то, что вы будете делать на работе - решать задачи, с половиной из которых вы точно никогда раньше не сталкивались, потому что у всех своя специфика работы.
а можно мне контакты Димы? мы его пособесим
лучше временно не сильно понимающий код джун, но способный спокойно работать с AI, чем старый пердун из советского НИИ
Дима буквально решал поставленные задачи, в чём проблема - я так и не осознал
Проблема в том, что на самом деле просто решить поставленную задачу мало, надо решить ее с учетом того, что код будут поддерживать, т.е. читать и переписывать другие люди. Переменные должны именоваться единообразно, соответствовать предметной области. Комментарии - описывать не что делает код, а почему он делает именно это - и только там, где это необходимо.
По рефакторингу - сначала пишем тесты, фиксирующие текущее поведение, и только потом - собственно рефакторинг. Алгоритм расчета цены при рефакторинге измениться не должен.
Нельзя считать поставленную задачу решенной без учета таких вещей.
Если бы Дима:
1) работал над проектом один, а не в команде
2) это был бы MVP, а не проект с многолетней историей и многолетним будущим, т.е. требующий поддержки
то проблемы бы не было.
Переменные должны именоваться единообразно, соответствовать предметной области. Комментарии - описывать не что делает код, а почему он делает именно это - и только там, где это необходимо.
это опять же не проблема задать все нужные правила в каком-нибудь AGENTS.md
И что мешало условному Диме все это проделать? Проблема Димы не в том, что он пользуется LLM, а в том, что он не хочет пользоваться своей головой.
Вы не задумывались, если за Димой надо не просто ревью проводить, а все построчно перепроверять, потому что Дима решает задачу с помощью LLM, не проверяя имплементацию и не приводя код к требуемому виду, то Дима в этой схеме выглядит лишним?
Можно убрать Диму, и ставить задачу LLM напрямую, ведь результат от наличия Димы не улучшается, проверять и править в обоих случаях придется одинаково, а 300к в месяц (с учетом взносов все 500) сэкономлено (ну, за вычетом десятки на токены).
Ну например, он не смог протестировать 2 реализации так, чтобы сравнить новую с эталонной - это не серьезная проблема?
Дима буквально решал поставленные задачи
Решать задачи это прекрасно а как насчет решить? Или это не обязательно?
Думаю, описанная ситуация - просто эволюция рынка. Зарплаты, в отличии от цен, не растут и приходится что-то придумывать. Может быть этот парень был хорошим синьором ранее, но пришел к выводу, что легче вайб-кодить на двух работах по 300к, чем перерабатывать за 400к без перспектив повышения.
половина не может обход дерева написать
Какого дерева, какой обход? Зачем?!
В live-coding секции теперь даю не «напиши», а «найди баг»
Признали ошибку и перестали заниматься глупостями. Это похвально.
За 300к на рынке найти мидла который всё руками пишет — ну, удачи.
Собственно даже курьера, который будет ходить ногами)))
Через пару лет, если всё не накроется тазом, программисты, возможно, будут только проверять код, а может и это уже будет лишним, пойдут в хлеборобы)
Это вряд ли )). Хайп схлынет. Уже пошел на спад. Пузырь лопнет - громко или не очень. И у программистов просто появится еще один инструмент. Ну т. е. он уже появился.
Одни программисты пишут код, не умея писать, другие его проверют, не умея читать. В результате программистами по неволе станут хлеборобы, чтобы свои джондиры с жпс хоть как-то гонять.
Тут дело вовсе не в ИИ. Тут дело в этом вашем сотруднике и его отношении к работе. Таких работников гнать надо известно какими тряпками. Он не вовлечен, равнодушен, не мотивирован на результат. Вне зависимости от профессионализма и используемых им инструментов - таких "работников" нужно обходить десятой дорогой. Если человек во главу угла ставит не результат труда команды, компании, а личные цели (карьеру, деньги, повышение статуса) - это не член команды и это вылезет для команды/продукта боком.
Ему не интересно вникать в задачу, стараться сделать её оптимально. Он не получает от этого удовлетворения. А ИИ тут вообще вторичен, ИМХО. тут не про hard skills история, а про soft skills.
Если человек ставит цели работодателя выше своих личных – он болен.
И да, я с удовольствием найму такого.
Он не вовлечен, равнодушен, не мотивирован на результат.
Кажется, вы дошли до понимания тезисов из книги одного ашкеназа из Трира, который очень хорошо описал разницу между работником и работодателем, да и вообще, логику современного ему общественного устройства. Как показала жизнь, современного не только ему...
У нас в проекте сообщения короткие, типа "unmarshal transport resp"
Честно говоря, если бы я такое увидел в незнакомой кодовой базе, первая мысль была бы не "наверное, тут как принято для удобства поиска в логах", а "кажется, тут всем пофиг на такие мелочи, как внятные сообщения об ошибках". Слово "response" не настолько длинное, чтобы над ним так издеваться.
потому что рядом stack trace и wrap, длинные строки только мешают потом grep-ать
А зачем вы хардврапаете стектрейсы? Чтобы в жизни было больше приключений?
В live-coding секции теперь даю не «напиши», а «найди баг». 20 строк Go с race condition, или утечкой горутин, или неправильной обработкой контекста
Шел 26 год. Люди продолжали делать это "открытие", лежащее буквально у них под носом. Но лучше поздно, чем никогда. С 2019 года провожу собесы с упором на ревью, а не на кодинг. Потому что ситуации, когда нужно покрутить деревья у меня возникнет с вероятностью 0.001. Зато точно возникнет ситуация "там сервис ИКС начал гадить в логи, в него Паша лазил, а он сейчас в отпуске, иди разберись".
половина не может обход дерева написать
Ну что ж, вот вы нашли такого человека. Что опять не так?
Или, можно, надо было немного на другие критерии опираться изначально, не?
У меня в команде коллеги стали активно использовать ИИ для создания кода. Не могу сказать что код стал прямо намного хуже, но постоянно приходится сражаться с пустым ненужным кодом. Внезапно в функции добавилось +10 строк. А нахуа не знает никто. ИИ решил что так лучше. Почему? Да потому что мол есть какие-то драйвера баз данных которые могут вернуть данные вот таким образом. Но у нас то наш драйвер, мы его менять не планируем.
Или вот функция пишет данные в базу, а перед запись проверяет что мол если данных нет то верни успех и ничего не делай. Но у нас подход обратный. Если пользователь прислал фигню значит функция должна вернуть ошибку. А тут подход "ничего не сделали но кивнули головой будто все в порядке".
Код ревью стал мучением ( и раньше был не сахар ). Теперь приходится выпытывать у них почему они сделали так ( а вдруг там логика какая-то ).
Я до последнего думал, что это тонкий троллинг. Ну не может быть типичный строковёрт-деревопроходец комрьютерсаенсный настолько сферическим в вакууме! Но, походу, может. Как же сильно обида на иишку застилает здравый смысл! Причина, по которой ваш Дима даже спорить не стал и спокойно ушёл в том, что он себе новую третью работу найдёт и будет также её делать, тратя пол часа в сутки, а время тратить на что-то более полезное или приятное, чем колупание в никому не нужных в реальной разработке ксных задачках для аутистов.
Тем более радостно от количества лайков на этом посте. Чем дольше у индустрии отнимет времени понять, что кс и раньше-то нужен был с большего для того, чтобы просто выпендриваться, а теперь и подавно, тем нам с Димой лучше. Удачи в хождениях по дереву!
Тесты проходили — он же сам написал тесты
Hahaha_Classic.jpg
да, кодеры превратились в дебаггеров и ревьюеров. проблема в том те, кто сразу начинал с LLM-ками не умеют дебажить, ну точнее умеют, через те же LLM и зачастую весьма неплохо, но, пока что у нейронок есть предел в отладке и он намного хуже чем генерация кода
Летом, пока все были в отпуске, в одной из инженерных команд синьор из IT решил срочно пофиксить код для ПЛК через Клод Код. Я такого уровня кода не видел даже у первокурсников на лабах, этот код собрал все ошибки, которые разбирают в любой книге «…для чайников», типа магические числа, какие-то выдуманные библиотеки. Как после этого оправдывать человека и Клод Код, я не знаю.
Тот код писал нейросетью. Это факт. Этот статью написал нейросетью. Это факт. Если Вам не нравится, что кто-то использует нейросеть, то почему Вы считаете, что можете нас кормить продуктом нейросети?
Комментарии, конечно, тлен и безысходность. Половина вообще не отдупляет в чем проблема.
Мой тимлид 2018 года наверное точно так же бурчал когда я гуглил ответы на StackOverflow вместо того чтобы читать маны.
Именно.
Поэтому тут решение простое. Раз уж вы хотите досконально контролировать команду, то надо просто самому досконально освоить данный инструмент, т. е. StackOverflow LLM. И просто для себя решить:
либо использование этого инструмента в вашей работе неприемлемо;
либо его использовать можно.
В первом случае всё понятно - просто на собесе это оговаривается. Во втором случае потребуется составить некий регламент использования LLM. Например:
досконально вычитывать весь код, который выдаёт модель;
не перекладывать на модель выбор ключевых решений (только реализация);
не давать модели писать тесты;
и т. д.
То есть какой-то такой свод правил, который гарантирует, что при их выполнении вы всегда будете срезать острые углы. Возможно, на первых порах этот свод нужно будет проверять на каких-то незначительных (внутренних) задачах / проектах.
На сегодняшний день пока не решена проблема закапывания языковой модели в своих собственных багах со временем. Также не решена проблема ограничения контекста. Все эти проблемы требуют регламентов при использовании LLM. А написание регламентов - это как раз задача управленца.
На сегодняшний день пока не решена проблема закапывания языковой модели в своих собственных багах со временем. Также не решена проблема ограничения контекста. Все эти проблемы требуют регламентов при использовании LLM
Пока не решена базовая проблема - ИИ тупо врет (галлюцинирует).
Со временем, наверное многое решится, но не эта - ведь иначе надо ИИ обучать только на верифицированных данных (исходниках без ошибок), что сложно реализуемо. Может появятся какие то подобные модели ИИ, но ценник их будет ой.
Мы (ну, вся индустрия, но мы в том числе) годами строили процесс найма вокруг «ЧТО ты умеешь делать». Напиши функцию. Спроектируй систему. Реши задачу. И если человек выдаёт правильный результат — мы его нанимаем. Нам было плевать КАК он пришёл к результату, потому что раньше единственный способ выдать правильный результат был — уметь это делать.
Не вполне согласимся.
Для начала - никогда не было такого, что единственный способ выдать правильный результат это уметь что-то делать. Потому что правильный результат подразумевает не только на 2*2 выдать 4, но и не выдать 4 на 3*3, а еще не сожрать при этом 20гб памяти и не считать это 15 минут.
ИИ опять же тут не при чем, история с боингом, где он аутсорсил задачи в индию, очень хорошо показывает, что до ИИ было ровно то же самое, просто на уровне повыше.
Собственно дело именно в уровне повыше - заказчики в принципе всю свою жизнь строили найм "сайт мне запили" на выдаче результата по определённым критериям. Если бы Вы наняли аутсорс фирму и выдали бы ей четкое ТЗ с четкими критериями приемки - Вы бы не полезли в код проверять результат, Вам плевать было бы что там внутри, просто потому, что внутренности не были бы критериями отказа в приеме работы в случае найма аутсорс фирмы, а с работником Вы такое можете себе позволить.
Имхо, открылась шкатулка пандоры вообще с появления TDD, где в буквальном смысле разработку перевернули с ног на голову, во главу угла поставили прохождение тестов, а как они проходятся - было вторичным.
Просто Дима не до конца освоил вайбкодинг:
1) Детальное документирование - нужно использовать SDD, тогда модели не нужны такие комменты, которые по сути выполняют функцию семантической разметки
2) codestyle проекта - если в команде нет устоявшихся правил которые можно взять в rules - запускается сперва анализ проекта и эти самые правила инициализируеются. Более того, модели позволяет использовать контекст проекта. Так бы Дима "подхватил" контекст проекта. В любом SDD фреймворке это есть, ну или что то вроде Memory Bank надо использовать
3) Ловушка с алгоритмом - нужен процесс Code Review или в рамках SDD или в самом агенте. Желательно другой моделью, которая как раз проверить и Code Style и наименования. О таких косяках она укажет. Также правильные rules обычно содержат "мантру" - "переспроси если есть сомнения или несостыковки". Вообщем такую историю отлавливают даже самые начинающие вайбкодеры
4) Понимание предметки... Единственное с чем пожалуй трудновато "с ходу". Тут нужна подготовка "документации нет - половина в slack, что то в confluence"... Нужен MCP и для того и для другого с RAG и индексацией. Это требует подготовки. Чтобы не было разных коммитов опять же сначала спецификация, потом код. Проверять надо спецификацию. Или руками своими (если чувствуем силу в предметке) или сделать MCP с RAG. Но тут вопрос и к автору - знание предметки надо проверять на собесе или смотреть релевантный опыт по резюме. Если считается не критичным то review спек или MCP с RAG должны быть.
Итого, полностью согласен с автором статьи - Дима действительно полностью заслужил увольнение. Вайбкодингу надо учиться, а "чатик с GPT" это не серьёзный уровень, за который надо увольнять.
Бизнес старается купить/создать что-то дешевле (чем в среднем по рынку) и продать это дороже (чем в среднем по рынку).
Работники стараются сделать то же самое, только для них товаром остаётся их работа. Что можно сделать, чтобы увеличить доход:
или продавать свою работу дороже (очень сложно, бо «конкуре не дре»…),
или спихнуть её на кого-то, кто сделает дешевле (сложно и накажут, если обнаружат),
или научиться выполнять её быстрее обычного (тоже сложно, но уже разумно, поощряемо)
А тут учёные (непонятно зачем, ну да ладно) подарили бесплатно, всем, даром нечто, что можно припахать по второму варианту под видом третьего. А уметь этим всем пользоваться учить не стали.
И всё заверте…
Go-шная классика,
if err != nil
В принципе в статье описана проблема найма, о которой я писал, но о которой редко говорят.
Обычно все говорят, что HR плохой.
На деле найм, по большей части, сломан из-за тех. спецов, который ищут "второго себя". Или просто понятного человека.
Если кто-то думает иначе или делает иначе, то это вызывает ступор.
Я сам проходил такие собесы и не раз. Ищется не человек, который решает задачи, ищется человек, который прочитал туже книжку, что и ты, при подготовке к собесу. Ищется человек, который с расшаренным экраном, явно стресуя, будет работать с кодом или конфигом так же, как работал бы собеседующий.
Ищется "такой же, как я".
А многие люди, они другие. У них могут быть другие привычки. Могут быть другие подходы. Они могут мыслить иначе. А ещё они реально стрессуют на любом собесе, от чего заикаются, забываются.
А ещё они не умеют читать мысли и не знают, что вам надо.
В итоге кандидаты не навыки показывают и то, как их можно использовать, а пытаются угадать, как угодить "экзаменатору"
А по факту надо было не ловить Диму, а учится у него. Помочь ему не просто поменять промпт, а составить какой-нибудь корпоративный AGENTS, где были бы прописаны конвенции и правила. Если бы задачи делались не за 5 дней, а за 2, глядишь было бы время на документацию и на выстраивание процессов, а не на "привыкни к тому, как у нас принято".
Так, карма у меня около нуля, а потому можно и слить :). Меня осенило в середине чтения статьи что это мне напомнило: Лет 5-7+ назад тоже самое поведение у людей, которые в условный проект в котором надо из А сделать Б тащат супер-мега библиотеку которую они нашли в интернете. Эта библиотека точно может делать из А - Б (также она может делать английский, немецкий, японский и китайский неупрощённый, но это неважно) с кучей зависимостей и этот приглашённый шапито надо подружить с местным зоопарком. А потом внезапно оказывается, что что-то из зависимостей надо обновить и для этого нужна библиотека следующей версии в которой из А получается ... Б.0001 но это автору неважно, потому что он к китайскому добавил упрощённый, а на вопросы предлагает разобраться и пофиксить самому.
Да, когда я примерно тоже самое описывал в те года я получал кучу критики и негатива. Ну теперь те тру-программеры наступают на вайб-кодеров с АИ, который ещё более упрощает кодерство, но результат получается немного более утрированный от того что я имел в виду ранее.
Вспоминается скандал, который был несколько лет назад. Мелкомягкий (ЕМНИП) кодер с з/п за 100 килобаксов был почти как Дима, но LLM тогда не было и он пользовал индусов.
Лайк за самокритическое мышление-размышление :)
половина не может обход дерева написать
А в ваших разработках с дерганием API перевозчиков точно необходима повторяющаяся реализация обхода деревьев (у другие с ними действия), и поэтому вам надо чтобы работник умел не просто вызвать функцию поиска в дереве, а написать её? А то ведь тема "неадекватных вопросов" на собеседованиях часто вызывает закипание и бурление...
будем нанимать не разработчиков, а операторов LLM, и платить им те же 300к, и всё будет нормально?
К сожалению, если инфляция в РФ будет продолжаться по 4-5% в год, как нам рассказывают (сарказм), то 300к через 5 лет уже будут выглядеть совсем грустно...
У нас там if на три экрана, вложенные, потому что тарифы зависят от типа доставки, региона, веса, объёмного веса (это вес / 5000, для тех кто не в курсе, и этот коэффициент 5000 зашит у нас хардкодом с 2019 года, потому что «потом поменяем на конфиг» — ну вы знаете как бывает с потом.
Иными словами у вас говнокод. if на три экрана и зашитый в код хардкод. За такое обычно бьют палкой по рукам и обвиняют в проф. непригодности, но вы нашли себе какое-то оправдание, поэтому сильно об этом не беспокоитесь. Удобно устроились.
Вот этот рефакторинг я и дал Диме. Разложить ифы на стратегии. Через четыре дня — PR, 1200 строк. Разложено по файлам, паттерн Strategy, интерфейсы, тесты. Красиво.
Человек за короткий промежуток времени переделал весь ваш говнокод, создав нормальную структуры, разложил всё по файликам и прочее. А вместо благодарности от вас он получил какие-то подозрения и попытки "вывести" его на чистую воду.
По итогу всей статьи видно, что вы стали завидовать молодому человеку, который с использованием LLM делает работу лучше вас, но вы боитесь себе в этом признаться. А учитывая, что вы потратили на освоение профессии больше времени, чем он, вам становится вдвойне обидно.
Высокая текучка кадров у вас в группе\подразделении, а также детские обиды на покинувших вас людей, заставляет задуматься, что вы наносите компании больше вреда, чем пользы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я два месяца платил 300к человеку, который тихо скармливал мои задачи в ChatGPT