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