Архитектор автомоек заменил штат инженеров ИИ: почему это не «вайб-кодинг»
Инженер с 25-летним стажем в промышленной автоматизации и системах реального времени рассказал, как в условиях банкротства компании он в одиночку заменил ушедшую команду разработчиков, используя искусственный интеллект. Для него это не эксперимент с кодом, а возвращение к принципам ручной работы с помощью нового инструмента: ИИ пишет код, но только в строгих рамках архитектуры, которую задает и проверяет человек.
# От ассемблера до ИИ: как один инженер поддерживал две сотни объектов
В 2000 году я писал программное обеспечение на ассемблере для проверки приборов спутникового слежения. Тогда я был уверен, что серьезные инженерные системы создаются только руками. До появления феномена, который теперь называют «вайб-кодингом», оставалось четверть века. Сейчас мне 50 лет. За эти годы я проектировал и программировал корабельные системы управления, комплексы для авионики, теплосчётчики и оборудование для автомоек самообслуживания. Мой путь был привычен: я сам создавал архитектуру, сам писал низкий уровень и прошивки. Но дальше начиналась неизбежная зависимость от коллектива: сервера, веб-интерфейсы, документация требовали отдельных специалистов, которых нужно было искать, нанимать и ждать. Пока сборка не завершена, архитектура существует только на бумаге.
К искусственному интеллекту я относился так же скептически, как и многие мои коллеги. Изначально это виделось мне как игрушка для наведения лендингов или написания стихов. Термин «вайб-кодинг» в моем понимании означал безответственность: человек не понимает сути задачи, а надеется, что модель сделает всё сама. Я не пускал уважаемых мной людей в серьёзные проекты с ИИ, и они не пускали меня.
Однако безвыходная ситуация заставила меня попробовать. В компании, где я отвечал за архитектуру ПО для автомоек, разработчики ушли, но на поддержку осталось более 200 объектов в России, Казахстане и Беларуси. Владельцы моек не заботились об штате производителя, но требовали, чтобы терминалы работали: определялись монетоприёмники, не сбоили платёжные сервисы. Чинить стало некому. Пришлось проходить через ИИ вообще все этапы разработки, включая задачи, которые ранее решала только полноценная команда.
Оказалось, что для промышленной автоматизации ИИ перестал быть игрушкой. Ставишь задачу, описываешь архитектуру, и система генерирует код так, как это сделали бы опытные программисты.
Серьёзная работа вместо покупки бэушки
Лучший пример моего перехода — замена устаревших контроллеров австрийской фирмы B&R в системах автоматизации моек. После ухода вендора купить новое оборудование стало невозможно, а старое начало выходить из строя. Подержанные контроллеры стоили от полумиллиона до трёх с половиной миллионов рублей за единицу.
Мы выбрали альтернативу: заменили «голову» контроллера на обычный мини-ПК, что стоило в десятки раз дешевле. Однако стойки с модулями ввода-вывода работают по протоколу POWERLINK — стандарту жёсткого реального времени с циклом в две миллисекунды. На обычном ПК он не заработает без специального драйвера сетевой карты и программного шлюза.
Открытые стеки под этот протокол забросили разработчики в 2019 году. Современные карты и ядра Linux их не поддерживают. Раньше такая задача требовала поиска редкого специалиста, и работа над ней стоила бы столько же, сколько и покупка нового контроллера.
С помощью ИИ драйвер для Intel I226-V, шлюз и интеграцию проекта были написаны за неделю. После тестирования на реальном стенде с настоящими стойками B&R первый длительный прогон дал почти 300 тысяч циклов обмена без единой ошибки.
Архитектор, а не исполнитель
В этом процессе важно распределение ролей. Код генерировал ИИ, но я определял, что писать, в какой последовательности и как проверять. Стенд с реальным железом также был построен мной, так как реальное время невозможно проверить на словах.
Интересно, что этот подход работает в обе стороны. Мой опыт помогает не пропустить критические ошибки, а ИИ собирает разрозненные элементы в единую систему, с которой мне раньше приходилось столкнуться. Раньше я искал в интернете кусочки кода и недели пытался склеить их в работающее целое. Теперь ИИ сразу выдаёт цельную основу.
Однако главный вопрос: как ИИ не выдаёт результат, который просто выглядит рабочим, но ломает систему? Здесь ключевую роль играет понятие «конус взгляда» инженера. ИИ не знает контекста объекта: где проходят силовые линии, как влияют электромагнитные помехи, какие особенности есть в нестандартном протоколе купюроприёмника, перепрошитого местными разработчиками. Он видит только то, что ему показали.
Поэтому я не ставлю задачу на «промпт-инжиниринг». Я задаю точные критерии, требую, чтобы ИИ описал каждый регистр, последовательность действий и возможные ошибки. Если запрос конкретный, результат конкретный. ИИ исправляет код, но я провожу финальную проверку на живом железе. Я проверяю, не залез ли новый код в память соседних процессов или не нарушил ли балансировку процессорного времени.
ИИ заменяет руки, которых не хватало, но не заменяет мозг архитектора. Без 25 лет опыта в построении систем реального времени я бы не мог ни поставить задачу так, чтобы её нельзя было понять неправильно, ни проверить результат.
Почему это не «гриб» и что дальше
В интернете есть мем про «гриб», где ИИ отвечает на вопрос «да» или «нет», не давая пояснений. В серьёзной разработке это недопустимо. Я научился формулировать вопросы так, чтобы ИИ не мог просто поддакнуть, а вынужден был разбираться в деталях. Мы итеративно доводим код до рабочего состояния, проверяя каждый лог и замер. Ошибки находим оба: я вижу то, что он не учел, он находит то, до чего не докопался я.
Кроме того, ИИ избавил меня от вечного перфекционизма в дизайне интерфейсов. Критерия «готово» там нет, а ИИ предлагает привычные и логичные решения, которые можно быстро адаптировать под мои требования по ровности и симметрии.
Этот опыт научил меня новому: предел того, что можно сделать с ИИ, задаёт человек. Сам инструмент этого предела не знает. ИИ умножает существующие знания и навыки. Если в «конусе взгляда» инженера остаётся мало того, что он может контролировать, смысла в инструменте не будет.
Мне сейчас интереснее работать, чем когда-либо. Жалеть об использовании ИИ некогда, работы много. Я убеждён, что при таком проверочном подходе искусственный интеллект способен заменить любых исполнителей, но самого проверяющего — нет. Это уже не «вайб-кодинг», а новое качество программирования, которого, возможно, ждали с тех пор, как код появился вообще.
В следующей статье я расскажу технические детали реализации драйвера и шлюза для замены контроллеров B&R на мини-ПК, включая работу с ядром реального времени и открытыми стеками.