Писать надо только тогда, когда не можешь не писать (С) Л.Н. Толстой

На самом деле я работал над статьей о Claude Code, но тут пальцы сами открыли ноут на начали набивать буквы. Извините!

Приквел

Начну издалека, с темы,  максимально далекой от предмета статьи. У меня есть друг, который постоянно норовит втянуть меня в свои хобби. За десятилетие я попробовал стать фанатом ножей, огнестрельного и пневматического оружия, охоты, выживания в БП, полетах на самолетах. Ни одно хобби не зашло.

Ровно два года назад, в новогодние праздники, он привез очередную задумку - FPV дрона Pavo20. Штуку - максимально странную, еле держащуюся в воздухе минуты 3. А, в моем исполнении, после коньяка - даже не взлетающую и вызывающую тошноту.

Как ни странно, тема зашла на УРА. Сначала было больно, но потом появились тысячи взлетов, утопленные в водопадах, потерянные, горящие дроны, серф в облаках - все то, что до появления данной технологии невозможно было представить (если ты не мечтал о небе с детства и посвятил себя небу полностью). Когда падаешь на неуправляемом дроне с высоты в полтора километра - адреналин выделяется ведрами.

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

Удивительная технология, когда ты летишь как птица. Супруга, сын, дочка - равнодушны, а лично я растворяюсь в полете и в возможности увидеть мир таким, каким не дано его видеть нам, рожденными ходить.

Из приквела надо запомнить только одну фразу: увидеть мир таким каким не дано его видеть нам. Едем дальше!

Про боль

В предыдущей статье о RAG https://habr.com/ru/articles/983974/ я писал о том, что являюсь техническим директором и, по совместительству, совладельцем небольшой продуктовой компании, разрабатывающей, производящей, внедряющей и обслуживающей системы управления освещением. Выжить в сумасшедшей конкуренции, например, с Филлипсом можно лишь одним способом - не повторять ошибок.Ошибки делают люди.

Мы внедряем порядка 10 000 контроллеров в год. Обмен информацией происходит через радиоэфир, соответственно, на каждые 200-300 контроллеров продается одно Устройство Сбора и Передачи Данных (УСПД). Прибор нашей разработки, который слушает эфир, передает логи в Цифровую платформу и, по совместительству, управляет нагрузкой. Грубо говоря, включили освещение по графику, ночью задимировали, чтобы, А - сэкономить, Б - не загрязнять светом окружающую среду и циркадные ритмы людей.

В результате - УСПД входит в состав полноценного Шкафа Управления Освещением (ШУО), итого: 300-400 ШУО в год. С годами мы настолько развили свою узкоспециализированную Цифровую Платформу, что у нас все ШУО в виде “живых” мнемосхем отображают в онлайне внешний вид и состояние оборудования внутри шкафа (рисунок 1).

В чем, собственно, боль?

Сначала в Цифровой платформе, в виде сущности, появился Шкаф Управления Освещением. Запись в базе данных с сотней параметров: где находится, как работает, идентификаторы, настройки, конфигурация.

Спустя годы решили нарисовать мнемосхему - благо появились технологии (не спрашивайте какие!). Но нарисовать решили по простому - JSON и библиотека для рисования на канвасе. Безусловно, моя команда умеет смотреть вперед на 3 шага и понимает риски. В контексте этого стратегического “вижна” решили синхронизировать мир настроек и мир мнемосхемы, но только в базовых вещах, например, размеры. Остальное оставили на потом, потому что было не понятно, полетит ли мнемосхема вообще.

Мнемосхема прижилась. Инженеры, пусконаладчики, даже клиенты начали рисовать Шкафы Управления. Я пытался наложить жесткие ограничения, но процесс рисования тогда сразу становился сложным, а рисовать надо, быстро, каждый день.

В результате начали появляться, а потом масштабироваться франкенштейны, например, трехфазный ШУ с однофазным счетчиком, счетчики разного размера, лишние автоматические выключатели.

