Мы привыкли видеть Telegram как список чатов и каналов на своём устройстве. Но это лишь малая часть большой экосистемы, ограниченная подписками каждого пользователя. А как выглядит вся экосистема целиком? Эта статья — о том, как мы провели масштабное исследование контента Telegram и разработали интерактивную карту с 500 000 каналами.
GigaCode vs SourceCraft Code Assistant: что выбрать аналитику в 2025?
Сравнил две российские AI-IDE по критериям, важным не разработчику, а аналитику: работа с документами, контекстное окно, агентный режим, бесплатные квоты. Плюс пошаговые инструкции — от регистрации до первого запроса в чате.
SourceCraft: 3000 предложений + 1000 чат-запросов в неделю бесплатно, лимиты прозрачны.
GigaCode: бесплатен для пользователей GitVerse, квоты не публикуются.
Бонус: таблица соответствия концепций Roo Code → российские платформы. Для тех, кто читал мои предыдущие статьи и хочет применить подходы на одобренном стеке.
Каждый РП стоял перед выбором: запускаем методом "Большого Взрыва" или попробуем "Работать с двух системах" - Parallel Running.
Кто не знаком с методологией:
Большой взрыв. Останавливаем "старую" систему и запускаем новую. Старую - вот прям останавливаем, чтобы не было соблазна вернуться или вести часть бизнес-процессов в "старой" системе. Очень жесткий запуск: новая система непривычна, люди путаются, работа в системе кардинально замедляется, куча ошибок. Внедряющая команда на стрессе, полностью в полях: научить, подсказать, исправить и - главное - доработать! Увидите седого РП - попросите рассказать парочку примеров из его жизни.
Отбор кажется точным, пока мы не задаёмся вопросом,
кого он вообще не увидел.
Введение. Вопрос, который возникает снова и снова
Под моей первой статьёй про современный найм несколько раз прозвучал один и тот же вопрос:
Зачем вообще разбираться в том, как устроен найм, если очевидно, что он не работает и скоро обязательно “поправится”?
Этот вопрос звучит рационально. Если механизм кажется неэффективным, появляется ожидание: либо его скоро исправят, либо заменят на другой. Хочется надеяться на лучшее.
Но это ожидание часто оказывается обманчивым. На практике сложные системы — и рынок найма в том числе — почти никогда не меняются сами по себе. Чтобы понять почему, важно сначала разобраться, откуда вообще берётся ожидание, что «скоро всё будет иначе».
Сотрудники и студенты Московского Энергетического Института изучили и провели анализ различных способов остановки электрических двигателей, в данном случае мы расскажем вам про метод останова двигателя противовключением.
· В чем заключается данный метод?
Данная схема предназначена для быстрой остановки электродвигателя. Она работает таким образом, что, когда мы хотим остановить наш двигатель, вращающийся в одну сторону, мы начинаем вращать его в противоположную таким образом замедляя его движение и приводя к останову. Таким образом противовключение значит, что мы включаем наш двигатель в обратную сторону – в противоположную.
ERP-системы непрерывно развивались с самого начала своего создания. Но их архитектура до сих пор опирается на принципы, сформулированные до эпохи повсеместного распространения данных в реальном времени и развития автономного агентного искусственного интеллекта.
Соответственно, можно с утверждением говорить, что текущая архитектура ERP-систем не отвечает современным вызовам. В этой статье разберем, почему ей нужен принципиально иной фундамент. Я предлагаю строить его на трех китах: семантический слой данных (USDL), открытая интеграционная среда и продвинутая мультиагентная платформа (AMAP).
Далее я подробно представлю архитектуру такой ERP-системы, типы AI-агентов и примеры их работы в реальных бизнес-процессах. Ключевая идея — гибкая автономия под контролем человека. В статье я опираюсь на актуальные разработки и аналитику 2025 года, чтобы показать и возможности, и подводные камни мультиагентных систем в корпоративной ИТ-среде.
В 2026 году мы уже понимаем, что одна LLM (даже GPT-5 или Claude 4.5) не может быть идеальным судьей в один проход. Сейчас используются агентные системы, которые сначала декомпозируют ответ, проверяют факты через инструменты (поиск, код), и только потом выносят вердикт.
Пока дел немного, юридический процесс кажется управляемым: статусы, отчёты, дедлайны.
Когда дел становится десятки тысяч, выясняется, что статусы не показывают процесс, а KPI не помогают управлять.
В статье — как мы перешли от статусов к событийной модели и что это дало.
Как мы уже обсудили в предыдущей части, роль фазы предпроектного исследования заключается в обосновании целесообразности создания целевой Информационной системы (ИС). Таким образом в результате стадии должно сложиться понимание о совокупности трех базовых составляющих производства ИТ-продукта:
1) Потребность в его создании. Кому-то он действительно нужен, кто-то получит разумные выгоды от его использования.
2) Возможность его создания. Кто-то может его реализовать, в обозримые сроки, используя определенные технологии.
3) Возможность финансирования его создания. Кто-то сможет оплатить все стадии производства.
При этом проведение самой фазы Инициации и анализа чаще всего является инвестицией, которая окупится (иногда с лихвой) в случае не наступления высоковероятных рисков неблагоприятных исходов производства (организационных, технических, неактуальных требований, сроков, обеспечения качества и безопасности, финансовых и прочих). Другими словами, стадия направлена на снижение уровня неопределенности результата производства и избегания необходимости внесения изменений уже в ходе реализации и внедрения.
Первое упоминание компьютерной программе было сделано практически век назад и датировано еще далеким 1833 годом. С тем пор были изобретены множество языков программирования, начиная от машинных и до современных C++, Java, Python. Постепенно понимание и сложность компьютерных программ менялось: если ранее максимальное внимание уделялось алгоритму, то сейчас в комплексных программных приложениях, акцент смещается в сторону данных. Изобретены множество прикладных методов внедрения информационных систем, которые по существу являются производными от трех классических моделей имплементации. Однако, неоспоримым является тот факт, что любая программа в первую очередь должна покрывать исходные потребности пользователей. Данная истина зачастую теряется рутинных активностях разработки приложений и их внедрения.
Множество литературных источников описывают подходы и методы анализа бизнес-требований [1-3], забывая то, что они не могут «жить» независимо. Требования являются важным элементом жизненного цикла программного обеспечения, именно с их формулирования начинается проработка концепции будущего программного продукта. Механизмы теории дизайн-мышления помогают сформулировать требования, если изначально пользователи не могут их озвучить. Получается, что требования – отправная точка разработки любого софтверного продукта, чем качественнее ведется их обработка, тем более управляемым становится проект реализации приложения.
Цель данной работы состоит в анализе жизненного цикла требований к программным продуктам для обеспечения эффективного внедрения коробочных ERP-решений в приемлемые сроки, с заданным уровнем качества и фиксированными затратами. Достижение указанной цели потребует реализации следующих задач:
/tl;dr
Бизнесу нужны рубли и проценты, а не слова про «выявление требований». Аналитик не кодит и не продаёт — как доказать, что он вообще что-то даёт? Цифрами.
Минимум метрик: трудозатраты на требования, доработки после релиза, конверсия, средний чек, время отклика бизнеса, ROI аналитики. Начните с двух–трёх — трудозатраты, баги, конверсия. Остальное добавите позже.
Сравнивать только «было» и «стало»: один и тот же функционал до и после переделки с аналитиком (например, при смене API). Иначе «задачи разные», «сезон другой» — и ваши цифры списывают на совпадение.
Зафиксируйте базовый период, нормализуйте цифры (на релизы, команду, сложность), постройте тренд и переведите эффект в рубли. Один график «до/после» сильнее десяти слайдов про «мы поработали хорошо».
ИИ и инструменты тоже измеримы: путь от требований до ТЗ сократился вдвое — считайте экономию в часах и рублях на фичу. Подставьте свои цифры — получите конкретный финансовый эффект.
Метрики — не способ оправдаться, а способ показать вклад аналитика и улучшать процессы. Сначала измеряй, потом убеждай.
Корпоративные стандарты АСУ ТП часто считают бюрократией: «ещё один документ, ещё больше рамок для инженеров».
На деле отсутствие стандарта — это настоящий «зоопарк»: разные ПЛК, разные библиотеки, разные теги, разные подходы к диагностике. Проекты плывут по срокам, простои растут, цифровизация упирается в хаос данных, а зависимость от «того самого инженера» становится критической.
Nestlé, Bosch, GM и другие уже давно инвестируют в стандарты — не ради моды, а потому что это реальные деньги:
В статье разбираю механизмы, которые превращают стандарт из бумаги в работающий актив: библиотеки блоков, генераторы кода, копирование сигналов, контроль версий.
Меня зовут Никита, я ведущий инженер‑программист финансового маркетплейса «Выберу.ру». Этой статьей я хочу предотвратить распространение мифа о том, что Цифровой профиль переходит в офлайн-режим взаимодействия из-за перехода с REST API на СМЭВ.
Статья будет полезна больше не столько разработчикам, сколько менеджерам финансовых организаций. Ибо разработчики и сами разберутся, но скромно промолчат. Тогда как менеджеры с умным видом продолжат повторять ерунду.
Основная мысль статьи в том, что нет никакой офлайн-версии Цифрового профиля в процессе удаленной выдачи займа.
Сегодня задача очень простая: надо в карточке контрагента добавить флаг «Работает с НДС». Ну, тут всё просто. Открываю Axure, иду на страницу редактирования контрагента и вставляю там чек-бокс между полями «ИНН» и «Заметки».
Опытные разработчики сразу по картинке увидят, в чём косяк такого решения. А я вот что-то зазевался. И пошёл дальше, в карточку контрагента…
Продолжение статьи о продуктовой гипотезе и дистрибуции. Здесь — только инженерная часть.
Эта статья — инженерный рассказ о том, как из набора разрозненных back-office продуктов выросла единая B2B SaaS-платформа.
Мы показываем путь от требований и прототипов до микросервисной архитектуры, объясняя не только что было сделано, но и почему именно так.
Начало всех начальных начал
Добрый день, уважаемые хабропоселенцы ;)) Сегодня мы будем говорить, снова о хакатонах и разработке RAG-моделей, вернее моделей с RAG-подходами и наших попытках выйти за рамки простого векторного поиска. Не так давно мы участвовали на всероссийском хакатоне “Альфа-Будущее”, организованным Альфа-Банком и посвящённому настройке RAG для вопросно-ответных систем.
Нам необходимо было создать интеллектуальный pipeline RAG-системы, которая по пользовательскому запросу находит релевантные фрагменты в корпусе данных. Вообще, было на выбор две задачи, вторая звучала как “Разработка copilot приложения для клиентов микробизнеса”, но нам ближе оказалась вторая задача. И, конечно же, мы “запилили” своё “модное” решение, о котором вам спешим рассказать в этой статье. Мы проиллюстрируем, как выстраивали архитектуру, какие модели тестировали, на чём остановились и почему, именно такой подход оказался для нас наиболее удачным. Покажем, как работает весь пайплайн — от чанкования документов до гибридного поиска и поделимся результатами бенчмарков и планами развития системы в дальнейшем. Всех заинтересованных лиц приглашаю по традиции под кат ;))
При работе в BIM-среде проектировщик не просто работает с геометрией, а взаимодействует с цифровой моделью, насыщенной данными. Параметры превращают набор линий и тел в осмысленный объект, способный участвовать в расчетах, спецификациях, проверках и выпуске документации. При этом, несмотря на то что параметры постоянно используются в повседневной работе, их роль зачастую воспринимается фрагментарно: как отдельных полей в свойствах элемента или источника данных для таблиц.
Попробуем последовательно разобраться, что такое параметры объекта, зачем они нужны и какую реальную роль играют на всех этапах жизненного цикла BIM-модели: от создания и редактирования элементов до выпуска рабочей документации в программе nanoCAD BIM Строительство.
Вы когда-нибудь задумывались, почему одни дашборды и графики мгновенно доносят мысль и запоминаются, а другие, перегруженные цифрами, вызывают только зевоту? В эпоху, когда любой график можно сгенерировать нейросетью за минуту, этот вопрос стал как никогда актуальным.
Сегодня мы расскажем о книге, которая учит не просто строить графики, а проектировать визуальные истории, способные увлечь аудиторию, будь то совет директоров или миллионы читателей онлайн. Это второе, полностью переработанное издание бестселлера «Искусство визуализации в бизнесе. Как представить сложную информацию простыми способами» от Натана Яу, автора культового блога FlowingData.
Привет! На связи команда Research & Insights Центра стратегии цифровых продуктов МТС. В прошлом году мы подготовили исследование мирового и российского рынка ИИ-агентов. Перед вами четвертая часть статьи об исследовании. В первой мы рассказали про интересные факты из него, во второй — про виды агентов, в третьей— про ситуацию в мире и России. А в этой раскроем детали будущего агентного ИИ: каким его видят исследователи и респонденты.
Большинство статей на Хабре про архитекторов написаны в жанре «как я туда попал и вам советую». Я расскажу, почему попадают не все, и кому лучше не пробовать. Ошибки в ожиданиях, самодиагностика, честный разбор.
