Я часто вижу в сети два противоположных мнения о том, что смогут сделать современные большие языковые модели (LLM). Одни уверенно заявляют, что уже в ближайшее время они полностью вытеснят программистов и инженеров‑разработчиков, другие — более скептически, считают, что нейросети лишь ускоряют работу, но никогда не смогут самостоятельно воплотить в жизнь сложный технический продукт.
Мой опыт в работе над реальными проектами, где участвуют механики, электроники и программисты, позволяет мне понять, где именно находятся границы возможностей LLM и почему они не могут стать «заменой» людям в процессе создания сложного устройства.
1. Что такое «супер‑процесс» и почему его сложно автоматизировать
Представьте, что нужно построить электронно‑механическую систему, регулирующую какой‑то технологический процесс. На входе у неё находятся аналоговые датчики давления, термопары, инкрементальные энкодеры; в качестве привода используют шаговые моторы, сервоприводы; а в качестве исполнительных элементов — клапаны, реле, соленоидные катушки.Требования к такому устройству обычно включают: поддержание заданных параметров (давление, температура), быстрый отклик (десятки миллисекунд), надёжность в агрессивной среде, ограниченный бюджет энергии и строгие нормативы электробезопасности.Это не просто набор микросхем и кода. Это система, в которой каждый элемент тесно связан с другими, а её поведение определяется физическими законами, характеристиками компонентов и особенностями самого технологического процесса.2. Кто обычно участвует в разработке
Инженер‑механик (генератор идеи). Он придумывает, как должна работать система, какие силы и движения нужны, какие ограничения у процесса. Часто его знания в электронике и программировании поверхностны.Электронщик‑конструктор. Он подбирает датчики, драйверы, схемы питания, разрабатывает печатную плату. Ему нужны точные параметры, уровни сигналов, ограничения по току и шуму.Программист‑встроенных систем. Он пишет прошивку, реализует алгоритмы регулирования, обеспечивает коммуникацию с внешними системами (SCADA, Modbus и т.п.). Без знания того, как именно устроена электроника, ему трудно понять, какие ограничения накладывают железные компоненты.Эти три роли часто работают разрозненно, и между ними образуется «пробел» в коммуникации. Если механик не знает, как правильно описать требуемый сигнал датчика, он не сможет сформулировать запрос к электронщику. Если электронщик не понимает, какие ограничения накладывает алгоритм регулирования, он может выбрать неподходящий драйвер. И если программист не видит полной схемы, он пишет код, который в реальном устройстве просто не будет работать.3. Что может предложить LLM, и почему этого недостаточно
Я пробовал обращаться к крупным языковым моделям с самыми простыми запросами: «напиши код инициализации ADC в STM32», «схема подключения шагового двигателя к драйверу DRV8825», «пример PID‑регулятора для поддержания давления». Ответы приходили быстро, выглядели аккуратно, часто включали комментарии и даже ссылки на документацию.Но здесь же сразу возникали проблемы, которые нельзя решить только «по‑прямому»:Неполные или неверные параметры компонентов. Модель могла предложить драйвер, который теоретически подходит, но не выдерживает ток, необходимый нашему мотору, или не имеет защиты от перегрузки.Несоответствие сигналов. Я просил схему, где датчик выдаёт 0‑5 В, а в прошивке уже был настроен ADC на диапазон 0‑10 В. Это приводит к неверному масштабированию и ошибкам измерения.Тепловые и электромагнитные ограничения. Никакая нейросеть сейчас не умеет предсказывать, перегреется ли драйвер при длительной работе или возникнет ли на плате помеха от соседних линий питания.Нормативные требования. В нашем проекте необходимо соответствовать ГОСТ 61010‑1, IEC 61800‑5‑1 и другим стандартам. Модель просто не знает, какие именно требования к изоляции, заземлению и маркировке надо выполнить.Таким образом, полученный от LLM материал — это лишь черновик, который без тщательной проверки специалиста может привести к дорогостоящим ошибкам.4. Почему генератор идеи и программист‑интегратор всё равно нужны
Генератор идеи – это человек, который понимает бизнес‑цели, ограничения процесса и умеет задавать правильные вопросы. Он формулирует техническое задание, определяя, какие параметры необходимо контролировать, какие скорости реакции нужны, какой уровень надёжности обязателен. Без этого «идея» остаётся абстрактным набором требований, а LLM не в состоянии сама понять, зачем нужен тот или иной датчик, почему выбран именно шаговый мотор.Программист‑интегратор – это человек, который соединяет всё вместе. Он читает схему, проверяет, что все сигналы совместимы, учитывает ограничения микроконтроллера (частота, память, тайминги), пишет код, который действительно работает в реальном времени, отлаживает прерывания, реализует защиту от сбоев. Даже если LLM выдаёт готовый фрагмент кода, без глубокого понимания аппаратной части программист не сможет гарантировать, что этот код не «упадёт» в реальном устройстве.Таким образом, ни один из этих специалистов не может быть полностью заменён машиной, потому что каждый из них работает в своей сфере знаний, а также в пространстве взаимосвязей, которые пока недоступны нейросети.5. Как реально использовать LLM в таком проекте
Я нашёл несколько практических приёмов, которые позволяют извлечь пользу из LLM, не полагаясь на неё полностью:Сформулировать чёткое техническое задание. Чем более детально описаны входные сигналы, диапазоны, ограничения по питанию, тем точнее будет ответ модели.Разбить задачу на небольшие блоки. Сначала попросить схему питания, потом – схему драйвера, потом – код инициализации, потом – алгоритм регулирования. Маленькие запросы дают более предсказуемый результат.Проверять каждый артефакт. После получения схемы я сравниваю её с даташитами, провожу симуляцию в LTspice, проверяю, не превышает ли ток компонентов их пределы. Код проверяю в IDE, компилирую, запускаю на стенде.Сохранять контекст. Веду журнал запрос‑ответ, чтобы в любой момент можно было вернуться к предыдущей версии и понять, где возникла ошибка.Использовать LLM как генератор «скелета», а не готового продукта. Я прошу модель написать структуру данных и функции чтения для датчиков, а дальше добавляю обработку ошибок, калибровку, проверку границ.Не забывать о лицензиях и ответственности. Часто фрагменты кода, предложенные моделью, могут быть скопированы из открытых репозиториев, а их лицензии несовместимы с нашим проектом.Эти приёмы позволяют ускорить рутинные части работы (например, написать шаблон драйвера), но конечный контроль остаётся за человеком.6. Куда движется технология и что может измениться
В ближайшие годы появятся более продвинутые цифровые двойники, которые смогут моделировать работу полной электромеханической системы в реальном времени. Интегрированные среды разработки с AI‑ассистентами будут проверять, совпадает ли код со схемой, предлагать альтернативные топологии и автоматически проверять соответствие стандартам. Стандартизированные аппаратные платформы (типа Arduino, RISC‑V‑Eval) уменьшат количество вариантов компонентов, делая задачу генерации более предсказуемой.Но пока всё это находится в стадии разработки, а процесс создания сложного продукта требует человеческой интуиции, опыта и ответственности. Нейросети могут стать отличным помощником, но они не способны заменить человека в роли генератора идеи или программиста‑интегратора.7. Итоги LLM — мощный инструмент, который может быстро генерировать черновые схемы, фрагменты кода и техническую документацию.
Они не обладают знанием реального физического контекста: параметров компонентов, ограничений среды, нормативных требований и бизнес‑целей проекта. Без эксперта полученный результат остаётся непроверенным и может привести к дорогостоящим ошибкам. Эффективное использование LLM требует чёткого ТЗ, разбивки задачи и обязательного контроля на каждом этапе разработки. Человек‑инженер остаётся центральным звеном: он формулирует идею, проверяет аппаратную совместимость и пишет надёжный код. Поэтому, пока мы говорим о сложных электромеханических системах, нейросети могут лишь ускорять отдельные части работы, но не заменять тех, кто превращает идею в работающий продукт. Их роль — быть «мостом» между разными специалистами, а не заменой этим специалистам.
PS: Статья была созда мной DemonRYB и отредактрована моей локальной LLM gpt-oss:120b
Автор: я, DemonRYB, работающий над реальными проектами в сфере автоматизации и встраиваемых систем.
Комментарии (38)
Ajex
12.02.2026 20:54Дак тут прямо написано нужен "Генератор идеи". на самом деле, по моему опыту АИ с этим справляется так себе. Т.е. как исполнитель - идеально, оно будет развивать твою идею до последнего вздоха, будет тащить твои догмы из контекста в контекст.
Но она не скажет мол стой, тут у нас развилка.
Ну точнее возможно скажет, но опять-таки по опыту, у меня на 15 версии было 3 ключевых развилки, при чем все в разные стороны. :D
Все 3 раза это были мои ключевые решения. Ни разу нейронка не сказала: - "ей, стой, мы свернули не туда" . Для нее оператор царь и Бог! Сказал надо, значит надо!
Возможно как-то это промптами правится, но мне пока не удалось .
Т.е. по крайней мере по дефолту это не сработает, нужно ее заставить мыслить критически.
ReadIt-Club
12.02.2026 20:54Ключевое слово здесь - «пока»… как долго это пока будет длиться никто не знает. Возможно еще год, может пару месяцев, а возможно и завтра выкатят GPT 7.0 который будет в тысячу раз продвинутее чем 5.2
Главная тенденция очевидна - незаменимых людей скоро не будет…
saag
12.02.2026 20:54AI начнет генерировать идею и попутно галлюцинировать, а реализатор веря во все это воплотит в жизнь левитатор...
ruomserg
12.02.2026 20:54Текущий ИИ (и глядя на снижение скорости развития - и перспективный без радикальных инноваций) - тупо бесполезен при решении инженерных задач (там где вам нужен точный ответ "сколько вешать в граммах").
ИИ прекрасен на стадии поиска идеи решения - за счет большого количества переработанных источников и связей между ними.
ИИ неплох для воспроизведения типовых элементов решения, о которых вы его попросите (и которые много раз в одном и том же виде встречались в обучающих данных)
ИИ хорошо подходит для любой задачи, где нужно преобразовать один текст - в другой.
ИИ совершенно не может закрыть пропасть между абстрактным знанием "есть идея как это решить" и его воплощением в виде конкретной инженерной разработки с выбором элементов, проведением расчетов, и т.д.
Причина банальная - у ИИ нет картины мира. Он мыслит только вероятными продолжениями текстов. С точки зрения практики - он похож на ребенка-трехлетку с карандашом, который калякает на бумажке, и при этом говорит: "вот это - киса, вот у кисы носик, а вот у кисы ушки...". Он воспроизводит правильный текст (так говорил взрослый, когда рисовал картинку кошки), но только у взрослого - на картинке возникает кошка, а у неразумного дитяти - безумное нагромождение кривулек. Так же и ИИ: он вам с удовольствием расскажет как правильно проектировать и рассчитывать схему - и тут же воткнет фильтрующий конденсатор последовательтно нагрузке, или поставит диод не в ту сторону. Для него это - мелкая и несущественная неточность...
IVA48
12.02.2026 20:54Суть в том, что КАК (та или иная) модель ИИ принимает (находит) решение (ответ). Когда человек (конечно если на голову здоровый) думает, то он не оперирует словами, а логически мыслит, сопоставляя факты, делает заключение и принимает решение используя свои знания для конкретной ситуации. Поэтому принципиально важно понимать механизм принятия (нахождения) решения и его логического обоснования моделью ИИ перед тем как её использовать при решении какой-то серьезной прикладной задачи.
sdramare
12.02.2026 20:54То, что вы не умеете пользоваться статистическими инструментами(частным случаем которых является LLM) говорит не об их бессполености, а только об отсутствии нужных у вас навыков и знаний(и вероятно о не желании эти навыки приобретать). Как ваш пример с конденсатором - вместо того, чтобы сделать верифицирующий mcp, вы просто заявляете "ии не детерминирован, а значит не нужен".
softel Автор
12.02.2026 20:54
ruomserg
12.02.2026 20:54Э-э, какой еще "верифицирующий mcp" ?! Установка конденсатора и последовательно, и параллельно другим компонентам - совершенно валидные кейсы (зависят от того, какой эффект вы хотите достигнуть!). Ваш MCP должен запускать симуляцию электрической цепи (что на самом деле отдельная задача - ибо нужно понять, хотите ли вы симуляцию в частотной области, или временной, интересует ли вас установившиеся значения или переходной процесс, и т.д.). Опять же в этом случае LLM должна решить, в каких узлах она хочет видеть значения токов/напряжений, и т.д.
И вообще - когда нам обещали искусственный интеллект, то вообще-то идея была в том, что он будет за человека думать! И мой пост ровно о том, что оно не думает достаточно - для того, чтобы его применять в инженерных науках. Ваша идея использовать недетерминированную систему для постепенного выращивания решения - заслуживает внимания, но объясните - зачем тут LLM ?! Генетические алгоритмы и отжиг известны десятки лет, они в принципе работают, и не требуют строительства новых дата-центров и ядерных электростанций поблизости. Использование же LLM в качестве мутатора решения - выглядит, э-э, несколько экстравагантно!
sdramare
12.02.2026 20:54Ваш MCP должен запускать симуляцию электрической цепи
Не мой, а ваш. Вы не можете как инженер сделать такую программу? Ну так это не проблема нейросетей.
И вообще - когда нам обещали искусственный интеллект, то вообще-то идея была в том, что он будет за человека думать!
Кто вам это обещал? Илон Маск в твиттере или какой-то другой такого уже уровня авторитетный источник?
Ваша идея использовать недетерминированную систему для постепенного выращивания решения - заслуживает внимания, но объясните - зачем тут LLM
При том, что LLM это инструмент, который возволяет решать очень большой класс задач, связаных с генераций решения на основе входного контекста, при этом конечный результат с какой-то вероятностью может быть не верен. Область применения LLM на основе трансформеров на порядок больше и значительно точнее, чем у генетических алгоритмов, линейных регрессий и других вычислительных методов. Спрашивать зачем нужны LLM когда есть генетические алгоритмы это как спросить зачем нужен автомобиль, когда есть лошадь.
Инженерный подход здесь это найти этому новому инструменту в своей работе такое применение, при котором время на верификацию результа будет значительно меньше времени на генерацию и значительно меньше чем время создания результата вручную. Писать MCP(да да, самому), делать на их снове скиллы, на наборе скилов агенты, из агентов пайплайны, декомпозировать задачи в пайплане чтобы их можно было быстро верифицировать, подбирать оптимальные модели под разные виды задач, настраивать трейсинг, аудит, оптимизировать стоимость и т.д. Большая инженерная работа, направленая на увеличение производительности труда и требующая знаний, навыков, времени и сил.
Ваш подход это "я вбил в чат хотелку, он мне выдал фигню в ответ, это ерунда какая-то, разбираться я в этом не хочу, мне пообещали что это будет волшебная палочка, которая за меня работать станет, а я только зарплату получать, меня обманули!".
Dron007
12.02.2026 20:54Он мыслит только вероятными продолжениями текстов.
Вероятность появления токена при генерации это же совсем не то же самое, что вероятность его появления в исходных текстах, иначе это были бы просто малополезные для генерации N-граммы. Где-то кто-то для упрощения назвал нейросети продвинутой т9 и все повторяют. При обучении из частот извлекается уже семантика, признаки и сохраняется в весах. Вероятность следующего токена при генерации строится на основании семантики и контекста, поэтому генерируются тексты, которых никогда не существовало и это не просто механическая склейка виденных фрагментов. Вероятность генерации токена это то, насколько модель считает данное продолжение подходящим, учитывая, в том числе, и извлеченную из текстов семантику.
Другой момент. Вот кодогенерация сильно улучшилась после появления агентских систем. Похожее встроено уже и в ChatGPT, когда основные факты тут же проверяются поиском, генерируется код для анализа изображений или подсчёта символов. Так что мешает применять те же подходы и в инженерных задачах?
ruomserg
12.02.2026 20:54Я не спорю с тем, что LLM прекрасны, когда нужно преобразовать один текст в другой (возможно, со сжатием или разжатием размера, замены эмоций или стиля, и т.д.). Проблема применения этого добра в инженерии емко сформулирована в народной пословице: "Языком п...ть - не мешки ворочать!". LLM пишет прекрасные тексты о том, как правильно делать блок питания. Она даже пишет прекрасный план, как она сейчас его сделает. И даже пишет что сделала. Но ничего общего с реальной схемой результат, к сожалению, не имеет. И даже когда оно пытается нарисовать схему/диаграмму того что оно спроектировало - оно не бъется с ее же собственным текстом. Это прямо один-в-один поведение студента который заглотил в себя учебник электротехники перед экзаменом: терминология усвоена, правильный порядок слов в основном - воспроизводится, но стоит только посадить решать реальную задачу - плывет... :-(
EmCreatore
12.02.2026 20:54Все сложнее и неприятнее. На самом деле никто не знает где AI сильнее или слабее. Известно только одно - нас корпорации реально тормозят в комуникации с AI. Дают маленькое окно контекста, делают задержки, ограничивают трафик, задирают цены и иногда просто отказывают в обслуживании по причине типа большой нагрузки на AI.
А так AI и идеи оригинальные предложит, и самые специфичные проблемы в прошивке решит на самом низком уровне.С электро-механическими системами мне AI запросто решает задачи по выбору и оптимизации электормеханики. Легко расчитывает соленоидные приводы, на шаговых движках, или на BLDC. Проверено практикой - силовой линейный привод на шаговом движке он мне расчитал прям идеально. Практически с фотографии с алика с таблицами режимов! А потом написал драйвер для блока управления с того же алика. Не скажу что сразу без ошибок, на за день легко.
И какой там еще PID? Мне Claude Opus сразу сказал - твоя проблема в шуме и недостаточной скорости обратной связи, и написал мне нелинейный фильтр Калмана на 4! канала, тот самый sensor fusion . Я всегда думал что такие фильтры микроконтроллер не потянет. Нет, Claude Opus написал мне фильтр сразу практически без ошибок! И он сразу заработал на страшенной механике с люфтами и неизвестной нагрузкой! Это ли не чудо?
Ошибка автора статьи в том что он решил что для его процесса нужно три человека. Но люди реально слабое звено при общении с AI, они тормозят в коммуникациях между собой. От этого падает на порядок эффективность AI. Это помимо того что нам дают пользоваться лиш тенью настоящего AI
xaoc80
12.02.2026 20:54Нелинейный фильтр Калмана (EKF, UKF), это примерно 100 строчек кода. Я, наверное, 20 реализаций на гитхабе видел. Вы пишите про люфты и неизвестную механику, что как бы сразу намекает на зашумленую систему. Если Клод помог, это замечательно, мне тоже помогает игогда. Но это пример задачи, давно решенной. Я не знаю деталей вашей системы, но у меня он с линейным фильтром не всегда справляется и часто отвергает использование EKF, когда очевидно, что шум не гауссов. А это, вроде передовая модель и большой контекст там не нужен
EmCreatore
12.02.2026 20:54Прикол в том что фильтр Калмана это не КИХ какой-нибудь , у него нет формулы.
Это конструкция матриц, выливающаяся при раскрытии в совершенно разные наборы формул.
Поэтому говорить про 100 строк это так себе аргумент, подозрительный я бы сказал.
Обычные фильтры Claude Sonnet вообще как орехи щелкает, абсолютно безошибочно (ну несколько я проверял)
Там еще сплайны я генерил и S-кривые для механики. Тоже идеально. Еще и в моих страрых сорсах ошибки с кривыми находил и исправлял.
Так что там у вас с нерешенными задачами? Подкинете?xaoc80
12.02.2026 20:54В смысле, нет формулы? Формула как раз есть, что у линейного, что у не линейного, просто имплементация может быть разная. Я с использованием eigen писал, там всесте с innovation gate примерно 100 строчек и вышло. В обвязке фильтра там чуть больше логики. Что касается нерешеных задач, то сложность в подборе ковариаций и адаптивном подборе их при работе фильтра. Модель каждый раз переписывала все, вносила регрессию, хотя я просил так не делать. А задача, трекинг объекта в 3Д, стейт - координаты и скорости, наблюдения - координаты
EmCreatore
12.02.2026 20:54Нет формулы, посмотрите внимательнее. Есть матрицы.
Матрица - не формула. Или покажите мне эту формулу.
Sensor Fusion - вообще магия, и какие сенсоры в этот fusion включать агенты отлично понимают в отличие от людей.
Я решал руками ту же задачу с 3D и траекторией. И маджвика имплементировал тоже.
И несмотря что тут кто-то что-то выкладывал, Claude решает это лучше.
И идите мне скажите, что задача подбора сенсоров для fusion решена.
IVA48
12.02.2026 20:54Когда "зависните" на AI, то без него не сможете обойтись и постепенно атрофируете свою способность мыслить и принимать решения. Вдобавок этот сервис может в любой момент быть запросто отключен (АУ АУ ... WatsApp, Youtube, где вы). О чем пишете, то сейчас подобных текстов от пропагандистов этого самого AI целое море. Конкретный пример детально со скринами по шагам "в студию", а потом и потолкуем.
softel Автор
12.02.2026 20:54Ну я например локально запускаю ИИ, так что пофиг где что там отключат. Главное чтобы электричество в розетке не отключили, хотя и на это пофиг, у меня есть дизельный генератор.
Dmitriila
12.02.2026 20:542-3 года уже говорят об этом на Западе, в России что то начало до некоторых доходить, молодцы
UserSergeyB
12.02.2026 20:54Если долго кричать, что ИИ не справится, можно однажды заметить, что кричишь из окна пенсионного фонда.
IVA48
12.02.2026 20:54Суть в том, что КАК (та или иная) модель ИИ принимает (находит) решение (ответ). Когда человек (конечно если на голову здоровый) думает, то он не оперирует словами, а логически мыслит, сопоставляя факты, делает заключение и принимает решение используя свои знания для конкретной ситуации. Поэтому принципиально важно понимать механизм принятия (нахождения) решения и его логического обоснования моделью ИИ перед тем как её использовать при решении какой-то серьезной прикладной задачи.
andrbag
12.02.2026 20:54Вот еще интересно на чем gpt-oss:120b локально завелась и как она реально по качеству пишет код для ембед?
softel Автор
12.02.2026 20:54
softel Автор
12.02.2026 20:54Но вообще код лучше пишет qwen3-coder-next:q8_0, но она еще тяжелее gpt_oss:120, хотя параметров обучения поменьше.
error911
12.02.2026 20:54Ну как не заменят? Уже заменяют и есть кейсы больших корпораций. В Spotify в последнее время ни строчки кода программисты не написали. Они только проверяют. Cloud все пишет и правит за них.
softel Автор
12.02.2026 20:54Но проверяют же! А если человек ни строчки кода в своей жизни не написал, то как он может проверить чей бы то нибыло код? Так что получается что человек программист остается, исчезают только тупые кодеры. А современная реальльность позволяет используя LLM намного быстрее стать программистом, перепрыгнув этап кодера. Но это доступно только тому кто реально хочет быть программистом. Я кстати про это пишу сейчас стаейку.
viordash
мне кажется это самоуспокоение :( И вскором времени разработчикам придется стать менеджерами AI.
OKEAHbI4
Кто сечёт фишку, уже стал.
zoshytlogic
Не самоуспокоение. Я разрабатываю среду разработки плк, графическую часть и прочее. Использую ИИ. Хорошо вижу, ии может подсказывать и советовать, еслии ее - ткнуть носом в упор задачи которую ты уже собрал. Иначе - ии только усредняет то чем ее учили. То есть - стандартные задачи/подходы - скажет как надо. И программисты делающие обычные вещи - имеют проблемы. Не стандартные задачи или решения- только если человек ПЕРВЫЙ это увидит, решит, и ткнет нейросеть туда носом. Но, ничего нового предсказательная модель не скажет. У человека асоциативное мыление гораздо шире чем у ИИ
viordash
Насчет того, может ли модель создать что-то принципиально новое это вопрос открытый. Но в том, что AI "в моменте" владеет большей базой информации, алгоритмов и подходов, чем среднестатистический разработчик, у меня сомнений нет.
За последний год активного применения я всё больше убеждаюсь в эффективности инструментов. Вероятно, такой полярный взгляд на пользу ИИ сильно зависит от специфики проекта, используемых моделей и, конечно, качества промптов.
zoshytlogic
База и алгоритмы могут совершенно ничего не решать. Я уже как то упоминал в комментах под ИИ - в своей среде разработки, LD диаграммы, я взял за основу - печатную машинку. ИИ предлагал - графы и прочее. У меня - быстрее, меньше памяти, нет рекурсий. Последовательный алгоритм который хорошо ложится на команды процессору. Можно бесконечно вставлять ветки друг в друга - ничего не ломается. Знает ли ИИ что такое печатная машинка? - знает. Знает что такое LD (язык программирования) лестницы? знает. Связал ли он одно из другим? - нет. А я - да. ИИ не хватит ни времени ни оперативной памяти проводить аналогии между всеми физическими процессами и приборами в мире. А человек - может, и за разумное время. Не знаю можно ли тут ссылки выкладывать, не вижу как в коммент вставлять фото. - вот проект: https://zoshytlogic.github.io/ Пока ИИ будет основан на "предсказании" он не обойдет человека, потому что такой ИИ может проигнорировать хороший но редкий метод, даже если ему такой попадался, в пользу - массовости. Все побежали - в графы, ну и он, ИИ туда побежал.
Jajaba
Большинству придётся стать курьерами и грузчиками, а вот оставшаяся малая часть может и будет менеджерами ии