Спустя 6 лет программист на Rust заметил, что у сарая нет стены

Так в этом и проблема. Если экспертизы нет и что там в коде происходит мы не знаем (тем более БЯМ пишет быстрее, чем мы читаем), то как предполагается разбираться?

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

Ну и дальше в интерактивном режиме. С хорошей моделью это пара часов максимум.

найди где была допущена ошибка, предложи исправления.

А еще намайни биткоинов,закадри телок на вечер, пожарь стейки, и скажи как слетать в другую галактику. Оно тебе кончено расскажет, и намайнит, вот только не будет у тебя ни биткоинов, ни телок, ни другой галактики, потому-что все выданное будет фуфелом. И ты на момент приема нейрослопа не будешь об этом знать. А фуфел будет обязательно, потому что нейронки-это технологии приближенного решения задач. Так было 50 лет назад и сейчас не изменилось ничего. Вот только 50 лет назад это четко декларировалось, и использовалось для решения задач, не требующих абcолютной точности, а сейчас наоборот навяливают это юзать для всего (но ответственность нести будет незадачливый юзер), ибо кто-то решил на этом сильно подзарабаотать

После исправления сделай тесты

Как мы тогда собираемся контролировать результат, если тесты тоже БЯМ пишет? Я понимаю (но это не точно) ещё реализацию такого своеобразного экстремального программирования, мы перестаём понимать код, но мы понимаем что он делает, а чего нет. Тут же реально — «дай говна, дай ложку», что-то чего БЯМ нагенерировала, должно проходить какие-то тесты, которые нагенерировала она же. Где в этой схеме человек, который вообще понимает что за херня происходит?

должно проходить какие-то тесты

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

Где в этой схеме человек, который вообще понимает что за херня происходит?

Там где ставит задачи контролирует результат. Нет, я могу и код почитать, просто уже пол года не надо было. Достаточно запросить чтобы БЯМ сама проанализировала проблему дав в промпт её симптомы. Но у меня правда и не управление реактором, просто интерфейс на PyQt. Там даже если что и отвалится между версиями, то пофиг.

Там где ставит задачи контролирует результат.

Как вы контролируете результат (помимо «компилируется / запускается») если тесты тоже нейронка пишет?

В моем проекте визуально. У меня сейчас морда на PyQt разрабатывается. Ну и тест пишется хоть и нейронкой, но по моему описанию проблемы\задачи. При необходимости, я проверю руками, я всё же программист. Просто просматривать 100500 однообразных тестов не вижу необходимости(пока не столкнусь с проблемой понятное дело).

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

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

Т.е. ии-шечка нихрена не меняет - в конечном итоге отвечает всегда кожаный

Не. Скорее всего, без ИИ он наворотил бы значительно меньше. И проблем было бы меньше.

Не. Скорее всего, без ИИ он наворотил бы значительно меньше. И проблем было бы меньше.

Тут вопрос основной, то что он наворотил, это только проблемы или это всё же было что-то полезное и выполняло работу? Если второе, то при «наворотил значительно меньше», возможно и работы никакой не было бы выполнено полезной\законченной.

Не, ну если так на это смотреть то всяко может быть.

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

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

Последняя новость, которую помню, это какой-то облачный сервис насчитал неожиданно много своим клиентам и программисты «не знают, в чём принина». Вот интересно, они тоже не спеша, попивая кофеёчек это дебажили силами одного промпта в нейронку.

Откатили все начисления и разбираемся, да. Сколько промптов и попивая ли кофеечек, это не так важно.

Когда кожаные косячили с биллингом раньше, так примерно и делали. Либо вообще прикидывались шлангом(мем длительностью в 20 лет «МТС ворует деньги»).

Или вон недавно(летом или весной) сброс лимитов делали у нейронок каких-то, тоже вроде по причине что накосячили.

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

А иначе просто прикрыли бы направление, денег то нет. А так, клиент доволен, ему дали то, что он просил(по функциональности).

Ну вот когда пересажают шлакоделов и денег больше станет у всех.

И что тут хорошего?

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

Ну вот когда пересажают шлакоделов и денег больше станет у всех.

