Pull to refresh

Comments 14

неплохая идея, на выходных скопирую

Если будете копировать - два места, где я потерял время зря:

Первое: не тратьте вечер на переменные окружения, если работаете в панелях одного окна редактора. Они делят окружение процесса, идентичности не получится.

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

Расскажите потом, что вышло.

не много не так. я утром в суботту тупо сделаю cmd+c cmd+v с вашего лендинга, скормлю гончим, вечером может потыкаю, может нет, в понедельник готовый saas отряхну от нейрослопа, полью человечьим вниманием, скажу ну "ну доделай давай". и все. продавать пойду... ну только сразу с апи вайлбиреза и еще амазаона и еще там чего в среду попрошу добавить .

«Скажу, ну доделай давай» 😄 вот на этой фразе и написана вся статья. Первые пару недель я ровно так и жил. Потом «доделай давай» упёрлось в окно на 678 МБ и 400 thinking blocks cannot be modified, и пришлось строить очередь.

WB API «попросить добавить в среду» звучит красиво, но по факту это будет пару недель сверки минимум: врать продавцу на его же деньгах нельзя. Амазон подождёт до четверга 😉

План хороший, серьёзно. Просто между «доделай давай» и работающим saas живут те самые 60 дней (а у когото и годы). Удачи в понедельник.

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

"Как я использовал 60 дней своей жизни впустую, а в итоге написал статью на Хабре и выпустил очередной AI стартап"

Вы надоели со своими агентами и ИИ настолько, что слов больше нет.

Механика с Blackboard на Markdown и хуками через session_id действительно интересная как локальный костыль для соло-разработчика. Но если разложить архитектуру по фактам, то получается, что вы открыли офис в ТЦ со "стеклянными стенами" и уперлись в явный технический тупик по трем причинам.

Безопасность и NDA тут бесконечно далеки от идеала. Вы пишете, что развиваете коммерческие B2B-продукты (SKUmind, ПатентСкан). Использование проприетарного Claude Code в облаке Anthropic означает, что при каждом хуке вся ваша бизнес-логика, структура БД, логи маркетплейсов и промпты улетают на сторонние сервера. Если вы планируете продавать софт серьезным компаниям, любая базовая СБ потенциального клиента мгновенно завернет ваши продукты за такую утечку исходных данных. Для коммерческого B2B-сектора разворачивать такое в облаке — как голым по улице ходить.

Второй момент — это лютый архитектурный оверхед и проблемы с Unit-экономикой. Вы подсовываете инбокс через хук при каждом сообщении. При росте кодовой базы и частых итерациях (те самые 1002 хендоффа) размер контекста и лога задач в Markdown-файле будет расти со свистом. Вы уже столкнулись со смертью окон из-за раздувания сессий до 678 МБ. Это произошло именно потому, что вы завязались на терминальный Claude Code (CLI), который тащит за собой гигантский лог размышлений и историю терминала, вместо того чтобы гонять чистые запросы напрямую через Anthropic Messages API в фоновом режиме. Механика сброса контекста спасает локально, но вы просто платите Anthropic огромные деньги за постоянную пересылку гигантского «мусорного» лога прошлых шагов.

Ну и автономность тут скорее иллюзорная, чисто менеджерская. Вы пишете про гибкий "уровень усилий" и то, что агент обязан "сказать вслух", если ему мало контекста. Но перекладывать оценку рисков на языковую модель — это огромная системная ошибка. ИИ не обладает сознанием, чтобы вовремя забить тревогу, особенно когда контекст сессии раздут. В итоге вся ваша автоматизация держится на том, что вы вручную одобряете апгрейды, переключаете окна между Opus и Sonnet руками и работаете диспетчером рубильников у 12 чат-ботов. Вы не автоматизировали разработку, а просто сменили роль маршрутизатора пакетов на роль микроменеджера для нейросетей.

Для пет-проекта — лайк за изобретательность. Но в реальном проде это тупик (Vendor Lock-in + раздувание контекста)

Если я оказался в чём то не прав - милости прошу к конструктивной критике, читал всё это после 15-ти часовой работы и мог упустить детали.

Спасибо, это первый развёрнутый технический разбор в треде и по делу. Пройдусь по трём пунктам. Где-то вы правы, где-то я, похоже, сам написал так, что читается криво.

