Программисты делают бизнес

KTS × Selectel создали ИИ-поиск для компаний, где каждый ответ нужно подтвердить документом В строительстве, производстве, добывающей отрасли и финансах сотрудники работают с большими массивами регламентов, ГОСТов и внутренних документов. При подготовке отчёта, прохождении проверки или аудита данные приходится искать в нескольких системах и сверять с первоисточниками. На это может уходить до нескольких часов в день. Совместное решение KTS и Selectel помогает значительно сократить время поиска информации. Сотрудник задаёт вопрос на естественном языке и получает структурированный ответ со ссылкой на документ и конкретную страницу. Также ассистент умеет: — подключаться к wiki, СЭД, файловым хранилищам и нормативным источникам; — суммаризировать длинные документы; — выделять тезисы, обязательства и риски; — экспортировать ответы в Word и PDF; — учитывать права пользователей через системы управления доступом (IAM и SSO). Безопасность заложена в архитектуру решения на нескольких уровнях. Система автоматически маскирует чувствительные данные, а встроенные механизмы контроля (guardrails) проверяют запросы и ответы ИИ на соответствие заданным политикам безопасности. ИИ-ассистент может закрывать большинство рутинных типовых запросов. Благодаря готовой инфраструктуре KTS AI Platform пилот можно запустить за две недели. Проверьте решение на собственных документах: загрузите их в настроенную базу знаний и оцените качество ответов. Протестировать ИИ-ассистента

Как меняется работа аналитика в AI SDLC В прошлом посте про AI SDLC я писал, что основной прирост эффективности даст не автоматизация отдельных задач, а перестройка всего конвейера разработки. Продолжу эту мысль на примере работы аналитика. Недостаточно сохранить прежний процесс и просто ускорить его с помощью Cursor, Claude или другого инструмента. Так делают все. Преимущество появится там, где AI меняет не скорость отдельных действий, а сам порядок работы. Нужно смотреть на каждый этап и спрашивать: а должен ли я вообще здесь включаться? Сейчас стандартная схема выглядит так: сначала ты думаешь, что и как будешь делать, а затем приступаешь к работе. Но порядок можно изменить. Сначала отдать задачу агенту, получить готовый артефакт, а потом проверить его и при необходимости отправить на доработку. То есть не читать ничего сырого, а работать уже с готовой версией. Этот эффект будет усиливаться с каждой новой моделью: они становятся умнее и получают больше контекста. Возьмём спецификацию. Здесь есть два сценария. Первый: самостоятельно разобрать постановку заказчика, дополнить её и подробно описать требования. Второй: передать модели исходную задачу, посмотреть, что она предложит, и уже потом доработать получившийся вариант. Раньше первый сценарий считался правильным, потому что переделывать было дорого. Сейчас стоимость итерации снижается. Если человек продолжает тратить силы там, где можно сначала получить черновик от модели, он просто теряет время. Чем умнее становятся модели и чем больше контекста у них появляется, тем чаще они смогут предложить вариант лучше того, который человек сформулирует на старте. AI меняет сам порядок действий. Работа аналитика при этом не исчезает. Аналитику всё ещё нужно собрать контекст, понять задачу и проверить решение. Но начинать с чистого листа теперь необязательно. Сильнее будет тот процесс, в котором человек подключается там, где действительно нужен: направляет модель, валидирует готовый результат и отправляет его на следующую итерацию. #максим_павлов 😀 #менеджментkts

❗️Осторожно: мошенники подделывают вакансии KTS Они предлагают работу, а затем просят установить программу, которая крадёт данные. К KTS эти предложения отношения не имеют. Установка подозрительных программ в тестовое задание не входит. Мы не просим кандидатов передавать пароли, коды из СМС, данные банковских карт или доступ к устройству. А вот настоящие вакансии у нас действительно есть: смотрите их на hh.ru. Если вы не нашли подходящую, не грустите и расскажите о своих талантах напрямую нашему HR-отделу: @kts_hr_talent_bot. Берегите данные, откликайтесь или перешлите этот пост тем, кто сейчас ищет работу.

Как геймификация помогает вовлекать сотрудников? Разберем на примере Ozon fresh 📦 Корпоративный праздник — отличный повод поздравить команду, а заодно прокачать её вовлечённость. Ко Дню работников склада мы с Ozon fresh и первым агентством внимания ЦЕХ за 3,5 недели запустили лендинг с игровой механикой. Что работало на вовлечение: 🔵 Постепенное усложнение. С каждым уровнем рос темп, сохраняя азарт до самого финала. 🔵 Прогрессия. За каждую победу игрок получал новый элемент экипировки персонажа. 🔵 Нативное обучение. Вместе с продуктами игроки собирали алмазы, которые открывали факты о складах Ozon fresh. Так знакомство с компанией вплели прямо в геймплей. 🔵 Статусы и вызов. В финале каждый получал звание — от «Стажёра» до «Легенды склада». Забрать высший статус могли только те, кто прошёл игру без ошибок и собрал все алмазы. За месяц игру прошли почти 2 000 участников, каждый четвертый возвращался снова, а средняя длительность игровой сессии составила 4 минуты.

