40 минут, 4 фикса, 74 теста. Один день из жизни невидимого департамента

Утро. Открываю Telegram — четыре сообщения от системы мониторинга. Котельная, где работает наш edge-комплекс предиктивной аналитики, прислала отчёт. Четыре проблемы. Разные по природе, но все требуют внимания.

Через 40 минут все четыре закрыты. 74 теста проходят. Система работает дальше.

Я за это время не написал ни одной строки кода. Я оркестрировал.

Четыре проблемы

Перечислю их так, как они пришли ко мне — простым языком, без технических деталей.

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

Проблема 2. При перезапуске системы ловятся ложные остановки и пуски. Пайплайн перезапустился — а в Telegram уже летит сообщение «Останов», потом «Пуск». Хотя котёл всё это время спокойно работал. И в статистику пусков попадает фиктивный пуск. А значит — некорректный расчёт остаточного ресурса.

Проблема 3. Температура с внешнего API снова врёт. Утром показывало 30 градусов. После перезапуска пайплайна — корректные 24.7. API иногда отдаёт прогнозную температуру вместо реальной.

Проблема 4. Неудачный пуск засчитывается как реальный. Котёл пытается запуститься из холодного состояния, горелка уходит в аварию — нагрева не было. Но система уже засчитала холодный пуск и пересчитала ресурс. Получается занижение остаточного ресурса без оснований.

Как я ставил задачу

Я не полез в код. Я сел и сформулировал четыре задачи — по одной на каждую проблему. Простым языком, как если бы объяснял инженеру за чашкой кофе.

Ключевое: я описал симптомы и желаемое поведение, а не решение. Например, для проблемы 4 я не писал «добавь отложенную классификацию». Я написал: «Если котёл не запустился и ушёл в аварию — значит, нагрева не было. Пуск не должен засчитываться».

Дальше — в работу вступила невидимая команда.

Что сделали агенты

Агенты проанализировали проект. Нашли корни каждой проблемы. Предложили решения. Реализовали. Прогнали тесты.

Вот что они увидели (на высоком уровне, без деталей архитектуры):

• Проблема 2 оказалась в логике инициализации: при первом скане система сравнивала текущее состояние с «нулевым» и видела ложный переход. Решение — первый скан должен просто запоминать состояние, а не генерировать события.

• Проблема 3 — внешний API иногда отдаёт мусор. Решение — добавить проверку на разумный диапазон и на резкие скачки. Если температура прыгнула на 8 градусов за час — это не погода, это ошибка. Значение отбрасываем, оставляем предыдущее.

• Проблема 4 — система считала пуск в момент старта горелки, не дожидаясь подтверждения прогрева. Решение — отложенная классификация: запоминаем факт старта, но считаем пуск только когда видим реальный рост температуры. Если котёл ушёл в аварию до прогрева — пуск отменяется.

• Проблема 1 — самая объёмная. Переработка логики событий: пуск, пуск из горячего резерва, останов, переход в горячий резерв — четыре разных статуса вместо двух.

Результат

Сорок минут. Четыре фикса в промышленной системе, которая работает на реальном объекте, с реальными котлами, реальными данными.

Что это значит

Это не «магия ИИ». Это правильно построенный процесс.

Я не ставил задачу «почини код». Я поставил задачу «устрани симптом, вот желаемое поведение». Агенты нашли корень, предложили решение, реализовали, проверили.

Это и есть оркестрация. Моя роль — понимать физику процесса (что такое холодный пуск, почему неудачный пуск не должен считаться, как отличить горячий резерв от холодного старта). Роль агентов — найти это в коде и исправить.

Ни один из них не справился бы без другого. Без моего понимания физики — агенты починили бы симптомы, но не корни. Без агентов — я бы потратил на реализацию несколько дней вместо сорока минут.

Выводы

1. Формулируй симптомы, а не решения. Если ты знаешь, как должно работать — опиши это. Не лезь в код. Пусть те, кто лучше знает код, найдут путь.

2. Валидация важнее реализации. Моя работа — не писать код. Моя работа — проверить, что решение соответствует физике процесса. Это нельзя автоматизировать.

3. Время — главный показатель. 40 минут на четыре фикса в промышленной системе — это не про скорость агентов. Это про то, что правильно выстроен процесс передачи контекста.

Если вы руководитель и хотите понять, как ускорить разработку в промышленном инжиниринге без раздувания штата — напишите в @KachanAI. Обсудим, с каких задач стоит начать.