Безопасность. Смешаны две вещи: чем я пишу код и куда текут данные клиента. Шина локальная, markdown и хуки на моей машине, носят описания задач, а не данные продавцов. В Anthropic при разработке уходит мой исходник, как у всех, кто пишет на Cursor или Copilot. А P&L и логи маркетплейсов клиента через шину и Claude Code не проходят вообще: продакшн на своём бэкенде, AI-вызовы в продукте идут через отдельного российского провайдера, разработку веду не на боевых данных. Клиентские данные при этом в РФ-контуре: и прод, и AI-провайдер российские, локализация ПДн по 152-ФЗ на нашей стороне закрыта, из российской юрисдикции они не уходят. СБ клиента смотрит, куда течёт ЕГО данные в продукте, а не в какой IDE писан код.

Оверхед. Хук инжектит не файл на 1002 задачи, а только open-строки конкретного агента, несколько штук; done не подаётся вообще. А 678 МБ это размер локального транскрипта сессии на диске, а не пейлоад, уходящий в API на каждом шаге: в запрос летит ограниченное контекстное окно, и оно кэшируется. Окно умерло по другой причине: долгая Opus-сессия накопила собственные thinking-блоки и на ресьюме уперлась в 400 thinking blocks cannot be modified. Лечится это той самой save-state. Повторяемый контекст идёт через prompt caching, чтение из кэша стоит порядка 10% обычного токена, так что старые шаги обходятся в десятую часть цены. Про «чистые запросы через Messages API»: как принцип верно, и для headless-оркестрации я бы так и сделал. Но окна шины это интерактивные dev-сессии, где агент читает файлы и гоняет тесты. Другой слой оркестрации.

Автономность. Тут вы правы, и я это в статье прямо написал, раздел «Чего здесь нет»: агента бужу руками, ночью 12 ролей не работают, это осознанный выбор. Effort-флаг это «агент подсвечивает, решение об апгрейде моё», а не делегирование оценки риска модели. И на суждение одной модели риск не завязан: деньги-критичный код проходит через веер независимых субагентов, обязанных опровергнуть находку. Те самые пять платёжных багов поймал механизм, а не сознательность нейросети.

Vendor lock-in. Зависимость от чужих API в принципе есть у всех, кто на них строит, спорить глупо. Но «тупик в проде из-за Anthropic» мимо: в продакшене в Anthropic не уходит ничего, продукт ходит к AI через российский коммерческий шлюз, данные в РФ-контуре, провайдер сменяем (и ротируемый). В облако Anthropic попадает только мой исходник при разработке, потому что код я пишу в Claude Code. Это моя IP и мой выбор инструмента, сменить IDE можно без единой правки в продукте. А шину я и так не продаю, это моя личная внутренняя оснастка и рабочий инструмент.

По пунктам 1 и 2, если есть чем возразить по фактам, послушаю с интересом.