Два Kubernetes-кластера вместо 35 виртуалок: как мы перестроили инфраструктуру Лазурита Продолжаем рассказывать про DevOps-проекты. Сегодня делимся историей крупного мебельного ритейлера «Лазурит».  Инфраструктура компании годами росла вокруг текущих бизнес-процессов: обработки заказов, распределения звонков, расчёта сроков доставки. Сервисы жили на отдельных виртуальных машинах, рядом лежали базы данных, бэкапы хранились на одном сервере. За мониторинг отвечал подрядчик, и доступ к метрикам шёл через его VPN.  Такая инфраструктура создавала риски: при сбое сетевой зоны могли пострадать данные, а релизы останавливали сервисы на несколько минут. Менеджеры не могли работать с заказами, а разработчики тратили время на ручную диагностику.  DevOps-команда KTS провела аудит и постепенно построила новую отказоустойчивую инфраструктуру: 🌟перевели бизнес-сервисы в Kubernetes: теперь они работают в двух мультизональных кластерах, мониторятся через новый стек и поддерживаются командой KTS; 🌟убрали простой при релизах: после переезда старая версия сервиса функционирует, пока новая не запустилась; 🌟перенесли бэкапы и файловый обмен в S3 и исключили привязку к локальной директории: если контейнер переезжает в другую зону, он подключается к хранилищу и продолжает работу с теми же данными; 🌟развернули новый мониторинг на VictoriaMetrics-стеке: у разработчиков «Лазурита» теперь есть прямой доступ к дашбордам по сервисам, базам, трафику и нагрузке. Это не заменяет сопровождение, но закрывает много мелких вопросов, которые раньше отнимали время. Подробнее о том, как построили новую инфраструктуру на Kubernetes и упростили релизы, читайте в кейсе

От выполнения задач к инжинирингу конвейера разработки Есть стандартный подход к автоматизации: сначала ты делал что-то руками, теперь используешь инструмент. Но опыт автоматизации наших проектов показывает, что основной прирост эффективности лежит в другом: нужно сократить количество передач между людьми. На каждом таком этапе теряется часть контекста. Поэтому пора смещать фокус с выполнения отдельных задач на инжиниринг всего конвейера. Не придумывать решение для каждой новой фичи, а создавать и докручивать систему, которая с каждой итерацией работает всё более автономно. Большая аналитическая часть при этом остаётся за человеком. Нейросеть не может самостоятельно обсудить задачу с заказчиком, собрать требования и проверить все детали. Для анализа и коммуникации по-прежнему нужны люди. Но после этого должны включаться правила, контрольные точки и автоматические проверки. Главный критерий здесь простой: чем реже участникам приходится передавать друг другу сведения, тем лучше. Глобальная цель — перейти от работы над конкретной фичей к инжинирингу конвейера. Разберём это на примере идеализированной технической поддержки. Заказчик пишет в чат, но часто не указывает важные детали. Сотруднику приходится отдельно уточнять, что произошло, при каких условиях возникла ошибка и как её воспроизвести. На это уходит время. При этом клиент уже в негативе: у него что-то не работает. Скорость обработки обращений сильно влияет на впечатление от подрядчика. Для команды это может быть небольшой баг. Для клиента он критичен: останавливает работу или не даёт выполнить нужное действие. В идеальной схеме в чат добавлен бот. Он принимает обращение и сразу запрашивает недостающие данные: шаги воспроизведения, условия возникновения ошибки и другие детали. Затем система исследует код, анализирует проблему, формирует баг-репорт и предлагает план исправления. На следующем этапе AI-агент вносит изменения в отдельной ветке, чтобы не затронуть основной код, и запускает автоматические тесты. Например, с помощью Playwright открывает браузер и проходит нужный путь. После проверки агент описывает внесённые изменения. Человеку остаётся вручную воспроизвести ошибку, согласовать итог или прочитать отчёт и убедиться, что результат соответствует постановке. Если через час или несколько часов заказчик получает протестированный фикс, готовый к выпуску, это впечатляет. К такому уровню сервиса быстро привыкают. Это и есть идеализированный AI SDLC: не отдельный инструмент, а полноценный конвейер разработки. #максим_павлов 😀 #менеджментkts