Как бы мы решали боль в старом мире

А вы знаете что фраза “Как бы мы решали боль” невозможна в ряде культур, например, в Китае, Англии - нет “нереального прошлого” и, соответственно, нет таких форм в языке. То есть они бы даже не смогли об этом поговорить. А мы поговорим!

Как проектный менеджер со стажем я бы:

1. Запросил от инженеров список возможных ошибок. Где-то через неделю получил бы список, видимо процентов на 70 полноты. Но выглядел бы он на 100%.

2. Дальше разбивка логики на задачи программистам. Настройки и мнемосхема - разные люди - две нитки задач.

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

4. Отдать инженерам, и тут окажется что список был полон на 70% и нужно снова заходить в двух-трех недельный круг. Скорее всего, не последний.

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

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

А теперь про мир с AI

Коллеги, оцените элегантность и эффективность!

Ставлю одну задачу: сделать кнопку, которая вызывает Webhook методом POST и передает пару параметров (рисунок 2) и в модальном окне выводит результат, пришедший в HTML. Вот и все. Вместо трех нудных месяцев я в течение пары дней получаю кнопку и больше мне программисты не нужны.

Дальше я за пару часов накидываю воркфлоу в n8n (рисунок 3). HTTP Request тут к нашему штатному API. JS код пишет Claude, получая на входе JSON из API и задачу. Тут 7 узлов CODE, 5 написаны с первого пропмта.

Когда автоматизация собрана осталось дело за малым (а на самом деле, за главным) - написать промпт проверки. Схема простая:

• Подложил контекст из результатов API, обработанных CODE.

• Написал условия вывода

• Написал 4 проверки. И вот эти 4 проверки высосали душу - устал - остановился. Основная трудность: сопоставить два JSONa и написать условия.

• Позвал инженера и сказал пиши! Как камень с души, думал я. Но через три проверки инженер вернулся еще более уставший, это раз. И вместо проверки ошибки ДА/НЕТ он, по ходу эпистолярных тренировок в промпте, выдумал еще сущность “Предупреждение”, это два.

• Тут мы с инженером позвали пуско-наладчика, показали волшебство и поручили написать в файле проблемы с которыми он сталкивался. Пуско-наладчик, своим скупым и корявым языком написал… Сначала я подумал, что мы сильно вильнули на пути здравого смысла в упрощении задачи.

• А потом я сделал так: Взял уже написанный промпт с контекстом и нашими проверками, добавил туда файл пуско-наладчика и сказал Claude - пиши остальные проверки. Случилось волшебство - появился промпт с 13 проверками. Инженер внимательно почитал и дал добро на “этот вариант”.

Мы нажали кнопку, подождали 30 секунд и получили чудо. Настоящее ЧУДО!

Пуско-наладчики пошли проверять мнемосхемы, накапливать опыт чего не хватает и что поправить в промпте проверок. На Рисунке 4 логи проверок в группе ТГ. 

Инженер, освобожденный от нудной процедуры проверок внес рацпредложение: пусть результат проверок выводится в таком порядке: сначала ошибки, потом предупреждения и в конце успешные. Я взял код форматирования в HTML (предварительно сохранив), положил его в Claude, попросил изменить порядок - ву-а-ля (рисунок 5).

Уважаемые читатели, каждый шаг - чудо. Новые подходы. Безумные скорости. И это только начало. Мы привязали к поясу реактивный двигатель и учимся жить в новой конфигурации. Эволюция, как мы знаем, потребует жертв. Но цена, определенно, небольшая.

Инсайты

Очень сложно объяснить подобные схемы программистам

Видимо, они о чем-то догадываются.

Когда вместо синхронов, рассказа бизнес логики проверок, обсуждений интерфейса, QA - я прошу просто кнопку с названием, которая будет делать… , видимо, это не укладывается в мировоззрение.

Повторные просьбы точно так же скользят. 

