- Регистрация
- 23 Авг 2023
- Сообщения
- 3,969
- Реакции
- 0
- Баллы
- 36
Ofline
Привет, Хабр.
Немного контекста, потому что я уже успел наступить на грабли: написал технический пост, получил пару “вежливых” комментариев, пару очень невежливых, и карма улетела туда, где зимой холодно. )))
Нюанс какой: я зашёл “с места в карьер”, как будто все уже знают, кто я, откуда и почему я так пишу и так думаю. А по факту — нет, конечно. Поэтому этот пост — “паспорт”: кто я, откуда выросла идея, почему я вообще полез в код, почему у меня агенты, почему “завод”, и что я могу обсуждать с инженерами предметно (а что — не могу и не буду, потому что там секреты/безопасность/коммерческое ядро).
Сразу честно: я не классический инженер. Я могу где-то не знать “ритуальную формулировку” термина или перепутать модное слово. Но я фанат причинности: если система говорит “работает” — она должна уметь это доказать. Всё остальное — разговоры.
1) Бэкграунд: логистика как школа сложности
Я вырос из логистики. Не “я чуть-чуть возил коробки”, а прям в том мире, где:
И логистика быстро учит одной вещи: когда система становится сложной — её нельзя держать в голове. Её надо держать в процессах, в проверках, в правилах, в журнале решений.
И вот дальше случилась классика: захотел сделать CRM для логистики “по уму”.
2) Почему вообще CRM — и почему всё упирается не в интерфейс
Начиналось как нормальная история: CRM под реальные процессы, под реальных людей, под реальные заявки, статусы, документы, события, интеграции.
Но чем дальше — тем больше стало ясно: проблема не в том, чтобы “написать CRM”.
Проблема в том, что в реальном проекте у тебя неизбежно появляется:
И если ты это не контролируешь системно, оно превращается в кашу. Даже если у тебя талантливые разработчики (а если ты один — тем более).
3) Где я “не классический” и почему это важно проговорить
Я не шёл по стандартной ИТ-тропинке “джун → мид → сеньор → архитектор”.
Я пришёл снаружи. Поэтому да:
И я заранее нормально отношусь к поправкам по терминам. Только просьба: поправляйте фактами и логикой, а не “иди учи матчасть”. Матчасть я учу постоянно — просто я её учу под задачу и под доказуемость.
4) Почему я полез в многоагентные системы
В какой-то момент я увидел, что объём работ по коду — объективно огромный. Не потому что “сложно”, а потому что много слоёв:
И тут у тебя развилка:
Команды у меня на старте не было. И я начал смотреть в сторону LLM и агентов не как в “магическую кнопку”, а как в инструмент масштабирования.
Но! Тут же выясняется неприятная вещь.
LLM без дисциплины — это генератор энтропии. Он может ускорять, но может и ускоренно ломать.
Поэтому сами по себе “агенты” ничего не решают.
Решает контур управления агентами.
5) От “агентов” к “заводу”: почему родился DevFactory
Я пришёл к простой мысли:
Если ты не можешь гарантировать качество каждой правки — ты должен гарантировать качество процесса, который эти правки производит.
Так и появился подход, который я называю “завод по программированию” (внутреннее название DevFactory, брендовый контур — FoxProFlow Engineering).
Идея не в том, чтобы “ИИ писал код вместо человека”.
Идея в том, чтобы любая работа (человека или агента) проходила один и тот же коридор:
Если на каком-то шаге нет доказательств — это не “ну ладно”. Это “не выпускаем”.
6) Как мы удерживаем качество: evidence-first вместо веры
Я очень не люблю слово “quality” в вакууме. Поэтому я говорю так:
Если система утверждает, что исправила баг — покажи артефакты.
У нас это оформлено в идею “ProofPack” (пакет доказательств). Внутри — не магия, а банальное, скучное, прекрасное:
И вот здесь начинается отличие подхода “весело генерим код” от подхода “мы строим систему, которая живёт годами”.
7) “Языковая группа” и FlowSec: что это вообще такое (без раскрытия ядра)
Один из поворотных моментов был такой: когда у тебя много языков, много агентов и много контуров, тебе нужен общий “клей”.
Но не в смысле “новый язык ради нового языка”.
А в смысле: общий слой управления, который описывает правила:
Мы это называем “языковая группа”: это смесь протоколов/DSL-описаний/политик/ранбуков, которая делает поведение системы предсказуемым.
FlowSec — это часть этого мира: система безопасности в стиле “deny-by-default” (по умолчанию запрещено, разрешаем точечно). Она не про “мы самые безопасные”. Она про то, чтобы не допускать идиотских утечек и случайных действий “на шару”.
Важно: я не буду раскрывать детали внутренней реализации языковой группы, пороги, схемы политик и всё, что может помочь воспроизвести ядро. Это и безопасность, и коммерческая ценность.
Но принципы и инженерную дисциплину — обсуждать готов.
8) Ещё один важный момент: автономность и “закрытый контур”
Я стараюсь строить систему так, чтобы она могла работать локально, без обязательной зависимости от внешних сервисов и постоянного интернета.
Не в смысле “мы никогда не используем внешние модели” — используем, когда нужно.
А в смысле: если завтра внешние сервисы недоступны, система всё равно должна уметь:
Это не “романтика автономности”, это снижение операционных рисков.
9) Что я могу дать Хабру (и что НЕ дам)
Чтобы дальше разговор был честный, вот границы.
Могу дать/обсуждать:
Не буду давать:
10) Зачем я вообще пишу это сюда
Потому что мне не нужен “лайк ради лайка”.
Мне нужно:
И да — я нормально отношусь к критике. Я плохо отношусь к критике в стиле “сам дурак”, потому что она ничего не улучшает.
Вопросы к сообществу (очень конкретно)
Если дочитал — респект.
Следующим постом (если этот формат норм) я могу аккуратно разобрать одну тему глубже: например, как выглядит ProofPack на практике (структура артефактов, checks, как не врать себе), но без всего, что опасно публиковать.
PS (важное про “карму” и странную ситуацию)
Раз уж я начал с честности — добавлю. У меня тут возникла непонятная ситуация: кто-то мне объяснил, что я якобы где-то под коммерческим постом оставил “не тот” комментарий, после чего пошли дизлайки в карму и даже тезисы в стиле “это бот, удалите аккаунт”.
Я без драм. Просто реально до конца не понимаю причину, потому что у меня не было цели спамить, продавать или строить из себя кого-то. Во избежание подобных недоразумений я и решил опубликовать этот пост: чтобы познакомиться и чтобы у вас было понимание, кто пишет и в какой логике.
Если я где-то накосячил по форме — скажите прямо, по делу, я поправлю. Я здесь не за тем, чтобы ругаться. Я здесь за тем, чтобы сделать систему лучше и научиться у сильных инженеров.
PPS
Если у кого-то был похожий опыт “влетел на Хабр не так, как надо” — поделитесь информацией.) Мне нужна обратная связь, чтобы дальше разговор был нормальный и предметный. Если данная тема и изложение никому не интересны, тоже понимаю и принимаю, больше не буду засорять эфир ))
Немного контекста, потому что я уже успел наступить на грабли: написал технический пост, получил пару “вежливых” комментариев, пару очень невежливых, и карма улетела туда, где зимой холодно. )))
Нюанс какой: я зашёл “с места в карьер”, как будто все уже знают, кто я, откуда и почему я так пишу и так думаю. А по факту — нет, конечно. Поэтому этот пост — “паспорт”: кто я, откуда выросла идея, почему я вообще полез в код, почему у меня агенты, почему “завод”, и что я могу обсуждать с инженерами предметно (а что — не могу и не буду, потому что там секреты/безопасность/коммерческое ядро).
Сразу честно: я не классический инженер. Я могу где-то не знать “ритуальную формулировку” термина или перепутать модное слово. Но я фанат причинности: если система говорит “работает” — она должна уметь это доказать. Всё остальное — разговоры.
1) Бэкграунд: логистика как школа сложности
Я вырос из логистики. Не “я чуть-чуть возил коробки”, а прям в том мире, где:
хаос — это не исключение, а состояние по умолчанию,
люди и процессы всегда немного “плывут”,
реальность постоянно меняет вводные,
любая “маленькая ошибка” превращается в деньги, сроки, репутацию.
И логистика быстро учит одной вещи: когда система становится сложной — её нельзя держать в голове. Её надо держать в процессах, в проверках, в правилах, в журнале решений.
И вот дальше случилась классика: захотел сделать CRM для логистики “по уму”.
2) Почему вообще CRM — и почему всё упирается не в интерфейс
Начиналось как нормальная история: CRM под реальные процессы, под реальных людей, под реальные заявки, статусы, документы, события, интеграции.
Но чем дальше — тем больше стало ясно: проблема не в том, чтобы “написать CRM”.
Проблема в том, что в реальном проекте у тебя неизбежно появляется:
несколько языков (backend, worker, SQL, ops-скрипты, UI),
много интеграций,
много точек отказа,
и постоянный дрейф: сегодня поправили одно — завтра незаметно сломали другое.
И если ты это не контролируешь системно, оно превращается в кашу. Даже если у тебя талантливые разработчики (а если ты один — тем более).
3) Где я “не классический” и почему это важно проговорить
Я не шёл по стандартной ИТ-тропинке “джун → мид → сеньор → архитектор”.
Я пришёл снаружи. Поэтому да:
я могу писать “человеческим” языком там, где принято писать “каноническим”;
я могу не знать какой-то узкий термин, потому что я не жил 10 лет внутри одного стека;
я могу задавать “неправильные” вопросы — но часто эти вопросы как раз вскрывают, где система неустойчива.
И я заранее нормально отношусь к поправкам по терминам. Только просьба: поправляйте фактами и логикой, а не “иди учи матчасть”. Матчасть я учу постоянно — просто я её учу под задачу и под доказуемость.
4) Почему я полез в многоагентные системы
В какой-то момент я увидел, что объём работ по коду — объективно огромный. Не потому что “сложно”, а потому что много слоёв:
API
фоновые задачи
база и миграции
проверки/верификации
инфраструктурные скрипты
документация/ранбуки
безопасность (и это отдельная вселенная)
И тут у тебя развилка:
Нанимать команду (хорошую, дорогую, управляемую)
Либо делать так, чтобы кодинг стал управляемым производственным процессом
Либо проект никогда не выйдет из “вечного прототипа”
Команды у меня на старте не было. И я начал смотреть в сторону 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) Зачем я вообще пишу это сюда
Потому что мне не нужен “лайк ради лайка”.
Мне нужно:
чтобы инженеры понимали, кто я и как я думаю
чтобы люди задавали точные вопросы, а не спорили с выдуманным образом
чтобы из обсуждений получались проверяемые улучшения, а не очередной холивар
И да — я нормально отношусь к критике. Я плохо отношусь к критике в стиле “сам дурак”, потому что она ничего не улучшает.
Вопросы к сообществу (очень конкретно)
Где чаще ломается многоагентная разработка в реальности: в контексте (агент “не так понял”) или в операционке (проверки/выпуск/регресс)?
Какие “железные” метрики вы бы повесили на такой завод, чтобы рано ловить деградацию качества? (кроме очевидного “тесты/покрытие”)
Как вы разделяете “показать полезное” и “не раскрыть ядро”, когда пишете про внутренние инженерные системы публично?
Если дочитал — респект.
Следующим постом (если этот формат норм) я могу аккуратно разобрать одну тему глубже: например, как выглядит ProofPack на практике (структура артефактов, checks, как не врать себе), но без всего, что опасно публиковать.
PS (важное про “карму” и странную ситуацию)
Раз уж я начал с честности — добавлю. У меня тут возникла непонятная ситуация: кто-то мне объяснил, что я якобы где-то под коммерческим постом оставил “не тот” комментарий, после чего пошли дизлайки в карму и даже тезисы в стиле “это бот, удалите аккаунт”.
Я без драм. Просто реально до конца не понимаю причину, потому что у меня не было цели спамить, продавать или строить из себя кого-то. Во избежание подобных недоразумений я и решил опубликовать этот пост: чтобы познакомиться и чтобы у вас было понимание, кто пишет и в какой логике.
Если я где-то накосячил по форме — скажите прямо, по делу, я поправлю. Я здесь не за тем, чтобы ругаться. Я здесь за тем, чтобы сделать систему лучше и научиться у сильных инженеров.
PPS
Если у кого-то был похожий опыт “влетел на Хабр не так, как надо” — поделитесь информацией.) Мне нужна обратная связь, чтобы дальше разговор был нормальный и предметный. Если данная тема и изложение никому не интересны, тоже понимаю и принимаю, больше не буду засорять эфир ))