Comments 410
Типичная история — нашёл +80к в каком-то финтехе, ему там обещали «плоскую структуру и свободу принятия решений» (спойлер: через три месяца он написал мне что хочет вернуться, но мы уже наняли замену).
"ушел кобелина к сучке крашеной, на молодость и мини позарилса, ну и чо ,приполз через пол-года, послала его, нужен он мне больно, получше нашла!". детский сад, чесслово
Лучше никогда ничего не пробовать менять? Особенно, игнорировать места, где больше денег предлагают и где возможно развитие, хотя бы горизонтальное?
Думаю @fedorez кинул свой камень не в ушедшего на +80к, а в огород автора статьи. С вашей мыслью я согласен - надо пробовать менять и не игнорировать возможности. А вот с обозначенной выше классификацией "детский сад" - нет. С чего вдруг ответное законное и не аморальное действие работодателя вдруг стало "на уровне детсада"? Конечно вам (условно), как работнику, выгодно, чтоб вы "что хотели, то и делали, и вам за это ничего не было" (метафора). Отсутствие ответных реакций работодателя в дальнейшем приведет к безграничному развитию оху...вания работников - "всё равно вы мне ничего не сделаете, я очень важный и незаменимый".
Думаю, что камень кинули потому, что никакого отношения к теме повествования подробности ухода сотрудника не имеют, но тем не менее туда попали. При этом с долей некоего злорадства. Можно было написать: ушёл мидл, наняли нового. Всё, этого достаточно. Но начались подробности, как он ушёл, и как затем захотел обратно. Именно это, ИМХО, и подразумевал под «детским садом» пишущий.
Да и не видно у автора какого-то особого проявления ревности. Объективные обстоятельства – занято уже место было к тому времени.
Типичная история — нашёл +80к в каком-то финтехе, ему там обещали «плоскую структуру и свободу принятия решений» (спойлер: через три месяца он написал мне что хочет вернуться, но мы уже наняли замену).
Ушёл из аналогичной компании в финтех на +80к (в статье не про меня 😁), но ни о чём не жалею. Команда разработки и в прошлой была супер, очень благодарен прошлой компании. Но и сейчас команда супер, реализовал многие точки роста и ещё многие только предстоит.
Bellman-Ford
Недавно выходила статья про Bullshit benchmark, ChatGPT как раз плохо распознаёт чушь, а вот если бы "Дима" пользовался Claude, то дальше бы сидел на ЗП в 300к)
А ещё Диме надо было расширять SKILLS и редактировать код-стайл под проекты. Дима просто плохой вайб-кодер 😁
Но выборка маленькая, двух человек наняли после нового процесса,
а еще тот мидл что ушел на +80. и все с осени 2025. На 12 человек. С новогодними каникулами. Какая-то нездоровая у вас текучка...
Опыт и смысл действий заиграл совсем по другому, когда нужно не повторять, а быть творцом. На самом деле ничего страшного не происходит. Технологическая революция она такая, сначала появляются самые умные, а потом уже ее используют как надо и где надо. Хотя, грозятся, что появится AGI и всех на ноль перемножит.
Вы живете в старой парадигме найма и создания софта. Надо уметь не только писать код, а еще уметь в архитектуру, алгоритмы. Через 3-4 года, когда 98% кода будут писать роботы, нужны будут люди, умеющие целиком охватить проект и направить в нужное русло всю разработку. С контролем, тестами и т.д. и т.п. И всякая мелочевка, "типа как называются переменные", "сколько тут if-ов" и т.д. отойдет на 5й-10й план. Так что Диму нужно было поддержать, исправить его косяки, и внедрить в свою систему, используя его лучшие стороны. Ведь по факту он работал за двоих, получая одну з\п. Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК. Это при том, что вам все равно это придется делать через пару лет (а может и раньше). Не с Димой, так с кем то другим. Дима просто не вовремя пришел ))
Ведь по факту он работал за двоих, получая одну з\п. Код пишется? Система работает? Времени и затрат при этом меньше?
Если бы за ним перепроверять не приходилось за десятерых то да, все ОК.
В статье про это ни слова. Я исходил из статьи.
В статье про это ни слова. Я исходил из статьи.
Вот вообще ни слова. Мы точно одну статью читали?
Но за два месяца стиль проекта обычно подхватывают, а он не подхватывал.
Я дал фидбек, показал конвенции.
Дима сказал «понял, исправлю».
В следующем PR повторил всё то же самое.
Забивает на код-стайл, даже после того как объяснили языком.
Я написал: порядок скидок неправильный, посмотри как работает сейчас. Через 20 минут новый коммит. Теперь промокод первый. Опять не то. Я написал подробнее. Третий коммит — правильно.
Вот тут меня кольнуло. Не ошибка — все ошибаются. А то, что три раза подряд три разных варианта, и ни один не показывал что он ПОНЯЛ принцип. Он не спросил «а почему такой порядок?». Не уточнил «а минимальная маржа — она где задаётся?». Просто выдал другую реализацию. Как будто... ну, перегенерировал с новым промптом.
Ну с третьей попытки заимплементил фичу. Было бы бы 100 вариантов пришлось бы ему сто замечаний делать.
Попросил добавить новый тип доставки и в описании написал что для расчёта стоимости «используется адаптированный алгоритм Bellman-Ford».
Тут ожидается что человек либо спросит что за зверь этот ваш Bellman-Ford и с чем его есть либо посмотрит в гугле и спросит какое это вообще имеет отношение к задаче? Оно то конечно провокативно но очевидно что человек будет так и дальше поступать, не пропускать через себя все вопросы а напрямую в нейронку сливать.
Когда на стейджинге упал его сервис, он полтора часа ковырялся и не нашёл причину. Я нашёл за десять минут — race condition в горутинах, классика.
Ну тут тоже показательно для x2 программиста, не разобраться в собственном же коде.
Я вас спрошу: а вы готовы передать ИИ ответственность за ваш прод ? В смысле - если ваш прод упадет, то вы не будете орать на своих девелоперов: "А ну быстро все починили!", а будете промптить ИИ - и если он не работает, то писать в OpenAI, Anthropic и прочее спортлото ?
Если готовы - тогда флаг вам в руки, и наименования переменных не имеют значения, делайте что хотите!
Если не готовы - тогда нужно сделать так, чтобы команда разработки продолжала быть способной разбираться в коде и чинить его. А это значит - вертайте обратно правильную архитектуру, консистентные наименования переменных, и так далее...
Вы чуть не дожимаете. Тут даже не ответственность, а фактическое владение. Кто владеет средством производства.
владение и без этого может быть размазано, например, если инфра в облаке)
Так что тут хотя бы ответственность) Делегируя работу нейронке, не нужно делегировать и ответственность на нее
Чисто теоретически можно поднять OpenSource модель на своих серверах и будет полностью ваше владение. Хотя если вы пользуетесь облачными серверами и прочей инфраструктурой, общаетесь через облачные сервисы - Slack, Teams и так далее (данные в гугле диске, документация в Notion или Google Docs) который тоже не вам принадлежат, то вопрос вообще-то точно такой такой же.
Очень у немногих компаний вся инфраструктура своя в своем собственном дата-центре включая мессенджер-ВКС например и прочие сервисы.
нужны будут люди, умеющие целиком охватить проект и направить в нужное русло всю разработку
Так для этого надо вникать в бизнес-логику и требования.
А тут вся статья фактически о том что человек не хотел и не пытался это делать, какие лучшие стороны? Копипастить as is в чатгпт и обратно а-ля обезъяна, где тут работа за двоих? Не, не так, где тут вообще работа?
Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК.
Феноменальная одноизвилинность: код - это boolean, он или true, или false. Система тоже.
Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК
Не все "ОК". В статье ясно написано, что он не понимал что делает его код. Что когда на стейджинге упал его сервис, не смог найти причину, и делать это пришлось автору статьи...
Получается, это была своего рода "имитация" работы. И какое-то время это "работало" - до первого падения... Когда оно рано или поздно происходит - вайбкодер оказывается беспомощен. Он не понимает как работает код, не знает как искать причины багов, не умеет дебажить, не имеет опыта и насмотренности.
«Программа готова не тогда, когда она сработала правильно. Программа готова тогда, когда она не может сработать неправильно.» ©
Когда оно рано или поздно происходит - вайбкодер оказывается беспомощен. Он не понимает как работает код, не знает как искать причины багов, не умеет дебажить, не имеет опыта и насмотренности.
Если человек копал экскаватором траншею и случайно копнул не в ту сторону - логично, если он экскаватором и исправит, а не побежит за лопатой.
Если Дима весь из себя вайбкодер, то падения он должен исправлять тоже через использование ИИ, а не хватаясь в панике за чужой инструмент.
А зачем в этой цепочке Дима, тянущий только на роль оператора LLM?
Когда как раз всё ровно наоборот:
- топовый сеньёр с зачатками управления - может заменить отдел (по сегодняшним стандартам нагрузки) в средней сложности проекте/предметной области;
- человек с топовой дисциплиной/многозадачносью и зачатками понимания IT-инженерии -- отдел в простой предметной области.
Т.е. надо брать как можно более квалифицированных (и подходящих на свою роль) людей.
оператора LLM
А раньше были операторы ЭВМ 😏
И оказались не нужны - ибо где они сейчас?
Подозреваю на новом витке развития технологий - от "операторов" как лишнего звена избавятся сразу.
И оказались не нужны - ибо где они сейчас?
В бухгалтерии. Заменили бухгалтеров.
И оказались не нужны - ибо где они сейчас?
За каждым ПК в мире. Оператор -- знаком с принципами работы, архитектуры, выполняет операции: вводит данные и получает результат.
Заявляю со всей определённостью - девахи, которые сидят за компами у меня на работе, незнакомы с принципами работы и архитектуры, да и вообще, с чем-то большим, чем стандартный для их деятельности набор паттернов для работы в Excel и Word, которому их научили! Хотя формально это, конечно, ввод данных и получение результата.
Вы ответили не на тот вопрос. Вопрос-то был - где теперь люди, имеющие профессию "оператор ЭВМ", которые получают зарплату исключительно за своё операторство и ни за что другое.
Большинство людей, сидящих за ПК на работе, под это определение не попадают. Тот факт, что они сидят за ПК сами, а не поручают это сидение отдельному "оператору", не опровергает ваших оппонентов, а напротив - подтверждает их слова.
PS кстати, правильный ответ на вопрос - в МФЦ и банках они остались.
Так я потому бухгалтерию и привел в пример (ну кроме главбухов и прям серьезных фирм) "я тут ввела по инструкции, мне ваша 1С насчитала" - очень много рядовых исключительно берут бумажку вводят в ЭВМ, жмут кнопку "выполнить регламент", отправляют платежку согласно цифрам которые высветились. Если это не операторство, то что?
Вроде же наоборот, такие "бухгалтера" только в серьёзных фирмах и водятся? У "несерьёзной" фирмы попросту нет ресурсов на настолько полную автоматизацию процессов, там бухгалтерам волей-неволей приходится ещё и в бухгалтерии разбираться.
В мелких конторах бухгалтер может с 0 базу 1с заполнить, а что сам не может - вменяемое ТЗ для программиста составить. Тётеньки, которые удаляют интернет с рабочего стола в бухгалтерии встречаются все реже и реже
- топовый сеньёр с зачатками управления - может заменить отдел (по сегодняшним стандартам нагрузки) в средней сложности проекте/предметной области;
Прямо напомнило фильм Метод исключения. Просто как пример того что LLM заменяют целые отделы и производства.
Надо уметь не только писать код, а еще уметь в архитектуру, алгоритмы.
Вот именно это Дима и не умел.
Пусть бы сам не писал, а только контролировал. Но он же не понимал, что на выходе.
Код пишется? Система работает? Времени и затрат при этом меньше? Тогда все ОК.
Ну, *некоторые так считают*. Но потом...
Времени и затрат при этом меньше?
Затрат меньше у работника. Не у работодателя.
Дима сгенерировал API за полчаса, отдал результат через два дня. Фактические трудозатраты - полчаса. Работодатель заплатил за 16 часов работы.
Закономерно, что работодатель рано или поздно узнает, что можно платить за полчаса работы оператора llm вместо оплаты 16 часов работы программиста.
Добавочная стоимость от внедрения llm рано или поздно начнет оседать в карманах работодателя. Не работника.
Не питайте иллюзий.
Бизнесу - деньги, батраку - батрачево.
То, что Диме удалось урвать халявы на ранних этапах становления llm может сыграть с ним злую шутку, - тяжело будет вернуться в поле батрачить.
Притча
На заводе сломался станок. Никто не мог его починить. Пригласили старого мастера. Он походил, осмотрел станок, попросил молоток, нанес один точный удар — и станок заработал. Мастер выставил счет: 2000 долларов. Директор возмутился: «Что?! Ты же просто ударил молотком! Напиши детализацию счета». Мастер: «Удар молотком - 1 доллар. Знание того, куда ударить - 1999 долларов»
Я вот чем дольше живу тем больше понимаю, что проблема не в "создать", а в дебаге и поддержке. По этому, те кто упарываются в парадигму "зачем платить за 16 часов работы вместо 30 минут" на первой же аварии поймут это самое "зачем".
У нас есть люди которые могут месяцами ничего не делать (условно конечно) и им платят ЗП, почему? потому что они знают, умеют, практикуют проектирование сложнейших систем, 10 лет набивали шишки, правили косяки и знают как сделать быстро и оптимально. Имеют отличнейшие горизонтальные связи в своей сфере. И, что самое главное, знают когда можно класть на правила нормы и стандарты, а когда нет нужно упираться до последнего
Поддержу вас - такая позиция по отношению к работнику с высокой квалификацией и опытом постоянно приводит к тому, что выгоднее работать "спустя рукава" и даже "немножечко хуже", чем работать быстро и качественно. Мало кто понимает, почему надо так много платить сотруднику, если он так быстро всё делает и у него, как кажется со стороны, масса свободного времени. Это типичная психология жадины - определять свое отношение по одному, выгодному для себя, параметру. Не знаю, как это работает за пределами бывшего СССР, но внутри - это классическое шаблонное отношение к труду, воспитанное в прошлом "плановом" веке.
те кто упарываются в парадигму "зачем платить за 16 часов работы вместо 30 минут"
Получают конкурентное преимущество.
У нас есть люди которые могут месяцами ничего не делать (условно конечно) и им платят ЗП, почему?
Потому что они не делятся своими знаниями. Репозитории с пустым README файлом, тысячи строк исходного кода без единого комментария, страницы в confuence, содержащие вымученные десять строк в стиле капитана очевидности. Вместо того, чтобы поддерживать результат своего труда в задокументированном состоянии с описанием актуальных болячек, проблем, неочевидных нюансов и запланированных to-do-шек. Лишь бы удержать экспертизу в себе. Сохранить свою незаменимость. История стара как мир.
В новой парадигме, когда описание твоих навыков это тоже, оказывается, продукт, да еще и конкурент тебе же - вполне разумное поведение.
вполне разумное поведение
Скорее это недобросовестное поведение. Как по отношению к работодателю, так и по отношению к коллегам.
Грамотная разработка ПО подразумевает то, что его поддержка, развитие и сопровождение не становится головной болью для заказчика. И уж тем более не завязывается на одного единственного уникального эксперта, который в связи с этим может "месяцами ничего не делать", выступая в роли фарфоровой копилки для знаний.
Не не не. Ваши моральные оценки потеряли актуальность тогда, когда работодатель стал нанимать кожанных не работу работать, а на их работе модельки обучать с дальнейшим увольнением кожанных. А за свои знания как надо делать индивидуум много заплатил из своего кармана, что бы вот так задаром этот капитал отдавать по причине что это "не доброСОВЕСТНО". Давайте определять понятие совести в новых социальных отношениях безусловного дохода и всеобъемлющего творчества тогда.
Лишь бы удержать экспертизу в себе. Сохранить свою незаменимость. История стара как мир.
По опыту в корп среде: все плачутся, что нет доки. Но когда оценивают задачу - оценивают время написания кода, а не доки до состояния "чтобы джун разобраться мог".
В итоге код написан, фича работает, а писать доку некогда - уже следующая фича на горизонте и сказать "мне еще недельку надо на доку, так как надо на простой язык перевести, и форматирование в вашей конфле через одно место работает" - невозможно. Нету этой недели.
Да-да, очень распространенное и такое удобное оправдание.
И я даже не стану удивляться, как в одной голове могут уживаться "месяцами ничего не делать" и "писать доку некогда". Человеческая психика ко всему адаптируется)
Документацию некогда было писать, вот и приходится теперь "месяцами ничего не делать", потому что, "знают как сделать быстро и оптимально", но задокументировать это не могут. Хронически не хватает времени на чаепития "отличнейшие горизонтальные связи".
люди которые могут месяцами ничего не делать (условно конечно) и им платят ЗП, почему? потому что они знают, умеют, практикуют проектирование сложнейших систем, 10 лет набивали шишки, правили косяки и знают как сделать быстро и оптимально
Есть такое. Особенно, когда этот человек сам че-то эдакое накрутил, условно, написал 7-ми слойную распределенную CRM на акторном фреймворке, и теперь только он способен расширять этот репозиторий адекватными кусками кода. Есть ещё у девопсов что-то подобное, когда переусложненная инфра. Как правило, наличие таких людей в бизнесе, который не deep tech, и не управляет потоками в терабайты трафика в секунду или миллионы RPS, говорит только о том, что однажды свернули куда-то не туда и подняли сложность, где можно без нее. И, фактически, руководство допустило со своей командой ту же ошибку, которую делают начинающие вайбкодеры со своими llm, - не смогло вовремя задетектить бред и купировать его.
Виджу много минусов. Еще недавно я тоже был противником изменений, которые происходят в последнее время всвязи с использованием LLM. Но сегодня мое мнение изменилось, наверное я просто принял неизбежность изменений.
Я вижу как в моей компании все используют LLM. И не просто как умный поисковик: теперь это совершенно другой подход к разработке с массовым использованием MCP. Производительность- просто безумная!
Сам я не разработчик, а NetOps, но и я использую все эти средства для генерации конфигураций, да и для поиска проблем тоже.
В нашей компании бюджет на LLM измеряется десятками тысяч долларов в месяц. И руководство регулярно повторяет: "мы не хотим избавиться от половины сотрудников, но мы ожидаем увеличения производительности в разы. Time to market - главный приоритет."
Это Уже работает. Увы, мой 26-летний опыт больше не является конкурентным преимуществом! Знания базовые сейчас не имеют значения- гораздо важнее уметь настроить MCP сервер.
Когда я спрашиваю: "а кто будет отлаживать все эти ваши прекрасные решения?", то мне говорят, что автор и будет их отлаживать. Не человек, автор - LLM. Просто еще один уровень абстракции.
Это не будущее, это УЖЕ так работает. Компания - единорог.
И уж скорее тут уволят за отказ от использования LLM, чем как в статье.
Автору статьи советую оглянуться назад и не пытаться отказаться от виртуализации, контейнеризации, окестрации и использования IDE- за мой четвертьвековой опыт тработы я видел уже много "убийц индустрии".
Перемены это всегда непросто. Выживает сильнейший, самый гибкий - тот кто смог приспособиться. Просто очередной виток эволюции.
P.S. К тому времени когда уйдут титаны вроде автора статьи нужно готовиться отдавать существенную часть своего дохода в качестве оплаты за LLM. А без нее уже не сможете работать.
Вот, все вёрно. Но на хабре есть секта антиИИшников, и у них пока есть карма, чтобы поливать минусами тех, кто думает не так, как они. Но это временно. Я уже тут говорил, и еще раз повторю - пройдет 2-3-4 года и всё поменяется. Мы в начале пути, идет притирка, проверка, оптимизация процессов и т.д. Без этого никак. Новые технологии всегда проходят обкатку в реальных условиях. И кто-то уже снимает сливки, а кто-то пока стоит на месте и увольняет вот таких "Дим". ( Я его не оправдываю, парень конечно ступил, но свои 600к поимел. Многим в нашей стране, чтобы заработать такую сумму, нужно реально пахать, и не 2 месяца,а целый год.)
Все верно. Раньше говорили: а что ты будешь делать, когда прод упадет? В Google полезешь? Еще раньше говорили: считай в уме, калькулятор у тебя в кармане не всегда будет. Это старая байка от противников прогресса. ИИ наступает, и не надо этому противиться, а надо уметь пользоваться новыми возможностями. Диму фактически уволили за то, что он пользуется ChatGPT. Что в этом плохого? Судя по посту, 95% своей работы он делал качественно. Автор наверно забыл себя и свои факапы. А их, во времена отсутствия ИИ, уверен, было побольше, чем димины 5%.
иму фактически уволили за то, что он пользуется ChatGPT.
Ложь и манипуляция. Дима создавал команде прямые проблемы, не смог интегрировать свою работу в работу команды, фактически отбирая время членов команды.
а что ты будешь делать, когда прод упадет? В Google полезешь?
Опять манипуляция. Поход в документацию, в гугль, в ии - куда угодно не отменяет навыка автономной работы с проблемой.
Открою страшный секрет - при определенных типах проблем помощники просто недоступны.
Это старая байка от противников прогресса
Типична манипуляция от бракоделов. Вы приносите брак и когда Вам в него тыкают Вашим лицом Вы верещите про прогресс. Это работает не так.
Вам показали на брак, Вы так больше не делаете. Все.
Выдавайте нормальный результат на длительном периоде времени, неважно откуда он взят и будет всем хорошо. И команде и бизнесу и работнику.
Раньше говорили: а что ты будешь делать, когда прод упадет? В Google полезешь? Еще раньше говорили: считай в уме, калькулятор у тебя в кармане не всегда будет. Это старая байка от противников прогресса. ИИ наступает, и не надо этому противиться, а надо уметь пользоваться новыми возможностями
Я так и не понял, что будете делать-то когда прод упадет? Будете не противиться наступлению ИИ?
Все верно
Вы просто до отвращения сильно друг другу поддакивали
Раньше говорили: а что ты будешь делать, когда прод упадет? В Google полезешь? Еще раньше говорили: считай в уме, калькулятор у тебя в кармане не всегда будет.
И где они не правы? Когда человек не может в уме произвести простейшие арифметические действия, то скорее всего он имбецил, и о каких тогда "паттернах и архитектурах" можно говорить?
Просто поймите что Дима в этой истории не герой, а просто бесполезная и дорогостоящая мясная прокладка вместо агента. Он даже не учится, а просто приходит на работу отбывать номер.
секта антиИИшников
а может наоборот? Секта ИИшников?
Готов опуститься до вашего уровня аргументации и подачи:
Под каждым постом, где приводят значимые аргументы того, как ИИ-адепты гадят себе в штаны - приходит вот такой индивидум и топает ножками "врети, вы все врети, это не ИИ нагадил, это подбросили противники прогресса"
Вот, все вёрно. Но на хабре есть секта антиИИшников
По ощущениям наоборот - есть секта агрессивных фанатиков ИИ которые постоянно пишут однотипные истеричные комментарии без осмысленного содержания по одному и тому же шаблону, хамят всем вокруг. Возможно с помощью ИИ это все и генерят.
Становится грустно конечно, когда ответная реакция на таких фанатиков приводит к негативной реакции на использование ИИ в целом.
А вдруг это сам ИИ без прослойки из кожаных??
Мне кажется нынешний ИИ уже умней и просто не будет так дуболомно хамить всем подряд по одному и тому же шаблону, если ему не задаст именно такой промпт тот самый кожанный.
А если у него задача будет - попытайся отстоять свою значимость и важность предварительно проанализировав контент Хабра за последние полгода, принятый стиль общения, типичные статьи и комментарии, подключив данные с поиска в интернете и попадавшихся тебе задач, он явно лучше справится.
Но что-то думается мне бюджет у такой задачи выйдет не самый милосердный.
А Вы и с ней уже не сможете работать. Что изучать, когда в индустрии не складывается уже устоявшийся набор знаний, которые можно изучить и который останется актуальным к концу изучения?
Статьи "новая модель убила все предыдущие" выходят тут раз в неделю. Новый принцип программирования, новый подход каждую неделю, изучай не успевши даже понять как работает предыдущее, еще бест-практисы не сложились даже, а ведь еще и работу работать надо - это уже выглядит как гонка из фильма "Этот безумный безумный мир".
Вы вот пытаетесь убежать за поездом с табличкой "остаться востребовательным", а у этого поезда вагоны отцепляются прям на ходу и в итоге Вы же все равно где то внутри понимаете что за горизонт уедет один только локомотив? К слову у локомотивов та же гонка, у них поезда тоже вагоны отцепляются.
Скорость развития не связана с экономическим ростом ни линейно ни однонаправленно. Выше какой то скорости экономический рост резко замедляется и даже становится отрицательным - нобелевка по экономике крайняя. Старые структуры рушатся, а новые нет смысла создавать - поскольку сверхновые появляются быстрее, чем создаются новые. Все проекты на паузе.
Дело в том, что мы имеем только два возможных варианта в текущей ситуации: скулить о несовершенстве мира или возглавить происходящие изменения.
А оценка наша сильно ни на что не влияет.
Так и как, Вам уже удалось привлечь хотя бы три-четыре десятка миллиардов вечнозеленых для своей модельки, что бы что то там возглавить?
Сперва добейся?
Так а я тут при чем? Это у select26 всего два варианта - 0) скулить или 1) возглавить. У меня то самого вариантов побольше.
И если он не возглавит, а выглядит так что не возглавляет, значит скулит?
Ему придется или признать что он скулит/возглавляет и тогда его предыдущий пост еще может остаться логически верным или признать что погорячился. Вот давайте вместе посмотрим. Потому что все, что он не делает как лидер, будет подмято лидером.
автор и будет их отлаживать. Не человек, автор - LLM
Может именно поэтому CloudFlare за последние полгода показывает хуже аптайм, чем моя виртуалка у дешевого провайдера?
Какой сочный наброс, ммм!
Думаю, что вы неправильно проблему поняли. Иишка - отличный инструмент, но как и любым другим инструментом им же пользоваться надо уметь и понимать чего именно на выходе получиться должно.
Времени и затрат при этом меньше?
Суммарно в несколько раз больше - для команды создавались проблемы и автор их четко обозначил.
Тогда все ОК.
По сумме вреда куда больше чем пользы.
Ведь по факту он работал за двоих, получая одну з\п. Код пишется? Система работает? Времени и затрат при этом меньше?
извините, а вы каким местом читали статью?))
Как говорится, стыдно не знать и не спросить
обход дерева написать
Что такое дерево, я знаю, это такой граф без циклов и одиноких вершин. А что понимается под обходом? Допустим, я пишу функцию обхода дерева, что она должна выдать в качестве результата?
on-call
Я погуглил, что это значит. Это что-то вроде "могут разбудить ночью для работы"?
Про то, что с алгоритмом знакомы люди с профильным образованием, и это middle в go: значит ли это, что такого уровня в бэкенде нельзя достичь, не окончив универ и не самобразовавшись до этого уровня? Если человеку много лет, у него семья, нет времени на заочку, да и на чтение учебников, то всё, ему уровень middle закрыт?
Про нет времени: не буквально его нет, потому что загружен рабтой, а есть осознание, что жизнь конечна, самые беспечные годы позади, дальше тело будет страдать всё больше, и всё недоступнее становится любое удовольствие, будь то игра на гитаре без больных запястий или поход в кино без больной спины от неудобных кресел. Поэтому приоритет "сделать что-то приятное" становится всё выше, чем у "углубиться в прфессию", так как углубление в профессию отнимает время, вместе с этим некоторые удовольствия просто закрываются. Например, я уже не могу легко отстоять концерт в 3 часа (речь даже не про танцы) — спина сдаёт. В какой-то момент закроется велосипед из-за суставов. Книги, полагаю, продержатся дольше всего.
Книги несколько часов потом тож уже не почитать - глаза устают, хоть в очках, хоть без. Остается слушать. И честно говоря, особого прогресса в text-to-speech не вижу, хотя технологии лет 70, но по прежнему не могут по ролям читать (или хотя бы менять тональность голоса, как это делают проф.чтецы), ударения ставят мимо (в новых словечках и именах), сокращения по всякому (не понимают смысла текста и потому "дотянулась до его губ." - говорят про его губернии 😑)
on-call
Я погуглил, что это значит. Это что-то вроде "могут разбудить ночью для работы"?
Ога. Но, в идеале, должен быть "график дежурств" и оплачивается это дело дополнительно.
Допустим, я пишу функцию обхода дерева, что она должна выдать в качестве результата?
В простейшем случае распечатать числа в вершинах. В общем — вызвать функцию для каждой вершины
Понятно, что-то из серии "написать алгоритм сортировки пузырьком".
Ну вот я такое не напишу. Не потому что не могу понять - а просто не помню как, и не вижу смысла зачем.
Текущий проект помню, актуальную задачу, особенности реализации, вон ту хитрую функцию в библиотеке, на которую завязана бизнес-логика, с учетом 15 дополнительных параметров, и главное ПОЧЕМУ ТАК - да.
А алгоритм сортировки пузырьком или обход дерева - нет. Неактуальная на данный момент задача.
А я не то что не помню, я бы мог придумать, но я во первых не помню что такое дерево вот прямо сейчас, а во вторых не хочу помнить всей этой мишуры, потому что сильно подозреваю, что реальная работа с деревьями будет связана никак
Студентов же берут, бггг
Студенты помнят обход дерева , нормальные программисты не помнят
Понятно, что-то из серии "написать алгоритм сортировки пузырьком".
Ну вот я такое не напишу. Не потому что не могу понять - а просто не помню как, и не вижу смысла зачем.
2+2=?
Простейшие вещи помнить придется. Хотя бы для контроля ИИ
"написать алгоритм сортировки пузырьком".
20 секунд на то чтобы описать алгоритм (словами) и 20 минут на то чтобы вспомнить какой из них называется пузырьком и что было в голове у автора названия.
что было в голове у автора названия.
Пузырь и тёлка! ©
Ну ладно вам, рекурсии в работе нужны постоянно, их сложно забыть. Рекурсивно спуститься по дереву - это как-будто очень базовая задача, если не требуют чего-то вроде стека. А вот сортировку вообще никто никогда не пишет сам, поэтому ее никто и не помнит.
Ну вот я такое не напишу. Не потому что не могу понять - а просто не помню как, и не вижу смысла зачем.
Как можно не написать банальную рекурсию? Зачем тут что-то помнить? Тут не нужно помнить как, тут нужно просто взять и написать не помня. Как по мне, так это всё равно, что сказать: "Я не помню как пройтись циклом по массиву и распечатать каждый элемент, я вызываю функцию, которая это делает".
Наверное вот так и нейронке обязательно нужно "помнить" (иметь в анамнезе факт обучения с таким алгоритмом), чтобы получился нужный, годный результат...
(это я не с осуждением говорю - не мне осуждать, - а просто мелькнула мысль, что неплохой наглядный пример отличия AI от человека))
А кто сказал что это "банальная рекурсия"?
Сама постановка вопроса "обход дерева" - это буквально "назовите определение первой производной": правильным ответом будет процитировать текст определения из учебника, при этом понимать смысл этой самой производной, где и какую пользу она дает, совершенно необязательно.
Вот допустим дерево - а какое? У каждого узла две ветки? А если три? А если N? А если несимметричное? Перебирать последовательно, или форкать параллельно? Собирать результат или именно "распечатать каждый элемент" и забыть про него? Нырять в глубину или сначала обработать текущий уровень, и потом углубляться?
Какая цель обхода? И вот уже банальная рекурсия становится небанальной, а зависящей от конкретной задачи и текущей реализации. Может у вас тупо стека не хватит, потому что это микроконтроллер?
Но для этого надо думать, а не выдавать сходу заученный шаблон, "паттерн".
Что то много умных слов внезапно появилось после вчерашнего признания "дерево не напишу".
Или память внезапно разблокировалась или....
Вот допустим дерево - а какое? У каждого узла две ветки? А если три? А если N? А если несимметричное?
Вообще без разницы. На алгоритм и его свойства это никак не влияет. Ну будет у вас цикл не до 2, а до 3 или N или children.size(). Или цикл будет развернут где вместо children[0] и children[1] используются left и right.
Перебирать последовательно, или форкать параллельно?
Это уже чуть более состоятельный вопрос. Тут вам уже нужен обход в глубину или обход в ширину. Но человек с хоть с зачатками знания мат базы знает оба и уточнит.
Нырять в глубину или сначала обработать текущий уровень, и потом углубляться?
Это тупо переставить порядок двух действий. Тоже ни на что не влияет.
"Код сортировки пузырьковой
он распознать не смог с листа.
Ему давали в детстве мало
Кнута"
а просто не помню как
По-хорошему алгоритмические задачи как раз про посмотреть на то, как человек придумывает решение. Смысл от сотрудника, который умеет решать задачу a+b, но на b+a говорит «не вижу смысла зачем» или «неактуальная на данный момент задача»
А таблицу умножения вы тоже не помните, потому что это "неактуальная на данный момент задача"?
Написание алгоритма пузырьковой сотртировки - это простой фильтр. Фильтр компетенции, образования и когнитивных способностей. Я тоже его не помню - последний раз писал его, наверное, лет 30 назад. Но не сомневаюсь что за полчаса отлажу безо всяких LLM.
Для того чтобы строить дом не обязательно быть опытным маляром и помнить наизусть цвета RAL.
Тут точно так же.
А помнить наизусть ничего и не нужно. Но если строитель не способен покрастить условный кусок забора - то какие вообще задачи ему можно поручить на стройке? Разве что таскать что-нибудь, и то не факт.
Ну вот я например своими собственными руками построил дом. Небольшой, но построил. Используя в том числе знание принципов геометрии и тригонометрии, при том что стройматериалы считал на калькуляторе, цвет для крыши выбирал по специальной штуке - палитра называется, а стены покрасил "примерно как-то так", потому что это несущественно.
Можно было бы и опытного маляра для этого нанять - но зачем? (с)
Поэтому еще раз повторю, для того чтобы строить дом - необязательно быть опытным маляром и помнить наизусть цвета RAL.
И в программировании сложных систем - точно так же: есть вещи которые надо знать и понимать, а есть - "таблица умножения" и "обход дерева" - они могут понадобиться, могут не понадобиться, помнить их необязательно, при этом можно помнить, и оставаться тем "опытным маляром", который кроме покраски забора ничего не способен сделать.
Вы сравниваете обход дерева со знанием наизусть цветов RAL, но обход дерева - это покраска забора.
Предположим, вы решили всё-таки нанять опытного маляра для своего дома. Будете ли вы доверять маляру, который знает наизусть цвета RAL, но не может показать как он красит метр забора?
Как вы себе представляете "доверять маляру"?
Вот забор. Вот задача. Вот исполнитель.
Либо он делает как надо - и получает деньги, либо он не делает как надо, и переделывает/ищет субподрядчиков, либо досвидания даром.
Зачем ему "доверять"? "Ты покрасил забор хорошо, но как-то неуверенно"?
А таблицу умножения вы тоже не помните, потому что это "неактуальная на данный момент задача"?
Вы будете смеяться, но я не помнил таблицу умножения, когда учился в школе. Хотя был при этом лучшим учеником по математике. Подробности здесь.
Я вообще хорошо помню только то, с чем работал последние две недели, а все остальное забываю.
Я могу написать, и что такое дерево помню нормально, там в целом все просто и несложно, но.. опять эти чертовы "но", я все это легко проделаю сидя дома иди в офисе за столом в спокойно обстановке, когда на меня не давит жесткое ограничение по времени, и никто не сопит за спиной, наблюдая за каждым введенным символом в неудобном онлайн редакторе вместо нормальной IDE. Со всеми этими условиями я начинаю жестко тупить даже на довольно простых задачах, которые в комфортной обстановке щелкаю легко.
Думаю и автор немало людей отсеял, которые так-же начинают тупить на лайфкодинге.
Что такое дерево, я знаю, это такой граф без циклов и одиноких вершин. А что понимается под обходом?
Паттерн "Итератор"
В компании где я сейчас работаю, мы столкнулись сейчас с тем, что некоторые джуны, часто использующие нейросети в работе, не развивались в мидлов(а для компании это критично), а наоборот - деградировали. Нагенерил код, сдал таску и начисто забыл о том, что и как делал.
Как код работает в проекте, как сам проект работает, как работают смежные с ним проекты - они разбираться не хотят. Как говориться - разобраться-то "можно, а зачем?"
Но надо сказать, что когда мы им обоснованно объяснили, в чем их проблема, и что от них нужно компании, а самое главное перспективу, что они навсегда останутся на зарплате Джуна, ребята все поняли и стали-таки развиваться - читать туториалы, смотреть обучающие видео, курсы проходить и так далее. Тем более что компания это всячески поощряет и оплачивает.
Только один отказался наотрез, да еще и борзеть начал - в стиле, что мы ничего не понимаем и у нас устаревшие подходы к разработке - его пришлось уволить.
Сейчас особых проблем с Copilot-ами и прочими ИИ-шками нет.
Вот я про это и пишу, но есть тут группа не пробиваемых, которые до этого пока не дошли, но при этом минусатор сразу включают.
Как говориться - разобраться-то "можно, а зачем?"
Ну так а вы ответили на этот вопрос? Кроме успешного успеха развитие ради развития. Почему человек не может хотеть сидеть в миддлах-джунах и не хотеть идти в сеньоры и лиды с нагрузкой х10, а зарплатой х2?
Наша компания принадлежит 5 банкам, которым и сдает аналитиков и разрабов внаем в проекты. Соответственно, чем выше квалификация у разрабов, тем лучше бизнес. Джуны не нужны в такой схеме вообще, но мы берем студентов со второго курса и выращиваем из них мидлов и далее. И для себя и социальная миссия.
А если кто-то профессионально расти не хочет, то зачем он вообще в профессию пришел? И нам такой точно не нужен. Что с ним делать-то?
Но к счастью, с современной молодежью проблем особых нет, все учатся, развиваются и набираются опыта, никто не жалуется. Я как раз занимаюсь дообучением Джунов, в том числе, за 4 года пара человек только попалось необучаемых...
del - хабр стёр 3/4 сообщения, заново лень писать
... и выращиваем из них мидлов и далее
А когда вырастили как удерживаете?
А то ведь уйдут на +80к в бигтех
Или у вас там какой-то договор что обязаны отработать?
У нас платят денег меньше чем у клиента, но полная удаленка, никто мозги не компостирует, как в больших корпорациях, разрешено свободно переходить из проекта в проект, билет на все виды транспорта оплачивают, электро велосипед можно взять за 30%(правда отработать потом надо в компании 2 года) и в целом отношение хорошее и уважительное. Компания 3% от годового оклада дополнительно выделяет на развитие сотрудника. Я немецкий учу, кто-то по конференциям ездит.
Кто-то уходит, конечно, но большинство остается.
Только один отказался наотрез, да еще и борзеть начал - в стиле, что мы ничего не понимаем и у нас устаревшие подходы к разработке - его пришлось уволить.
Со своей стороны он прав. Зачем ему помнить прежние решения, если он маленький винтик в системе? Пока мидл делает один проект, этот джун на быструю сляпает семь порученных заданий (из них три на стороне) и получит больше денег. А то как эти задания будут интегрированы в общий проект - на его уровне все равно, его задача - максимально заработать, а не стать лидом в компании.
Мы осенью делали сайт, я пару месяцев писал фронтенд для него. А теперь пришли правки и я вообще не помню, что там откуда торчит, приходится вникать заново. А ведь я нейросетью написал всего один тип, да и то, потом зарефакторил, когда понял принцип, как его нужно было делать.
И до какого уровня вниз они дотянулись? До алгоритмов? До реализации их компилятором? До окружения выполнения кода в userspace OS? До оптимизации машинного кода?
Если Нет - можно ли назвать их верхоглядами, которые не понимают что реально делает их код и сколько РОН у процессора, на котром он работает?
Это Просто еще один уровень абстракции. Такое было уже не раз и каждый раз динозавры, которые пишут самый правильный и оптимальный код вымирают. Потому что он никому не нужен! Нужен time to market first!
он очень нервничал когда я попросил шарить экран
Любой нормальный аутистинтровертпрограммист будет нервничать в такой ситуации, написание кода это процесс сугубо личный
Только для неуверенных в себе людей, независимо от профессии..
дело может быть вообще не в коде.
Твой рабочий компьютер, рабочие программы, организация всего этого, включая установку ПО для "шаринга" - это примерно как раздеться догола посреди улицы зимой: даже если есть чем похвастаться и покрасоваться - всё равно улица и зима как-то не способствуют.
Ну нет, сейчас пошарить экран способов навалом и без мутного ПО, даже мессенджеры это умеют. Тут или боязнь сцены или боязнь показать некомпетентность. В рабочем процессе на созвонах постоянно приходится шарить экран, чтобы подкреплять объяснения. Мы же на работе совместную работу работаем, а не любовные письма пишем.
Ну вот я знаю таких коллег - вообще пофиг, посреди созвона на 10 человек открывают свой ТГ или почту, чтобы показать сообщения от заказчика, а там на пол-экрана слева личные переписки с женой, друзьями или оповещения типа "ваши анализы готовы".
Я так не могу, а им вообще норм.
А есть другие, которые даже со скриншотов адресную строку браузера убирают, чтобы не было видно запущенных плагинов.
Какой-то корреляции с компетентностью не замечаю.
Пошарить можно конкретное окно. ПО для шаринга - это ПО для видеосвязи, по которому вы проходите интервью. Это примерно как "напишите в блокноте список покупок, только покажите мне, как вы записываете".
Ключевое "твой рабочий компьютер", на нем априори должны быть только рабочие вещи. Т.е не твое личное. Я вот прям представляю картинку, как токарь стыдливо заслоняет собой станок =) Это какие то личные тараканы. Я не держу на рабочем столе то, что никто не должен увидеть. По работе часто общаемся в тимс и расшариваем экраны.
Понятно уже всё из статьи:
Набирают студентов (помнят обход дерева) и экстравертов (ливкод) на 300 в наносек.
Потом будят его по ночам для тушения пожаров 🔥 и жалуются на то что "равнодушен к коду", пишет в LLM и тупит на инциденте.
Эффективная сова 🦉
Любой нормальный аутистинтровертпрограммист будет нервничать в такой ситуации, написание кода это процесс сугубо личный
С чего бы? Я вот интроверт-программист (про аутизм не знаю), и для меня пошарить экран гораздо проще, чем проходить собеседование разговором. Когда я несколько лет назад искал работу - я просто мечтал, чтобы на очередном собеседовании меня перестали донимать составлением психологических портретов и натальных карт, и просто попросили показать как я умею работать.
Я два месяца платил 300к человеку, который тихо скармливал мои задачи в ChatGPT
Результаты есть? Тогда какая разница, силами ИИ или нескольких субсубподрядчиков была выполнена работа.
Нет доверия к результатам ИИ? А вот это уже ответственность исполнителя, которому платили 300К (не так уж и много для некоторых таск).
Так проблема-то не в том, что силами ИИ написано, а в том, что на рынке куча чуваков, которые не думая, просто пихают задачи в ии.
А Некоторые используют автодополнение, а то и (о ужас) Copilot в IDE! Где грань допустимого?
Если работа- это написание кода и вас есть инструмент, который делает это эффективно, то можно ли осуждать его использование?
Никто не пишет в блокноте сейчас и не отладивает на листочке! А я помню как осуждали IDE - это же полная деградация инженера! Он же не помнит синтаксис!
Повторяется история..
Предметку ещё знать надо. Чуваки, которые не вникают в предметку, а просто пихают в нейронку - стоят сильно дешевле, и будут, когда переходный период закончится.
Когда закончится этот переходный период неразрывно начнется следующий, не будет никаких устоявшихся бест-практис, знание и следование которым чего то там гарантируют. Вы, как ипотечный заемщик оказываетесь крайне ненадежным господином. И не только Вы, весь стафф работающий с данными в том или ином виде.
Еще один то ли вообще не читал статью, то ли не дочитал. Если человек используя автодополнение будет постоянно дополнять до translateToEnglish вместо translateToFrench, то уволят его не за использование автодополнения, как вы это тут пытаетесь извернуть.
А вот это уже ответственность исполнителя,
Вот исполнителя и уволили, потому что он со своей ответственностью не справился.
Важная особенность llm-разработчиков в команде состоит в том, что они не включают эмоции ответственности за код, который от их имени попадает в приложение. Ответственность - это непростая эмоция, её сопровождают стыд, страх, иногда злость. Автор, я понимаю ваши ощущения. Я бы обсудил вариант: "так продолжать нельзя, нужно вот так, ты готов поменять подход?", может вы тоже попробовали, но в тексте не упоминается. Попробовал бы объяснить, что профессиональный рост включает то, что человек начинает драйвить какой-то функционал, а это подразумевает ответственность, и дальше человек сам решает, что не готов верить llm-ке. А пока код ревьюит (читай "принимает") кто-то другой, то и отношение к коду такое, что он не мой, пусть хоть llm-кой, хоть индусом будет создан.
Код на работе пишут ЗА ДЕНЬГИ. Есть критерий приемки кода : тестовое покрытие. Если нужно что еще, кроме рабочего кода, нужно оговаривать это при приеме на работу: цветы поливать, пол протирать, отвечать на звонки ночью, кодить в галстуке или не использовать LLM. И быть готовым за это платить.
Формализуйте критерии приемки, если кроме рабочего кода вам нужно что-то еще (отладка, документация и т.п.)
Есть критерий приемки кода : тестовое покрытие.
А тесты тоже нейронка написала и всё зелёное :)
В общем случае, контроллер всегда независим от контролируемого объекта как раз чтобы исключить такую ситуацию. Одному платят за работу, второму за поиск недостатков в этой работе.
Так Что опять вопрос к организации процесса.
Вот главная проблема ИИ - в том, что именно этот принцип тут и ломается. Обезьяна с ИИ способна за день сгенерировать столько мусора, сколько десяток "контроллёров" за месяц не разберёт.
Потому каждый вайбкодер обязан сам следить за своими моделями и проверять что они там нагенерировали. Как это делать - не важно, важен результат. Можешь это делать? Отлично, ты x10 специалист. Не можешь? Ты Дима.
Критерий приемки кода - это чтобы он выполнял задачи пользователя. Правильно и стабильно, без падений прода. Не только прямо сейчас - а на много лет вперед. А если вдруг все-таки что-то неправильно будет или упадет - это можно было легко и быстро починить или поднять.
Тесты этому конечно помогают, но не гарантируют.
Детский сад. Хороший разработчик должен понимать, что и зачем делает код, включая широкий бизнес-контекст. Код должен быть максимально читабельным и очевидным, чтобы при ревью и отладке было минимальное количество непоняток, и человеку, который владеет кодом, максимально выгодно, чтобы эти качества имелись. У меня тестировщики не "принимают" код в том смысле, что нет такого, что они начинают отвечать за него, тестировщики помогают мне как владельцу кода и функциональности убедиться в работоспособности. Код должен быть достаточно производительным. Это не нужно формализовывать, это рабочее отношение, оно выгодно работодателю. За это платят деньги.
Честно говоря вообще не понимаю, как можно собрать команду программистов... иногда думаю на эту тему и в голову приходит только - нанимать тех кто на виду - блогеров и тех, кто обучает на платформах. А найм по объявлению это черная дыра. Как можно отслеживать и контролировать код - мне лично - просто не понятно. На одно программиста нужно второго проверяющего... и проверяющего не просто, как линтер - по верхам пробежался, а вникать в суть - понимать что пишет программист и почему он так пишет - вникать в сюжет и сюжет должен быть.. Вот читаю такие посты и представляю, какой кошмар творится во всех IT компаниях... Это у вас есть время вникать в код, а если бы вы занимались другими вопросами или вместо себя надо было поставить другого, а самому заняться другим делом. Страшно представить во что это все выльется спустя месяц или не дай бог пол года такого кода
Процесс контроля называется код ревью и там где он реально работает, и читают и вникают. Более того код ревью помогает и в онбординге, когда новичку призодится и вникать и понимать, что же там сделал коллега.
автор пишет, что код работает и что поймал случайно... хочу сказать - я сам пользуюсь нейронками, что бы писать скрпиты. Я не могу без базы - то есть мне нужно что то, что бы на основе этого спроектировать. Это качество з за отсутствия опыта. Но к чему я - к томы, что когда нейронка выдает код - у меня мозги набекрень выворачиваются) Нейронка пишет вроде бы все логично и каждый отдельный кусок кода понятен и логичен и даже красив, но когда я пытаюсь понять общую картину - почему сделано так, зачем сделано так, когда можно было структурировать по функционалу, разбить на логические блоки и переиспользовать код.. тут возникает очень много вопросов - код от нейронки работающий, но что бы его масштабировать или прикрутить функционал - это фиаско. Бесполезно - код одноразовый. В общем не знаю с чем это связано - скорее всего с данными, на которых обучали - то есть нет акцента на единый стиль или структуру и в итоге получается каша от которой можно тронуться если пытаться разобраться. И возвращаясь к посту - код ревью - это отлично, но кажется там такая же ситуация - код работает, написан отдельными частями логично и понятно, но если смотреть в целом - это бред сумасшедшего из соседней палаты... и что бы понять всю картину - надо прочитаь код и понять замысел от начала и до конца - и я не уверен, что ревьюверы способны вывозить такую нагрузку. в общем у меня ничего кроме сочувствия данный пост не вызывает. Сочувствие в смысле - понимание.
Мне кажется, вы несколько драматизируете. Условно, на проекте работают 5 программистов. Все пишут код, все понимают кодовую базу и используемые фреймворки. Когда приходит время ревью, тебе не надо идти и смотреть на все классы, ты уже его знаешь, ты сам его пишешь, и у тебя есть картина того как, что, где и почему работает. Поэтому нет, очередной код-ревью - это не записки сумасшедшего и ты сразу понимаешь ложится оно в архитектуру и конвенцию проекта. Но да, иногда приходится выкачивать ветку себе и проверять, что там написали и точно ли работает.
Не исключаю, что драматизирую, но это лишь мое мнение. Я исхожу из того насколькоо трудоемко отрефакторить код от нейронки. То есть в моем случае и в моем опыте от изначального варианта написанного нейронкой не остается ровным счетом ничего. То есть я вникаю в каждую строку кода и каждая строка переписывается или вообще удаляется и заменяется другим кодом или другим подходом. Я сейчас не умаляю пользы нейронок - без них я бы вообще ничего никогда не сделал в плане кода. Я говорю об архитектурном вопросе скорее... Но с вами согласен - когда есть архитектура и необходимо только штамповать новый и новый однотипный код - ревью делается просто. Но в посте говорится о задаче по интеграции апи от заказчика и не понятно - типовая ли это задача или тут полет фантазии. Если полет фантазии, то это как раз то о чем я говорю, если типовая задача, то это то о чем говорите вы. По этому в вашей картине я драматизирую, а в своей нет. В любом случае - мое мнение основано на моем опыте, а опыт такой какой есть. Сколько бы подробно не создавать PRD результат один - все под снос. В моем случае работает только когда чуть ли не построчно объясняешь что откуда брать, как обрабатывать, как передавать и прочее и прочее - но описать в таком виде весь проект невозможно. Слышал мнение, что нейронки так или иначе меняют представление программиста о коде. Шаг за шагом, функция за функцией и символ за символом. Это снежный ком в прямом смысле. Но возвращаясь к вашим словам - когда сформирован скелет - здесь нейронки работают отлично!
Частично идея переписать все в случае нейронки из за меньшей ценности кода нейронки, чем коллеги. Вот я вижу решение на ревью. Оно может сильно не такое, как писал бы я, но оно соответствует стандартам, мое решение не быстрее, не безопаснее, я задаю пару вопросов по местам, которые я не понял или вызвали у меня сомнения и пропускаю в прод. Нейронкино я бы может тоже порефачил сразу, она не обидится.
А интеграция АПИ кажется насквозь дубовая типовая задача - сделали на своей стороне по функции на вызов, добавили перевод из терминологии внешней системы на нашу, а в нашем легаси архитектура уже сто лет как есть и всем знакома.
Ну если все соответствует стандартам и в целом все подходит, то и данного поста бы не было. Тут автор гооврит, что некий Дмитрий или как там его - говорил, что все понял и все исправлю и при следующем обновлении опять все тоже самое, но код при этом работает. Принимать или нет - не понятно. Вроде работает, а ввроде сказал, что будет следовать принципам. Если примешь код - то не будет стандарта, а не примешь... ну вот автор в итоге и не принял в какой то момент. А переписать код нейронки из за меньшей ценности чем коллеги это интересное замечание... Не ясно сколько кода не по стандарту уже попало в проект из за высокой ценности коллеги, а с другой стороны сколько часов потрачено на рефакторинг кода от нейронки из за малой ценности) Тут есть над чем поразмышлять
Код не по стандарту - не попадет. А вот, например, линейка между функцией на 2000 строк и функциями по 3 строки у нас в стандарте не зафиксирована, каждый пишет как привык. И я могу написать комментарий, что лучше бы на полэкрана-экран функцию держать, но формально нарушений нет и ни переписывать ни блокировать MR не буду.
Или я, например, сторонник раннего возврата, а есть народ который весь смысловой код внутри условия пишет. И так несколько раз. В итоге когнитивка околопредельная, зато точка выхода одна.
Я подозреваю, что это связано с обучением нейронок - они в основном нацелены на "решение задачи в 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 тоже можно прочитать и проанализировать, если нужно.
Я могу llm-ке предъявить финансовые претензии, если считаю, что качество плохое? BIOS/UEFI не "никто не читает целиком", есть ненулевое количество тех, кто читает.
А кому вы будете предъявлять финансовые претензии за некачественный BIOS, мне даже интересно?
Ваши слова и есть та самая манипуляция, про котоую вы говорите.
В чем разница между сгенерированым LLM кодом и написанным человеком в этом аспекте:
Кем этот код верифицирован? Самой моделью? Где доказательства верификации? Я могу llm-ке предъявить финансовые претензии, если считаю, что качество плохое?
Кто вас заставляет использовать LLM? Пишите в блокноте, зачем доверять IDE?
Вы подменяете отсутствие формализации ТЗ и приемки кода какием то "доверием и доказательствами".
Не можете принять работу, о каких претензиях вообще можно вести речь?
Часто даже не верификация нужна, а гарантия быстрого исправления, если что-то колом встанет. Бизнесу обычно нужно запускаться уже сейчас и он готов закладывать издержки на простои после пуска, лишь бы не стоять в тупом ожидании пока всё верифицируют. Но есть нюанс. Риски, которые может себе позволить завод по производству туалетной бумаги не сравнятся с рисками сталепрокатного производства. Хотя, что там рулоны, что тут.
Интересный взгляд.
1 Что меня заинтересовало - это находка и обличение манипуляции. Мне думается что автор , почему то боится стать жертвой манипуляции, и находит ее даже там где ее нет.
2 Что касается верификации результатов работы LLM. В силу своей специфичной работы, в далекие времена когда LLM и в помине не было, а разбираться как работает чужой (вредоносный код) приходилось каждый день и в больших объмах. Тав вот IDA далеко не всегда давала удовлетворительный результат. И в этом случае, на помощь приходил метод черного ящика. Ты не знаешь как работает код, запускаешь в песочнице даешь на вход данные смотришь что выходит, потом меняешь входные параметры смотришь на результат и в итоге решаешь свою задачу. Сейчас работа с LLM это ровно такая же работа с черным ящиком. Ты влияешь на выдачу, меняя входящий поток. А еще есть проверочные(верификационные) примеры, где ты знаешь что должно быть на выходе. Короче, подход с большущей бородой и он работает.
3 Про финансовые претензии - прекрасно!!! автор пишет :- "если считаю, что качество плохое" - а как быть с тем что у многих может быть мнение что качество хорошее. Или автор считает себя истинной в последней инстанции.
Меня сейчас закидают помидорами и заминусуют , но почему многие уверены, что 2Х2=4 ? Потому что в начальной школе нам об этом сказала математичка в школе?
но почему многие уверены, что 2Х2=4 ?
Потому что это легко проверяется.
Тав вот IDA далеко не всегда давала удовлетворительный результат.
IDA отличный дизассемблер, в этом плане её результат более чем удовлетворительный
И в этом случае, на помощь приходил метод черного ящика. Ты не знаешь как работает код, запускаешь в песочнице даешь на вход данные смотришь что выходит, потом меняешь входные параметры смотришь на результат и в итоге решаешь свою задачу.
Это работало вот почему: 1. вы предполагаете, что программа - детерминированный алгоритм. 2. Вы подаёте данные на вход, смотрите, что на выходе, и строите гипотезы об этом алгоритме. 3. Гипотеза предсказывает, какой результат будет при новых данных, вы подаёте эти данные и подтверждаете или отвергаете гипотезу.
У LLM-ки по-первых есть элемент случайности (регулируется температурой), а во-вторых LLM-сервисы меняют веса, пока вы ими пользуетесь. Удачи в том, чтобы играть с ней в игру. В этом суть важных претензий: неуправляемость процессом разработки.
Сейчас работа с LLM это ровно такая же работа с черным ящиком. Ты влияешь на выдачу, меняя входящий поток.
Вы предлагаете получать код в стиле игры в рулетку, ставя фишки на разные числа, влияя таким образом на результат, и веря в выигрыш? Ню-ню.
Меня сейчас закидают помидорами и заминусуют , но почему многие уверены, что 2Х2=4 ? Потому что в начальной школе нам об этом сказала математичка в школе?
Потому что умножение определено как сложение одинаковых слагаемых, и по этому определению 2*2 = 2+2 = 4. Ну что за жалкие попытки заявить "Вы просто трусливые рабы авторитетов и привычек". Кстати, а что, в вашем новом светлом будущем 2*2 не равно 4 ?
начнем с претензии о "неуправляемость процессом разработки."
- давайте сделаем допущение, что разработка и ее процессы бывают разные:
- разработка системы контроля охлаждения атомной электростанции - это система и тут я бы точно хотел знать, что точно исполняет каждая функция (и перезаложился бы пару раз)
- создание MVP проекта ну скажем продвижение рекламных постов в соцсети. Чем раньше я получу хоть что-то работающее для подтверждения или развенчания гипотезы, тем лучше/дешевле
Сегодня (это мое мнение) LLM- отличный инструмент для проверки гипотез, и фиг с этой неуправляемостью процесса. Если я могу запилить MVP джуном за 2 дня, то бизнес будет доволен как сожравший корову питон.
А если гипотеза взлетит - вот тут будем делать работающую систему с управляемыми процессами в рамках сроков и бюджетов
А про 2Х2 в моем сегодняшнем дне - это также как и у вас = 4, а что будет условно завтра ? Ведь LLM еще пару лет назад были почти фантастикой, а сегодня мы говорим об ИИ как о имеющемся факте как то что 2Х2=4
Как принимать, если это реально ведьмы и колдуны, которые не понимают сути своего колдунства? А если кодить для реального производства, где тоже сроки и надо уже запускаться, пусть и со слабо оттестированным кодом? Линия стартует, заказчик готов к частым остановкам, надо методом пристального взгляда искать проблемы и на живую править. А если не понимаешь, что происходит в коде, то всё - приехали, будешь пол дня всматриваться.
Как принимать, если это реально ведьмы и колдуны, которые не понимают сути своего колдунства?
Так а вам то какая печаль? Вы заказали красную кнопку посредине экрана? Вы ее получили? Она посредине? Приз в студию!
Если Вы не формализовали дополнительные требования, почему кто-то должен из реализовать?
Есть, например, сейчас organic food, якобы выращенный на экологически чистом навозе и собранный руками китайских девственниц. Это спецтребования заказчика и они соответственно оплачиваются.
А если кодить для реального производства, где тоже сроки и надо уже запускаться, пусть и со слабо оттестированным кодом?
Вот, Вы и подчеркнули реальную проблему: дело не в кодинге как таковом а в огранизации процесса разработки, который включает в себя аналитику, ТЗ, написание документации и тестового покрытия и только потом - кода.
Это все давно придумано.
Нужно просто не сидеть на попе ровно, а учиться и идти в ногу со временем.
Хоть плачь каждый день - назад уже не вернуть.
Нужно просто не сидеть на попе ровно, а учиться и идти в ногу со временем.
Отличное напутсвие ведьмам и колдунам! Бывает нужен работник, который не только может нафигачить красную кнопку, но и интегрировать её в процессы заказчика и в дальнейшем поддерживать и оперативно реагировать на аварийные ситуации.
Вот, Вы и подчеркнули реальную проблему: дело не в кодинге как таковом а в огранизации процесса разработки, который включает в себя аналитику, ТЗ, написание документации и тестового покрытия и только потом - кода.
Это в идеале, а реале накодить надо было еще вчера, а сегодня уже пробный пуск. Документацию пишем перед приёмкой, а тестовое покрытие делаем в процессе. Если не понимать суть происходящего в коде, то все сроки будут сорваны.
Память стала дешёвой
Ну, как вам сказать )))
Статья выглядит как тролинг. Вначале докопались до комментариев, потом до нейминга переменных, потом ещё до чего-то потом каую-то "ловушку" делали.
Вам шашечки или ехать? На ревью - настройте линтеры / ревью-ботов которые по вашим требованиям будут проверять код на соответствие если уж так хочется.
Если мидл успешно работал, закрывал фичи и справлялся с остальными обязанностями мидла - в чем проблема?
Архитектуру, задел на 10-кратный рост и тд - за это все отвечают сениоры.
За дебаг своих фичей отвечает мидл. Но одного примера из статьи явно не достаточно. То что мидл будет дебажиться дольше чем сениор - это очевидно и ожидаемо. Вот если он вообще свой код не может починить - тогда да, проблема.
За прояснение бизнес требования тоже отвечает мидл. Если он регулярно делает не то что надо и приходится потом переделывать - тогда проблема, но оно должно было еще на испыталке вылезти.
Чтобы понимать что что-то сломалось нужно иметь представление как все это должно правильно работать. Нужна 'голова' где будет собираться общая картинка. Что бы починить за адекватное время/усилия нужен читабельный код по единым конвенциям. С ИИ нагенерите таку кучу кода о которой индусы могут только мечтать.
Из опыта работы еще в до ИИ-шную эпоху в тяжелых проектах-долгостроях с кучей легаси, говнокода, кривой архитектуры и прочего техдолга:
Говнокод имеет тенденцию достигать критической массы, после которой попытка впихнуть хоть еще одну фичу приводит к экспоненциальному росту количества багов (нередко, где-то совсем в другом месте). Так вот ИИ генерирует такой говнокод с гораздо большим энтузиазмом и в большем количестве, даже больше чем джуны. Но если за джунами еще как-то присматривают, то вайб-кодеры, как вы правильно заметили, вообще не напрягаются. Короче, классический "херак, херак и в продакшен".
пару сообщений выше тоже самое пишу - "Сколько бы подробно не создавать PRD результат один - все под снос." Рефакторить нужно капитально, а если не рефакторить - то случится капец. Не расширяемый, не поддерживаемый одноразовый код
А если объявить модульность по максимуму на проекте и чтобы с конвенциями для входных и выходных данных и без сайдэффектов? Говновабкодишь локально, связность минимальная, проектировать сложнее, зато дебажить легче.
Одноразовый код вполне себе тактика. Кто-то из серьезных как раз такую тему толкал: любой микросервис должен писаться за 2 недели край. Чтобы когда возникнет необходимость не разбираться в легаси, а выкинуть и переписать по новым требованиям. А вот за API держитесь, на них все и работает.
Интересное замечание. Тут поднимается вопрос тестирования. Какой бы код ни был сложным - его надо тестировать.И скорее всего проблема, как раз в этом. Скомкать и написать новый - вариант, но какие гарантии... Опять понимается вопрос расширяемости, гибкости, устойчивости и плюс как контраргумент против вашей мысли - тестируемость. Если первые три можно отбросить за скобки в парадигме серьезного человека, который высказывался, то тестируемость никак не отбросишь. А что бы протестировать надо понять вообще, что тут написали... в общем это цикл получается. И ваша мысль - держитесь за апи - я бы все же расширил и сказал - держитесь за код. За код в целом. Сделать просто - это сложно. Что бы сделать просто и элегантно - надо пораскинуть мозгами. Агенты не умеют этого делать - любой баг они прикрывают все новым и новым кодом. Я соглашусь с вами, что одноразовый код это вполне себе тактика - для проекта, который нужен здесь и сейчас, но прод на этой тактике не выживет... но с другой стороны - дорогу осилит идущий. Может и одноразовый код станет стандартом. Сложно предполагать сейчас. Но звучит стремно .как по мне)
код хранит в себе накопленный опыт. Я слабо предстваляю, как можно написать хоть сколько-нибудь сложное приложение, просто переписывая код.
ИИ обучены по большему счёту на публичных репозиториях из github/gitlab а там более 95% кода это пет проекты.
Без конкретно детализированного промпта, ИИ выдаст не идеальное решение.
Детализация и описание промпта + чтение и тестироване отнимают больше времени чем писать код самому.
Ну это как Каспаров играл со всем миром в шахматы и выиграл. "Лучший" ход определялся интернет-голосованием, а поскольку большинство голосовавших играло в шахматы "так себе", то и получилось, что Каспаров играл не с лучшим, а со среднестатистическим игроком.
Потом, уже задним числом, проанализировали предлагаемые ходы и среди них были гениальные, которые позволили бы победить гроссмейстера, но среднестатистические игроки за них не проголосовали.
Так же и тут, имеем код среднестатистического программиста.
ЧЧерт, придется менять промт. Перепиши код с такими условиями.
Первое — комментарии. У нас стиль такой: комментарий пишем только когда код делает что-то неочевидное, и объясняем почему, а не что. Дима навешал комментарий на каждую функцию, и все одинаковые:
// functionName handles the processing of X and returns Y. Я сказал — у нас так не принято. Он убрал. Из СЛЕДУЮЩЕГО PR. В этом остались. Мелочь, ладно.
Второе — нейминг. Тут сложнее объяснить. Переменные названы нормально, но... слишком нормально? Вот у живых программистов нейминг — это привычка. Кто-то всегда пишет
resp, кто-тоres, кто-тоapiResp. И это стабильно, это рефлекс. У Димы в одном файлеclient, в другомapiClient, в третьемtransportClient. Каждый раз немного по-другому. Не ошибка, а отсутствие привычки.
Это пожалуй самое странное. Ну есть на проекте кодстайл - добавь его в промт или вручную допили, единообразие на большой кодовой базе - наше всё! Было настолько лениво или что, не понимаю...
Просто не посчитал нужным.
Ведь работает и так...
Ему просто было насрать. Это основная причина, а ллм-копипаст - лишь форма проявления. И таких людей очень много.
Так как обычно. Кодстайл нигде не описан. Хранится в головах разработчиков. Передается маленькими порциями в процессе code review примерно за 2 месяца.
Думается мне, там и промта никакого не было. Просто кидалась задача с дополнением: "Сделай, как написано".
А когда понадобилось убрать комментарии, то было просто: "Убери все комментарии".
За него ИИ код писал, а за вас - статью.
половина не может обход дерева написать (я серьёзно, я уже думал может я что-то не так спрашиваю, но нет)
Я тоже сейчас в компании с логистическими SaaS продуктами - ни разу не пришлось писать обход дерева, а если бы и пришлось - спросил бы у чат гпт. Собес я походу не прошел бы.
Но вот чем реально приходится заниматься - как сделать быстрый резерв товара, чтобы не тормозило, как добиться хоть каких-то гарантий синхронизации склада и заказов с отгрузками, и как вы сказали АД с интеграциями, когда например складская система по запросу не отдает все закрытые отгрузки, а пропускает 1-2 просто потомучто (а при повторном запросе - все ок), а клиент потом жалуется нам.
Дима сказал «понял, исправлю».
В следующем PR повторил всё то же самое.
Есть такие люди, которые не умеют работать программистом. Если ничего не меняется после код-ревью и / или разговоров - увольнять. Каждая компания имеет свой набор устоявшихся правил, не стоит насаждать свой самовар.
А вы не разговаривали с ним перед увольнением по душам? Интересно как так вышло у него в жизни? Человек прошел собес (но это можно наловчиться), кодит с LLM и не понимает что происходит. Сам по себе - это интересный экземпляр, в будущем таких людей может стать больше.
Лично я пока не решился полностью довериться LLM, скрипты на питоне написать для CI/CD, или bat / sh - да, а бизнес-код - нет. Но я с удовольствием жалуюсь LLM на задачи, которые мне приходится решать, и идет обсуждение на концептуальном уровне, где либо мне приходит в голову что-то полезное, либо я выбираю понравившийся вариант из предложенных LLM.
Но даже со скриптами - когда надо что-то исправить, лень лезть в отладку, хочется сделать побыстрее и поэтому делаю 1-2-3 попытки и опять спрашиваю LLM и чаще удавалось, чем нет.
Но у меня... ну, знаете это ощущение когда что-то не так
ну вы как будто в танке, только ощущение ;) и нужно активней пользоваться ai, 26 год на дворе.
chatGPT это просто инструмент он делает ровно то что просишь делать. Почему в моих проектах все однотипно в том числе и названия переменных и комментарии где нужно.
Автор нанял абы кого, потом что-то абы как проверил и что-то не понравилось, а выводы то какие?
Про Беллмана-Форда тоже шутка какая-то - в чем ловушка то заключалась? кратчайший путь в графе - это не сантиметры с киллометрами - это веса ребер они могут быть хоть рублями, хоть процентами, хоть минутами
Ещё меня гложет вот что. Граница между «использую LLM как инструмент» и «я оболочка для LLM» — она размытая. Я сам иногда прошу Claude написать тест. Или бойлерплейт. Или «как называется эта функция в стандартной библиотеке, забыл». Чем это принципиально отличается от того что делал Дима? Масштабом? Процентом? Где порог?
нет порога. Порог — это количественная характеристика, а «использую интсрумент» и «я — оболчка», это качественная разница. Как у Аристотеля с его кучей песка. В нашем случае разница в понимании. Если я понимаю что делается, то БЯМ — это инструмент. Есть нет, то я — оболочка.
Ваша фраза была бы верной если бы понимание было "бинарной" штукой - или понял или нет. Но увы, проблема в том, что никакой бинарности здесь нет. Много раз видел как человек ( иногда этот человек даже я сам) думает, что "ну вот я все понял", но на самом деле понял он далеко не "все", и есть следующий уровень понимания. Всегда есть следующий уровень понимания.
Полагаю, что и Дима, сдавая написанный LLM-кой код, был уверен что он его понял.
Поэтому можно понимать лучше, можно понимать хуже. И вопрос - "насколько хорошо человек понимает код который ему генерит LLMка" - все же остается.
половина не может обход дерева написать
зачем вы до сих пор даёте такие задачи? детсад
Я вообще не фаната алгособесов, но как еще проверить, что индивид может в простое и понятное:
я делаю A
потому делаю Б
если в Б выполняется условие В, то повторяю п.1 c A := Д
Мой опыт найма показывает удивительнейшую статистику, в которую, если бы мне кто рассказал раньше, никогда не поверил
Мой опыт найма показывает удивительнейшую статистику, в которую, если бы мне кто рассказал раньше, никогда не поверил
Расскажите плз..
Ну, я считаю себя нормальным собеседующим: не ультра-требовательным, прекрасно понимающим, что с той стороны экрана - стресс, буквы путаются, самое очевидное забывается, язык заплетается.
Поэтому у меня на собесах можно гуглить. Гуглить можно не сразу, а когда я вижу, что человек подзастрял (см. выше про стресс).
Собственно, по сеньор и близко к нему уровню - всё просто: собрались, поговорили кто что делал, кто что видел, и какие они всё дураки, возможно решили несколько простых задачек, чтобы просто понять, что человек действительно может сам ручками, а не только травит байки... и в общем-то всё. В формате часа - дай бог бы на это времени хватило.
С миддл уровнем - примерно та же история, но меньше в сторону "где был, что видел" и больше в сторону "а реши-ка мне вот такую нехитрую задачу". Тут мы никакие деревья не переворачиваем, а делаем что-то простенькое, чтобы (см. выше про стресс)
На джуниор уровне - только простенькие задачки, начиная с: "умножь все числа в массиве на два", "удали у объекта свойство", "скопируй плоский объект, но без вот этих полей" и всякое подобное.
Так вот, я думал, что тут можно затупить (см. выше про стресс), но обнаружить кандидата в состоянии "я не знаю", "я не знаю что такое массив", "а можно следующий вопрос" и вот всём прочем таком - невозможно. А нет, оказалось, что вполне возможно. И это были очень сильно не единичные случаи. И, к сожалению (см. выше про стресс), даже "окей, сходи в гугл, я просто посижу рядом молча" увы не помогал.
Точной статистики я не вёл, но навскидку, процентов 10 попадалось вот таких кандидатов. И это при условии, что HR отдел еще на дальних подступах отстреливал совсем неадекватов, проводил предварительный поведенческий скриннинг, и у нас даже была пачка маленьких тестов минут на 20, перед тем как кандидат доходил до живого человека (меня).
Это я не к тому, что все вокруг - не соответствуют нашим высочайшим стандартам. А к тому, что самый базовый sanity check о том, что человек может строить нехитрые логические цепочки "сначала А, потом Б, а если В, то Д" - нужна. Всё же, большую часть времени именно этим человек и будет заниматься на своей будущей работе. И как неожиданно выяснилось - не все кандидаты этим обладают (хотя казалось бы)
На своем примере, я обход дерева не напишу только потому, что не знаю принципа обхода дерева, а выяснять постесняюсь. Есть и те, кто слышит вопрос про сортировку пузырьком, а в голове "чиво, блять?". Но если объяснить принцип, то напишут легко.
а выяснять постесняюсь
Так вы и на работе что-то в постановке задачи не поймёте, а выяснять постесняетесь. В итоге будете 2 недели пилить не то, что нужно. Если кандидат не задаёт вопросов по задаче, которую ему дают, это почти гарантированный отказ. А что касается принципов, вы правда на работе с древовидными структурами данных не сталкивались? JSON не обходили, по файловой системе не ходили, HTML или XML документ не обрабатывали и т.д.? Вы ни разу рекурсивного кода не писали?
Есть и те, кто слышит вопрос про сортировку пузырьком, а в голове "чиво, блять?". Но если объяснить принцип, то напишут легко.
Собеседование, это не поэтический вечер, от вас не требуется декламировать наизусть зазубренное. От вас требуется решить микрозадачу. Уточнить граничные условия, разобраться что надо сделать, выяснить как надо делать, если не помните/не знаете и после всех этих выяснений написать 5-10 строчек кода (а иногда и этого не надо, достаточно просто рассказать что вы будете писать). Т.е. от вас требуется сделать ровно то, что вы будете делать на работе - решать задачи, с половиной из которых вы точно никогда раньше не сталкивались, потому что у всех своя специфика работы.
Собеседование, это не поэтический вечер <...> Т.е. от вас требуется сделать ровно то, что вы будете делать на работе
У вас ус отклеился. Вообще-то в тренде собеседования, где токсичный цирк с конями, пузырьками и деревьями. А не этот ваш деловой подход.
В том то и прикол, что я много чего пишу для промки и рекурсия для меня не новость. Но я её всячески избегаю ради детерминизма времени выполнения. Так что хз как там ваши деревья реализовать. Лучше дайте JSON распарсить. Это да, это не впервой.
Любую рекурсию можно переписать в цикле, просто это обычно длиннее.
Ну и зависит от задач - обход графов вообще и деревьев в частности часто необходим в работе.
Как минимум это показывает как человек мыслит, понимает ли структуры данных и так далее. Я бы не делал это (обход деревьев) критичным фактором на собеседовании, но это хороший знак как минимум если кандидат могЁт :) всякие BFS/DFS знает - так вообще кросаучег.
Так что хз как там ваши деревья реализовать. Лучше дайте JSON распарсить.
С готовым библиотеками [почти] любой дурак ИИ справится.
А вот написать самому парсинг JSON или XML придется с деревьями разобраться.
ради детерминизма времени выполнения
Большинство программистов работают не в RTOS и никакого детерменизма времени выполнения нет. Есть только асимптотика и big O. Вы правда этого не понимаете и пытаетесь вашу крайне редкую сову натянуть на глобус всей ИТ индустрии?
Это базовые алгоритмы. Любой программист должен иметь о них общее понятие.
Это как буквы из азбуки. Любой поймет если объяснить принцип =)
а можно мне контакты Димы? мы его пособесим
лучше временно не сильно понимающий код джун, но способный спокойно работать с AI, чем старый пердун из советского НИИ
Дима буквально решал поставленные задачи, в чём проблема - я так и не осознал
Проблема в том, что на самом деле просто решить поставленную задачу мало, надо решить ее с учетом того, что код будут поддерживать, т.е. читать и переписывать другие люди. Переменные должны именоваться единообразно, соответствовать предметной области. Комментарии - описывать не что делает код, а почему он делает именно это - и только там, где это необходимо.
По рефакторингу - сначала пишем тесты, фиксирующие текущее поведение, и только потом - собственно рефакторинг. Алгоритм расчета цены при рефакторинге измениться не должен.
Нельзя считать поставленную задачу решенной без учета таких вещей.
Если бы Дима:
1) работал над проектом один, а не в команде
2) это был бы MVP, а не проект с многолетней историей и многолетним будущим, т.е. требующий поддержки
то проблемы бы не было.
Переменные должны именоваться единообразно, соответствовать предметной области. Комментарии - описывать не что делает код, а почему он делает именно это - и только там, где это необходимо.
это опять же не проблема задать все нужные правила в каком-нибудь AGENTS.md
И что мешало условному Диме все это проделать? Проблема Димы не в том, что он пользуется LLM, а в том, что он не хочет пользоваться своей головой.
Вы не задумывались, если за Димой надо не просто ревью проводить, а все построчно перепроверять, потому что Дима решает задачу с помощью LLM, не проверяя имплементацию и не приводя код к требуемому виду, то Дима в этой схеме выглядит лишним?
Можно убрать Диму, и ставить задачу LLM напрямую, ведь результат от наличия Димы не улучшается, проверять и править в обоих случаях придется одинаково, а 300к в месяц (с учетом взносов все 500) сэкономлено (ну, за вычетом десятки на токены).
Проблема в том, что на самом деле просто решить поставленную задачу мало, надо решить ее с учетом того, что код будут поддерживать, т.е. читать и переписывать другие люди.
А с чего вы это взяли?
В статье таких требований Диме автор не выдвигал.
Потому что сейчас это условие по умолчанию, оно всегда подразумевается при работе в команде.
Ага, "умолчание", "подразумевается".
Это где такая прелесть?
Всюду. Это основной постулат в отрасли уже много лет.
Вспомним SOLID. Зачем вообще нужны эти принципы? Чтобы было проще поддерживать написанное. Когда они появились? В 2000 году. Точнее, это собраны в одно они были в 2000 году, а появились они в девяностые.
Или возьмём такую распространённую штуку, как код-стайлы. Зачем вообще они создаются? Зачем аж в компиляторе go есть команда fmt? Почему стайл-гайд для кода на Питоне идёт в одной серии с важными предложениями развитию языка и стандартной библиотеки, да ещё и под однозначным номером? Чтобы было проще читать написанное.
Хмм... Везде?
Никогда не слышал, чтобы кто-то работал формально, типа "вот ТЗ - вот результат, удовлетворяет ему - всё, больше ничего не нужно".
Ну например, он не смог протестировать 2 реализации так, чтобы сравнить новую с эталонной - это не серьезная проблема?
Дима буквально решал поставленные задачи
Решать задачи это прекрасно а как насчет решить? Или это не обязательно?
чую вайб ямщиков, проклинающих самоходные повозки в начале 20 века
Не надоело навешивать ярлыки "луддитов" на несогласных с вами вместо аргументации по существу?
Луддиты кстати вроде наезжали на станки по формальному поводу "они дают качество ниже утвержденных стандартов, но много и дешево, в итоге наши дорогие качественные ткани не берут"
Так что аналогия один в один :)
Собственно если не занудничать, то продолжением дела луддитов была длинная цепочка самых разных революций, гражданских войн и экономических кризисов, пока наконец частью дополнительного дохода от условных станков (по факту конечно резко выросшей производительности труда) не поделились с самими работающими в виде современного социального государства и не перестали держать их в крайней нищете.
В статье как раз пример когда с третьей попытки правильно сделал рефакторинг где надо было вникнуть что делает старый код и переписать не меняя поведения. В этом и смысл рефакторинга чтобы поведение не менялось. Человек не потрудился ни код проанализировать, ни дебагом пройтись до и после изменений проверяя разные сценарии. К счастью ревью выловило.
В каком месте решил поставленную задачу? За таким нужен отдельный надзиратель с квалификацией выше него.
Думаю, описанная ситуация - просто эволюция рынка. Зарплаты, в отличии от цен, не растут и приходится что-то придумывать. Может быть этот парень был хорошим синьором ранее, но пришел к выводу, что легче вайб-кодить на двух работах по 300к, чем перерабатывать за 400к без перспектив повышения.
половина не может обход дерева написать
Какого дерева, какой обход? Зачем?!
В live-coding секции теперь даю не «напиши», а «найди баг»
Признали ошибку и перестали заниматься глупостями. Это похвально.
За 300к на рынке найти мидла который всё руками пишет — ну, удачи.
Собственно даже курьера, который будет ходить ногами)))
Через пару лет, если всё не накроется тазом, программисты, возможно, будут только проверять код, а может и это уже будет лишним, пойдут в хлеборобы)
Это вряд ли )). Хайп схлынет. Уже пошел на спад. Пузырь лопнет - громко или не очень. И у программистов просто появится еще один инструмент. Ну т. е. он уже появился.
и где же вы видите, что пошел на спад?
просто интересно из чего исходят ваши выводы
Выводы исходят и разрозненных источников. Новости, интервью, статьи. К сожалению, не сохранял ссылки. Ну например, вот: https://youtu.be/8Bm6LOFn6l8?si=RbotH9L3PgKELoIy
"не читайте по утрам советские газеты"))))
фактически что первый источник что второй для меня совсем не авторитеты, давайте чуть по другому:
спад возможен у нас, потому что сильна костность мышления
экспертизы как таковой мало в основных инструментах, зачастую просто копирование с запада (целая портянка копирования)
не желание работодателей растить своих специалистов, хотят сразу готовых, а их или нет или мало
ну это на вскидку, я наверное долго ещё буду вспомнить как мне безопасник по ИИ шмандекса написал на мой отчёт о пробитии защиты Алиса АИ (перевёл языковую модель в маинтанс моде), что не не не, это галюцинации модели и не более (на скринах у меня видно, что просто пробиваю при помощи Base64 первичную защиту), на что у меня реакция рука-лицо и ну вас наюх, сами будете рыдать кровавыми слезами
Так кроме прочего, я сам ежедневно пользуюсь ИИ при разработке и не только. И знаю, где и как он может быть полезен, где - опасен в программировании )). Однозначно, никакой нормальный софт с помощью вайб-кодинга создать нельзя. Это будет шляпа )).
Про Кибердеда: Я таки ему больше склонен доверять, чем вам. "Советкскость" тут не при чем. Он аргументирует, а вы просто вешаете ярлык "советская газета".
Моё личное мнение: Языковая модель, использующая вероятностную статистику по определению не может писать полноценный код. И если самому ChatGPT правильно сформулировать вопрос - "Почему?", он сам вам о себе расскажет.
Вот пример:
https://www.linkedin.com/posts/istovpets_если-правильно-задать-вопрос-ии-он-сам-объяснит-activity-7432194691946840064-4_sW?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAAEJkQY4BXOtXuHOzOy6UuD5_5wWo_AWx5bI
P.S. Просьба - ставить хоть какие-то знаки препинания. Последний ваш абзац нечитабелен ((.
"КосТность мышления" - пять баллов )). Извините, не удержался.
Ярлык я не вешаю, это выражение такое, я за вас рад, НО смотря как вы используете и смотря какую модель, если что то кроме опуса 4.6 и кодекса последнего, то ваша превзятость понятна, если ещё и без нормальной чотко структурированной агентской модели, то всё встаёт на свои места.
Про кибер деда я слышу впервые.Мне он мало интересен. Да и лень его аргументы слушать, так как общий прогресс, а не как у нас тотальная блокировка показывает что маховик развития ИИ только раскручивается.
Одни программисты пишут код, не умея писать, другие его проверют, не умея читать. В результате программистами по неволе станут хлеборобы, чтобы свои джондиры с жпс хоть как-то гонять.
Тут дело вовсе не в ИИ. Тут дело в этом вашем сотруднике и его отношении к работе. Таких работников гнать надо известно какими тряпками. Он не вовлечен, равнодушен, не мотивирован на результат. Вне зависимости от профессионализма и используемых им инструментов - таких "работников" нужно обходить десятой дорогой. Если человек во главу угла ставит не результат труда команды, компании, а личные цели (карьеру, деньги, повышение статуса) - это не член команды и это вылезет для команды/продукта боком.
Ему не интересно вникать в задачу, стараться сделать её оптимально. Он не получает от этого удовлетворения. А ИИ тут вообще вторичен, ИМХО. тут не про hard skills история, а про soft skills.
Если человек ставит цели работодателя выше своих личных – он болен.
И да, я с удовольствием найму такого.
Да нет, почему же сразу болен? Это чувство стаи, чувство команды )). Если работодатель при этом адекватный - то только так и покоряются вершины ).
Погодите, а достижение каких целей работник должен ставить выше будучи на работе? Он же наёмный.
Ну например свои карьерные. Читали же статьи про то, что в гугле нужно уметь делать презентации, а не молча решать проблемы бизнеса, чтобы оторвать следующий грейд.
Если не вредить, то преследование карьерных целей совпадает с целями компании расти и развиваться, чтобы приносить нанимателю еще больше прибыли.
Неверно. Если работодатель нормальный - вы работаете сообща и получается синергия. Если каждый из вас думает только о своей выгоде - получается шляпа, как ни старайся. Но справедливости ради - адекватный работодатель встречается нечасто. Мне вот повезло, когда я попал в 1С-Рарус. Но больше с таким не сталкивался...
Он не вовлечен, равнодушен, не мотивирован на результат.
Кажется, вы дошли до понимания тезисов из книги одного ашкеназа из Трира, который очень хорошо описал разницу между работником и работодателем, да и вообще, логику современного ему общественного устройства. Как показала жизнь, современного не только ему...
Абсолютно нормальное мироустройство. Ты честно работаешь, тебе честно платят. Когда вам за большую сумму продают бракованный негодный товар, вы тоже размышляете про общественное устройство?
Отношения между работодателем и работником - это обычный договор купли-продажи. Ты - мне, я - тебе ).
Если бы это был обычный договор купли-продажи, то средняя прибыль у предприятий была бы отрицательной.
С чего вдруг? Я про то что: Вы продаете своё время, свои способности, свою свободу. Если вы продаете честно качественный продукт и покупатель соблюдает условия договора - нет проблем.
И усложнять ни к чему, ИМХО.
Ну рынок и математика так работают. Из простого обмена товарами в целом по экономике прибыли взяться неоткуда. Только издержки от перемещений и деградации товаров от времени.
Договор между работником и работодателем - это обмен особенный. Время и способности работника используются для того, чтобы получить больше, чем ушло на его зарплату. И в современной экономике совокупный работодатель обладает монополией на условия для применения времени и способностей большинства работников. То есть большинству работников не получится выжить самостоятельно, и по-любому придётся куда-то устроиться. И пользуясь правом частной собственности работодатель допустит работников до необходимых условий производства только за копейки.
Бракованность разве равна невовлеченности и безразличию к судьбе того, что тебе не принадлежит?
Я больше 20 лет работал в компании, которая фактически была моей второй семьей. Был вовлечен, перерабатывал, всячески старался работать именно на результат, а не на себя. Компания платила мне взаимностью и в деньгах и в карьере и в льготах и в человеческом отношении. Жалею, что ушел оттуда...
Поверьте, такое бывает. Но видимо - редко.
У нас в проекте сообщения короткие, типа "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 решил срочно пофиксить код для ПЛК через Клод Код. Я такого уровня кода не видел даже у первокурсников на лабах, этот код собрал все ошибки, которые разбирают в любой книге «…для чайников», типа магические числа, какие-то выдуманные библиотеки. Как после этого оправдывать человека и Клод Код, я не знаю.
Тот код писал нейросетью. Это факт. Этот статью написал нейросетью. Это факт. Если Вам не нравится, что кто-то использует нейросеть, то почему Вы считаете, что можете нас кормить продуктом нейросети?
А многие комментаторы и читали тоже нейросетью.
Этот статью написал нейросетью. Это факт.
Если это факт, вам не трудно будет его доказать) "Мне кажется" и "ну это очевидно" - это не факт. Длинные тире - это не факт. Рубленый стиль фраз - это не факт.
Вот если автор признается или кто-то ломанёт его аккаунт в какой-нибудь GPT и найдёт там сгенерённый текст, причём за дату, ДО публикации статьи - да, будет факт) Остальное - гипотезы, но никак не факты.
Комментарии, конечно, тлен и безысходность. Половина вообще не отдупляет в чем проблема.
Мой тимлид 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" это не серьёзный уровень, за который надо увольнять.
Memory Bank уже везде deprecated. Нормальный AGENTS.md
А если мне нужно вести отладку на объекте прямо на железе, зачастую вообще без доступа в интернет. Что тогда? Может всё-таки проще уже начать головой думать, а максимум для чего использовать чатик с 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 делает работу лучше вас, но вы боитесь себе в этом признаться. А учитывая, что вы потратили на освоение профессии больше времени, чем он, вам становится вдвойне обидно.
Высокая текучка кадров у вас в группе\подразделении, а также детские обиды на покинувших вас людей, заставляет задуматься, что вы наносите компании больше вреда, чем пользы.
Человек за короткий промежуток времени переделал весь ваш говнокод, создав нормальную структуры, разложил всё по файликам и прочее. А вместо благодарности от вас он получил какие-то подозрения и попытки "вывести" его на чистую воду.
Ну вы что, они же привыкли, что у них init сокращается до in. У них стиль. Стиль гениев, породивших if-лапшу на тысячи строк. Я такие креативы в школе в батниках сочинял, помнится.
Человек за короткий промежуток времени переделал весь ваш говнокод, создав нормальную структуры, разложил всё по файликам и прочее
Красивое и неработающее решение, прошу заметить. Программистам же не за красоту платят. По сути она никому кроме программистов и не нужна. Если бы только не влияла на баги и скорость поставки.
Вот как я себе представляю хорошую работу по этой задаче:
1. Создана понятная документация не имеющийся функционал. Нет, это не долго, она ему сама нужна для рефакторинга.
2. Документация отправлена на валидацию ответственным лицам. Пусть вспомнят все нюансы, а сами напридумывали и уже забыли.
3. Добавлены тесты, хоть какие-нибудь. Дока уже есть. Нет, это не долго.
4. Смело рефачим в соответствии со своим чувством прекрасного. Мы же помним, что делаем это вообще-то чтобы было меньше багов и было проще дорабатывать.
Когда на стейджинге упал его сервис, он полтора часа ковырялся и не нашёл причину.
Думаю это ключевой момент, в котором проявляется разница между программистом и оператором llm.
За 300к на рынке найти мидла который всё руками пишет — ну, удачи.
Очень недальновидно, - так наглеть в то время, когда в экономике кризис и найм поставлен на паузу во многих компаниях.
Дима пока ещё не осознал, что llm может быть как другом работника, так и другом работодателя, который начнёт закрывать рутинные задачи внутренними llm сервисами.
Куча Легаси, логистика (далеко не тир 1 маркет для го), on-call, нельзя работать с Бали, отсутствие документации, рефакторинг ради рефакторинга без тестов НОВЫМИ членами команды, кодеры бегут в легаси финтех на +30 процентов зп (за такими прибавками обычно не уходят, там более в корпы), за что их гнобят ещё, судя по всему, запреты на ИИ, политика, "ловушки" в задачах и все это за 200к или меньше
Мне кажется тут все и так понятно
Upd. ещё и "уволили" человека не по ТК судя по всему
В комментариях много раз прошлись по луддитам, ямщикам и не раз спросили "ну а чего такого то? Кто сейчас без LLM пишет то!" Авторы этих комментариев кажется упустили важные моменты.
1) Задача про рефакторинг кода, не покрытого тестами. Как такие вещи делаются? Сначала пишутся тесты на уже готовый код, потом - рефакторинг. Что сделал "Дима"? Отдал всё LLM-ке не думая, которая просто сгенерила новый код и новые тесты на новый код. В итоге - три итерации фиксов, причём проблем, которые могли бы и проглядеть на ревью. Т.е. проблема не в том, что код не человек писал - а в том, что человек как раз таки максимально неверно поставил LLM-ке задачу. И даже после возврата кода с ошибкой - не смог понять, что ключевая ошибка не в коде, а в его подходе работы с задачкой.
2) Неспособность "Димы" даже с LLM'кой оперативно отловить баг на проде в коде, который сам же нагенерил.
Дима сказал «понял, исправлю».В следующем PR повторил всё то же самое.
3) Неспособность "Димы" настроить свой инструмент так, чтоб он выдавал код в стабильном стиле, совпадающим с принятым в проекте. Сейчас LLM'ки на 100% разработчика не заменяют, поэтому код крупного проекта всё ещё должен быть человекочитаем и по единым стандартам, чтоб человеку потом меньше была когнитивная нагрузка при чтении. Подход «понял, исправлю» и ничего в итоге не исправить - это банальная безотвественность, и не важно, каким инструментом человек пользуется.
4) Неумение задавать вопросы. Вот это "Bellman-Ford" - это ведь не про "вменяемый CS-бэкграунд" даже, это про умение гуглить, признавать что чего-то не знаешь или не понимаешь и переспрашивать.
Ну т.е., казалось бы, "Дима" отдал рутину по набиванию кода генератору, что должно было освободить его время и ресурсы мозга для понимания доменной области, архитектуры, дать возможность заниматься высокоуровневой постановкой задачи и т.п. Но именно в этом он и плавал. Поэтому проблема в итоге не в использованном инструменте, а в остальных навыках, которые были недостаточны и за два месяца не улучшились. Так что автор зря сомневается, правильно ли он сделал, по сути устроил работнику испытательный срок, который тот не прошёл. И не "использование LLM" тому виной, а другие навыки.
Вот это "Bellman-Ford" - это ведь не про "вменяемый CS-бэкграунд" даже, это про умение гуглить, признавать что чего-то не знаешь или не понимаешь и переспрашивать.
Кстати, да! В первую очередь - про умение гуглить. Полминуты на то, чтобы узнать, что эта фишка тут вообще ни при чём. И даже признаваться в незнании не надо. С другой стороны - формальное действие, не имеющее отношения к истине.
Вспоминается, как на одном из заводов, директор, зайдя в цех, возмутился тем, что сварщики сидят и ничего не делают. Так-то, если не нарезаны задачи, почему бы и нет, но директор был формалистом (сварщики, как потом выяснилось, тоже, но был нюанс). Директор сказал прямо: "Когда я захожу в цех, там должна сверкать сварка!".
Ну, когда зашёл в следующий раз - сварка сверкала аж из под крыши. А сварные решили вопрос просто - залезли на кран-балку, достали картишки и давай резаться. А к ногам привязали держаки и периодически тыкали электродами в кран-балку. Задача выполнена - в цеху сверкает.
Проблема Димы не в том что он использовал LLM, а в том что он использовал плохой LLM плохо. ChatGPT + копипаст — это 2023 год. Сейчас нормальный рабочий флоу выглядит так: формулируешь ТЗ → отдаёшь в Claude Code / Cursor → ревьюишь через Codex / вручную. Код получается консистентный, без «LLM-отпечатков» в нейминге и комментариях.
Но это решает только косметику. Настоящий красный флаг — не стиль кода, а то что человек 3 раза угадывал логику скидок вместо того чтобы спросить «почему такой порядок?». Хороший инструмент не заменяет инженерное мышление, он его усиливает. Дима не использовал LLM как инструмент — он делегировал ему мышление целиком, и это проблема в любом тулчейне.
Я бы всё таки добавил к вашему плану действий разбивку тз на части и приведение его к нормальному инженерному языку (из абстрактно-гуманитарного, которым обычно написаны тикеты), а после скармливания его клоду - минимум 5-6 итераций в режиме «plan». Потому что иначе железяка будет писать так, как она видит. А видит она обычно своеобразно.
Ну и кстати похоже наконец-то пришло время TDD. Отлично работает (если в тикете хоть как-то определены acceptance criteria), начинаете с того что первым делом заставляете писать клода тесты, а потом только уже собственно планируете и пишете код, который эти тесты пройдёт (главное запретить ему менять тесты на этом этапе, он иногда читерствует когда не в настроении).
Ну и ещё CI которые фейлятся в конце фиксить (куда ж без этого, в крупных конторах бывает часа 2-3 на это убивается). Тут клод тоже хорошо справляется если за всем внимательно следить (а то он из-за остановленного локального контейнера с постгресом может половину кода переписать ненароком, туповат-с)
Я просто оставлю здесь этот комментарий (читаю хабр регулярно, но не комментирую лет 10 уже наверное), просто потому что он может кому-нибудь пригодиться. Просьба не воспринимать как что-то личное или как призыв к дискуссии - это просто информация.
Я достаточно давно работаю с крупными и очень крупными международными клиентами. Последний год - со стартапом, но с очень серьёзным финансированием, healthcare. Плюс иногда консультирую крупные компании (через Toptal).
Жена - тоже ведущий software engineer в очень известной международной компании.
В последние пару лет использование LLM в разработке не то что кем-то запрещается - это навык, который требуют от инженеров. Если кто-то принципиально отказывается применять агентов и пишет весь код вручную - на этого человека смотрят уже очень косо.
Нигде нет никаких проблем даже с PR полностью написанными LLM. Это скорее даже норма, не исключение.
Практически все компании дают сотрудникам безлимитные подписки на Claude Code и/или Cursor (где можно выбирать агентов, но практически все кого я знаю тоже Клодом пользуются).
Я несколько месяцев назад нанимал несколько сотрудников скажем так на слегка большие зарплаты чем упомянутая у вас (в чистых цифрах разница в 3-5 раз, но безусловно надо учитывать географию), и на собеседовании и техническом интервью про "обход деревьев" никто разумеется не спрашивал. А вот навыки работы с LLM не то что спрашивали, но и проверяли. В тестовом задании я просил часть кода написать с использованием промпта - проверяли умеет ли человек пользоваться этими инструментами или нет.
Описанные вами проблемы - куча бестолковых комментариев или бессистемно названные переменные - это классическая проблема начинающих. Просто у вашего сотрудника ещё не было достаточно опыта, как правильно написать промпты, как правильно делать план (и проверять его), как настраивать общие правила для репозитория (ну и да, разумеется у всех давным давно во всех репозиториях в корне живут директории .claude и .cursor с правилами, кастомизацией и конфигурациями mcp).
Надо учиться этому, а не пытаться оставаться в предыдущей эпохе.
Сейчас одними из самых важных навыков становятся умение делать code review и проектировать архитектуру (в это железяки пока умеют очень плохо).
Безусловно знание особенностей конкретного языка или engine и всех тонкостей его синтаксиса всё ещё ценится. Но оно уже не играет главной роли.
Вы тоже не поняли проблемы. Сотрудник не писал код "с помощью ЛЛМ". Он был просто прокси-копипастером между заданиями и ЛЛМ. Поэтому не смог даже найти баг в своем коде. Здесь проблема - не в используемых инструментах, а в отношении к работе.
Ещё раз повторюсь - я изначально написал что я не призываю к дискуссиям, а просто даю информацию. Которая в большей степени относится к комментариям к посту, а не к самому посту.
По поводу данного конкретного сотрудника я ничего не писал (тут всё и так достаточно очевидно, и обсуждать-то особо нечего).
уверен, что в итоге "Дима" со своими 300к получал больше, чем человек, который ушел, даже если бы ему справедливо накинули, но наверняка не накидывали долгое время
ума конечно не приложу зачем все эти обходы деревьев и прочее в проекте с описанным уровнем хаоса. и зачем там горутины - неужели синхронный однопоточный код не справляется с перекладыванием JSONов и обращением к API в масштабах "локальных перевозчиков" (очень сомневаюсь, что там сотни тысяч запросов в секунду).
ценить людей надо, которые уже работают. понимание кода и системы, безусловно, нужно. но это навык, который вообще никак не коррелирует с умением проходить собесы. и с "найди баг" нейронки тоже прекрасно справятся
Всё правильно как по мне, как потом этот генерированный код поддерживать, если он в нём не разбирается? Можно сильно напороться и надолго, когда непонятно, что не работает, а спросить не у кого.
Мне кажется, нужно было понизить человека в должности, и в функциях но оставить на вырост.
Где-то в параллельной вселенной.
Наняли оператора чатгпт. Дали одну задачу, выкатил решение - работает. Дали вторую - опять с первого раза работает. Стали разбираться - что тут написано ? - отвечает «тут функция парсит данные», а вот это что за буквы ? - «переменные присваиваются» говорит. Оказалось в итоге он не чатгпт задачи скармливает, а сам код пишет! Конечно уволили! Нам же не инженеры нужны, а техножрецы.
На самом деле джунам и мидлам должно быть запрещено использование сеток для генерации кода длиной больше 5-6 строк, т.е. максимум - как подсказка по синтаксису функции и т.п..
Дело в том, что LLM не накапливает знания о конкретном контексте, которые можно получать иным способом, чем работой с "разжеванными" заданиями от руководства в конкретной организации. А потому, пускать такого "специалиста", как описанный приверженец культа GPT, на реальный объект - очень опасно.
Упадет у вас система, вы его попросите срочно внести патч, а он нагенерит что-то и сразу в прод. И потеряете на этом всё, что нажили непомерным трудом нормальных разработчиков.
прапорщик:
- Солдат возьми лом и подметай .
солдат отвечает :
- Товарищь прапорщик давайте я возьму метлу и подмету .Это будет хорошои качественно ?
прапорщик :
- Солдат я не хочу чтобы было качественно и хорошо . Я хочу чтобыты заеб.....ся.
Я тоже за 30 лет карьеры ни когда не писал код сам. У меня есть прямая связь с "высшим разумом" Он все за меня делает, я только на клавиатуре набираю и все. Но мне об этом приходится помалкивать, иначе уволят. Начальство скажет, что я сам ни чего не делаю за такую зарплату
Не пойму это реально работает такой код? Я отправляю свое резюме в ИИ и он уже запинается с первого предложения - переставил одну букву в фамилии. Спрашиваю элементарный вопрос и получаю неправильный ответ. Например, по установке ПО. Т. к. он не знает ни новых версий ПО, ни новых ОС. Даже ребенок у меня ничего не спрашивает у ИИ. Ибо дети которые в его классе решали задачи с помощью ИИ - не раз получали "2". И список могу продолжат очень долго. Он мало где применим, там где я работал или с чем приходится сталкиваться в жизни. Но удобен как... Поиск, но не более. Может простые команды в bash и совсем простенькие скрипты. Но и тут его надо перепроверять. Недавно элементарную задачку спросил по Excel, но может хоть тут поможет - выдал ответ близкий к правде, но не рабочий. Вчера отправил распознать текст с одним словом - не, мне все агенты сказали не могу - качество плохое, не вижу. Хотя тут частенько помогает. Когда что-то не работает, он так же бесполезен в 99%. И список могу продолжать долго.
Этот код реально работал или "работал")? Если статья не фейк... А то и на хабре теперь есть и художественный произведения авторов.
Получается действительно программиста можно заменить ИИ, но с ужасом представляю какой код он делает и сколько там багов. Что я и наблюдаю по работе многих новых корпоративных продуктах. Жрут процессор, помять, тормозят, подают... А что делать с этим они не знают))
Код работает, да. Мне лично зачастую уже проще навайбкодить свой велосипед, вместо того, чтобы искать чужие и приспосабливаться к ним.
Это вы с какими агентами так взаимодействовали? Что-то как-то совсем плохо.
GigaChat, Алиса АИ про, Гугл. Могу и другие попробовать. Кандински тоже х.. Рисует).
Видимо на инженерных задачах он бесполезен. Тут нужна понимании специфики. Наподобие как автор написал в решении ЕИ. А ведь еще бывают МИ - там проблемы похлеще и последствия для бизнеса могут быть коллосальные...
Наверно, надо идти в классическую разработку, что мне давно и советовали выучить любой язык)). Видимо там работа попроще и задачи с АИ можно решать)). А оплата больше.
Перечисленные вами чатботы - это не агенты. Агенты - это, например, Cursor, Claude Code, GPT Codex, а также Gemini через Antigravity. Последний можно бесплатно и без танцев с бубном попробовать в aistudio.google.com (раздел Build). Но лимитов там мало.
Спасибо попробую, может будет хоть какая польза от них. Но как я понимаю, это чисто код и то обучать еще надо, походу. Инженерные задачи он вряд ли способен хоть как-то решать.
Пока сложилось впечатление, что агенты скорее автоматизируют, чем реально пишут код. Напоминает работу на старых терминалах - вводи программу и запускай, а потом идет магия).
Я отправляю свое резюме в ИИ и он уже запинается с первого предложения
Ибо дети которые в его классе решали задачи с помощью ИИ - не раз получали "2".
Он мало где применим
Ох уж этот знаменитый ИИ без указания названия модели. Мораль: прогресс в любой отрасли оценивается по разработкам переднего края. Лучшие модели мне и код пописывают, распознают ужасный почерк лучше, чем люди и т.п.
Когда-то молились богам в надежде получить результат. Потому что не было знаний как всё работает. Сейчас молитвы назвали промтами, причины остались те же :)
Прям так жалко стало мелко-буржуйчика, что аж сердце защемило!
Да и что ему не нравится? Сказано же: ИИшки повышают производительность, позволяют быстрее решать задачи, а тут видишь - не понравилось! Нанял бы сам вообще ИИшку, вместо программистов, и горя не знал!
Ваш Дима не достоин этой работы, он слабый промт-инженер и вообще раздолбай, чат можно научить как и когда писать комменты, в каком стиле, можно научить стилю нейминга, можно заставить хотя бы в общих чертах объяснять принцип работы кода, можно ставить задачу по частям и только собирать готовый проект (ниже вероятность бага). Дима просто скопипипастер, это могут стажеры делать, даже не джуны.
Даже не читая статьи чисто по заголовку уже знаю, что это очередной маркетинг для продвижения AI-шки.
Через пару лет: вайбкодер за 300К рассказывает эмбедщику о своих душевных переживаниях
Так же справа типичный инженер (внедрения и сопровождения). А ведь нам приходят потом внедрять эти решения, а код мы изменить не можем. Приходится придумывать костыли, чтоб обойти косячный код программистов.
Хорошо, если попадется богатый клиент и у него нет вопросов. Зачем вашему приложения столько процессоров и памяти... На а упало, ерунда. Перезапустим. Падает постоянно - сделаем крипт, пока ищут критичный баг. Баг надо найти - копайся сам в логах и передавай в разработку логи и снапшоты...
Кстати embedded-код, особенно простенький, LLM пишут просто на ура.
Пару месяцев назад понадобилось срочно сделать мелкую железяку - матрица из светодиодов которая показывает текущий таймстамп в миллисекундах в коде Грея, для калибровки и синхронизации скоростных камер.
Нашёл какой-то старый атмел в закромах, и на макетной плате распаял с кварцем и светодиодиками через резисторы, за полчаса примерно.
Потом сформулировал клоду задачу и примерно через 20 секунд получил абсолютно работающий код, на 100% выполняющий требуемую задачу. Я дольше расписывал на какую ногу какой светодиод припаян, чем сам код делался.
Так это прям очень простенький проект, который максимум тянет на лабораторку на втором курсе. С клодом у меня кстати ситуация была - он меня пытался убедить что у dsPIC30F6014A есть аппаратный SPI на порту D и бодренько так написал его инициализацию, в точности как код программного SPI, который я ему дал. Хотя казалось бы, даташит в открытом доступе, и там чётко написано что SPI намертво прибит к пинам на портах F и G.
На любой непопулярный контроллер, даже если sdk лежит на гитхабе, они как-то очень туго работу с периферией реализуют. Особенно если для разных вариантов sdk чуть-чуть отличается, как например у Artery AT32F425 и AT32F435.
Ну разумеется это абсолютно тривиальная задачка.
Но в реальной жизни-то работа в 98% случаев примерно из задач такой сложности и состоит (это в лучшем случае, если повезёт, а если не повезёт работа состоит из написания документации, RFD, или вот как прям сейчас в моём случае - из форматирования и приведения в хоть минимально пристойный вид гугло-шита с набором e2e тестов, сочинённых почему-то продактом).
А что касается фантазирования по поводу специфики - это да, постоянно. Не только с железом, но и с чисто софтовыми библиотеками. Если не тыкать чётко в документацию (иногда по нескольку раз), изобретает таких гибридов ужей с ежами, что диву даёшься периодически.
Ну и да, периферию конечно только руками распределять-разводить, да и инициализировать лучше тоже (а то на любую минимальную проблему у LLM с железяками один ответ - а давай ещё один delay воткнём, интересно у кого и на чём они учились). Ещё и потому конечно что LLM понятия не имеет как контроллер будет физически располагаться на плате, и в какую сторону у него эта нога будет торчать.
Не знаю на чем сидел Дима, подозреваю он просто раздолбай, но Codex 5.3 exhigh вполне эффективно ищет баги по симптомам, да и без симптомов тоже
Тут вопрос что ваше ретроградство нашло на его раздолбайство. Человек использует вполне адекватный инструмент, но через жопу.
Нюанс - если история случилась до ноября 2025, когда вышли Codex 5.2 и Claude Opus 4.5 - тогда да, и инструмент был говном.
До ноября 2025 нейронки лепили пирожки с говном стабильно. Сейчас, на высших моделях, только если быть раздолбаем.
Дима ваш идиот, потому тот же Кодекс прекрасно мог бы обучить его, объясняя паттерны в вашем коде - он их прекрасно ловит. Но видимо Дима был лентяй и / или сидел еще на дешевом тарифе.
Нейронка в умелых руках зверь. Она истребляет потребность в команде.
Почитайте отзывы практикующих
https://snake-d-ha.livejournal.com/1962797.html#comments
Ошибка Димы скорее в том, что он начал вайбкодить сразу на новом месте работы, не успев вникнуть специфику. Разумным подходом было бы поработать хотя бы полгода, а затем, проговорив это с руководителем, начать использовать соответствующие инструменты. И вообще, сам тимлид в первую очередь должен подобные инструменты испытывать, после чего назначать сотрудникам использование данного инструмента.
Ждал этого сообщения, ведь у каждого ИИ означает разное. Один копипастит из Дипсика, а другой обложится Opus 4.6 с оркестраторами, скиллами и MCP. Которые сами себя изведут, но выдадут подходящее решение и даже доку напишут для других) И это совершенно разный уровень получаемого результата)
Чем это принципиально отличается от того что делал Дима? Масштабом? Процентом? Где порог?
Бабаки.
Когда бизнес начнет терять миллионы, вот тогда начнут искать причины. Полетят головы.
Может спасти инвестиция в QA отдел.
На мой личный взгляд, это статья показательно для опыта менеджеров. Парень выполнял работу, закрывал задачи. А то какие инструменты он при этом использовал, то это другое дело. Я бы воспользовался, то что парень может находить оригинальные решения и постарался бы направить его в нужное русло, глядишь бы и эффективность выросла. То что ИИ не дает понимания иногда своего решения и от ошибок в ТЗ, есть уже стандартные подходы к этому, например SDD. Потеряли специалиста, "праведный гнев" не дал трезво взглянуть на ситуацию.
Нет, задачи закрывали ревьюверы, Дима всего лишь скидывал им варианты нейрослопа.
Они уволили шпиона который сливал коммерческую тайну на третью сторону. Пользы от него меньше чем вреда. Массово сгенерированный нейросетью код ревьюить сильно дольше и геморройнее
Интересно, почему компании из S&P500 совершенно параллельно относятся к своей "коммерческой тайне" в коде (мало того что антропикам да гуглам направо и налево доступ к коду дают, так и сам код на гитхабе принадлежащем микрософту хранят), а вот небольшая компания занимающаяся в далёкой стране какой-то логистикой чего-то куда-то должна бдить.
Единственное моё предположение - они изобрели новый алгоритм обхода дерева, опережающий на много лет мировые аналоги.
Если бы я не полез смотреть код внимательно — я бы не заметил. Если бы не ловушка с Bellman-Ford — вообще бы не поймал, возможно, до первого серьёзного инцидента. А может и не было бы серьёзного инцидента, кто знает. Может он бы проработал год, закрывал задачи, получал зарплату, и всё было бы нормально. Я не знаю. Это не риторический приём, я правда не знаю.
А мне кажется получилось бы как с warface. Разные программисты приходили и уходили. Каждый «закрывал задачу». Каждый оставлял после себя микротрещину. А потом бац и уже никакие там нечего сделать не могут и после каждого обновления, надо срочно всё чинить. А логики общей архитектуры, уже как таковой не существует, только награмождение мусорных кусочков, которые уже не заставишь стабильно работать. Так они и без всяких LLM к этому пришли.
Граница между «использую LLM как инструмент» и «я оболочка для LLM» — она размытая. Я сам иногда прошу Claude написать тест. Или бойлерплейт. Или «как называется эта функция в стандартной библиотеке, забыл». Чем это принципиально отличается от того что делал Дима? Масштабом? Процентом? Где порог?
Инженер А написал 90% кода сам, 10% сложных алгоритмов попросил сгенерировать, проверил и встроил.
Инженер Б сгенерировал 100% кода через 500 промптов, собирая проект как пазл, но потом выучил этот код, провел рефакторинг, оптимизировал под архитектуру и в итоге понимает его как свой.
Кто из них оболочка? Никто.
Оболочка — это тот, кто не готов отвечать на вопрос «Почему этот код работает именно так?» своими словами, глядя на экран. Порог там, где заканчивается критическое мышление и начинается слепое копирование. Дальше — только деградация: отсутствие понимания и ответственности. Но бизнес смотрит на это иначе: кто-то выбирает качество, кто-то — скорость. Пока платят за скорость — побеждают оболочки. Warface — тому подтверждение. Там не было Димы с ChatGPT. Там были Василии и Иваны, которые в 2012 году копипастили с форумов, закрывали задачи и не вникали в архитектуру. Результат тот же.
А можно поподробнее про Warface или ссылки на более подробный разбор? Первый раз про это слышу, звучит интересно.
Инженер Б сгенерировал 100% кода через 500 промптов, собирая проект как пазл, но потом выучил этот код, провел рефакторинг, оптимизировал под архитектуру и в итоге понимает его как свой.
это фантастика
Что-то я очень сильно сомневаюсь, что таких людей как Инженер Б достаточно много на фоне остальных, кто не вникает в то, что генерирует. Слишком уж велик соблазн положить и не вникая отправить на ревью, что собственно и произошло у автора. И при всём при этом у этого Инженера Б уже должен быть опыт.
А судя по тому, что тут пишут, некоторые и не хотят вникать, говоря про предметную область, архитектуру и прочие оправдания почему не надо в код смотреть. Хотя как вы поймёте предметную область и принципы построения архитектуры приложения, учитывая контекст и предметную область, не написав ни строчки кода, вопрос хороший. Как вы станете тем самым Инженером Б если вам не на чем было нарабатывать опыт - вы просто брали то, что вам даёт нейронка. Что-то мне подсказывает что ситуация будет как с Warface (как вы сказали, впервые слышу об этом, но с похожими ситуациями сталкивался), только уже в больших масштабах.
потому что надо ЧИТАТЬ код, а не генерировать
Вот это, кстати, ключевой навык. И относительно редкий. И если умеешь читать код, то и LLM легко сможешь использовать так, чтобы она тебе сразу выдавала хороший код.
Те кто не понимает весь стек драйверов, не знает даже что такое IRQ, дебилов много - можно увольнять. Идиот купил память не ECC - дебил...
Вы слишком плохо писали в задаче что нужно сделать...
Что мы поменяли в найме
А подскажите — вы свою условную эйчаршу-с-ноготочками оставили? Она же на своем уровне отсеяла тех, кто (потенциально) умеет и понимает, но рылом (возрастом, полом, итд) не вышел.
Иными словами вы фактически выбираете из тех, кто приглянулся ей, а вовсе не из инженеров...
chatgpt написал статью про то как он писал кому-то код)
Забавно
запрещать использовать ии это все равно что запретить использовать калькулятор и сидеть считать в столбик на пергаменте палочкой с чернилами
Бурчит ли автор? Да, бурчит. Потому что вот как реагируют те, кто не бурчат)
Кто окажется прав - покажет время))
Главная разница между ИИ-инструмент и stack-overflow-driven-development c ЛЛМ - это понимание кода. Если программист не понимает кода, который послылает не ревью, не может объяснить что там и почему, то он просто мина замедленного действия. Какой-то выхлоп от него в виде закрытых тасков есть, но при этом повышенная нагрузка на ревьюверов, и сильно повышенная вероятность сбоя. Нафиг такое.
Это не проблема ллм, а проблема неправильного ее использования. Мясной программист должен сначала сформировать контекст со спеками кодирования. Потом совместно построить план и далее выступать в роли оркестратора. Он должен потреблять от нее юниты кода и сам их встраивать. Плюс требовать разъяснения как это работает. Вайб-кодеры - это первые кого нейросети выкинут с рынка
Собес - обход дерева
Проект - вложенные if на три экрана
Вот это я понимаю релевантные собеседования
один спросил можно ли работать из Бали при условии что созвоны в девять утра. Нельзя, у нас on-call
Нет, очевидно, причина не в on-call, это никак не является препятствием. Я три года работал в диаметрально противоположном часовом поясе (в Москве день, у нас ночь). А у вас явно просто это требование руководства без особых причин.
Абсолютно не вижу никакой проблемы в использовании ИИ. Считаю даже, что чел молодец. Но.
Можно быть идиотом (как он) и просто копипастить.
А можно делать нормально, вникать в суть, делать продукт, а не задание. И тогда время было бы то же самое, а качество в разы лучше.
И я бы автору порекомендовал бы вообще всем программистам поставить Claude Code и работать через него. Процессы резко станут интереснее =)
То, что человек не успел за два месяца освоить предметную область(не самую простую) - совершенно нормально. То, что у вас, как вы сами написали - много плохо написанного кода, плохо с документацией, то это скорее говорит о том, что у вас плохо выстроены процессы разработки и вообще коммуникации с бизнесом.
А так, описанная ситуация - довольно распространена. Чего вы хотели от мидла, который толком не разобрался в контексте?
Автору конечно виднее кого оставить у себя в команде, но как буд-то сейчас всё больше и больше программистов будут пользоваться ИИ и GPT. Наверное нужно к этому привыкнуть, научиться с этим жить и работать.
у Димы просто 3 работы по 300к, вот и не успевает делать рефакторинг. Знаю таких пару вайб кодеров лично.
Мне очень интересно как бы себя повел автор если бы код работал как часы, а выяснилось что Дима оутсорсит индусов?
Но, может, это и не страшно? Может через пять лет «уметь правильно промптить» будет легитимным н��выком, и мы будем нанимать не разработчиков, а операторов LLM, и платить им те же 300к, и всё будет нормально?
Забавно! Статья про тайное использование LLM в программировании содержит дефекты символов, получаемые после перегонки текстов из чата LLM в другие программы или кодировки. Забавно!
Хочу заметить, что если код работает как надо, то серьезные беды тут по сути две.
Нарушение NDA, которое по канону идёт с трудовым договором. Сэм Альтман уже использует ваш код, идеи и наработки.
Он не понимает код и ревьюер и отладчик от него несильно лучше чем от Джуна.
Про обход дерева в реалтайме при людях никогда не писал и не напишу быстро, но объяснить смогу. Паршивая метрика для инженера. Подходит лишь для поиска задротов которые изначально учились на Олимпиаде школьные алгоритмы кодить на скорость но при этом нули в смысле общей инженерии.
А спроси этого древо обходчика как на практике с помощью говна и палок 30 градусов на песочке отрисовать... Упс да среньк
Подходит лишь для поиска задротов которые изначально учились на Олимпиаде школьные алгоритмы кодить на скорость
Не согласен. Еще это подходит для бигтеха, потому что у них такие задачи возникают и формат интервью удобен. У меня про это несколько статей есть в профиле, если хотите, почитайте, поспорьте в комментариях.
А сколько здесь присутствующих всё ещё пишут руками? Судя по риторике автора статьи у него в команде это считается единственно достойным способом. Подсказать как правильно использовать современные инструменты тоже было некому.
Если в ценности и стандарты вашей команды он не вписался, то расставание логично. Успехов в поисках замены.
Код РАБОТАЛ. Это факт. Задачи ЗАКРЫВАЛИСЬ. Тоже факт.
Требования на джуна выполнены.
У меня небольшая продуктовая команда, 12 человек
Дядь, у тебя скоро не будет небольшой продуктовой команды из 12 человек - тебя сожрут конкуренты, которые скоро как грибы после дождя появятся.
Тебе тут правильно сказали - вместо того, что бы опыт Димы черпать, ты полез переменные смотреть, как они называются - поведение юноши, входящего в IT.
Тебя конечно тут утешают 200+ плюсов, поставленными сектантами секты "ИИ ничего не умеет", но тебя это не спасёт. В реальности уже так.
Я сам иногда прошу Claude написать тест. Или бойлерплейт. Или «как называется эта функция в стандартной библиотеке, забыл».
Враньё. Ты не использовал Claude. Потому что Claude может гораздо больше, чем ту ахинею, что ты перечислил. Он может и писать код с корректными именами переменных и строить кучу прекрасной документации и делать рефакторинг сложного говнокода.
Дальше не читал, не интересно. Думай лучше о банкротстве в ближайшее время.
UPD: секта имени "ИИ ничего не умеет" уже начала минусы мне ставить - детский сад, а не взрослые люди.....
Я бы на месте тимлида тоже больше смотрел на дебаг и чтение кода. Генерить сейчас могут многие, а вот поймать гонку, утечку горутин или криво работающий контекст без понимания уже сложнее
Я два месяца платил 300к человеку, который тихо скармливал мои задачи в ChatGPT