И в итоге в той стране, где пересажают и не пойдут за тенденциями, лет через 10 будет критическое отставание от тех, кто влился. Мы такое уже видели на излете СССР с IT-технологиями.

Был на одном ресурсе чувак лет 10-15 назад, рассказывал что за роями дронов будущее. Над ним смеялись и считали клоуном. Ну и кто теперь клоуном оказался?

Как ты ловко шлакоделство замаскировал за словом «тенденции».

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

Мы такое уже видели на излете СССР с IT-технологиями.

«На излёте СССР» проблемы были вовсе не IT-специфичные, и к тенденциям никакого отношения не имели.

Шлакоделы вредны для общества - они жрут ресурсов больше чем надо, а на выходе дают в лучшем случае низкокачественный товар

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

«На излёте СССР» проблемы были вовсе не IT-специфичные, и к тенденциям никакого отношения не имели.

Я имел ввиду именно уровень развития IT в те годы и сравнение его с уровнем в кап. странах. Даже не IT как таковое, а компьютеризацию имел ввиду.

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

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

Фанаты вайбкодинга чаще других понятия не имеют, что вообще делает их код. К сабжу отношения вроде не имеет, тут 100% человеческий косяк.

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

Ты еще задолбаешься вырезать всевозможные проверки, шифрования.

Никогда не читал старые ишью в виду их бесполезности.

Очень плохо. Это пример того, как вы решаете свои проблемы за счёт времени и средств своих клиентов. Надеюсь вы хотя бы понимаете, за что они вас ненавидят.

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

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

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

А теперь представьте меня с другой стороны баррикады, где я голосом и интонацией Алексея Смирнова говорю «ты у меня третий». И каждому в наследство. И каждый вместо того, чтобы сесть и изучить историю начинает спрашивать одно и тоже от рождения Адама. Потом исчезает на полпути и появляется новый.

История логичная и понятная. Если встать на место человека, который рискует своими деньгами, я бы, может, тоже так поступил. За державу ИТ, однако, обидно. Одно говнище кругом, переусложнённое, тормозное, глючное и дырявое. И я как бы тоже часть этого всего. Стыдно подрастающим поколениям будет рассказывать, чем на жизнь зарабатываю. Придётся врать, пока не подрастут, скажу, тапёром в борделе работал. Потом вырастут, смогут понять, простить …

Шо это за задача такая, которую уже третий программист не может осилить и прямо бежит от такого счастья. Я бы призадумался.

У нас уже давно ходит шутка, в которой огромная доля правды и которая появилась не вчера и не относится к конкретной компании. «В частной компании любая задача всегда поручается наименее компетентному и способному решать эту конкретную задачу сотруднику». Примеры из жизни - задача исправить ошибку на си будет обязательно поручена специалисту по питон. Задача программировать GPU будет отдана спецу по FPGA. Гарантировано. Исключений нет. Как так - загадка!

Примеры из жизни - задача исправить ошибку на си будет обязательно поручена специалисту по питон

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

Впрочем, тех двух счастливчиков начинаю понимать. Что, и ИИшка не помогла?

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

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

Впрочем, тех двух счастливчиков начинаю понимать. Что, и ИИшка не помогла?

Это я не знаю. Мне всё равно, как и кто решает проблему в чужой компании. Проблема на вашей стороне, значит используйте свои силы и возможности и решите ee.

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

Вот это организация работы. Т.е. ни описания ошибки, ни способа её воспроизведения. И код, который НА САМОМ ДЕЛЕ ничего не исправил. И очухались где-то через код. А ты сиди и ковыряйся в экскрементах мамонта. Это победа! Не удивительно, что третий превратился в двацатого. Это всё из-за заботы о клиенте, я знаю. Чтобы фичи быстрее пилились и как можно скорее до клиента доходили. А баги? А баги - не фичи.

Там надо просто взять из jsonа набор правил и по очереди впердолить их в железный коммутатор. И по команде извне обновлять. Ии нагородил какую-то монструозную дрянь на такой простой задаче. И под api микросхемы которую выбрали надо под ноль переписывать.