«Монстропланетяне» в «Магните»: из космоса в офлайн 🛸 Вместе с коллегами из «Магнита» разработали геймификацию, которая подталкивает зайти в приложение, а оттуда — заглянуть в большие форматы сети. За счёт чего работает: ▫️ Ежедневный азарт. В центре игры автомат-хватайка, в котором каждый день можно вытащить капсулу с призом: купоны на скидки и товары за 1 ₽ и выгоду в магазинах Магнит Семейный, Экстра и Доставке. Для тех, кому не хватает бесплатных попыток, начисляем ещё за бонусы М+ или целевые действия: покупки и продуктовые задания. ▫️ Мостик к полкам. В самих магазинах поселились 7 игрушек-персонажей: Топыч, Ничоськина, Фанич, Смайли, Соняшкина, Энгрич и Норман. Покупаешь монстропланетянина на кассе — получаешь не только физичекую копию, но и цифровой элемент коллекции в приложении. А за всю собранную коллекцию можно получить гарантированные призы и пропуск в финальный розыгрыш. Заходите в приложение «Магнита», знакомьтесь с монстропланетянами и получайте призы 👾

ИИ вне разработки В прошлых постах много писал про разработку. А что поменялось в процессах других отделов? Сегодня поговорим про эволюцию отдела продаж. За последние несколько месяцев было попробовано много инструментов. Начиналось все, как, думаю, и у всех, с того, что сейлзы начали использовать нейро-инструменты. Например, начали обсуждать с ChatGPT свои сделки. Сами лиды при этом лежат в CRM, сметы считаются в таблицах, КП готовится в фигме, а процесс выработки решения довольно сложный и состоит из встреч с партнерами, клиентом, технической командой и т.д. Когда сейлзы начали использовать ИИ-инструменты, это, как и в случае с разработкой, начало ускорять работу и делать ее местами более качественной за единицу времени. Но это все еще не кратное ускорение / улучшение. Поэтому мы продвинулись чуть дальше. Но перед этим нужно понять классические проблемы отдела продаж (не только нашего). Изучение кейсов и продуктов компании обычно занимает пару месяцев, адаптация сейлза к процессу сбора КП, синхронизация с командой, все это приводит к длинному онбордингу, на который накладывается еще и длинный цикл сделки и в итоге сейлз может начать что-то приносить через полгода. При этом капитализация отдела продаж в основном в: — Контактах в CRM — Отработанных лидах и кейсах (которые часто не структурированы и разбросаны по системам) — Всяческих шаблонах и готовых упаковках — Опыте конкретных людей Соответственно, чтобы выходить на новый уровень качества/скорости, нужно усиливать эту капитализацию с ИИ. Все перечисленные пункты на самом деле раскладываются на 2 задачи: — Накопление знаний (четкая структура, быстрый и простой доступ) — Типовые кросс-командные решения Поэтому первое, что мы сделали, — ИИ-агента с поиском по нашим решениям. Позволяет быстрее ориентироваться в продуктах и кейсах (которых, на минуточку, больше нескольких сотен, и никто не знает про все). А второе — агент, который позволяет оценивать уровень качества КП по оформлению и принятым практикам. Таким образом, регламенты и подходы становятся не просто рекомендациями (которые на практике быстро деградируют), а правилами, заложенными в систему. Но этого было недостаточно. Во-первых, оба инструмента находятся в нашей внутренней системе. Получается, сейлз работает в CRM, сидит в чатах и почте, звонит по телефону, готовит КП вместе с ChatGPT и еще кучу всего делает. А тут ему еще одну вспомогательную систему дали. Мотивации туда заходить не так много. А новые инструменты добавляются централизовано, а значит долго и не извлекают экспертизу и знания конкретного сейлза в общие практики. А артефакты подготовки конкретного КП все так же передаются в гугл-папках, CRM, чатах и тд. И тут становится понятно, что эти проблемы давно решены в разработке: — Экспертиза, знания и правила — это скиллы для ИИ-агентов — Общее хранилище данных — репозитории, где работают все инженеры (вместе с им-агентами) в одном контексте — Генерация артефактов с кодинговыми агентами работает лучше всяких чатов с gpt. Поэтому решение стало очевидным: сейлзы должны начать накапливать знания о своих пресейлах и генерить решения вместе с техническими командами так же, как это делают разработчики. Мы сделали один общий git-репозиторий для продаж. Он содержит: — Схему данных о клиентах и их заявках для накопления всех артефактов о заявках — MCP CRMки — Набор скиллов для работы с кодинговыми агентами Процесс выглядит так: При поступлении новой заявки и начале работы над ней сейлз получает данные о заявке из CRM с помощью скилла. Другой скилл делает предварительный анализ клиента и заявки. Сейлз может поразгонять его в глубину вместе с агентом. Дальше может быть первичный созвон с клиентом. Запись попадает в папку лида в репозитории и агент может использовать ее для помощи в генерации первичного решения. Аналогично с записью брейншторма команды по генерации решения. На основе собранных артефактов сейлз может составить план КП. А партнер или архитектор решения сразу получает весь набор артефактов, просто спуллив апдейт репозитория. Таким образом, и сейлзы, и архитектор, и все участники процесса, включая ИИ-агентов, находятся в одном контексте и капитализируют знания. Эти знания дальше может использовать агент при поиске в том же репозитории. Отдельный кайф в том, что сейлзы в процессе работы создают скиллы для ИИ-агентов в том же репозитории. Например, сегодня один из сейлзов сделал скилл для процесса упаковки технического решения по нашим стандартам. И главное — этот скилл автоматически становится доступным всем другим участникам команды пресейлов (даже если они о нем не узнают, ИИ-агент сам найдет и использует скилл, когда нужно). #сергей_чернобровкин 👨

