Доброго времени!) Спасибо за разбор! Отказ от векторных БД в пользу zero-infra на малых масштабах - отличный подход. Вопрос по архитектуре: как вы решаете коллизии, когда на один description претендуют сразу 2–3 смежных Markdown-файла (например, общее правило и специфическое под проект)? Не начинает ли харнесс в этот момент галлюцинировать или дропать тела из-за лимитов контекста?
Абсолютно с вами согласен!) Именно в оркестрации и контроле скрывается вся магия, ведь блин по сути, написать длинный системный промпт могут многие, но под реальной нагрузкой он моментально захлебнется. И честно сказать на такую "проверку" которую вы описываете многие бы просто не взялись))
Рад, что мы поняли друг друга.) Что касается терминологии Enterprise: в контексте ИИ-агентов и LLM-интеграций этот уровень определяется не только миллионами конечных потребителей, но и требованиями бизнеса к отказоустойчивости, изоляции потоков данных, SLA, кастомной архитектуре и безопасности (вроде хостинга в контуре РБ и соответствия Закону № 99-З "закон о защите персональных данных" - т.к. у данного клиента идёт сбор телефонов, даты рождения и пр.). Когда no-code костыль падает от пиковой нагрузки, а кастомное решение на n8n + Redis держит поток и оцифровывает старую базу в реальном времени - для локального бизнеса это и есть технологический Enterprise-подход, решающий их боли. Может и понятия для бизнеса разное (где грань между энтерпрайз а где нет) - тут не поспорю, просто по опыту знаю , а если касаться данного кейса - то в такой нагрузке мало кто хотел на фрилансе браться). Но честно, сугубо назвал так не для самопиара уж точно).
В любом случае, спасибо за диалог, дискуссия вышла полезной!
Всем добра!) Я считаю - это очень круто, когда ИТ-команда понимает истинную ценность своей работы, не просто закрывать тикеты, а помогать врачам спасать жизни и делать этот мир чуточку добрее.)
Спасибо за статью!🦇 От души) Очень вдохновляющий эксперимент! Запуск MVP за полтора дня с девятью фичами и тестами - это мощный аргумент в пользу AI-first подхода. Ограничения с автомодом и тайм-менеджментом агентов вполне ожидаемы, но сама структура со стандартами и реестром ролей выглядит очень зрело; респект за смелость и крутую автоматизацию рутины!
Очень здравый подход с "рамкой" в самом начале. Без четкого разделения на явно вызванные функции и фоновый трафик любой разговор про приватность в IDE действительно быстро скатывается в панику уровня "всё пропало, код сливают". Понравился аргумент про то, что факт TLS-соединения или проверки обновлений - это еще не отправка исходников. Спасибо за крутую структуру, таблица с категориями отлично проясняет логику!)
Подписываюсь под каждым словом. Фраза про то, что "мы не слегка адаптировали систему, а фактически строили внутри универсальной системы отдельный новый продукт" - это главная боль любого масштабного внедрения!(
Ваш кейс наглядно доказывает: стабилизация процессов и грамотная специализированная архитектура в долгосроке всегда окупаются, снижая затраты на поддержку и избавляя команду от рутины !)
Уважаемый Vicollel! Спасибо за комментарий!) Суть вашего негатива мне, честно говоря, неясна. Либо вы пролистали статью по диагонали, заметив лишь один абзац, либо дело в чём-то другом.
Вы абсолютно правы в одном: клиенту действительно до фени, что там под капотом, ему нужно куртки продавать. Но ему точно не плевать, когда из-за кривого no-code конструктора его бот при первой же ночной распродаже шлёт покупателям глупые ответы невпопад, плодит дубли сделок в CRM и сливает рекламный бюджет на тройные токены.
шоурум - это лишь одна из локаций моего заказчика, само ателье работает с размахом на СНГ. И этот клиент обратился ко мне именно потому, что уже обжёгся на готовых платформах ботов. Ему как раз таки на практике было понятно, что такое дебоунс, ведь он своими глазами увидел эту "магию" в работе, когда система склеивает дробные сообщения, радикально экономит деньги на API и выдаёт клиенту один точный ответ вместо каши. Клиент платит инженеру за то, чтобы система РАБОТАЛА и приносила прибыль, а не жрала его ресурсы.
Любой разработчик обратил бы внимание на архитектуру и решение боли расходов заказчика, а не на умение красиво продавать себя. Отличие в том, что я продаю решение технической проблемы клиента, а не "успешный успех" из серии "вы нам должны заплатить, потому что мы много влили в пиар". Когда есть умение решать задачи бизнеса - сарафанное радио работает на ура. А вот когда навыков решать проблемы нет - тогда да, таргет в помощь. P.S. Ниже скрин, чтобы вы понимали масштаб "энтерпрайз"(с), привожу сухие цифры реальной нагрузки из логов только за неполный месяц на сегодняшний день (18 августа)
Доброго времени!) Спасибо за разбор! Отказ от векторных БД в пользу zero-infra на малых масштабах - отличный подход. Вопрос по архитектуре: как вы решаете коллизии, когда на один description претендуют сразу 2–3 смежных Markdown-файла (например, общее правило и специфическое под проект)? Не начинает ли харнесс в этот момент галлюцинировать или дропать тела из-за лимитов контекста?
Абсолютно с вами согласен!) Именно в оркестрации и контроле скрывается вся магия, ведь блин по сути, написать длинный системный промпт могут многие, но под реальной нагрузкой он моментально захлебнется. И честно сказать на такую "проверку" которую вы описываете многие бы просто не взялись))
Рад, что мы поняли друг друга.) Что касается терминологии Enterprise: в контексте ИИ-агентов и LLM-интеграций этот уровень определяется не только миллионами конечных потребителей, но и требованиями бизнеса к отказоустойчивости, изоляции потоков данных, SLA, кастомной архитектуре и безопасности (вроде хостинга в контуре РБ и соответствия Закону № 99-З "закон о защите персональных данных" - т.к. у данного клиента идёт сбор телефонов, даты рождения и пр.). Когда no-code костыль падает от пиковой нагрузки, а кастомное решение на n8n + Redis держит поток и оцифровывает старую базу в реальном времени - для локального бизнеса это и есть технологический Enterprise-подход, решающий их боли. Может и понятия для бизнеса разное (где грань между энтерпрайз а где нет) - тут не поспорю, просто по опыту знаю , а если касаться данного кейса - то в такой нагрузке мало кто хотел на фрилансе браться). Но честно, сугубо назвал так не для самопиара уж точно).
В любом случае, спасибо за диалог, дискуссия вышла полезной!
Всем добра!) Я считаю - это очень круто, когда ИТ-команда понимает истинную ценность своей работы, не просто закрывать тикеты, а помогать врачам спасать жизни и делать этот мир чуточку добрее.)
Спасибо за статью!🦇 От души) Очень вдохновляющий эксперимент! Запуск MVP за полтора дня с девятью фичами и тестами - это мощный аргумент в пользу AI-first подхода. Ограничения с автомодом и тайм-менеджментом агентов вполне ожидаемы, но сама структура со стандартами и реестром ролей выглядит очень зрело; респект за смелость и крутую автоматизацию рутины!
Доброго времени суток! 🦇
Очень здравый подход с "рамкой" в самом начале. Без четкого разделения на явно вызванные функции и фоновый трафик любой разговор про приватность в IDE действительно быстро скатывается в панику уровня "всё пропало, код сливают". Понравился аргумент про то, что факт TLS-соединения или проверки обновлений - это еще не отправка исходников. Спасибо за крутую структуру, таблица с категориями отлично проясняет логику!)
Спасибо за шикарную и честную ретроспективу! 🦇
Подписываюсь под каждым словом. Фраза про то, что "мы не слегка адаптировали систему, а фактически строили внутри универсальной системы отдельный новый продукт" - это главная боль любого масштабного внедрения!(
Ваш кейс наглядно доказывает: стабилизация процессов и грамотная специализированная архитектура в долгосроке всегда окупаются, снижая затраты на поддержку и избавляя команду от рутины !)
Уважаемый Vicollel! Спасибо за комментарий!) Суть вашего негатива мне, честно говоря, неясна. Либо вы пролистали статью по диагонали, заметив лишь один абзац, либо дело в чём-то другом.
Вы абсолютно правы в одном: клиенту действительно до фени, что там под капотом, ему нужно куртки продавать. Но ему точно не плевать, когда из-за кривого no-code конструктора его бот при первой же ночной распродаже шлёт покупателям глупые ответы невпопад, плодит дубли сделок в CRM и сливает рекламный бюджет на тройные токены.
шоурум - это лишь одна из локаций моего заказчика, само ателье работает с размахом на СНГ. И этот клиент обратился ко мне именно потому, что уже обжёгся на готовых платформах ботов. Ему как раз таки на практике было понятно, что такое дебоунс, ведь он своими глазами увидел эту "магию" в работе, когда система склеивает дробные сообщения, радикально экономит деньги на API и выдаёт клиенту один точный ответ вместо каши. Клиент платит инженеру за то, чтобы система РАБОТАЛА и приносила прибыль, а не жрала его ресурсы.
Любой разработчик обратил бы внимание на архитектуру и решение боли расходов заказчика, а не на умение красиво продавать себя. Отличие в том, что я продаю решение технической проблемы клиента, а не "успешный успех" из серии "вы нам должны заплатить, потому что мы много влили в пиар". Когда есть умение решать задачи бизнеса - сарафанное радио работает на ура. А вот когда навыков решать проблемы нет - тогда да, таргет в помощь. P.S. Ниже скрин, чтобы вы понимали масштаб "энтерпрайз"(с), привожу сухие цифры реальной нагрузки из логов только за неполный месяц на сегодняшний день (18 августа)