В 2000 году я писал на ассемблере софт для проверки приборов спутникового слежения и был уверен, что серьёзные системы делаются только руками. До вайб‑кодинга оставалась четверть века.

Сейчас мне 50. С тех пор я почти всё время писал софт для железа: корабельные системы управления, проверочные комплексы для авионики, теплосчётчики, домофоны, последние годы оборудование для автомоек самообслуживания. Архитектуру своих систем я всегда придумывал сам, и низкий уровень, прошивки, тоже писал сам. А вот дальше начиналась зависимость от людей. Сервер, веб‑интерфейс, документация: под каждую такую часть нужен был отдельный человек, которого ещё надо найти и оплатить, а потом сидеть и ждать. Пока всё это не собрано, твоя архитектура существует на бумаге, и сколько ни говори «я архитектор», показать тебе нечего.

К ИИ я относился так же, как большинство знакомых мне инженеров. Игрушка. Лендинг накидать, стишок написать, в лучшем случае скрипт. Слово «вайб‑кодинг» для меня означало примерно это: человек сам не понимает, что делает, и надеется, что модель как‑нибудь сделает за него. Люди, которых я уважаю, в серьёзные проекты ИИ не пускали, ну и я не пускал. Пробовать я стал от безвыходности: в компании не осталось разработчиков, а объектов на поддержке осталось две сотни. Через ИИ пришлось пропустить вообще всю разработку, включая задачи, за которые раньше взялась бы только команда. И тут выяснилось, что это давно уже не игрушка. Ставишь задачу, задаёшь архитектуру, и он делает так, как сделали бы нормальные программисты.

Статей про то, как человек в одиночку с ИИ заменил команду, на Хабре уже хватает. Я их читал, и почти все они про веб, про популярные стеки, где у модели перед глазами миллион примеров. У меня другая область. Ядро реального времени, драйвер сетевой карты, протокол, которым пользуется по сути один вендор, платёжное железо с самодельными прошивками. Примеров по этому в интернете почти нет, а ошибку ты видишь на осциллографе, в логах её может не быть вообще. Про это и расскажу: почему оно у меня заработало и что для этого нужно.

Что случилось с компанией

Компания, в которой я работаю, делает оборудование и софт для автомоек самообслуживания. Я в ней много лет отвечал за архитектуру ПО, а в ежедневной работе в основном поддерживал софт вендинговых терминалов. Потом дела пошли плохо, дошло до банкротства. Производство встало, разработчиков сокращали одного за другим, и в какой‑то момент на всю разработку остался я один.

При этом сами мойки никуда не делись. Их больше двухсот, в России, Казахстане и Беларуси. Они каждый день принимают деньги, у каждой есть владелец, и владельцу совершенно всё равно, сколько человек осталось в штате у производителя. У него завис терминал, или перестал определяться монетоприёмник, или платёжный сервис поменял протокол, и кто‑то должен это починить. Чинить стало некому, кроме меня, причём на всех уровнях сразу, от микроконтроллера до облака.

Как поддержка вытащила бизнес

Первое время я занимался только тем, чтобы система не упала. Но когда система работает, это замечают. Пошли заказы, начался ребрендинг, понадобились новые функции и интеграции. В итоге как раз живой, работающий софт помог привлечь инвестиции и перезапустить компанию под новым брендом, уже под другие задачи и другой масштаб.

Только делать всё это по‑прежнему было некому. С конца 2024 года я работаю в связке с ИИ.

История с контроллерами B&R

Лучше всего это видно на одной задаче из промышленной автоматики. Многие российские производители моек, и мы в том числе, строили автоматику на контроллерах австрийской фирмы B&R. После ухода вендора купить это железо стало нельзя, а стареть оно не перестало. Обычно первым умирает контроллер, а стойки с модулями ввода‑вывода продолжают жить. Подержанный контроллер через серый импорт стоит от полумиллиона до трёх с половиной миллионов рублей. За штуку, и так при каждом отказе.

Мы придумали другой вариант: поменять только «голову». Вместо контроллера ставится обычный мини‑ПК, который в десятки раз дешевле, а родные стойки остаются на месте. Проект автоматизации, его логика и визуализация остаются как были, меняется одна конфигурация. Проблема в том, что стойки разговаривают по POWERLINK. Это протокол жёсткого реального времени с циклом в две миллисекунды, и на обычном ПК он сам по себе не заработает. Нужен драйвер сетевой карты под реальное время и программный шлюз, который опрашивает стойки по POWERLINK и отдаёт данные в том виде, в каком их ждёт проект. Открытый стек под этот протокол существует, но его забросили в 2019 году. Современных сетевых карт он не знает, под новые ядра Linux не собирается.