Стримы, как зона ответственности Глядя на предыдущий пост, становится понятно, что зона ответственности должна быть в размере объекта поставки специалиста — что «под ключ» может сделать специалист. Если атомарной задачей может стать фича целиком, то это и есть новый объект поставки. И специалист тем ценнее, чем больший объем этого объекта он может сделать «под ключ»: условно маленькую фичу или большую, комплексную или простую, с простым пайплайном или сложным. Поэтому в нашей новой матрице грейдов мы отдельно выделили термин объекта поставки, чтобы смещать восприятие, что такое атомарная задача. В мире, где опытный специалист может с клодом сделать фичу так, как он хочет, быстро и почти автономно (реальный кейс нашего архитектора — 39-часовой околоавтономный рефакторинг проекта  с fable 5), этому специалисту просто не хочется дробить задачу и объяснять детали младшим специалистам, а потом за ними проверять, и все это с большой задержкой (часы / дни) вместо минут у клода. Но у этого специалиста все еще остается ограничение — контекстная вместимость и приоритеты. Он не может удерживать в голове 10 разнородных треков. Даже 3 уже сложно. А значит ценно для такого старшего специалиста полностью передать один из этих контекстов на младших специалистов. То есть, чтобы они взяли «под ключ» какой-то из стримов. Сложность этого стрима очевидно должна быть соразмерна грейду специалиста. Как и размер объектов поставки в рамках этого стрима. И поэтому в новой матрице грейдов мы сфокусировали внимание и конкретизировали не только блоки по разработке (техническим скиллам), но и блоки по работе с требованиями, ответственностью и самостоятельностью в достижении бизнес-результата. Эти мета-скиллы всегда были важны, но часто по моим наблюдениям (не только нашей компании) им придавали меньшее значение, чем технике. Сейчас значение этих скиллов будет расти вместе с упрощением / ускорением разработки. Поэтому мы плавно меняем матрицу и фокусируемся на них уже сейчас в развитии и обучении. #сергей_чернобровкин 👨

Монорепы на пути к AI SDLC В прошлом посте рассказывал про то, как мы перенесли документацию в гит и сделали удобный инструмент согласования бизнес-требований с заказчиками. Следующий шаг «сближения» данных и сбора общего контекста для разработчиков и агентов — создание монорепы / общего воркспейса с несколькими репозиториями у проекта. Классическая картинка выглядит так: есть репа с бекендом, есть с фронтендом, и еще несколько вспомогательных реп на какие-то смежные сервисы. Сама структура репозиториев не позволяет одним коммитом добавить функционал: нужно, например, сделать бек, потом фронт, а часто это еще и разные специалисты и разные задачи в трекере, за синхронизацией которых между собой следят менеджеры и тимлиды. Это очевидная точка оптимизации на пути к AI SDLC. Если я могу (утрированно) сгенерить код фронта за час, но мне нужно ждать целый день, чтобы его передать следующему спецу, который сделает бек, а потом это все сливать в стейдж, чтобы отдельно интеграционно потестит, то я теряю уйму времени на передаче контекста и отслеживание статусов атомарных задачек и контроля их синхронизации. Никаким кратным ускорением не пахнет. Соответственно, возможность, которую хочется использовать в AI SDLC — атомарной задачей должна стать сама фича, а не ее кусочки. А для этого мне нужно в одном месте собирать все артефакты: от бизнес-требований (см предыдущий пост) до автотестов. Это место — в идеале монорепа. Тогда я смогу одним коммитом вмержить целый блок функционала: и актуальные бизнес-требования, и техническую спецификацию, и реализацию, и автотесты. Это гарантирует синхронизацию артефактов между собой, сократит время на менеджмент подзадач, позволит агентам точнее выполнять задачу. Идеальный процесс тогда может выглядеть так: – Аналитик собирает требования, кладет расшифровки звонков в репу, любые другие артефакты в процессе анализа, и генерит документацию по бизнес требованиям. Все это в ветке монорепы. – Опционально аналитик может даже сгенерировать прототип в реальном коде на основе своих же бизнес-требований и показать клиенту (автоматический деплой из фича-ветки, такая вот нативная интеграция наших услуг) – Менеджер / тимлид в этой же ветке может загрумить задачки, поразгоняв с агентом. И сразу же завести их в трекере по mcp, если нужно. Автоматически приложив в задачу ссылку на документацию в нашем же сервисе. – Разработчик вместе с агентом реализует фичу в этой же ветке, глядя на согласованные бизнес-требования и прототип (который он потом просто выкинет) прямо в этой же ветке. Обновляет автоматически документацию, если есть изменения в процессе. – Ветка проходит ревью у тимлида целиком. – Тестировщик тестит эту же ветку (снова нативная интеграция фича-стендов) в изолированном окружении и дописывает автотесты. Фича стала набором связанных артефактов и они все одной транзакцией попали в основную ветку при мерже. Я специально на каждом шаге в примере приводил разных специалистов, хотя уже видно, что следующие шаги на пути к AI SDLC — это скиллы, которые позволяют с должным уровнем качества делать эти шаги с помощью агентов. А потом какие-то шаги делать автономно. Про это буду писать в следующих постах по мере реализации на практике. #сергей_чернобровкин 👨

