Промпты вместо кода: кейс автоматизации промышленного IoT с Claude и n8n

Промпты вместо кода: когда слова важнее функций

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

Я это понял, когда клиент пришел с задачей: "У нас 5000 светильников на территории завода. Нужно управлять ими по зонам, времени суток, присутствию людей. И чтобы все отображалось на интерактивной карте. И чтобы завтра работало".

Классический подход? Команда из трех разработчиков, два месяца работы, куча Python-скриптов, база данных с геоданными, веб-интерфейс. Стоимость - от $80k.

Мы сделали это за день. Без единой строки кода. Только промпты и воркфлоу.

Почему это работает в промышленности, где все должно быть надежно

Потому что в промышленном IoT главное - не красивый код. Главное - предсказуемость. Когда вы пишете промпт "Включай освещение в зоне А с 18:00 до 06:00, если есть движение", это либо работает, либо нет. Нет скрытых багов в обработке исключений. Нет memory leaks. Нет race conditions.

В статье Claude + n8n: кейс ускорения IoT-разработки я уже показывал, как это работает для сбора данных. Но управление - это другая история. Здесь ошибка стоит дороже.

Архитектура, которая не выглядит как архитектура

Вот что происходит на самом деле:

Самое важное: вся логика теперь описывается в промптах. Хотите изменить алгоритм управления освещением? Не нужно искать разработчика. Просто пишете новый промпт, Claude генерирует обновленный workflow, тестируете на стенде, разворачиваете.

Шаг за шагом: от промпта до работающего освещения

1Подготовка MCP-сервера n8n для Claude

Claude Code (последняя версия на 01.02.2026) поддерживает MCP (Model Context Protocol). Это протокол, который позволяет Claude взаимодействовать с внешними системами. Для n8n нужно поднять MCP-сервер.

Как НЕ надо делать: пытаться написать свой MCP-сервер с нуля. Это потраченные две недели и куча багов.

Как надо: использовать готовый n8n-mcp-server, который уже включает все необходимое:

# Клонируем репозиторий
 git clone https://github.com/n8n-io/n8n-mcp-server
 cd n8n-mcp-server
 
 # Устанавливаем зависимости
 npm install
 
 # Настраиваем конфигурацию
 cp .env.example .env
 # В .env указываем:
 # N8N_API_KEY=ваш_ключ
 # N8N_BASE_URL=http://localhost:5678
 
 # Запускаем сервер
 npm start

2Описание логики освещения в промпте

Вот промпт, который превращается в рабочий workflow:

Создай n8n workflow для управления промышленным освещением.

Требования:
1. Триггер: Webhook POST запрос с JSON телом
2. В теле запроса приходят:
   - zone_id: идентификатор зоны (строка)
   - motion_detected: boolean (есть ли движение)
   - current_time: время в формате HH:MM
   - daylight_level: уровень естественного освещения (0-100)

3. Логика управления:
   - Если motion_detected=true И daylight_level < 30: включить освещение
   - Если motion_detected=false: выключить освещение через 5 минут
   - Если current_time между 18:00 и 06:00: включить освещение независимо от движения
   - Если daylight_level > 70: никогда не включать освещение

4. Действия:
   - Отправка MQTT команды на контроллер освещения
   - Логирование в базу данных (PostgreSQL)
   - Уведомление в Telegram при аномалиях

5. Обработка ошибок:
   - Retry 3 раза при ошибке MQTT
   - Dead letter queue для неудачных команд
   - Alert в Telegram при повторных ошибках

Используй ноды:
- Webhook для триггера
- IF для условий
- Wait для задержки 5 минут
- MQTT для управления
- PostgreSQL для логирования
- Telegram для уведомлений

Claude через MCP-сервер получает доступ к n8n, анализирует доступные ноды и создает workflow. Весь процесс занимает 2-3 минуты.

3Интеграция с интерактивной картой

Самое интересное начинается здесь. Нужно отображать состояние освещения на карте завода. Раньше для этого писали отдельный веб-сервис на React с Leaflet.

Теперь - один промпт:

Создай workflow для обновления интерактивной карты освещения.

1. Триггер: любое изменение состояния освещения (из workflow управления)
2. Чтение GeoJSON файла с координатами зон
3. Обновление состояния зоны (цвет маркера)
4. Генерация статической карты в PNG
5. Отправка обновления:
   - В веб-сокет для реального обновления
   - В телеграм-канал с картой
   - В S3 bucket для архива

Используй ноды:
- Watch файлы для GeoJSON
- Function для обработки геоданных
- Canvas для генерации карты
- WebSocket для реального времени
- AWS S3 для хранения

Что пошло не так: реальные проблемы и их решения

Не все было гладко. Вот три главные проблемы, с которыми мы столкнулись:

