Я часто вижу в сети два противоположных мнения о том, что смогут сделать современные большие языковые модели (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, работающий над реальными проектами в сфере автоматизации и встр
Автор: softel