3000 томов без потерь: как Karpov.Courses переехал в российские облака Пока мы рассказывали про менеджмент, AI и продуктовую разработку, DevOps-проекты копились в портфолио. Пришло время выпустить их из серверной. Начинаем с истории Karpov.Courses: как перенесли образовательную платформу в российские облака без остановки обучения и потери данных. К моменту нашего подключения платформа выросла из нескольких сервисов на виртуальных машинах до системы в Kubernetes. Часть инфраструктуры оставалась у зарубежных провайдеров. Это стало прямым риском для бизнеса. Платежи проходили с перебоями, часть студентов не могла зайти на платформу из-за блокировок IP, а провайдеры могли в любой момент ограничить обслуживание российских сервисов. Что сделали: — перенесли основную инфраструктуру в VK Cloud и Yandex Cloud; — развели сервисы по требованиям к доступности; — без потерь перенесли около 3000 томов с ноутбуками, датасетами и результатами заданий; — перевели управление приложениями на GitOps. Во время миграции студенты сохранили доступ к платформе и своим данным. После перехода на GitOps цикл от коммита до применения изменений сократился с десятков минут до секунд, а инфраструктура стала независимой от зарубежных провайдеров и готовой к росту. В кейсе подробно рассказали, как спланировали переезд и перестроили работу с инфраструктурой.

Спецификации на пути к автономной разработке В прошлых постах рассуждал про инженеров будущего и про автономный цикл создания ПО. Мы работаем над инструментами для такого AI SDLC (как сейчас модно говорить) и масштаб компании дает как преимущества, так и создает проблемы. С одной стороны, мы видим очень много разных проектов. Это дает возможность проанализировать их и найти общие паттерны, выработать общие подходы к разработке, стараться автоматизировать их. С другой стороны, внутренние инструменты, которые мы создаем, должны отвечать требованиям очень разных команд. Нет возможности срезать углы и закастомить под конкретную команду — всегда должно быть общее решение. Теперь вернемся к AI SDLC. По моему мнению, сейчас не столь важны инструменты, сколько создание общей среды для агентов и людей. Накопление знаний и создание общего контекста. LLM меняются, инструменты меняются, данные и знания остаются. Это значит, что первая задача, которую надо решить на пути к автономному созданию ПО — максимально «сблизить» данные, которыми оперируют разные специалисты и агенты. И первая задача, которую все решают при создании ПО — сбор бизнес-требований. Spec driven development уже давно звучит из каждого утюга. Но проблема в том, что конечный стейкхолдер выдает требования обычно обрывочно и не структурировано. Их нужно собирать с заказчика, анализировать и на основе них синтезировать спецификацию. А потом согласовывать. И обычно этот процесс ведется в удобных инструментах типа Гугл-доков или конфлюенсов, где можно оставить комментарии, предложить изменения и тд. Но даже после согласования документации есть не менее объемная задача поддержания документации в актуальном состоянии. И при этом хочется, чтобы конечные доки лежали в том же месте, что и код и другие артефакты по проекту. Тогда и получится максимально использовать агентов для последующей генерации уже технической спецификации, кода, тестов и тд. В целом, работать через mcp с теми же гугл доками можно. И мы так и делали в первых итерациях. Проблема в том, что «мостиком» между агентом и документацией тогда является человек, который работает с агентом. Он должен указать документ, с которым работает, изменить его (например, автоматически обработать комментарии заказчика) через mcp часто бывает неудобно (перетирается весь док, нельзя включить режим предложений). А обновить документацию уже потом в процессе разработки — отдельный шаг, который точно кто-нибудь забудет. Мы даже разработали плагин к гугл докам, который умеет обработать комментарии, внести правки в режиме предложений. Но этого все еще недостаточно, потому что кодинговый агент, живущий в репозитории, лучше всего работает с артефактами из этого репозитория. Поэтому единственное качественное решение, к которому мы пришли: вся документация по бизнес-требованиям должна быть в той же репе в гите. Ок, это не проблема для аналитиков, но заказчик точно не захочет смотреть мерж-реквесты в гитлабе. Он привык к удобным гугл-докам. Поэтому нам пришлось разработать сервис для просмотра и согласования документации, которая лежит в репозитории. Сервис позволяет комментировать (через комменты к мерж-реквестам) и редактировать (через коммиты) документы прямо онлайн, полностью имитируя процесс гугл-доков. Теперь большинство аналитиков согласуют с заказчиками документацию в нашем сервисе, и она автоматически попадает в репозиторий, где ее же и использует агент. А комменты от заказчиков можно обрабатывать автоматически. Затем разработчики используют документацию уже для программирования и в процессе разработки могут автоматически (агентом) проапдейтить документацию, если было изменение в процессе реализации. Но мало сделать, надо еще и внедрить. Для внедрения мы сделали простой yaml-конфиг, описывающий структуру документации в репозитории. Разработчикам / аналитикам нужно добавить только этот конфиг и репозиторий автоматически покажется в интерфейсе сервиса для просмотра и согласования документов. Вуаля, и вот мы сделали маленький, но важный шажок на пути к автономному AI SDLC. #сергей_чернобровкин 👨

