134 автоматизации ведёт один инженер - и бизнес не его заложник

Последние годы я веду AI-направление закрытой платформы сообщества (проект под NDA, поэтому без имён и деталей продукта). Веду - потому что сам его и сделал: спроектировал и собрал с нуля, практически в одиночку. AI-агент клуба, рекомендации знакомств, поиск людей под запрос, рассылки и вся начинка под ними - примерно 134 процесса в n8n, которые всё это исполняют.

Стек: Directus + n8n + React, поиск на векторной базе Qdrant, пять арендаторов на одной кодовой базе, полный набор стендов - dev, stage, prod. Стенды, промоушен и дисциплину сопровождения, о которых пойдёт речь дальше, я тоже довёл до нынешнего вида сам.

Low-code продаётся как "быстро собрал - работает". Это правда ровно до сопровождения. Сто с лишним воркфлоу невозможно держать в голове: через полгода собственная схема читается как чужая, любое изменение может задеть соседний процесс, а нового человека приходится вводить в курс руками. По моему опыту порог - примерно два десятка сценариев: если их больше и ни у одного нет описания, это уже техдолг.

Обычный финал такой истории - "у нас есть человек, который знает, как оно работает, не трогайте его". Это не масштабируется и делает проект заложником одной головы. Меня такой финал не устраивал, потому что эта голова - моя.

У каждого воркфлоу есть заметка "О процессе" прямо на холсте: зачем процесс существует, откуда приходят данные, куда уходят, какие есть неочевидные места. Та же заметка зеркалится в markdown-базу знаний проекта. Документация внутри инструмента работает лучше вики "где-то рядом": её видно в момент работы.

Правило простое: заметка пишется для того, кто открыл воркфлоу впервые. На практике "тот, кто открыл впервые" - это я сам через полгода и AI-ассистент, которому нужен контекст. Расследование "почему тут так" сводится к чтению заметки.

Изменения идут через репозиторий: каждая версия сохраняется, видно, кто и что менял, любую правку можно откатить - всё, к чему привыкли в обычной разработке, работает и для low-code. Когда что-то сломалось, я не гадаю: сравниваю с вчерашней версией и вижу, что в ней изменилось.

Dev - верстак: здесь можно ломать. Stage - репетиция. Prod - только то, что прошло первые два. Один и тот же процесс на всех трёх стендах называется и подключается одинаково, поэтому изменение переносится процедурой, а не пересобирается руками "по образцу". На боевом не всплывает то, чего не было на репетиции.

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

Рутину сопровождения я отдаю AI-агенту: пересчитать процессы и сверить стенды между собой, найти, где ещё используются те же данные, набросать черновик заметки "О процессе". Здесь замыкается круг: агент справляется ровно потому, что первые три пункта дали ему читаемую систему - описания, файлы в git, предсказуемые стенды.

Это, пожалуй, главный вывод кейса: AI-ассистент не компенсирует бардак, он умножает порядок. На хаосе он умножает хаос.

Один инженер спроектировал, построил и ведёт AI-направление платформы на пять арендаторов: развитие, сопровождение и прод-инциденты. "Человека-энциклопедии" в единственном экземпляре при этом нет, потому что знание о системе лежит в самой системе: новая фича начинается с чтения заметок, инцидент - с диффа.

Отдельный бонус всплыл позже: когда понадобилось передавать часть процессов коллегам, онбординг свёлся к "открой воркфлоу и прочитай заметку". Документация, написанная для себя-через-полгода, оказалась готовой документацией для кого угодно.

Возьмите свои часы. Даже десять разборов "почему тут так" по часу в месяц при ставке сотрудника 500 рублей за час - это 5 000 рублей, а если разбирается руководитель, каждый такой день стоит 7 000 - 10 000 рублей. Столько же уходит на ввод нового человека без описаний. С заметкой внутри процесса и историей изменений это чтение, а не расследование.