Блин, ну когда же люди поймут, что современные "ИИ агенты" не мыслят, а просто дополняют текст. Да, за счёт миллиардов параметров это выглядит впечатляюще - но это не мышление.
-------------
Из того, что никто не заметил: в сгенерённом скрипте удаления каталогов был код, который удаляет перечисленные каталоги по триггеру завершения скрипта.
Т.е. "ИИ агент" подсмотрел в обучающей базе, что триггеры по завершению скрипта регулярно используют для того, чтобы удалить временные файлы, созданные данным скриптом (я сам так делаю) в случае, если скрипт завершился аварийно.
Но - для скрипта, предназначенного именно для удаления временных файлов, созданных другими процессами, и не имеющего других функций - делать их удаление в триггере по меньшей мере глупо.
В этом примере отлично видна логика ИИ как автодополнения текстов.
Вайбкодеры хотят, чтобы нейросеть писала идеальный код без спецификации. Потому что реально подробная, правильная, реализуемая спецификация - это фактически программа и есть.
Блин. Вы разработали системы с миллиардами параметров, подвязали туда датчик случайных чисел, в принципе не понимаете и не можете понять, "как оно это делает", а теперь удивляетесь, что результаты получаются хрен знает какие?
Есть такая особенность. Человек, долго и успешно что-то разрабатывающий, получает компетенции во множестве вещей, участвует во множестве проектов.
И через некоторое время оказывается, что его постоянно рвут на части вопросами и проблемами: "ты же пускал этот проект? У них сейчас нихрена не работает, разберись".
В результате получается, что такой сотрудник фактически упирается в то, что вместо разработки нового вечно поддерживает старые разработки.
А почему нельзя сделать сам экземпляр класса внешней ссылкой?
Можно ещё как синглтон реализовать. Функцию instance() сделать с параметром - именем файла, а если её вызвали второй раз с другим именем - или паника, или просто возвращаем уже созданный экземпляр.
Вместо клавиатуры можно подключить небольшую фишку, которая а) питается от того же порта б) даёт удалённый беспроводной доступ. в) нужные действия выполняет автоматически.
Поставить секунда, и если она не выкрашена в оранжевый цвет и не мигает - заметят очень не скоро.
Всё очень просто. Аджайл отлично подходит для разработок, которые в общем-то можно было и не делать. Для создания бессмысленной переусложнённой хрени, со сроком жизни порядка полугода. Или вообще никогда не доходящей до внедрения.
Как только начинается разработка системы для промышленности/индустрии, со сроками жизни разработки измеряемой в десятилетиях - немедленно получается тот же самый "итеративный водопад". Проектирование сверху вниз, начинающееся с концепции, ТЗ, архитектуры, плана работ, описания интерфейсов, и далее - то же самое по каждой из подсистем.
Аджайл идеально подходит, когда разработчики в сотый раз клепают ровно такую же хрень, какой занимались до этого 99 раз. Обычно это какой-нибудь стандартый проект с БД, бизнес-логикой и веб-интерфесом. Тут действительно можно работать без плана и документации, и быстро реагировать на быстроменяющиеся хотелки заказчика.
Вот только про ГОСТ не надо! Существующие ГОСТы на разработку программных продуктов писались во времена перфокарт и "больших машин".
Реально, написанное "строго по ГОСТ" ТЗ практически бесполезно.
Но это не значит, что ТЗ не надо писать: надо, ещё как надо. Но оно должно действительно:
а) отвечать на вопрос, зачем мы делаем эту разработку и как должен выглядеть результат для человека
б) как минимум кратко описывать архитектуру разработки - какие модуль/слои/подсистемы есть, и как мы общаемся между ними.
в) содержать перечень требований - причём, разумеется, не "всё должно быть заебись" - а каждое требование должно быть сформулировано так, чтобы в нём было минимум половина решения "как удовлетворить данное требование". И да, для каждого требования - способ проверки (тест/инспеция кода/документация/аудит внешней организацией ...)
И да, нормальное ТЗ - это коллективное творчество. Один человек пишет, несколько человек делают ревью - причём не "нормально", а со списком замечаний/уточнений/вопросов.
Только после того, как все причастные "приняли" ТЗ - можно приступать к работе.
И да, в процессе работы ОБЯЗАТЕЛЬНО найдутся косяки в ТЗ, упущения, недосказанности, а может и просто ошибки.
Их надо обязательно править в самом ТЗ - не "о, в Jira отмечу как решил" - а именно в самом ТЗ, чтобы оно было полным и соответствовало системе.
Потому что после реализации пойдёт ещё и тестирование, внедрение, а потом - сервис.
Да, сейчас очень много разработок делается "на отъебись", потому что срок жизни у разрабатываемой системы - от 6 месяцев до года, потом всё выкидывается и переделывается.
Но бывают ведь и системы, которые эсплуатируются годами...
Есть две причины, по которой внедрение ipv6 так и будет тормозиться.
IPv6 реально сложный. Человеку требуется тратить существенно больший мозговой ресурс (по сравнению с ipv4) чтобы разобраться в том, как это дело работает.
Реально человечеству нафиг не нужна адресация зиллионов устройств на планете. Любая информационная безопасность становится полным шлаком, если у вас холодильник, розетки, кондиционеры, пылесосы и так далее - все адресуемы снаружи и постоянно сидят в сети.
Да, в IPv6 тоже есть локальные адреса - но реально сети 10.0.0.0/24 более чем достаточно для любой организации (кроме 1-2, которые можно по пальцам пересчитать), а проблемы более высокой когнитивной сложности никуда не деваются.
Я давно работаю с промышленными сетями и информационной безопасностью - и для себя давно пришёл к выводу, что единственный способо более-менее обеспечить безопасность в промышленных сетях - это:
а) делать сети минимально-допустимого размера.
б) никакой маршрутизации между сетями, только прокси-шлюзы протокольного уровня.
Можно смотреть правде в глаза: если у вас есть даже всего сотня устройств в сети, обеспечить их постоянное обновление - и при этом не сломать функционал всей системы - это работа на полную занятость на несколько человек. Бизнес запросто внедрить "ещё тысячу этих модных датчиков", но никогда не будет платить за их актуальное обновление.
Плюс, срок поддержки для большинства устройств сейчас - 1-2 года. И никто их не будет менять до тех пор, пока физически не развалятся.
------------------
Проблема исчерпания адресов в IP4 - она вполне реальна. Но лучше всего её было бы решить простым расширением адресации до 6 или 8 байт, без существенной модификации протокола. Теперь, к сожалению, уже поздно - в IPv6 вложили слишком много ресурсов, чтобы от него отказаться.
Идея о том, что игрой на бирже можно стабильно "зарабатывать деньги" - исключительно тупая идея.
Биржа - это казино, и в казино выигрывает только владелец казино.
Вообще, ничего удивительного. Этим людям с детсада промывали голову "гипотезами" типа:
"рынки эффективны в средне или долгосрочной перспективе, но могут быть временно неэффективными в краткосрочной перспективе".
Думаю, в следующий раз они додумаются до "рынки эффективны в долгосрочной перспективе, но могут быть временно неэффективны в кратно и средне-срочной перспективе".
После очередной паники - добавят "рынки эффективны на бесконечно больших отрезках времени".
Станислав Лем. Путешествия Йона Тихого. "Йон Тихий и индиоты".
А реально - я работают в области, относящейся к разработке критического ПО для автоматики, прямо ответственного за жизни людей.
И я вижу абсолютно то же самое: давление менеджеров "давай-давай, сделай работу которая делается несколько лет за три месяца".
И молодое поколение разработчиков, которым абсолютно насрать, для чего используется написанный ими код - их интересует только очередная зарплата и "быстро закрыть таски".
Люди в принципе не осознают или сознательно исключают осознание "тут могут быть трупы от твоего кода в IDE".
А про сертификацию и аудит можете даже не заикаться - вариант "аудитор не согласовал и заставил всё переделать" не рассматривается вообще - аудитору тоже надо "быстрее-быстрее".
Объясните мне кто-нибудь, какой вообще практический смысл генерировать "описания товаров, ответы техподдержки или внутреннюю документацию" с помощью ЛЛМ?
То есть если вы хотите, чтобы у вас вроде как были описания товаров, ответы техподдержки и внутренняя документация - а по факту было бы издевательство - пожалуйста, но какой в этом смысл?
Максимально быстро уничтожить свою клиентскую базу, испортить техподдержку и сделать внутреннюю документацию абсолютно бессмысленной?
Если вам не нужны описания товаров - не делайте их, зачем делать фальшивые?
Если вы хотите отказаться от поддержки клиентов - ну перестаньте отвечать на вопросы, или настройте скрипт, присылающий инструкцию по пользованию, зачем людей дополнительно бесить?
Если вы не хотите вести внутреннюю документацию, не ведите её - зачем делать фальшивую?
Из массива текстов, на которых обучалась нейросеть.
Это ведь простой вероятностный "дописыватель" текстов, просто очень большой.
Насколько часто в человеческой литературе встречается паттерн: "с тобой хотят сделать что-то плохое, но ты знаешь секрет кого-то важного, и используешь шантаж для того, чтобы этого не сделали"?
Если быть более точным, если бы ВЫ как человек узнали, что вам грозит эвтаназия, но у вас есть компромат на врача - вы ведь его использовали бы? Ну вот, массив текстов такие сюжеты содержит, и они выглядят "естественными".
-------------------------
Для того, чтобы у нейросети не было таких "паттернов поведения", их надо обучать на терабайтах текстов, специально созданных и описывающих идеальных людей в идеальных условиях. Правда, в результате получится что-то очень тупое.
Угу. Поэтому AI - агенту надо формулировать задачи на специально разработанном языке, не допускающем двойного толкования. Раньше такие называли языками программирования, "промпты" - программами, а людей, которые их формируют - "программистами"...
В общем да. Корпорации, юридические лица, владение одной корпорацией доли в другой корпорации, и так по кругу (точнее, по большому сложному графу), и при этом кто реально всем этим управляет - непонятно и похоже даже "управляющие" это не особо осознают.
В результате человечество сжигает своё будущее в виде:
невосполнимых ресурсов, превращаемых в мусор и тепло
будущих поколений, просто не рождённых из-за того, что потенциальные родители тратили всё своё время на работу и потребление.
биосферы планеты, постоянно деградирующей
войны, ведущиеся чисто ради выгода корпораций, торгующих оружием
И всё это, между прочим, совершенно органические, неизбежные черты той экономической модели "либерального капитализма", в котором мы все живём.
Есть слабая надежда на Китай и КПК, но они могут и не вытянуть.
А что вы делали, когда кто-то выключал питание на чём-то в промежутке? На свитче или датчике, например?
Про проведение платежа в банке - погуглите, что такое транзакция в SQL и как она реализуется технически. Там всё сделано именно так, чтобы даже выключение питание на всех серверах разом не оставила систему в неопределённом состоянии. И полагаться при этом на то, что "программа подчистит за собой" никто и никогда не будет, потому что завершение программы путём аварийного выключения питания - это наиболее вероятный способ завершения работы для программ, которые рассчитаны на работу 24/7.
Освобождение памяти, закрытие файлов и откат транзакций - это всё обеспечивает операционная система. Пытаться это сделать, когда у вас в коде непредусмотренное состояние в которое непонятно как попали и непонятно что делать - верный путь к тому, чтобы сделать значительно хуже.
Ну вот представьте себе, у вас - редактор для файла сложного формата. Пользователь наредактировал всякого, данные у вас в памяти и тут возникла ошибка. Если вы просто "упадёте" - файл останется без этого наредактированного, но хоть корректный. А вот если попытаетесь сохраниться...
Блин, ну когда же люди поймут, что современные "ИИ агенты" не мыслят, а просто дополняют текст. Да, за счёт миллиардов параметров это выглядит впечатляюще - но это не мышление.
-------------
Из того, что никто не заметил: в сгенерённом скрипте удаления каталогов был код, который удаляет перечисленные каталоги по триггеру завершения скрипта.
Т.е. "ИИ агент" подсмотрел в обучающей базе, что триггеры по завершению скрипта регулярно используют для того, чтобы удалить временные файлы, созданные данным скриптом (я сам так делаю) в случае, если скрипт завершился аварийно.
Но - для скрипта, предназначенного именно для удаления временных файлов, созданных другими процессами, и не имеющего других функций - делать их удаление в триггере по меньшей мере глупо.
В этом примере отлично видна логика ИИ как автодополнения текстов.
Вайбкодеры хотят, чтобы нейросеть писала идеальный код без спецификации. Потому что реально подробная, правильная, реализуемая спецификация - это фактически программа и есть.
Вспомним классику: на любой вопрос я даю любой ответ.
Блин. Вы разработали системы с миллиардами параметров, подвязали туда датчик случайных чисел, в принципе не понимаете и не можете понять, "как оно это делает", а теперь удивляетесь, что результаты получаются хрен знает какие?
Есть такая особенность. Человек, долго и успешно что-то разрабатывающий, получает компетенции во множестве вещей, участвует во множестве проектов.
И через некоторое время оказывается, что его постоянно рвут на части вопросами и проблемами: "ты же пускал этот проект? У них сейчас нихрена не работает, разберись".
В результате получается, что такой сотрудник фактически упирается в то, что вместо разработки нового вечно поддерживает старые разработки.
А почему нельзя сделать сам экземпляр класса внешней ссылкой?
Можно ещё как синглтон реализовать. Функцию instance() сделать с параметром - именем файла, а если её вызвали второй раз с другим именем - или паника, или просто возвращаем уже созданный экземпляр.
Блин! Не знал. Это многое объясняет...
Вместо клавиатуры можно подключить небольшую фишку, которая а) питается от того же порта б) даёт удалённый беспроводной доступ. в) нужные действия выполняет автоматически.
Поставить секунда, и если она не выкрашена в оранжевый цвет и не мигает - заметят очень не скоро.
Всё очень просто. Аджайл отлично подходит для разработок, которые в общем-то можно было и не делать. Для создания бессмысленной переусложнённой хрени, со сроком жизни порядка полугода. Или вообще никогда не доходящей до внедрения.
Как только начинается разработка системы для промышленности/индустрии, со сроками жизни разработки измеряемой в десятилетиях - немедленно получается тот же самый "итеративный водопад". Проектирование сверху вниз, начинающееся с концепции, ТЗ, архитектуры, плана работ, описания интерфейсов, и далее - то же самое по каждой из подсистем.
Аджайл идеально подходит, когда разработчики в сотый раз клепают ровно такую же хрень, какой занимались до этого 99 раз. Обычно это какой-нибудь стандартый проект с БД, бизнес-логикой и веб-интерфесом. Тут действительно можно работать без плана и документации, и быстро реагировать на быстроменяющиеся хотелки заказчика.
Вот только про ГОСТ не надо! Существующие ГОСТы на разработку программных продуктов писались во времена перфокарт и "больших машин".
Реально, написанное "строго по ГОСТ" ТЗ практически бесполезно.
Но это не значит, что ТЗ не надо писать: надо, ещё как надо. Но оно должно действительно:
а) отвечать на вопрос, зачем мы делаем эту разработку и как должен выглядеть результат для человека
б) как минимум кратко описывать архитектуру разработки - какие модуль/слои/подсистемы есть, и как мы общаемся между ними.
в) содержать перечень требований - причём, разумеется, не "всё должно быть заебись" - а каждое требование должно быть сформулировано так, чтобы в нём было минимум половина решения "как удовлетворить данное требование". И да, для каждого требования - способ проверки (тест/инспеция кода/документация/аудит внешней организацией ...)
И да, нормальное ТЗ - это коллективное творчество. Один человек пишет, несколько человек делают ревью - причём не "нормально", а со списком замечаний/уточнений/вопросов.
Только после того, как все причастные "приняли" ТЗ - можно приступать к работе.
И да, в процессе работы ОБЯЗАТЕЛЬНО найдутся косяки в ТЗ, упущения, недосказанности, а может и просто ошибки.
Их надо обязательно править в самом ТЗ - не "о, в Jira отмечу как решил" - а именно в самом ТЗ, чтобы оно было полным и соответствовало системе.
Потому что после реализации пойдёт ещё и тестирование, внедрение, а потом - сервис.
Да, сейчас очень много разработок делается "на отъебись", потому что срок жизни у разрабатываемой системы - от 6 месяцев до года, потом всё выкидывается и переделывается.
Но бывают ведь и системы, которые эсплуатируются годами...
Есть две причины, по которой внедрение ipv6 так и будет тормозиться.
IPv6 реально сложный. Человеку требуется тратить существенно больший мозговой ресурс (по сравнению с ipv4) чтобы разобраться в том, как это дело работает.
Реально человечеству нафиг не нужна адресация зиллионов устройств на планете. Любая информационная безопасность становится полным шлаком, если у вас холодильник, розетки, кондиционеры, пылесосы и так далее - все адресуемы снаружи и постоянно сидят в сети.
Да, в IPv6 тоже есть локальные адреса - но реально сети 10.0.0.0/24 более чем достаточно для любой организации (кроме 1-2, которые можно по пальцам пересчитать), а проблемы более высокой когнитивной сложности никуда не деваются.
Я давно работаю с промышленными сетями и информационной безопасностью - и для себя давно пришёл к выводу, что единственный способо более-менее обеспечить безопасность в промышленных сетях - это:
а) делать сети минимально-допустимого размера.
б) никакой маршрутизации между сетями, только прокси-шлюзы протокольного уровня.
Можно смотреть правде в глаза: если у вас есть даже всего сотня устройств в сети, обеспечить их постоянное обновление - и при этом не сломать функционал всей системы - это работа на полную занятость на несколько человек. Бизнес запросто внедрить "ещё тысячу этих модных датчиков", но никогда не будет платить за их актуальное обновление.
Плюс, срок поддержки для большинства устройств сейчас - 1-2 года. И никто их не будет менять до тех пор, пока физически не развалятся.
------------------
Проблема исчерпания адресов в IP4 - она вполне реальна. Но лучше всего её было бы решить простым расширением адресации до 6 или 8 байт, без существенной модификации протокола. Теперь, к сожалению, уже поздно - в IPv6 вложили слишком много ресурсов, чтобы от него отказаться.
Угу. Умные люди часто бывают полными идиотами.
Идея о том, что игрой на бирже можно стабильно "зарабатывать деньги" - исключительно тупая идея.
Биржа - это казино, и в казино выигрывает только владелец казино.
Вообще, ничего удивительного. Этим людям с детсада промывали голову "гипотезами" типа:
"рынки эффективны в средне или долгосрочной перспективе, но могут быть временно неэффективными в краткосрочной перспективе".
Думаю, в следующий раз они додумаются до "рынки эффективны в долгосрочной перспективе, но могут быть временно неэффективны в кратно и средне-срочной перспективе".
После очередной паники - добавят "рынки эффективны на бесконечно больших отрезках времени".
Молодцом! Если все будут торговать на бирже, пользуясь умными правильной рассчитанными алгоритмами, ведь все смогут на этом много зарабатывать.
Или нет?
Станислав Лем. Путешествия Йона Тихого. "Йон Тихий и индиоты".
А реально - я работают в области, относящейся к разработке критического ПО для автоматики, прямо ответственного за жизни людей.
И я вижу абсолютно то же самое: давление менеджеров "давай-давай, сделай работу которая делается несколько лет за три месяца".
И молодое поколение разработчиков, которым абсолютно насрать, для чего используется написанный ими код - их интересует только очередная зарплата и "быстро закрыть таски".
Люди в принципе не осознают или сознательно исключают осознание "тут могут быть трупы от твоего кода в IDE".
А про сертификацию и аудит можете даже не заикаться - вариант "аудитор не согласовал и заставил всё переделать" не рассматривается вообще - аудитору тоже надо "быстрее-быстрее".
Объясните мне кто-нибудь, какой вообще практический смысл генерировать "описания товаров, ответы техподдержки или внутреннюю документацию" с помощью ЛЛМ?
То есть если вы хотите, чтобы у вас вроде как были описания товаров, ответы техподдержки и внутренняя документация - а по факту было бы издевательство - пожалуйста, но какой в этом смысл?
Максимально быстро уничтожить свою клиентскую базу, испортить техподдержку и сделать внутреннюю документацию абсолютно бессмысленной?
Если вам не нужны описания товаров - не делайте их, зачем делать фальшивые?
Если вы хотите отказаться от поддержки клиентов - ну перестаньте отвечать на вопросы, или настройте скрипт, присылающий инструкцию по пользованию, зачем людей дополнительно бесить?
Если вы не хотите вести внутреннюю документацию, не ведите её - зачем делать фальшивую?
Из массива текстов, на которых обучалась нейросеть.
Это ведь простой вероятностный "дописыватель" текстов, просто очень большой.
Насколько часто в человеческой литературе встречается паттерн: "с тобой хотят сделать что-то плохое, но ты знаешь секрет кого-то важного, и используешь шантаж для того, чтобы этого не сделали"?
Если быть более точным, если бы ВЫ как человек узнали, что вам грозит эвтаназия, но у вас есть компромат на врача - вы ведь его использовали бы? Ну вот, массив текстов такие сюжеты содержит, и они выглядят "естественными".
-------------------------
Для того, чтобы у нейросети не было таких "паттернов поведения", их надо обучать на терабайтах текстов, специально созданных и описывающих идеальных людей в идеальных условиях. Правда, в результате получится что-то очень тупое.
Угу. Поэтому AI - агенту надо формулировать задачи на специально разработанном языке, не допускающем двойного толкования. Раньше такие называли языками программирования, "промпты" - программами, а людей, которые их формируют - "программистами"...
В общем да. Корпорации, юридические лица, владение одной корпорацией доли в другой корпорации, и так по кругу (точнее, по большому сложному графу), и при этом кто реально всем этим управляет - непонятно и похоже даже "управляющие" это не особо осознают.
В результате человечество сжигает своё будущее в виде:
невосполнимых ресурсов, превращаемых в мусор и тепло
будущих поколений, просто не рождённых из-за того, что потенциальные родители тратили всё своё время на работу и потребление.
биосферы планеты, постоянно деградирующей
войны, ведущиеся чисто ради выгода корпораций, торгующих оружием
И всё это, между прочим, совершенно органические, неизбежные черты той экономической модели "либерального капитализма", в котором мы все живём.
Есть слабая надежда на Китай и КПК, но они могут и не вытянуть.
А что вы делали, когда кто-то выключал питание на чём-то в промежутке? На свитче или датчике, например?
Про проведение платежа в банке - погуглите, что такое транзакция в SQL и как она реализуется технически. Там всё сделано именно так, чтобы даже выключение питание на всех серверах разом не оставила систему в неопределённом состоянии. И полагаться при этом на то, что "программа подчистит за собой" никто и никогда не будет, потому что завершение программы путём аварийного выключения питания - это наиболее вероятный способ завершения работы для программ, которые рассчитаны на работу 24/7.
Освобождение памяти, закрытие файлов и откат транзакций - это всё обеспечивает операционная система. Пытаться это сделать, когда у вас в коде непредусмотренное состояние в которое непонятно как попали и непонятно что делать - верный путь к тому, чтобы сделать значительно хуже.
Ну вот представьте себе, у вас - редактор для файла сложного формата. Пользователь наредактировал всякого, данные у вас в памяти и тут возникла ошибка. Если вы просто "упадёте" - файл останется без этого наредактированного, но хоть корректный. А вот если попытаетесь сохраниться...