Сегодня студенты живут свою лучшую жизнь… ... потому что им помогают AI-агенты Обычно подготовка научной или дипломной работы начинается с попыток сформулировать тему и часов поиска подходящей литературы. Для ДВФУ и РАНХиГС мы разработали AI-агента, который выдаёт готовую основу для исследования за минуты. Вместе с командой ГигаЧат реализовали проект за 3 недели: спроектировали инфраструктуру, настроили RAG и векторизовали 200 000 книг из библиотечных фондов. По запросу пользователя агент подбирает источники из базы знаний и передаёт их в LLM. Модель ГигаЧата суммаризирует данные и генерирует ответ с формулировками темы, структурой научной работы и списком литературы. Так за один короткий запрос студент получает всё необходимое для начала исследования без привлечения научного руководителя. 🤨 Этот проект показывает, как AI-решения на основе RAG помогают структурировать разрозненные источники данных, упрощают работу с базами знаний и экономят часы на поиске информации. Подробности — в кейсе

Заказчики больше не хотят платить за прокси-менеджеров Точечную автоматизацию сейчас может сделать почти любой. Не надо даже быть студентом технического вуза — справится и школьник, который более-менее разбирается в компьютере. Мы видим эту тенденцию и на своих проектах. К нам приходят либо с технически сложными задачами, либо с высоким уровнем неопределённости. Где нужен опыт, чтобы дойти до результата за один-два эксперимента, а не за пять. В такой ситуации трансформируется и роль менеджера. Заказчикам больше не нужен координатор, который просто передаёт информацию туда-сюда. Когда менеджер задаёт правильные вопросы технической команде прямо на встрече, сразу возникает ощущение добавочной ценности. Если он по большинству задач понимает Definition of Done или хотя бы может с одним запросом к ИИ разобраться в деталях, это сильно сокращает количество итераций и фасилитирует процесс. Мы два года не меняли профиль менеджеров-сеньоров, которых хотим видеть в команде, и получали хороший результат. У нас изначально была высокая планка по технической осведомлённости, но мы не выделяли это как отдельный критерий. Больше смотрели на погружение в задачи, которые ставятся разработчикам. Сейчас требования выросли, и это логично: заказчик платит за часы тех, кто каждым действием приближает проект к результату. И всё меньше готов платить за «я уточню у разработчиков и вернусь». #максим_павлов 😀 #менеджментkts

⚡️Поймали апдейт в Рейтинге Рунета 2026 KTS вошел в десятку лучших российских компаний в категории «Разработка и развитие порталов и веб-сервисов». За последние 3 года мы заточили когти на серьезные продуктовые вызовах и мощно поднялись из Топ-50 в Топ-10. И еще два важных попадания в общие рейтинги: ⭐️ 24 место — разработчики универсалы. Впервые попали в эту категорию и сразу оказались в первой тридцатке сильных игроков рынка. ⭐️ 22 место — разработчики мобильных приложений. За 3 года поднялись на 135 строчек. В профильных направлениях тоже есть чему порадоваться: ⭐️ 3 место — Геймификация ⭐️ 3 место — Недвижимость «Разработка и интеграция» ⭐️ 12 место — Разработка и внедрение AI-решений Спасибо всем в KTS, кто ведет сложные проекты от первых обсуждений до прода, и партнерам, которые ставят перед нами новые вызовы. Фиксируем мощный буст и двигаемся дальше. Stay Tuned 😎