Проблема 1: Claude слишком "творчески" подходит к обработке ошибок

Когда мы попросили добавить обработку ошибок, Claude создал workflow с 15 уровнями вложенности IF-нод для проверки каждого возможного сценария. Workflow стал неподдерживаемым.

Решение: конкретизировать промпт:

Добавь обработку ошибок ТОЛЬКО для:
1. Потери соединения MQTT
2. Ошибки записи в PostgreSQL
3. Таймаута Telegram API

Для каждой ошибки:
- Retry 2 раза с задержкой 10 секунд
- Если все retry неудачны - записать в отдельную таблицу errors
- Отправить alert в Telegram

НЕ добавляй проверки для валидации входных данных - это делается в источнике.

Проблема 2: Производительность при масштабировании

Когда мы протестировали систему на 5000 светильников, workflow начал тормозить. Проблема была в том, что Claude использовал Function ноду для обработки каждого светильника отдельно.

Решение: переписать промпт с акцентом на batch-обработку:

Оптимизируй workflow для обработки 5000+ устройств:
1. Обрабатывай данные пачками по 100 устройств
2. Используй parallel processing для независимых зон
3. Кэшируй GeoJSON данные в памяти
4. Используй bulk insert в PostgreSQL

Избегай Function нод в циклах.

Проблема 3: Поддержка и документация

Когда через месяц клиент захотел изменить логику, оказалось, что никто не понимает, как работает workflow. Промпты были утеряны.

Решение: интегрировать с Git и автоматически генерировать документацию:

# Автоматический экспорт workflow и промптов в Git
 n8n export:workflow --all --output workflows/
 
 # Генерация документации из промптов
 python generate_docs.py --prompts prompts/ --output docs/

Сравнение с традиционным подходом

Давайте посмотрим на цифры:

Когда это НЕ работает

Не обманывайте себя - этот подход не панацея. Вот когда нужно писать код по-старинке:

• Высокочастотная обработка данных (>1000 событий в секунду). n8n не справится, нужен Rust или Go.
• Сложные алгоритмы машинного обучения. Claude не напишет эффективный inference engine.
• Системы реального времени с гарантированным временем отклика. n8n дает 100-200мс, а нужно <10мс.
• Обработка видео/аудио потоков. Не те задачи для workflow-движка.

Как я писал в статье Cursor против Warp против Claude Code, каждый инструмент хорош для своих задач. Промпты вместо кода - это для бизнес-логики, а не для системного программирования.

Что будет дальше? Прогноз на 2026-2027

Судя по тому, как развивается Claude Code и n8n, вот что нас ждет:

1. Автоматическая оптимизация workflows. Claude будет не только создавать, но и улучшать существующие воркфлоу на основе метрик производительности.
2. Генерация тестов из промптов. "Создай нагрузочные тесты для этого workflow на 10,000 RPS".
3. Мульти-агентные системы. Один агент создает workflow, второй проверяет безопасность, третий оптимизирует производительность.
4. Интеграция с hardware-in-the-loop. Промпт "Протестируй этот workflow на реальном PLC Siemens S7-1500 через OPC UA".

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

FAQ: частые вопросы от скептиков

Это же ненадежно! А если Claude сгенерирует баг?

А если разработчик напишет баг? Разницы нет. В промышленном IoT все равно нужны тесты, code review, staging environment. Только вместо review кода - review промптов и сгенерированных workflows.

А как же производительность? n8n медленный!

Для 95% промышленных задач n8n достаточно быстр. Контроллер освещения не требует наносекундных задержек. Датчик температуры обновляется раз в минуту. Если нужна реальная производительность - используйте специализированные стеки вроде NVIDIA NIM.

А если n8n упадет? Весь завод встанет!

n8n можно развернуть в кластере. Можно сделать active-active репликацию. Можно использовать n8n в high-availability конфигурации. Плюс все workflows можно экспортировать и запустить на резервном сервере за 5 минут.

Это дорого? Claude Code стоит $20/месяц!

Разработчик стоит $8000/месяц. Claude Code - $20. Математика простая. Даже если добавить n8n Enterprise ($400/месяц), это все равно в 20 раз дешевле разработчика.

Мой главный совет

Начните с малого. Не пытайтесь перевести весь завод на промпты за один день. Возьмите одну простую задачу: мониторинг температуры в одной комнате. Создайте промпт, сгенерируйте workflow, протестируйте. Потом добавьте алерты. Потом - интеграцию с телеграмом.

Через месяц у вас будет работающая система, созданная без единой строки кода. И самое главное - вы сможете ее поддерживать и изменять без помощи разработчиков.

Промпты вместо кода - это не будущее. Это настоящее. Просто большинство еще не поняло, насколько оно уже наступило.