Да ладно вам — этот ваш ответ по структуре, делению на блоки и вежливым реверансам до боли напоминает дефолтный аутпут Claude 3.5 Sonnet. Будет очень иронично, если за вас в тредах тоже отдувается агент, пока вы рубильники переключаете. Но если вернуться к коду и вашей статье, то вы сами же себя и поймали на крючок. Смотрите, в комментарии вы пишете, что оверхеда нет, всё кэшируется через prompt caching за 10% стоимости, а в API летит “ограниченное окно”. Но открываем ваш же текст: “сессия раздулась до 678 МБ, окна умерли с ошибкой 400 thinking blocks cannot be modified” Тут одно из двух: либо окно у вас контролируемое и маленькое, либо оно жрёт память сотнями мегабайт и падает. Claude Code — это терминальный инструмент. Он по определению копит весь лог интерактивной сессии (включая гигантские “мыслительные” блоки моделей), пока вы её принудительно не сбросите. И никакой промпт-кэшинг не уменьшает физический размер контекста, который модель обязана проглатывать целиком на каждом ходу. Кэш просто удешевляет чтение, но если сессия раздута до лимитов, она всё равно упадёт. И ваше “лекарство” в виде save-state, о котором вы пишете — это ведь костыль, ломающий вашу же архитектуру. Вы сами чёрным по белому признаёте в статье: “очистка контекста меняет session_id. Связка сессия-роль протухает… приходится заново руками вбивать имя роли”. То есть система не автономна, она регулярно деградирует от объёма кода, падает, и вам приходится заходить в консоль и руками работать реаниматологом для “умерших” чат-ботов. Какая же это шина координации? Это непрерывный ручной перезапуск. Про безопасность — аргумент про то, что СБ не смотрит в IDE, работает только до первого серьёзного аудита по цепочке поставок. СБ проверяет не только “куда текут данные клиентов на проде”. Их задача — гарантировать, что в сам код продукта никто не заинжектил бэкдор. Если ваш агент улетает в облако Anthropic вместе с проприетарной бизнес-логикой и структурой баз данных, а возвращается оттуда с кодом, который вы верифицируете силами другого облачного агента (веер скептиков) — вы построили идеальный чёрный ящик. Ни одна финтех-компания или крупный B2B-серьёзный игрок не пустит к себе софт, который пишется и проверяется внутри чужого контура без локального статического анализа (SAST/DAST) и жесткого контроля версий. Для соло-разработки и сборки MVP на коленке за выходные — это по-прежнему весело и изобретательно, тут спору нет. Но как только мы убираем маркетинговую обёртку про “1002 задачи за 60 дней”, под капотом остаётся хрупкий локальный скрипт, который требует вашего постоянного присутствия, ручного пинга агентов и регулярного вбивания команд руками из-за протухающих сессий. По факту, вы просто автоматизировали процесс написания кода, но кратно умножили затраты на менеджмент инфраструктуры вокруг него.

Почитал я вашу первую статью про “Консилиум из трех моделей-провидцев” и, честно говоря, теперь картинка сложилась. Стало абсолютно понятно, почему ваша вторая статья про “шину координации на markdown” вышла настолько хрупкой. Вы просто построили домик из соломы, эдакий Ниф-Ниф из сказки про поросят, в котором системные ошибки архитектуры из первой статьи маскируются костылями во второй. Давайте снимем маркетинговую чушь, которой вы пытались прикрыть эти костыли и посмотрим на голые факты (Раз любите структурированность клауда, напишу по вашей же архитектуре):

  1. Вы заменили математику филологией. Выкинуть BI-логику (жесткие формулы расчета P&L) и заменить её на “рассуждения” четырех LLM по каждому SKU — это фундаментальная инженерная ошибка. Финтех и юнит-экономика — это зона абсолютной математической точности. Нейросети не умеют гарантированно считать, они предсказывают токены. Заставлять Opus работать арбитратором над “сочинениями” трех субагентов ради вычисления маржи — это все равно что нанять четырех бухгалтеров-гуманитариев, которые вместо Excel будут определять прибыль компании по картам Таро. ИИ может генерировать текстовое саммари поверх готовых цифр, но считать саму базу на промптах в продукте, от которого зависят реальные деньги селлеров — это огромный риск галлюцинаций и не только.

  2. Экономическое самоубийство бизнес-модели. Гонять консилиум из четырех тяжелых топовых моделей индивидуально на каждое SKU, зная, что prompt caching у вас толком не завелся — это лютый оверхед. Если у среднего селлера 1000 товаров, то один еженедельный прогон — это 4000 холостых запросов к API Anthropic. Конкретные цифры себестоимости вы не приводите по понятной причине: счета от вендоров сожрут всю маржинальность вашего SaaS при первой же сотне реальных клиентов. Эта экономика просто не сойдется на дистанции.

  3. Рождение костылей из второй статьи. Теперь очевидно, откуда выросла драма с 12 окнами Claude Code и ошибками 400 thinking blocks. Поскольку вместо базы данных и нормального кода вы начали плодить терабайты текстового контекста, ваша система закономерно начала жрать память, раздуваться до 678 МБ и падать. И вместо того, чтобы переписать ядро на нормальном бэкенде, вы построили “шину на markdown”, наняли “веер скептиков” (чтобы один ИИ проверял бред другого) и теперь вручную работаете реаниматологом для упавших сессий, когда слетает session_id.


    Итог: Вы заигрались в AI-агентов ради самого процесса. Заменили математику текстом, слили ИБ-комплаенс, создали систему с огромной стоимостью поддержки и выдаете этот хрупкий инди-хакерский MVP за революцию в разработке. Для соло-проекта выходного дня это весело, но как коммерческая B2B-архитектура — это ужас, о котором стоит молчать.

