Привет, Хабр.
Немного контекста, потому что я уже успел наступить на грабли: написал технический пост, получил пару «вежливых» комментариев, пару очень невежливых, и карма улетела туда, где зимой холодно.:-)
Нюанс какой: я зашёл «с места в карьер», как будто все уже знают, кто я, откуда и почему я так пишу и так думаю. А по факту — нет, конечно. Поэтому этот пост — «паспорт»: кто я, откуда выросла идея, почему я вообще полез в код, почему у меня агенты, почему «завод», и что я могу обсуждать с инженерами предметно (а что — не могу и не буду, потому что там секреты/безопасность/коммерческое ядро).
Сразу честно: я не классический инженер. Я могу где‑то не знать «ритуальную формулировку» термина или перепутать модное слово. Но я фанат причинности: если система говорит «работает» — она должна уметь это доказать. Всё остальное — разговоры.
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
Если у кого‑то был похожий опыт «влетел на Хабр не так, как надо» — поделитесь информацией :-) Мне нужна обратная связь, чтобы дальше разговор был нормальный и предметный. Если данная тема и изложение никому не интересны, тоже понимаю и принимаю, больше не буду засорять эфир :-)
Комментарии (42)
SolidSnack
19.02.2026 00:09Меня смущает вера людей в то что можно отдать нагенерированный код другой машине-генератору и спросить что с этим кодом не так...
FoxProFlow Автор
19.02.2026 00:09Немножко не так. Здравствуйте. Любой программист когда ищет баг в коде, он выполняет определенный набор команд, проверок, прогонов. По сути процесс ровно такой же, как у любого программиста при поиске бага. Просто этот цикл автоматизирован. Проверяет не другая магическая машина, а обычный код: тесты, контрактные проверки, sandbox-прогоны, e2e, анализ логов. Всё на понятных языках и с воспроизводимым результатом. LLM в этом процессе — не судья и не пророк, а ускоритель гипотез. Истина определяется только проверками и воспроизводимостью.
Это по сути та же самая работа программиста, который 50–200 раз гоняет код, пока не получит стабильный результат. Просто цикл сделан автоматизированным.
SolidSnack
19.02.2026 00:09Вы считаете что любой программист просто рандомно перебирает что не так в месте бага?))
Или всетаки изучает кропотливо как все работает и там уже прикидывает где что может пойти не так?)
Да и вот ещё одна фантазия ИИ адептов - покроем код тестами тогда багов не будет...
Порог входа в профессию сделали вообще минимальным, люди прогреты, каждый может стать промпт инженером (прогеры не нужны) только подписочку оформляйте скорее.
Может это все ради консолидации умения кодить в руках компаний?)) Джуны ведь не нужны))
FoxProFlow Автор
19.02.2026 00:09Программист не перебирает рандомно - он выдвигает гипотезы и проверяет их. Разница только в том, что у человека этот процесс происходит в голове и через инструменты (логи, дебаггер, тесты), а у меня часть этого цикла формализована и автоматизирована. То есть не рандомный перебор, а: воспроизводим баг, сужаем область поиска, проверяем гипотезу, смотрим результат, повторяем цикл. Нейросеть участвует только на этапе формирования гипотиз
SolidSnack
19.02.2026 00:09У человека все процессы происходят в голове, человеку думать надо (желательно).
Какую гипотезу вам формирует ии? Что там есть баг? Не понятно...
Ну и опять же, вы рассматриваете частный случай работы с багом. А если человек знает хорошо проект и в голове может прогнать где что не так и точечно внести изменения с 1 раза. А вы, судя по всему, ставите на схожесть процессов в одном конкретном случае - итеративный подход и считаете что раз что там что там цикл то это одно и тоже
FoxProFlow Автор
19.02.2026 00:09Я, возможно, неправильно сформулировал - поэтому уточню. Я не пытаюсь описывать, как должен работать опытный инженер. Я почти год не вынимая строю свою систему и говорю только из собственного опыта. У меня нет 15 лет в разработке, поэтому я опираюсь не на идеальное знание проекта в голове, а на формализованный процесс. Да, сильный инженер, который знает систему вдоль и поперёк, может внести точечный фикс с первого раза. У меня такой глубины понимания пока нет, поэтому я сделал ставку на цикл гипотеза - проверка - результат. LLM в моем случае - это не замена мышления, а способ быстрее сформировать гипотезу. Проверки остаются обычными инженерными: sandbox, тесты, логи, воспроизводимость. Возможно, со временем, когда я буду знать систему в голове, цикл станет короче. Сейчас это просто способ снизить количество собственных ошибок. И если честно LLM за тебя ничего не сделает полностью, она может что то ускорить, что то объяснить, что-то подсказать, сгенерировать код файла (в теории рабочий) на этом все. Остальное на данный момент все так же делает человек. Но я честно видя этот взрывной рост развития LLM не очень понимаю куда все идет. Слишком быстро нейросети развиваются.
SolidSnack
19.02.2026 00:09Ничего личного, но именно по этому я и говорю про порог входа.
А то получается что опыта разработки у вас нету, вам в руки дали ИИ и вы теперь на ресурсе для прогеров рассказываете как создали какой-то процесс по созданию каких-то продуктов. Хотя видение процесса и продукта вам взять неоткуда кроме ИИ...
Прежде чем строить фундамент, надо хотя-бы понять как он выглядит?
treblereel
19.02.2026 00:09ну это если предположить что стоит такая задача. Я подозреваю, что задача состоит немного в другом :)
FoxProFlow Автор
19.02.2026 00:09а не могли бы вы более развернуто прояснить свои подозрения, что бы я как то мог их развеять, либо подтвердить? Услыште пожалуйста меня. Я здесь зарегистрировался и пытаюсь что то постить только потому, что ресурса подобного Хабру больше нет. Мне не интересны лайки/дизлайки и карма в принципе как цель. Я просто думаю, что в ближайшее время, много людей будут пробовать работать с многоагенкой, много людей придут в профессию так же как и я, не совсем подготовленными, без Вашего багажа знаний. Они будут стараться, постигать новые знания, биться головой в определенные барьеры, обходить трудности (как я думаю делали все независимо от структуры приобретения знаний и опыта) И они неминуемо будут сталкиваться с теми самыми проблемами с которыми сталкивался я. По этому у меня возникла идея зарегистрироваться на Хабре. Что бы я мог делиться приобретенными знаниями и взаимодействовать с гораздо более опытными людьми. Но я думал, что разговор будут конструктивным, а не с непонятными подозрениями в непонятных задачах. Но я все еще хочу услышать вашу теорию )) заинтригован. Интересно в чем же моя задача? ))
treblereel
19.02.2026 00:09Ok. Один из важных плюсов хабра это высокая (я надеюсь) экспертность пользователей. Здесь плохо заходят статьи которые многокрастно пережовывают уже написанное, с пафосом пересказывают очевидное и тд. Я не про Вашу статью, а в целом.
В использовании большого количества агентов нет ничего нового, много кто с этим работает. Понятно, что собрать агентов в некоторый workflow задача достаточно простая, как и использовать это для запуска тестов. Это очень не сложно.
Я думаю, в этом состоит реакция на вашу статью.
ps: за ваш доброжелательный стиль прям огромный респект, без шуток.FoxProFlow Автор
19.02.2026 00:09Спасибо, это очень полезный фидбек. Если workflow агентов сам по себе не новость, значит ценность нужно показывать не словами, а конкретикой. Я могу ошибаться, но по моим наблюдениям проблема сейчас не в агентах, а в том, как сделать контур воспроизводимым, чтобы изменения проходили проверки, не ломали соседние части, и результат можно было доказать артефактами (а не на глаз). Следующий пост сделаю как микро-кейс проблема - проверки - evidence - выводы (на синтетике, без секретов). Если подскажете 2–3 пункта, что именно в таком кейсе важно показать, что будет интересным и полезным другим людям, буду благодарен.
SolidSnack
19.02.2026 00:09проблема сейчас не в агентах
Дак вот именно что в агентах, это же они ломают свой же код)
Как вы хотите формализовать требования чтобы ии тестировал функционал сайта, например? Мне вот вообще не понятно)
По моему у вас эффект Данинга-Крюгера, кайфуете от первых шагов, но преподносите это как какую-то экспертность.
SolidSnack
19.02.2026 00:09Я лично думаю что - выйти на доход какой-то, а когда эта тема утихнет (или трансформируется в то что прогеры без ИИ будут переделывать слоп проекты) переключиться на что-то другое.
Если бы вы любили код, вы бы и без ИИ начали писать.
FoxProFlow Автор
19.02.2026 00:09Вы не правы. Но эта тема философская больше. На Хабре невозможно зарабатывать. На Хабре можно только стать кому то полезным выкладывая какую то полезную информацию. И я понимаю, что однозначно с оговоркой, что информация должна быть полезна. Судя по отзывам вижу, что не полезна ))) без обид. Я все понимаю и всех понимаю, больше писать не буду ))). Зарабатывать надо всем, но для этого есть другие ресурсы и площадки.
SolidSnack
19.02.2026 00:09Зарабатывать на прогерстве с ИИ, где-то на хабре был человек который очень рад что нашёл своего клиента под ии генерацию.
Мне кажется вы человек позитивный, не воспринимайте ничего лично, это все только с профессиональной, конкретной стороны.
FoxProFlow Автор
19.02.2026 00:09С профессиональной, конкретной лучше бы чего то подсказали дельного)). И вы правда не правы. Я влюбился в код, когда начал с ним взаимодействовать ))) это невероятный плацдарм для творчества!
SolidSnack
19.02.2026 00:09А что тут подскажешь, перестаньте маяться иишными делами и возьмите кисть в свою руку, чтобы это стало творчеством) А пока вы в полной зависимости.
Ну и называть статью что вы построили производство кода без команды, достаточно самоуверенно, этот момент бы тоже подправить)
FoxProFlow Автор
19.02.2026 00:09Не, писать буду ))) но больше наверное с конкретными проблемами и разборами. И лишний раз людей не тригерить и опыт профессионалов как не крути незаменим.
SolidSnack
19.02.2026 00:09Хабр любит код, конкретику, что можно не только прочитать, но и проверить самому. Ну кроме всяких архитектруных статей, тут ИМХО тоже поле не паханое)
Приносите что-то конкретное да, и полезное, вот определить что полезно будет для разработчика не разработчику, мне кажется, тяжело. Да и каждому разработчику свое полезно)
Я бы вот про WebGL почитал например с радостью что-то интересное, но нейронки, вроде, пока плохо в нем варяться)
FoxProFlow Автор
19.02.2026 00:09Видение процесса и продукта я не взял из ИИ. Оно выросло из практики: почти год я строю конкретную систему, сталкиваюсь с конкретными багами, регрессами, несостыковками и пытаюсь их минимизировать. Я не утверждаю, что у меня есть 15 лет индустриального опыта. У меня его нет. Поэтому я и сделал ставку на формализацию процесса - чтобы компенсировать отсутствие данной глубины. Если вы опытный инженер и для вас часть этого процесса избыточна, то для меня это способ лишний раз перепроверить и успокоить себя. Если фундамент хромает, прошу объяснить в чем.
SolidSnack
19.02.2026 00:09Но вы же строите с помощью ИИ все это, разве нет?
Для меня ошибка - перекладывать работу на непонятную машину с огромной вероятностью рандома, вместо самосовершенствования.
Несостоятельность ИИ уже стали прикрывать rag, берём количеством ИИ (был 1 бредогенератор, стало 10) Тем что надо не llm, а agimegaiq архитектуру...(только никто не знает что это)
Мне лично супер лень разбираться в коде который мне сыпет ИИ. Самому написать проще и сразу все понятно, а копаться в чужом коде, ещё до ИИ, всегда было не самой приятной работой)
FoxProFlow Автор
19.02.2026 00:09Я не перекладываю работу. Я работаю сам. Я точно так же разбираюсь в языковых особенностях, точно так же изучаю массу информации и постигаю нюансы на практике. Просто способ получения и интеграции информации разный. Нейросеть это не волшебная кнопка. И да, я понимаю что это не та глубина постижения языков программирования когда ты на них думаешь. И нейросеть не построит за вас систему (по крайней мере не сейчас) максимум что она может это сгенерировать код файла и то, если ты дашь понятный и правильный промт. И даже в таком случае, она может галлюцинировать...
SolidSnack
19.02.2026 00:09Я точно так же разбираюсь в языковых особенностях, точно так же изучаю массу информации и постигаю нюансы на практике.
Ну вот, давайте проверим, скажите вы знаете различие между ссылкой и указателем в C++?))
Вручную перекладывали биты по регистрам в ассемблере?))
Я вот это все делал на 1 курсе, и заканчивался он курсовой на С++, что-то я помню до сих пор, и вообще как основу он мне очень много заложил, для меня его синтаксис и ООП супер удобны (python вообще не для меня, как и lua)
Вы можете этим всем за год похвастаться, в параллели с изучением высшей математики?)
FoxProFlow Автор
19.02.2026 00:09Я не из лагеря покроем тестами - багов не будет. Тесты - это фильтр регрессии, а не гарантия отсутствия ошибок. Они уменьшают поверхность риска, но не отменяют инженерное мышление. Что касается “промпт-инженеров” и “прогеры не нужны” - я к этому отношусь скептически. Без понимания архитектуры, данных, потоков и ограничений модель легко генерирует уверенную ерунду. Автоматизация ускоряет цикл. Понимание системы остаётся обязательным. Без понимания системы и рабочих процессов на данный момент времени невозможно сделать что то рабочее и достаточно воспроизводимое. Нейросети галлюцинируют довольно сильно. Но надо воспринимать как факт, нейросети развиваются просто с невероятной скоростью. И то что сейчас вообще стало возможным при помощи них, год назад казалось ну по крайней мере мне невероятным.
SolidSnack
19.02.2026 00:09Если честно по тестам у меня нету однозначного мнения. Можно и без них написать хорошо рабочую систему без багов, это не панацея.
По поводу эволюции ИИ - может толстосумы поняли что можно ещё раз погреть народ на новых технологиях? Low-код платформы были, IDE разработчиков создали, распилили все монолиты на микросервисы (как в гугле кстати), видели это и не 1 раз...
Вам легко рассуждать про эволюцию ИИ, вы же не вкидывали в неё миллионы (если не миллиарды) долларов. Инвесторы, по моему, не так воодушевленны такой автоматизацией, по крайней мере начинают прозревать)
FoxProFlow Автор
19.02.2026 00:09Да можно все, безусловно! Тесты отнюдь не панацея! И однозначно с хорошей командой профессионалов, особенно если домен узкий и все держится в головах, можно запилить и без тестов. Но я еще раз акцентирую внимание на том, что я пришел в программирование не совсем традиционным (наверное) способом. И данным уровнем знаний, что бы пилить системы без тестов не обладаю. Я это признаю и не бью себя в грудь, что могу что то чего не могу )). Тесты мне необходимы как способ снизить риск регрессии. Это один из самых воспроизводимых способов. Про инвесторов, если честно не очень понял. Да и миллионов у меня нет, что бы вкидывать, пусть об этом думают те у кого они есть )))
SolidSnack
19.02.2026 00:09Здесь ведь разговор не только про вас, а про совокупность "вас" и ИИ.
По поводу денег - ну вы не замечаете сколько денег было соженно в топке ИИ чтобы подтянуть её выдачу (дай бог индуса не посадили вам отвечать)
treblereel
19.02.2026 00:09| который 50–200 раз гоняет код,
эмм, Вы хоть раз искали баг в коде?FoxProFlow Автор
19.02.2026 00:09Думаю, что суть была понятна. Это не рандомный перебор, это повторяемый цикл гипотиз проверок и результатов. Цифры поставлены условно для понимания что это много и долго зачастую
treblereel
19.02.2026 00:09| много и долго
Баги бывают разные, есть долго и много, а есть сразу понятно в чем дело. Не стоит генерализировать
0xBAB10
19.02.2026 00:09отличие подхода “весело генерим код” от подхода “мы строим систему, которая живёт годами”
боже чел.. нейро-кал хайпует от силы годик-два. вот когда этот кал проживет 5-7-10 лет в режиме активной разработки и поддержки, вот тогда и расскажете про систему живущую годами
SolidSnack
19.02.2026 00:09Не знаю кто хайпует хотя-бы годик, вчера только статья была как ИИ слил бирже 2 млн баксов)
0xBAB10
19.02.2026 00:09дак биржи для того и существуют чтоб обувать лохов, можно подумать "классические" трейдинг боты не сливают миллионы
SolidSnack
19.02.2026 00:09Там не торговый бот был, а какая-то нейронка (клауди, если не ошибаюсь) неправильно рассчитывала стоимость лота в коде и как итог люди покупали сильно ниже рынка)
FoxProFlow Автор
19.02.2026 00:09)) я пробую, стараюсь, пока живет. Как только проживет 5-7 лет, надеюсь вернемся к диалогу )) но я правда стараюсь сделать на года, проверяемо и доказуемо. Здесь только время рассудит.
K_P_A_H
19.02.2026 00:09В целом высказанные идеи выглядят конструктивно. Но я не специалист в области программирования. ) но может в этой оценке оно и к лучшему. Конечно все это надо прокручивать к конкретным реалиям. Где-то в чем-то может и будет эффективно. Но не менее интересно где и почему неэффективно! И это принципиальное различие в подходе к выложенной информации.
noidol
19.02.2026 00:09Крч, ИМХО конечно, но всё вроде строго и корректно написано. Пусть и прогнали через нейронку. Кто на Хабре сейчас с чат-ботами не общается. Нонсенс же)) Возможно (гипотеза), что такая реакция на "Ваши" мысли из-за некоего такого флёра надменности в тексте. Типа, давайте общаться как инженер инженеру, Я многое сделал/добился, и готов Тебя научить, можем даже подискутировать. Вроде и нет токсичности, но есть послевкусие))) Возможно это и послужило такой реакцией на статьи. Раннюю Вашу статью не читал. Здесь в комментариях мнения тоже различные. От Меня, лишь удачи пожелаю в любых начинаниях!)
onyxmaster
Может хоть свои мысли без переписывания моделью научитесь выражать, товарищ Архитектор? Всё под копирку -- нумерованные разделы, в них короткие утверждения, с двоеточиями и буллет-списками для подтверждения...
FoxProFlow Автор
Ок, сигнал понял. Я правда использую автоматизацию при подготовке текста, но ключевой критерий для меня — проверяемость и доказуемость. Вижу, что подача считывается как “шаблонная” — это моя ошибка по форме. Абсолютно все мысли мои и статья написана полностью мной лично, автоматизирована только финальная доводка. Учту на будущее, что финальная доводка статей нейросетью на Хабре не приветствуется.
onyxmaster
Вы спрашивали что не так в предыдущих постах, но когда вам указывают вы становитесь в защитную позу со значительной дозой агрессии.
Ещё и редактируете свои ответы потом чтобы резко изменить свою тональность, в исходном вашем тексте было «почему я должен сам мудохаться несколько дней с текстом, проверять все на орфографию». Потому что это уважение к читателю, а если вам нужно выверять орфографию, то письмо это не ваше, не пишите просто и всё, идите в сантехники, говорят это новые программисты по уровню дохода. Написание статей это работа, а «идей по мультиагентной оркестрации» может кто угодно набрать себе 100500 штук пообщавшись часа 2 с Клодом.
Тоже мне, непонятый носитель сверхценного знания, угнетаемый ИИ-фобами…