Корпоративное ПО в эпоху AI 8 месяцев назад мы с коллегами обсуждали выбор ПО для автоматизации части внутренних процессов. Мы были в классической ситуации, которую сами помогаем решать нашим клиентам: каждый отдел использует свои инструменты разного уровня автоматизации — от экселек с аппскриптами до специализированного ПО под конкретные задачи. Типичная «лоскутная автоматизация». Мастер-данные при этом не хранятся в единой системе: сотрудники в 1С, клиенты в CRM, финансы в агрегаторе, отчетность в таблицах, ДО и КЭДО в отдельных сервисах, управление проектами в трекере. Все это помазано сверху самописными сервисами, которые перекладывают данные между системами. Мы, как и наши клиенты, встали перед выбором: либо делать кастомную систему, либо покупать коробочное решение. Прикинув, что коробочное обойдется, скорее всего, дешевле, мы начали смотреть варианты. И пока выбирали, я начал переделывать одну из систем для хранения маркетинговых данных с no-code на самописную. А мы все еще выбирали, смотрели альтернативы. Любые из них, как и полагается коробкам, были не совсем подходящими для наших данных и процессов. Мы начали обсуждать, как будем натягивать потенциальное решение на текущие системы, что придется поменять в процессах и какие системы придется сделать для синхронизации текущих источников данных. Тем временем вышел Opus 4.5, я смог достаточно качественно «кодить» в перерывах между звонками по 5–10 минут, моя самописная система разрасталась и уже покрывала несколько важных процессов. Затем прошел этап внедрения. Часть администраторов проектов стали работать в моей системе. Постепенно к созданию системы подключились и другие разработчики. За несколько месяцев довели продукт до продакшн-уровня, заместили часть текущих систем, выработали подходы к работе и документации для еще более быстрой разработки и даже дали менеджерам делать простые инструменты (не затрагивающие кор-функционал) под себя самостоятельно через согласование спецификаций. Это дало кратный буст и уже значительно сказалось на бизнесе: от прямой экономии ФОТ (проще всего посчитать в экономике) до онлайн-мониторинга показателей и сокращения времени принятия управленческих решений. Всего за несколько месяцев я увидел, как капитализировалась большая часть нашего опыта, данных, процессов, живущих до этого в головах, документах и разрозненных системах. Более того, благодаря подключению «нетехнарей» получилось сократить цикл создания ценности в продукте: бизнес-пользователи лучше всего знают свои процессы, и теперь они могут не рассказывать аналитикам, что же нужно сделать, чтобы аналитики написали ТЗ, передали его в разработку и т. д. Теперь они сами часто пишут ТЗ, согласуют его и реализуют нужный им функционал. (Для скептиков: не пугайтесь, есть гардрейлы и централизованная архитектура, а эффект от распараллеливания кратно превосходит риски.) Раньше это было невозможно в принципе. Сейчас, при правильной подготовке, это дает намного больший синергичный эффект для бизнеса, чем классическая лоскутная автоматизация из кучи коробочных решений. Видимо, нас ждет новая эра расцвета кастомной автоматизации, где даже небольшие компании смогут делать ПО под свои процессы, тогда как раньше даже не подумали бы об этом. #сергей_чернобровкин 😊

Как AI превращает проджекта в «десятикратного» менеджера Раньше наш стандартный трек внутренней автоматизации выглядел так: анализируем процесс, описываем его, аналитики структурируют, составляем ТЗ. Потом разрабатываем, тестируем, делаем приёмку. А после — внедрение, и… новый цикл доработок. В итоге процесс растягивался на месяцы. И это у проактивных менеджеров, которые пушат всех. За это время у команды пропадал запал — долго, сложно, копится усталость. Сейчас я вижу сильное изменение: менеджеры, у которых нет жёстких блоков «надо всё делегировать разработчикам» и «код не моё дело» получают в руки очень мощный инструмент — нейронки. Опытный менеджер уже умеет формулировать требования, понимает, что поедет, и как это внедрять. Раньше процесс упирался в зависимость от разработчика. А теперь менеджер сам ставит задачу, сразу валидирует, поедет ли решение в таком виде, и тут же фиксит. Это работает особенно мощно, если команда выстроила предсказуемый пайплайн: доработки не ломают всё, их можно изолированно тестировать и быстро катить. В результате мы получаем «десятикратных» менеджеров — с помощью AI они дают в 10 раз больше результата. По аналогии с «десятикратными» программистам из книги «Мифический человеко-месяц» Фредерика Брукса. Например, наш финдиректор долго ждала доработок от разработчиков, чтобы автоматизировать несколько сценариев в гугл-таблицах. С помощью ИИ допилила инструмент сама: подтягивает нужные данные, агрегирует, настраивает под себя. Чтобы получить такой результат, важны две вещи: — понять, что мир изменился, и сломать внутренний блокер «я должен делегировать это разработчикам» — выстроить предсказуемую работу с ИИ и обеспечить среду, в которой можно итеративно пробовать, не боясь всё сломать. В доработках, где нет сложных интеграций и асинхронных операций, с задачей справляется человек, который умеет формулировать, что ему нужно. В результате скорость изменений внутренних процессов кратно растёт. То, что раньше требовало участия разработчиков и занимало квартал, сейчас можно внедрить за неделю. #максим_павлов 😀 #менеджментkts