Вот это инженеры и называют серьёзной работой: ядро реального времени, драйвер, низкоуровневый протокол. Раньше я бы под такую задачу искал редкого специалиста. Нашёл бы или нет, вопрос, а несколько месяцев его работы стоили бы примерно тех же миллионов, что и контроллер. То есть выгоднее было просто докупать бэушные контроллеры, пока они где‑то есть.

С ИИ получилось по‑другому. Драйвер под Intel I226-V, шлюз и разбор проекта заняли меньше недели. Ещё неделю мы гоняли всё это на стенде с настоящими стойками B&R, и первый же длинный прогон дал почти триста тысяч циклов обмена без единого пропуска. Как устроен драйвер и почему старый стек не заводится на новых картах, я подробно разберу во второй статье, она будет чисто техническая. Здесь скажу про распределение ролей. Код писал ИИ. Что писать, в какой последовательности и чем проверять, решал я. И стенд тоже на мне, потому что реальное время на словах не проверишь, нужны живые стойки и приборы.

Интересно, что работает это в обе стороны. Есть места, где мой опыт не даёт пропустить ошибку, про них ниже. А есть обратная ситуация, когда ИИ собирает воедино вещи, которые я по отдельности делал, а вместе никогда. С ядром реального времени я сталкивался. Изоляцию ядер процессора под задачу делал. Драйверы писал. Но свести всё это в один работающий проект мне раньше не приходилось.

И ещё одно отличие, для меня, наверное, главное. Раньше такая работа выглядела так: ищешь в Google куски кода, как собрать ядро, как поднять драйвер, склеиваешь их и потом неделями выясняешь, почему оно не работает. С ИИ ты сразу получаешь цельную основу, с которой можно работать дальше. По сути он заменяет несколько разных специалистов, потому что умеет свести код из разных областей в один проект. При условии, что архитектуру и контекст ему задаёшь ты.

Что ещё пришлось делать одному

С остальной работой, которую раньше делали сокращённые люди, вышло так же. Сейчас на мне прошивки микроконтроллеров, драйверы, образы операционных систем для терминалов, бинарники панелей под новый бренд. Облачное приложение для диспетчеризации и удалённого управления мойками, со статистикой, аналитикой и доступом по ролям. Система лояльности на картах MIFARE с облаком, личными кабинетами, транзакциями и бухгалтерией. Интеграции биллинга с «Яндекс Заправками», СБП и другими сервисами. Боты для оповещений. Плюс сборки проекта автоматизации в Automation Studio, это среда разработки B&R. В неё я раньше почти не заходил, и оказалось, что это не мешает: мне достаточно понимать, что должно получиться на стойке, и уметь это проверить.

Раньше такой объём был бы планом на год для целой команды. Язык и стек при этом перестали что‑либо значить. Прежде их определяло то, каких программистов удалось нанять, теперь их определяет задача. Я могу взять чужой код или существующую технологию на любом этапе, разобраться, доработать и сдать в рабочем виде. Для меня это ценнее любой экономии.

Про гриб

Есть такой мем:

Про контекст

Когда говорят «программирование», обычно имеют в виду код. В автоматизации проблема запросто может оказаться в электромагнитной совместимости: помеха от силового оборудования на линии связи выглядит в точности как ошибка в протоколе. Или дело в кабеле, в заземлении, в температуре внутри шкафа.

Или в том, что нарушен стандарт. Из‑за санкций монетоприёмники и купюроприёмники у нас перепрошивают местные разработчики, своим нестандартным кодом, чтобы устройства принимали новые купюры и монеты, а они появляются до сих пор. И вот тут с полтычка не разберёшься. Устройство видно, по протоколу вроде бы общается, а работает неправильно, и в документации ответа нет, потому что стандарт уже нарушен. Раньше на такое уходили дни с осциллографом и дампами обмена. С ИИ‑агентами разбор таких ситуаций и поиск нужных доработок пошёл в несколько раз быстрее. Но куда копать и финальную проверку на живом железе я по‑прежнему оставляю за собой.

