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

«Монстропланетяне» в «Магните»: из космоса в офлайн 🛸 Вместе с коллегами из «Магнита» разработали геймификацию, которая подталкивает зайти в приложение, а оттуда — заглянуть в большие форматы сети. За счёт чего работает: ▫️ Ежедневный азарт. В центре игры автомат-хватайка, в котором каждый день можно вытащить капсулу с призом: купоны на скидки и товары за 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 месяцев? 🔴 Посмотреть выпуск

AI — только для enterprise? Доказываем, что это не так! Миф: AI — это дорого и только для крупных корпораций. Реальность: в проектах KTS мы видим, что ИИ-решения работают в бизнесе любого уровня. Вопрос не в бюджете, а в том, с чего начать и как измерить результат. В новой статье собрали главное для тех, кто только присматривается к внедрению: 🌟почему проекты зависают в «вечном пилоте» 🌟 какие процессы автоматизировать в первую очередь 🌟 какие метрики действительно показывают бизнес-эффект 🌟 как платформенный подход меняет экономику AI-проектов Рассказываем, как за 1–2 месяца сделать AI прикладным инструментом с измеримым эффектом.

Инженер будущего Последние 4 месяца активно работаем над формированием образа специалистов, которые должны работать в компании. Этот вопрос пересекается с производственным процессом, потому что именно он диктует формат команд и роли внутри них. В этом посте позволю себе немного пофантазировать на тему будущего процесса разработки и места человека в нем. Думаю, что уже сейчас человек является бутылочным горлышком в производственном цикле. Представим роботизированную линию в каком-нибудь цеху. В нем есть участки, на которых стоят роботы с производительностью 100 изделий в час, но между участками есть этапы с людьми с производительностью 10 деталей. Общая производительность конвейера - 10 деталей. Классический конвейер разработки выглядит так же: аналитика -> дизайн -> разработка -> кодревью -> тестирование -> релиз Между каждыми этапами есть много административных временных издержек, а какие-то из этапов могут полностью блокироваться человеком. Стандартный пример — согласование требований. Аналитик написал ТЗ, ждёт согласования заказчика. Оно асинхронное и даже одна итерация правок может занимать от 1 дня до недели. Это не создавало проблем раньше, так как одно согласованное ТЗ, даже если на него уходила неделя, создавало большой объем работы на следующих этапах. Соответственно общая производительность зависела от производительности «участка» разработки. Сейчас же скорость создания артефактов в каждом участке, включая разработку, выросла в разы. И узким местом стали согласования, проверки качества и так далее. То есть все, что делает человек между участками производства. Какой смысл от того, что я могу написать ТЗ за 1 час вместо 6, если для согласования мне все равно придется подождать минимум день? Или какой смысл от быстрого написания кода, если мне нужно ждать кодревью от другого человека (при том, что его еще и завалило сверху бОльшим количеством ревью)? Текущие инструменты в основном применяют для ускорения участков, но не пайплайна целиком. В такой конфигурации можно получить прирост общей производительности в единицы или в лучшем случае пару десятков процентов, если «был запас». Но кратный прирост не получится. Это значит, что нужно изменять сам пайплайн. Минимизировать ручное администрирование и контроль, при этом обеспечив те же качество и предсказуемость, что и раньше. Тогда целевая функция инженера — не просто выдать артефакт, а доработать систему выдачи этих артефактов, чтобы в будущем результат был более стабильный и предсказуемый. Дообучить систему, короче говоря. Тогда роль «инженера будущего» в постоянном улучшении и ускорении пайплайна. Фактически как сейчас CI/CD, только в качестве шагов — агенты, которые делают те или иные проверки, вносят изменения в создаваемый продукт, а инженер отслеживает, в чем агенты ошибаются и изменяет самих агентов, или добавляет новых, чтобы в будущем система не допускала таких же ошибок. Тогда разработка — это полностью продукт агентов. А продукт инженера будущего — это система по автономному предсказуемому произведению цифровых продуктов с заданным качеством. #сергей_чернобровкин 😊

RAG-платформа для 12 000 операторов Альфа-Банка: ускорили поиск данных в 20 раз Раньше операторы контакт-центра вручную искали информацию в базе знаний, чтобы ответить клиенту. На обработку одного запроса в среднем уходило 5 минут. Чтобы ускорить работу операторов, Альфа-Банк решил внедрить RAG-платформу. За помощью обратились к команде KTS. За 4 месяца мы вместе вывели проект в production и настроили систему так, чтобы данные всегда были актуальны, и каждый оператор получал ответ с учётом его уровня доступа. Платформу развернули внутри контура банка и запустили на двух GPU H100. Это позволило уложиться в экономику проекта и при этом обеспечить запас по производительности. В результате RAG-платформа ускорила и упростила работу операторов: ▪️ среднее время обработки запроса уменьшилось на 40 секунд: с 5 минут до 4 минут 20 секунд ▪️ поиск данных стал в 20 раз быстрее: 3 секунды вместо 60 93% операторов положительно оценили работу платформы, и решение масштабировали на всех сотрудников Альфа-Банка. Сегодня система обрабатывает 85 000 запросов в сутки. Больше деталей про настройку и работу RAG-системы показали в кейсе

Отметились на Workspace Digital Awards/26 🏆 Workspace Digital Awards — ежегодный конкурс лучших digital-кейсов. В этом году награды получили три проекта KTS: 🟢2 место в номинации «Маркетинг и реклама. Креативный подход» за кейс Орево для «Бургер Кинга». Голосовая геймификации в мобильном приложении собрала 4,1 млн взаимодействий и привела 400к+ уникальных участников. 🟢3 место в номинации «SMM и PR. Спецпроекты» за проект Выживалити для «Пятницы!». Игра в Telegram, синхронизированная с телеэфиром, удержала 86% аудитории на протяжении всего сезона шоу. 🟢3 место в номинации «Сайты. Мебель, интерьер и товары для дома» за Флатику. Вместе с коллегами из Mish провели полный ребрендинг международной платформы под российский рынок. Принимаем поздравления 💚

Раньше менеджеры девелопера вручную оповещали агентов по каждому изменению статуса — это съедало время колл-центра и тормозило цикл сделки. Мы настроили единую систему триггерных уведомлений, где агент получает нужную информацию сам, в нужный момент, в удобный канал: 🟢 Telegram-бот для агентов: напоминания, статусы, документы 🟢 Личный кабинет для агентств: управление командой и аналитика В кейсе показываем, какие именно триггеры сработали, как выстраивали интеграцию с внутренними системами застройщика и что в итоге изменилось в цифрах. 😎 Читать кейс

Вы всё ещё переплачиваете за инфраструктуру? Тогда мы идём к вам. Расходы на облако часто растут незаметно. Тестовые среды работают ночью и в выходные. Неиспользуемые ресурсы продолжают списывать деньги. У команд нет общего правила, кто следит за потреблением и где проходит граница между «нужно» и «просто осталось включенным». В итоге счета растут, а ясности, за что платит бизнес, становится меньше. Мы поможем найти, где инфраструктура расходует лишнее, и сократить затраты без риска для продукта и команды. Что делаем: — проводим аудит расходов на облако; — оптимизируем инфраструктуру; — настраиваем мониторинг потребления и уведомления; — выделяем центры затрат; — прогнозируем бюджет; — считаем TCO и ROI. Если есть ощущение, что можно сэкономить на инфраструктуре, начните с бесплатного аудита. За 5 рабочих дней покажем, где вы теряете деньги. Сначала доведем до результата и только потом возьмем оплату. Гонорар KTS = подтвержденная экономия за 6 месяцев.