Привет, Хабр.

Немного контекста, потому что я уже успел наступить на грабли: написал технический пост, получил пару «вежливых» комментариев, пару очень невежливых, и карма улетела туда, где зимой холодно.:-)

Нюанс какой: я зашёл «с места в карьер», как будто все уже знают, кто я, откуда и почему я так пишу и так думаю. А по факту — нет, конечно. Поэтому этот пост — «паспорт»: кто я, откуда выросла идея, почему я вообще полез в код, почему у меня агенты, почему «завод», и что я могу обсуждать с инженерами предметно (а что — не могу и не буду, потому что там секреты/безопасность/коммерческое ядро).

Сразу честно: я не классический инженер. Я могу где‑то не знать «ритуальную формулировку» термина или перепутать модное слово. Но я фанат причинности: если система говорит «работает» — она должна уметь это доказать. Всё остальное — разговоры.

1) Бэкграунд: логистика как школа сложности

Я вырос из логистики. Не «я чуть‑чуть возил коробки», а прям в том мире, где:

  • хаос — это не исключение, а состояние по умолчанию,

  • люди и процессы всегда немного «плывут»,

  • реальность постоянно меняет вводные,

  • любая «маленькая ошибка» превращается в деньги, сроки, репутацию.

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

И вот дальше случилась классика: захотел сделать CRM для логистики «по уму».

2) Почему вообще CRM — и почему всё упирается не в интерфейс

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

Но чем дальше — тем больше стало ясно: проблема не в том, чтобы “написать CRM”.

Проблема в том, что в реальном проекте у тебя неизбежно появляется:

  • несколько языков (backend, worker, SQL, ops-скрипты, UI),

  • много интеграций,

  • много точек отказа,

  • и постоянный дрейф: сегодня поправили одно — завтра незаметно сломали другое.

И если ты это не контролируешь системно, оно превращается в кашу. Даже если у тебя талантливые разработчики (а если ты один — тем более).

3) Где я “не классический” и почему это важно проговорить

Я не шёл по стандартной ИТ-тропинке “джун → мид → сеньор → архитектор”.

Я пришёл снаружи. Поэтому да:

  • я могу писать “человеческим” языком там, где принято писать “каноническим”;

  • я могу не знать какой-то узкий термин, потому что я не жил 10 лет внутри одного стека;

  • я могу задавать “неправильные” вопросы — но часто эти вопросы как раз вскрывают, где система неустойчива.

И я заранее нормально отношусь к поправкам по терминам. Только просьба: поправляйте фактами и логикой, а не “иди учи матчасть”. Матчасть я учу постоянно — просто я её учу под задачу и под доказуемость.

4) Почему я полез в многоагентные системы

В какой-то момент я увидел, что объём работ по коду — объективно огромный. Не потому что “сложно”, а потому что много слоёв:

  • API

  • фоновые задачи

  • база и миграции

  • проверки/верификации

  • инфраструктурные скрипты

  • документация/ранбуки

  • безопасность (и это отдельная вселенная)

И тут у тебя развилка:

  1. Нанимать команду (хорошую, дорогую, управляемую)

  2. Либо делать так, чтобы кодинг стал управляемым производственным процессом

  3. Либо проект никогда не выйдет из “вечного прототипа”

Команды у меня на старте не было. И я начал смотреть в сторону LLM и агентов не как в “магическую кнопку”, а как в инструмент масштабирования.

Но! Тут же выясняется неприятная вещь.

LLM без дисциплины — это генератор энтропии. Он может ускорять, но может и ускоренно ломать.

Поэтому сами по себе “агенты” ничего не решают.

Решает контур управления агентами.

5) От “агентов” к “заводу”: почему родился DevFactory

Я пришёл к простой мысли:

Если ты не можешь гарантировать качество каждой правки — ты должен гарантировать качество процесса, который эти правки производит.

Так и появился подход, который я называю “завод по программированию” (внутреннее название DevFactory, брендовый контур — FoxProFlow Engineering).

Идея не в том, чтобы “ИИ писал код вместо человека”.

Идея в том, чтобы любая работа (человека или агента) проходила один и тот же коридор:

  • намерение (что хотим изменить и зачем)

  • изменение (patch)

  • проверки (checks)

  • доказательства (evidence)

  • решение (DecisionLog: почему так, риски, откат)

Если на каком-то шаге нет доказательств — это не “ну ладно”. Это “не выпускаем”.

6) Как мы удерживаем качество: evidence-first вместо веры

Я очень не люблю слово “quality” в вакууме. Поэтому я говорю так:

Если система утверждает, что исправила баг — покажи артефакты.