ИИ видит только то, что ему дали. Если он не знает, где на объекте проходит силовая линия, он выберет самый простой путь, который на этом объекте может и не подойти. Сам он про неё не спросит, об этом должен подумать тот, кто ставит задачу.

Поэтому я не думаю, что дело в «промпт‑инжиниринге». Скорее из такой работы со временем вырастет другое знание: чем должен владеть специалист в своей области, чтобы ИИ в его руках давал результат.

Про дизайн

Чего я от ИИ совсем не ждал, так это помощи с дизайном. Я перфекционист. В алгоритмах это полезно. Ставишь себе цель, допустим обработка за две миллисекунды без единого зависания, и добиваешься её, потому что понимаешь, как всё устроено, и цифра либо получена, либо нет. С дизайном и интерфейсами так не выходит. Критерия «готово» там нет, переделывать можно бесконечно, и довольным не остаёшься никогда. ИИ меня от этого избавил. Он сразу предлагает привычное решение, а с привычным трудно спорить, оно потому и привычное, что понятно всем. Заодно я понял про себя, что мой перфекционизм вообще не про красоту. Мне нужны ровность, симметрия и логичные переходы, а это можно потребовать и проверить точно так же, как две миллисекунды.

Откуда у меня этот опыт

В двухтысячные я писал софт для корабельных систем управления и руководил их разработкой. Под моим руководством сделали собственную ПЛК‑платформу, универсальный комплект модулей ввода‑вывода, на котором собирается любой прибор управления и автоматики. Весь софт к ней писал я. Настраивалась она, между прочим, с однострочного семисегментного индикатора. Оборудование с моим софтом с середины двухтысячных ставят на военные корабли, и ставят до сих пор.

Архитектором меня сделал именно этот опыт. Диплома архитектора ПО у меня нет, есть двадцать пять лет систем, которые работают. Беда была в том, что доказать это я мог только чужими руками. Сначала кого‑то убеди, потом найми людей, потом жди, пока сделают.

По характеру мне нужно проверять гипотезы и ломать шаблоны, и раньше на каждую проверку уходили месяцы. Сейчас от идеи до проверки проходят часы. Архитектурное решение больше не приходится защищать на словах. Его можно запустить и показать, в разумный срок и без штата.

Обстоятельства, из‑за которых я во всё это влез, я бы сам себе не выбрал. Но именно благодаря им я стал тем, кем стал: архитектором, который сам доводит свои решения до работающего результата. Честно скажу, работать мне сейчас интереснее, чем когда‑либо.

Что я из этого понял

Знания ИИ мне не заменил. Он заменил руки, которых не хватало. В этом для меня и разница с вайб‑кодингом. Я точно знаю, что должно получиться. Знаю архитектуру, протоколы, знаю, как это ломается и как проверяется, а ИИ пишет код в этих рамках. Без двадцати пяти лет опыта я бы не смог ни задачу ему поставить, ни результат проверить. Так что загвоздка в этой связке одна, и это я сам. ИИ умножает то, что у человека уже есть, и если умножать нечего, толку не будет.

Отсюда главное, что я вынес. Предел того, что можно сделать с ИИ, задаёт человек, который ставит ему задачу и принимает результат. Сам ИИ этот предел не задаёт. У каждого инженера есть свой, как я это называю, конус взгляда: насколько широко он развивался, чем интересовался, понимает ли он, как всё устроено, от физики сигнала в проводе до психологии человека у терминала. Всё, что в этот конус попадает, ИИ сделает, потому что ты сможешь это поставить, проверить и заметить ошибку. Всё, что за его пределами, останется без проверки. У тебя просто не будет критериев, чтобы отличить работающее от похожего на работающее.

Чем шире опыт, тем меньше остаётся задач, которые нельзя поручить ИИ. Я думаю, что при таком проверяющем он способен заменить любых исполнителей. Самого проверяющего он не заменит.

Можно, наверное, называть всё это вайб‑кодингом. Только когда идёшь к нему четверть века, это уже обычное настоящее программирование, причём такое, какого, мне кажется, ждали с тех пор, как программирование вообще появилось. Ко мне этот инструмент пришёл в пятьдесят лет. Жалеть об этом некогда, работы много.

Как именно мы заменили контроллеры B&R на мини‑ПК, с драйвером, шлюзом и всеми подробностями, расскажу в следующей статье. Задача, кстати, распространённая: автоматики на B&R в стране много, а поддерживать её после ухода вендора почти некому.