Программисты четко понимают новую архитектуру. У них открыты эти автоматизации n8n. Они сами туда добавляют какие-то непонятные мне структуры. Но повторить даже простые вещи пока не могут. Ничего - научу.

Пример промптов проверки

Та самая проверка, в которой Инженер ввел термин Предупредить

## Настройки серверов подключения

1. Получить из настроек шкафа:

   - destinationIp1 (IP адрес сервера 1)

   - destinationPort1 (Порт сервера 1)

   - destinationIp2 (IP адрес сервера 2)

   - destinationPort2 (Порт сервера 2)

2. Проверить что все 4 поля заполнены (не "null" и не пустая строка)

3. Проверить что порты имеют значения "7338" или "7339"

4. IP серверов 217.15.204.149 

5. Ошибки:

   - Если поля не заполнены - указать какие именно

   - Если порты неверные - указать какие порты и их значения

6. Если значение IP серверов отличаются от 217.15.204.149 - вывести предупреждение (не ошибка)

7. Предупредить пользователя обратить внимание на значение IP

Проверка сделанная Claude

## Датчик открытия двери

1. Найти на мнемосхеме элемент с типом "DoorOpenSensor"

2. Получить из настроек шкафа значение doorOpenSensorContactNumber (Датчик открытия двери (№ входа))

3. Проверки:

   - Если на мнемосхеме есть DoorOpenSensor, но doorOpenSensorContactNumber не равен "1" - ошибка

   - Если на мнемосхеме нет DoorOpenSensor, но doorOpenSensorContactNumber равен "1" или любому другому значению - ошибка

   - Если на мнемосхеме есть DoorOpenSensor и doorOpenSensorContactNumber равен "1" - успешно

   - Если на мнемосхеме нет DoorOpenSensor и doorOpenSensorContactNumber равен "null" - успешно

4. Ошибки:

   - "На мнемосхеме присутствует датчик открытия двери, но в настройках не указан контакт №1 (текущее значение: {doorOpenSensorContactNumber})"

   - "В настройках указан контакт №1 для датчика открытия двери, но на мнемосхеме датчик отсутствует"

5. Успешный результат:

   - "Датчик открытия двери корректно настроен на контакт №1"

   - "Датчик открытия двери отсутствует и doorOpenSensorContactNumber равен null (настройка корректна)"

Проверка всегда дает результат

Сначала я в жестокой форме требовал у LLM не выводить результат успешных проверок. Зачем знать о том, что все хорошо. Оказалось, что заставить LLM что-то не выводить - очень трудозатратная история. Выглядит так, что вывести любую чушь для LLM любого создателя проще/выгоднее, чем не вывести ничего.

Решил не насиловать стохастического попугая, просто попросил форматнуть вывод в JSON и ввести признак типа результата. Это, кстати, проще потом форматнуть в HTML, и, в целом, правильнее и логичнее.

Отдал написание проверок в промпте самим инженерам

Уменьшить эффект испорченного телефона - логичное и доброе дело. Но, в итоге, промпты для AI должен писать другой AI.

Когда я презентовал функционал сервисным инженерам и пуско-наладчикам, они сразу попросили кнопку Исправить

Вот тут я очень… удивился. Удивился тому, что сам не додумался до такой простой и функциональной кнопки. С серьезным лицом я порекомендовал народу сначала проверить сотню шкафов, чтобы отшлифовать промпт, а потом приходить за новым чудом.

MCP

Теперь у меня постоянно открыт наш документ с описанием API. В автоматизациях существенное время уходит на то, чтобы накликать заголовки HTTP Request к API под задачу. Думаю, что все сэкономленное время программистов отправить на написание MCP сервера и уже закрыть дверь старого медленного и неэффективного мира

Заключение

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

Потом появились программисты - более жестокие враги людей. Они начали отнимать работу и у простых людей и у инженеров.

И вот появился монстр - AI отнимает работу даже у программистов!

Ну а я займусь тем, что сделаю кнопку ИСПРАВИТЬ (это еще одна задача для программистов) и подумаю на MCP.