У нас это оформлено в идею “ProofPack” (пакет доказательств). Внутри — не магия, а банальное, скучное, прекрасное:

  • что было за баг (симптомы)

  • где нашли причину

  • что поменяли

  • какие проверки прогнали

  • какие результаты получили

  • где лежат логи/артефакты

  • чем откатиться, если всё пошло не так

И вот здесь начинается отличие подхода “весело генерим код” от подхода “мы строим систему, которая живёт годами”.

7) “Языковая группа” и FlowSec: что это вообще такое (без раскрытия ядра)

Один из поворотных моментов был такой: когда у тебя много языков, много агентов и много контуров, тебе нужен общий “клей”.

Но не в смысле “новый язык ради нового языка”.

А в смысле: общий слой управления, который описывает правила:

  • что разрешено / что запрещено,

  • кто может что делать,

  • какие проверки обязательны,

  • как фиксируется аудит,

  • как система “закрывается” при неопределённости.

Мы это называем “языковая группа”: эт�� смесь протоколов/DSL-описаний/политик/ранбуков, которая делает поведение системы предсказуемым.

FlowSec — это часть этого мира: система безопасности в стиле “deny-by-default” (по умолчанию запрещено, разрешаем точечно). Она не про “мы самые безопасные”. Она про то, чтобы не допускать идиотских утечек и случайных действий “на шару”.

Важно: я не буду раскрывать детали внутренней реализации языковой группы, пороги, схемы политик и всё, что может помочь воспроизвести ядро. Это и безопасность, и коммерческая ценность.

Но принципы и инженерную дисциплину — обсуждать готов.

8) Ещё один важный момент: автономность и “закрытый контур”

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

Не в смысле “мы никогда не используем внешние модели” — используем, когда нужно.

А в смысле: если завтра внешние сервисы недоступны, система всё равно должна уметь:

  • крутить API,

  • выполнять пайплайн,

  • прогонять проверки,

  • собирать доказательства,

  • фиксировать решения,

  • жить и развиваться в локальном контуре.

Это не “романтика автономности”, это снижение операционных рисков.

9) Что я могу дать Хабру (и что НЕ дам)

Чтобы дальше разговор был честный, вот границы.

Могу дать/обсуждать:

  • принципы управления многоагентной разработкой без “магии”

  • как устроен коридор “Intent → Patch → Checks → Evidence → DecisionLog”

  • примеры структуры proof/evidence (на синтетических данных)

  • подходы к deny-by-default и аудит-логике на уровне принципов

  • как мы минимизируем дрейф и “самоуверенные правки”

Не буду давать:

  • внутренние схемы/пороги/политики, которые раскрывают ядро

  • всё, что позволяет воспроизвести систему “как есть”

  • реальные секреты/ключи/боевые данные (очевидно)

10) Зачем я вообще пишу это сюда

Потому что мне не нужен “лайк ради лайка”.

Мне нужно:

  1. чтобы инженеры понимали, кто я и как я думаю

  2. чтобы люди задавали точные вопросы, а не спорили с выдуманным образом

  3. чтобы из обсуждений получались проверяемые улучшения, а не очередной холивар

И да — я нормально отношусь к критике. Я плохо отношусь к критике в стиле “сам дурак”, потому что она ничего не улучшает.

Вопросы к сообществу (очень конкретно)

  1. Где чаще ломается многоагентная разработка в реальности: в контексте (агент “не так понял”) или в операционке (проверки/выпуск/регресс)?

  2. Какие “железные” метрики вы бы повесили на такой завод, чтобы рано ловить деградацию качества? (кроме очевидного “тесты/покрытие”)

  3. Как вы разделяете “показать полезное” и “не раскрыть ядро”, когда пишете про внутренние инженерные системы публично?

Если дочитал — респект.
Следующим постом (если этот формат норм) я могу аккуратно разобрать одну тему глубже: например, как выглядит ProofPack на практике (структура артефактов, checks, как не врать себе), но без всего, что опасно публиковать.

PS (важное про “карму” и странную ситуацию)

Раз уж я начал с честности — добавлю. У меня тут возникла непонятная ситуация: кто‑то мне объяснил, что я якобы где‑то под коммерческим постом оставил «не тот» комментарий, после чего пошли дизлайки в карму и даже тезисы в стиле «это бот, удалите аккаунт».

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

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

PPS

Если у кого‑то был похожий опыт «влетел на Хабр не так, как надо» — поделитесь информацией :-) Мне нужна обратная связь, чтобы дальше разговор был нормальный и предметный. Если данная тема и изложение никому не интересны, тоже понимаю и принимаю, больше не буду засорять эфир :-)