Ии нагородил какую-то монструозную дрянь

Фабрику фабрик какую-нибудь? :)

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

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

у нас на работе один товарищ нанейрослопил гору говна на расте, и уволился.

Наверное это был первый и единственный способ использования раста на реальной работе

Раст тут каким боком, кроме того что эта херабора написана на нем, как могла была быть написана хоть на питухоне хоть на чем еще

у нас на работе один товарищ нанейрослопил гору говна на расте, и уволился.

Наверное это был первый и единственный способ использования раста на реальной работе

Вот ещё один:

Создатель Ruby on Rails объявил о конце эпохи ручного написания кода

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

А я Вас не понимаю.

Вот ситуация. Я - программист, умею програмирувать, готов починить все баги, запилить любую фичу. И во разговор:

• надо починить баг
• какой?
• у заказчика где-то там-то.
• а подробности можно?
• поищи в истории, где-то год назад. Там эту багу уже правили, но она снова вылезла.

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

Чего же я не понимаю, так это Вашу роль в этом воображаемом примере. Если работодателя, который пытается добиться толку от нерадивого работника, то надо посмотреть в воображаемое зеркало. Если же усталый заказчик, которого уже достали мимолетные программисты, то надо решать вопрос с воображаемыми подрядчиками. Для начала путём увещевания. А там по обстоятельствам.

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

Ситуация следующая. Есть контракт на разработку, поставку, и поддержку крупного аппаратно-программного комплекса. Допустим разработка и поставка закончены, приёмка произведена, теперь фаза поддержки. В процессе эксплуатации появляются «дефекты», которые контрактор должен устранить. Моя организация заполняет репорт на дефект (issue в вашей терминологии) с описанием, воспроизведением, и оценкой важности (impact по вашему). После этого начинается то, что я сверху описал. Сначала год, чтобы объяснить как воспроизвести дефект. Потом год, чтобы объяснить, что делать. Потом год, чтобы протестировать исправление. Потом год, чтобы система безопасности одоборила релиз. Потом год, пока поправка попадёт в релиз. Раз в месяц работники со стороны контрактника исчезают и появляются такие, как вы - читать историю или не умеют или не хотят или религия не позволяет. Как только приходит новый человек, он начинает мотать нервы моей организации по поводу и без повода. Поэтому весь процесс начинается с этапа «ну вот появился репорт на новый дефект, итак, как бы нам его воспроизвести. Оппа, а у нас такого оборудования нееет… а я этого не знааааю … а у нас он больше не рабооооотает …». То есть с нуля. Отсчёт годам пошёл.

Моя не понимать. Если есть репорт с воспроизведением, то все есть. Хотя если изменения три года до прода едут, то удивляться не приходится. Мнения я своего не поменял. Косяк руководителя. Тикет должен быть на контроле до приемки. Не прошло? Возвращение с указанием номера. Этого достаточно. А уж отсутствие оборудования - тем более. Программист-то тут при чем?

Упд. Я не оправдываю программиста, Вы в праве смотреть на подрядчика как единое целое. И претензии должны быть по адресу, т.е. руководству.

Если есть репорт с воспроизведением, то все есть.

Вот вы не поверите! И тоже так думаю.

Косяк руководителя.

Руководителя чего?

Тикет должен быть на контроле до приемки.

Этот как? Дефект был обнаружен в процессе эксплуатации.

А уж отсутствие оборудования - тем более.

Что тем более?

И претензии должны быть по адресу, т.е. руководству.

Руководству чего?

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

Если меня не устраивает время исправления проблемы, я действую по своим внутренним каналам и контрактора на прямую не беспокою. У нас есть способы воздействия.

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

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

Руководству чего?

Вашего подрядчика. Это именно его заботам организовать все так, чтобы все крутилось. И чтобы заказчики был доволен. От вас, как от заказчика ничего больше не требуется: один раз расписали и полно. Ну может один раз созвониться, для уточнения деталей, но не более.

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

Руководству чего?

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

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

Как говорил один герой российского сериала «прогнило всё, Вова!».

Тут я могу только посочувствовать.