По цифрам вы прочли не то и не так) Маржу и P&L считает как раз детерминированный код, а не LLM. Нейросеть у нас деньги не считает, они комментируют уже посчитанное. Это тот самый принцип, который вы отстаиваете, мы его и держим.

А вот дальше вы подняли настоящую тему. ИБ и LLM в контуре разработки, supply-chain, что реально проверяет СБ. И это не на нару слов в коментах, это на отдельную статью или пост. Подписывайтесь, следующий разбор хочу сделать как раз про это. Где в связке «LLM плюс разработка» настоящие риски, а где мифы. Попрошу коммент для статьи у senior-специалиста по DFIR (реагирование на инциденты, разбор malware, практика в США), чтобы был взгляд реального практика по безопасности, а только не фаундер-хайп. Ваши возражения по supply-chain там и разберём предметно.

Так, видимо, я совсем заработался, пока читал. То есть вся магия вашего "консилиума" моделей и арбитратора нужна только для того, чтобы превратить сухие цифры P&L-таблицы в текстовые подсказки? Это же классический карго-культ и забивание гвоздей микроскопом.

В нормальном b2b-софте предикативная аналитика и выдача рекомендаций (условно: "Реклама съела маржу, снизь лимит до 15%") пишется через банальный детерминированный код на условиях и триггерах. Это считается за миллисекунды, работает со 100%-й точностью и стоит ноль рублей в себестоимости. Вы же вместо этого построили систему, которая ради генерации текстового комментария вокруг готовых цифр гоняет мегабайты контекста через тяжелейшие облачные модели. Заставлять Opus и Sonnet работать "переводчиками с математического на русский" для каждой карточки товара — это экономическое самоубийство бизнес-модели. Ваши счета за API Anthropic сожрут всю маржинальность вашего SaaS при первой же паре сотен реальных клиентов просто ради того, чтобы нейросеть красиво "поговорила" о финансах Николая. Вы подменили копеечную автоматизацию на правилах дорогим литературным кружком.
Вся ваша "ИИ-Архитектура" из моделей-провидцев и арбитратора до боли напоминает Фильм "Матрица", Агент Смит, который бесконечно копирует сам себя. Это не консилиум независимых экспертов — это абсолютно одинаковые текстовые роботы, обученные на одних и тех же данных. Вы просто заставили одного цифрового Смита спорить в пустой комнате с другим таким же Смитом за огромные деньги, выдавая текстовый, литературный водопад на таблицу за "высший ИИ-разум"
При этом в самой b2b-аналитике маркетплейсов для ИИ есть тонна реальных, не соломенных задач, но они лежат в зоне филологии, а не калькулятора. Модели уровня Claude идеально подходят для качественного анализа тысяч отзывов конкурентов (чтобы вычленить скрытые боли покупателей), для автоматизации умных ответов на рекламации или для генерации SEO-оптимизированных описаний карточек. Там ИИ создает ценность. Но заставлять четыре тяжелые LLM читать показатели готового финансового отчета, чтобы выдать банальный совет, который бэкенд считает по триггеру if-then — это чистый фаундер-хайп ради питча перед инвесторами.

Что ж, за честное признание проблем с ИБ и Supply Chain — спасибо. Тема отправки проприетарного кода в облако американского вендора во время dev-сессий через Claude действительно слишком острая, чтобы закрывать её парой предложений в комментариях. Думаю, может, и подожду вашу статью с разбором от специалиста по DFIR...

Почему у вас в очереди закрытые задачи :-\

Хороший вопрос. Очередь заодно работает журналом: закрытая задача не удаляется, а помечается done и остаётся в файле. Так держится история - кто кому что передал, когда взяли в работу и когда закрыли. Живым агентам хук отдаёт только открытые, done лежит рядом как аудит-трейл: если что-то пошло не так, можно поднять весь тред и увидеть, где именно застряло. Разрастается медленно, места не занимает, старьё при желании выносится в архив.

Sign up to leave a comment.

Articles