😎 Как запустить AI-агента и не утонуть в инфраструктуре В enterprise AI-агенты часто превращаются в проект на месяцы: данные, интеграции, качество, безопасность. Масштабировать сценарии при таком подходе сложно — каждый раз приходится проходить этот цикл заново. Для тех, кто хочет запускать агентов в закрытом контуре за пару часов, а не за пару месяцев, мы развиваем AI Platform. Внутри — готовая инфраструктура для быстрой проверки гипотез и масштабирования: Агентская платформа ускоряет деплой до нескольких часов: новое решение не требует разработки с нуля, обновления выкатываются автоматически после проверки качества, а длинные сценарии не падают на середине из-за одной ошибки. Есть статистика по каждому запросу: какие инструменты использовались, время, стоимость. Платформа данных объединяет разрозненные источники в структурированную базу знаний. Система учитывает права доступа и правила безопасности — агент видит только ту информацию, которая доступна конкретному пользователю. Чувствительная информация остается внутри корпоративного контура. LLM-платформа помогает управлять разными моделями и контролировать безопасность, качество и бюджет. Запросы распределяются между внутренней инфраструктурой, российскими облаками и внешними моделями по заданным правилам. Подробнее о том, как устроена AI Platform, рассказываем на сайте: kts.tech/ai-platform

Когда опыт в менеджменте мешает Показательный кейс: сейчас помогаю с онбордингом менеджера в одном из наших юнитов. Небольшая команда, высокая скорость, нет жёсткого разделения обязанностей, «все делают всё». Разбираемся вместе, как выстроить менеджмент в таких условиях. Руководитель юнита поставил менеджеру задачу: по краткому перечню работ описать критерии приёмки, definition of done. Предметная область сложная — без технического специалиста сходу не разберёшься. Предложил менеджеру использовать для этой задачи AI-инструменты, так как привык так делать сам. У опытного менеджера здесь два привычных пути. Первый — классическое делегирование. Подключить технарей, распределить задания, выстроить приёмку общего результата. Второй — сделать самому. Большой контекст, нет смысла погружать специалистов. Менеджер выбрал этот вариант: потратил день-два, детально проработал материал с помощью AI и пришёл с финальным артефактом. Когда начали смотреть вместе с руководителем юнита, оказалось, надо много переделывать. Но главное не это. Выяснилось, что руководитель уже перестроил своё мышление и изначально ждал не готовый результат, а черновик от нейронки. Чтобы вместе докрутить то, что не понравится, прямо на встрече. И здесь появляется третий путь. Он меняет саму ткань делегирования, сам производственный процесс. AI генерирует ровную базу за минуту. Менеджер докручивает по своим критериям — убирает очевидно слабые места, задаёт направление. И приходит с этим черновиком на обсуждение. Дальше вместе правим на ходу. Реальная экономия уже не в том, что кто-то один тратит время и приносит готовый результат. А в том, чтобы не начинать с чистого листа. Менеджер признался, что жёстко прочувствовал эффект. Это не просто написать текст быстрее с помощью ИИ, а изменение собственных паттернов поведения. Когда годами работаешь на опыте, сложно в моменте включить голову и принять решение, как делать дальше. В этом и есть, пожалуй, главный вызов. Не научиться пользоваться новыми инструментами — это несложно. А разобраться, в каких местах накопленный опыт теперь скорее мешает. Там, где раньше не нужно было думать, потому что ответ и так был очевиден — теперь стоит остановиться и спросить себя заново. #максим_павлов 😀 #менеджментkts

От RAG до агентов: что бизнес ждет от AI? В подкасте «Большой разговор про AI» Александр Опрышко, сооснователь KTS, рассказал, как AI уже меняет разработку и digital-рынок: от оцифровки базы знаний к агентам конкретных действий, от отдельных ассистентов к AI-центричному подходу в SDLC. Обсудили: ▫️почему компании так активно смотрят в сторону RAG, ассистентов проектировщиков и аналитики? ▫️как бизнес оценивает эффективность AI-проектов? ▫️почему многие хотят on-premise решения? ▫️куда перестраивается рынок? ▫️какой тренд показывает наш кейс ассистента Альфа-Банка с ROI 6 месяцев? 🔴 Посмотреть выпуск