Внутри AI | Кейсы ИИ Агентов в бизнесе

ИИ-базу знаний купили, никто не пользуется. Что делать?

Представьте, в компании внедрили ИИ-ассистента по внутренним документам. Провели демо, разослали ссылку, написали в общий чат. Через 2 месяца посмотрели статистику: десяток заходов в неделю, из них половина — это те, кто помогал внедрять базу знаний.

При этом ChatGPT или его корпоративная обёртка у людей открыты в соседней вкладке весь день. Первое объяснение, которое приходит руководителю в голову: сотрудники сопротивляются новому. Но те же самые люди сидят в «чатике» весь день, добровольно и без обучения. Причина не в сопротивлении, это отказ от одной конкретной системы.

С чем её сравнивают

MIT в прошлом году посчитал разрыв: официальную подписку на LLM купили около 40% компаний, а личными инструментами на работе пользуются больше 90% сотрудников. Отсюда важный вывод: люди уже знают, каким бывает нормальный ИИ, и к статичным корпоративным системам относятся гораздо жёстче.

То есть вашу базу знаний сравнивают не с поиском по Confluence, где десять нерелевантных ссылок — норма. Её сравнивают с ChatGPT. И достаточно одного случая, когда она уверенно назвала отменённый год назад регламент, чтобы сотрудник больше туда не вернулся. Второго шанса у таких систем обычно нет: люди не проверяют, «может, поправили».

Четыре причины, из-за которых система ломается чаще всего:

1) Контент. Модель не знает, какой из двух документов главнее. Действующий приказ и черновик двухлетней давности для неё просто два текста, и она аккуратно и уверенно процитирует оба. Дальше сотрудник один раз получает отменённый регламент, и система для него закрыта.
Поэтому основная часть внедрения — это разбор документов, а не настройка модели. Обычно это закладывают в план, но не уделяют должного времени (а работа с информацией — это отдельная практика, или даже культура).

2) Система не исправляется. Сотрудник нажал «плохой ответ». Через неделю задал тот же вопрос и получил то же самое. Всё, обратная связь больше не придёт: люди отказываются от инструментов, которые не запоминают и не меняются. И здесь речь не про дообучение модели, а про банальное: жалоба должна превращаться в задачу владельцу документа, а исправление — возвращаться пользователю.

3) Никто не знает, о чем её спрашивать. Часть сотрудников не понимает, где ИИ может улучшить их работу. Остальные видят пустое поле ввода и закрывают вкладку. «Спросите что угодно» — худший онбординг из возможных. Работает обратное: вот пять вопросов, которые вы задаёте коллегам каждую неделю, пишите их сюда.

4) Нет ранних последователей и лидерства на примере. Менее очевидная причина. Часть сотрудников не применяют доступный ИИ просто потому, что им не пользуются коллеги. Массовая рассылка эту стену не пробивает, нужны живые люди в командах, которые показывают инструмент на своих задачах.

Что делать:
▪️ Начать с 2-3 сценариев, а не с «единой базы знаний компании». Онбординг новичков, ответы по тарифам для продаж, регламенты первой линии. Узкая зона с ощутимой болью, где ответы можно проверить руками.
▪️ Дать каждому разделу владельца и срок годности. Устаревшее в архив, а не «пусть лежит». Триста проверенных документов лучше тридцати тысяч непроверенных.
▪️ Показывать источник и дату под каждым ответом, что, кстати, умеет наша AI-база знаний. И научить систему говорить «не знаю, спросите такого-то».
▪️ Встроить в мессенджер и рабочие системы. Отдельный портал, до которого надо дойти, проигрывает по умолчанию.
▪️ Посмотреть, зачем сотрудники ходят в ChatGPT, и не запрещать, а забрать эти сценарии себе. Это готовый бэклог, составленный без вас и бесплатно.

#иван_лавров

Переосмысление агентов 

Предыдущие выводы про MCP натолкнули на совсем крамольные мысли. 

Обычно агенты в проде работают по фиксированной схеме: вот набор тулов (RAG, вызов оператора и прочие), вот промпт. На этом всё. Агент собирает контекст, как-то переваривает данные и выдаёт результат. Если данные представляют собой структурированную информацию (таблицы, числа), то вероятность ошибки очень высокая: агент может неправильно что-то просуммировать, агрегировать и т.д.

Локальные агенты решают это с помощью скриптов. Они обрабатывают данные не напрямую, а пишут скрипт с нужным представлением. В итоге задача «определи выручку за сентябрь» превращается в «напиши скрипт, который просуммирует все транзакции за заданный период, запусти его и выведи результат пользователю». 

А что, если дать агенту возможность в рантайме писать код и подтягивать нужные зависимости? Сразу же возникают вопросы. А как же изоляция? А как запускать их? Придётся под каждую сессию поднимать отдельный контейнер? Это же сколько ресурсов нужно... 

Но такой подход обеспечивает гибкость работы агентов. Сильно снижается объём внедрения, так как агент может в рантайме работать с интеграциями. По сути, мы получаем полноценный облачный агент, который может работать без инициативы пользователя. Полноценная агентность, a.k.a. нейросотрудник. 

Большой вопрос только в безопасности и эксплуатации. Когда я начал копаться в этом глубже, я нашёл проекты, которые идут в ту же сторону:

1) https://github.com/google/ax
2) https://github.com/agent-substrate/substrate

Мы сейчас у себя их тестируем, скоро расскажем подробности.

#александр_опрышко

Переосмысление ценности MCP

На всякий случай, MCP — это стандартный протокол подключения тулов к агентам.

Идея достаточно очевидна: унифицировать интеграции с LLM, чтобы можно было подключать знания из разных систем. Но на практике возникают проблемы:

1) Если API возвращает большой ответ, то нужно как-то предобрабатывать запрос. Следовательно, интерфейс уже не такой универсальный, и на практике он порождает слой проксей, которые подготавливают данные для конкретной задачи.

2) Возникает дополнительное препятствие для внедрения агентов, так как нужно строить платформу для MCP и продумывать им ролевые модели. Из-за этого приходится делать ооочень много технических приседаний и проходить не меньше согласований, а по итогу выхлоп может быть нулевым.

До недавнего времени я был убежден в том, что для этой вашей «ИИ-трансформации» компаниям нужно в обязательном порядке строить MCP-хабы, но переосмыслил эту гипотезу из-за одного практического примера.

Мы занимались автоматизацией тестирования приложения на Dev-среде, а для этого нужно было научить агента катить на Dev. У нас настроены динамические окружения, так что каждая ветка может существовать изолированно. Мы подключили GitLab MCP к агенту с выделенным пользователем с ролью developer на проекте. Вот только в MCP не оказалось возможности запускать пайплайны, и сам агент в процессе размышления попытался найти GitLab-токен с правами запуска пайпов. И это натолкнуло меня на мысль: а что, если агенту просто дать GitLab-токен пользователя с ограниченными правами и вызвать API напрямую из агента? Очевидно, это решение сработало.

В этот момент и произошло переосмысление: а зачем нам вообще нужен MCP? Почему мы не можем использовать текущие API для интеграции с уже продуманной (и, главное, принятой) ролевой моделью? Агенты поумнее вообще могут в реальном времени писать скрипты интеграции и сразу готовить формат, как себе нужно, а для агентов потупее можно заранее писать набор тулов для интеграции. С помощью агентов поумнее, само собой.

В итоге MCP-хаб (маркетплейс интеграций) превращается в набор скиллов (.md-файликов), который описывает, каким образом и с какой системой интегрироваться. Так в итоге еще и появляется самоактуализирующаяся документация. Актуализация происходит в момент, когда агент пытается написать интеграцию: если API не работает как описано, то он может сделать PR на обновление скилла, а овнеры уже могут принять или отклонить этот запрос.

#александр_опрышко

В Agent Platform появились новые языковые модели

Недавно мы обновили работу с изображениями, а теперь добавили Claude Opus 5.5 от Anthropic и шесть моделей OpenAI: GPT-6 Astra, Astra Pro, Luna, Luna Pro, Sol и Sol Pro.

Выбирайте модель и пробуйте её в Agent Platform.

Моя работа плохо ложится в трекеры. Поэтому её забрал AI-ассистент

У нашего Head of QA, Романа Авдонина, много задач, которые не оставляют следов в привычных трекерах. За день он может обновить матрицу грейдов, согласовать новый процесс, что-то доработать во внутреннем инструменте, провести несколько встреч. А раз в полгода проходит перформанс-ревью — и приходится по чатам, календарю и заметкам восстанавливать контекст. Раньше на такой квест уходило до двух дней.

Вести рабочий журнал руками Роме не хотелось, поэтому он собрал под свою задачу AI-ассистента из Claude Code, Obsidian и markdown-файлов.

Роман общается с Claude обычным текстом и рассказывает ему, чем занимался, а ещё закидывает транскрипты созвонов. Вся память хранится в markdown-файлах, Obsidian служит интерфейсом к ним, а привязки к конкретной модели нет. 
Ассистент раскладывает информацию по нужным разделам и запускает часть автоматизаций по расписанию. Контур состоит из нескольких частей:

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

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

Встречи и люди. Из транскрибации созвонов ассистент вытаскивает договорённости, экшн-айтемы и обновляет заметки о людях. Перед следующей встречей может собрать план разговора.

Автоматизации. Сейчас их две: вечером ассистент синхронизирует цели между Google-таблицей и журналом, а к утру понедельника готовит дайджест для 1:1 с руководителем. Раньше такую картину приходилось собирать по чатам час-полтора.

Копилка достижений. Заметные результаты параллельно складываются в отдельную папку. Перед следующим перформанс-ревью ассистент составит черновик селф-ревью с датами и ссылками на журнал.

В статье Роман подробно показал, как устроен контур, описал правила безопасности и оставил готовый промпт, который можно вставить в Claude Code, Cursor или другой инструмент. Агент проведёт небольшое интервью и соберёт похожее решение уже под вас.

Почитать статью и забрать промпт себе

Больше возможностей для работы с изображениями в Agent Platform

▪️ Добавили топовые графические модели от ведущих провайдеров:

— Google, Nano Banana 2: отличается высоким уровнем детализации, может создавать изображения в разрешении до 4K и точнее понимает контекст сложных запросов

— OpenAI, GPT Image 2: корректно добавляет текст на изображения, стабильнее работает в сериях и генерирует реалистичный UI и скриншоты

— Black Forest Labs, Flux.2: умеет делать фотореалистичные кадры и учитывает данные из открытых источников в реальном времени

Полный список моделей смотрите в комментариях.

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

Тестируйте обновления в Agent Platform и делитесь впечатлениями

Эпоха жирного SaaS заканчивается

Ещё лет пять назад мы жили так: нужна функциональность — ищешь подходящий инструмент, смотришь его возможности и решаешь, что в своих процессах переделать, с чем смириться, а что донаращивать надстройками и плагинами. И только после этого начинается работа.

Классический пример — JIRA. Инструмент с кучей ограничений, вокруг которого вырос целый рынок плагинов, пытавшихся донастроить отсутствующую функциональность. В итоге получалось дорогое решение, прикрученное скотчем и верёвочкой: вроде работает, но каждая смена процесса — риск, что что-то отвалится или придётся докупать очередную надстройку.

С приходом AI-инструментов для разработки скорость поставки решений выросла, а трудозатраты сократились. Появился ряд продуктов — в их числе моя OKRsana, — которые можно гибко настраивать под себя и запрашивать у поставщика кастомизации, если это по карману (а по карману это обычно только энтерпрайзу). 

Но часть лидов, приходивших ко мне, вообще не хотели внедрять систему целиком и перекраивать процессы под неё. Им были нужны точечные автоматизации. Например, быстрые проверки OKR перед тем, как драфт уйдёт на встречу, или на выравнивание целей по горизонтали и вертикали. И тогда, и сейчас это были кастомные задачи — «возьмётесь ли сделать». 

Сегодня мы можем предложить доменным специалистам самим создавать таких агентов без разработки. И дело здесь не только в стоимости — решение у опытной команды дешёвым не бывает. 

Суть в том, что кастомных агентов нужно поддерживать и развивать: процессы меняются, появляются новые вводные, всегда хочется что-то докрутить. Если агента настраивает и обновляет сам специалист, цикл «есть идея — реализовали — проверили» сокращается в разы. Про этот сдвиг отдельно писали в постах о Spec-Driven Development как новом уровне no-code и агентских автоматизациях.

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

KTS разрабатывает продукт — Agent Platform, который закрывает эту потребность. Он даёт доменным специалистам создавать агентов и объединять их в цепочки для автоматизации своих процессов без разработчиков. 

В основе — три принципа:

Простой интерфейс. Как сборка шведской мебели: в комплекте все детали и инструкции, идёшь по шагам, и решение собирается.

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

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

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

#иван_лавров

Разработали AI-поиск по сотням документов Level Group и получили точность ответов выше 90%

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

Чтобы инженеры и менеджеры быстрее получали точные ответы, мы вместе с командой Level Group запустили ИИ-ассистента. Обычно для ускорения поиска используют классический RAG, где система ищет фрагменты по семантической близости. Но для процессов в девелопменте у такого подхода есть ограничения: модель не видит связей между разрозненными чанками и теряет общий контекст.

Для ИИ-ассистента Level Group мы спроектировали архитектуру на базе KTS AI Platform и подключили к ней корпоративную wiki. При разработке решения использовали фреймворк LightRAG, который объединяет векторный и графовый поиск. Такой подход позволяет связывать разрозненные документы в единые смысловые кластеры.

Например, сотрудник спрашивает о порядке действий при обнаружении дефекта. Векторный поиск найдёт шаблон акта осмотра. Графовый свяжет его с регламентами по расчётам с подрядчиками, строительными ГОСТами и сроками устранения. LLM получит полный контекст и сможет точнее сформулировать ответ.

Чтобы быстрее получить измеримый результат и подтвердить эффективность решения перед масштабированием, мы сначала запустили пилот на одном источнике. На подготовленном массиве данных точность ответов превысила 90%. 

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

Агенты и агентские автоматизации

В прошлом посте писал про Spec-Driven Development, который даёт новый уровень абстракции в nocode-разработке. Теперь сузим скоуп и посмотрим на агентские автоматизации.

Классический сценарий AI-агента — это чат для взаимодействия с пользователем. Сначала такие чатики практически ничего не умели и выступали в роли поисковиков и собеседников. Потом появились инструменты (MCP), которые подключают агента к внешним системам и позволяют выполнять действия. Но принцип оставался тем же: пользователь что-то попросил — ИИ сделал.

Агентская автоматизация работает иначе. Она даёт возможность автономного запуска агентов и делает их полноценными участниками бизнес-процессов.
По сути, это набор детерминированных шагов, внутри которого агенты выполняют действия и при необходимости обращаются к человеку за согласованием плана или подтверждением. Так называемый human in the loop.

Простой пример: есть Excel-таблица, каждую строку которой нужно проскорить по определённым критериям. Процесс можно собрать так:

▫️ сценарий получает строки из таблицы;
▫️ запускает агента и последовательно скорит строки;
▫️ передаёт результат обратно в таблицу или отправляет во внешнюю систему.

Это сочетание жёсткой логики и нейросетевой гибкости даёт два важных плюса.

Предсказуемость. Агент не выдумывает процесс, а идёт по заранее определённым этапам. При необходимости инженеры могут собрать датасеты и улучшить качество агентских шагов.

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

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

Именно в этой парадигме мы развиваем новый продукт — Agent Platform. Он позволит предметным специалистам самостоятельно создавать агентов и объединять их в цепочки для автоматизации своих процессов без разработчиков.

Сейчас проводим закрытые пилоты. Скоро расскажем подробнее про работу продукта и откроем запись на демо.

#александр_опрышко

Какие процессы можно автоматизировать поверх корпоративной базы знаний от KTS × Selectel

ИИ-поиск помогает сотрудникам быстрее находить и проверять информацию. Следующий уровень работы с корпоративными знаниями — автоматизированные цепочки под конкретные процессы компании.

Решение KTS и Selectel можно использовать для различных сценариев:

— подготовки черновиков документов;
— проверки отчётной документации;
— контроля контрактов с поставщиками;
— мониторинга рисков;
— поиска аналогов неисправностей;
— поддержки сотрудников по вопросам техники безопасности и обслуживания оборудования.

Такие цепочки сокращают ручную работу в регламентированных операциях и ускоряют подготовку и согласование документов.

В совместном решении KTS отвечает за платформенный слой: мы разрабатываем ассистентов на базе собственного решения AI Platform. Настраиваем RAG (Retrieval-Augmented Generation), сценарий и логику работы агента, встроенные механизмы контроля (guardrails) и интеграции с источниками данных и корпоративными системами. 

Наш партнёр Selectel обеспечивает инфраструктуру: ассистент может быть развернут как в облаке, так и в контуре заказчика — в этом случае Selectel предоставляет серверы с GPU (графическими процессорами) в аренду, размещая и обслуживая их на площадке клиента.

Обработка данных и эксплуатация — совместная зона: Selectel держит ресурсы и связность, а KTS контролирует индекс, качество и сценарии.

✅ Протестировать решение на собственных документах

Запустили AI-ассистента для ФК «Динамо» Москва

ФК «Динамо» Москва — один из самых известных футбольных клубов России с большой аудиторией болельщиков. У клуба много информационных поводов, а у пользователей регулярно возникают повторяющиеся вопросы: когда следующий матч, где купить билеты, что нового в команде, какие товары доступны в магазине.

Чтобы быстрее обрабатывать такие запросы и снизить нагрузку на поддержку, мы запустили для ФК «Динамо» Москва AI-ассистента. Он уже работает в онлайн-чате на сайте и во внутреннем портале для болельщиков.

Ассистент помогает подобрать товары в интернет-магазине, рассказывает новости, показывает расписание матчей, объясняет, как купить билеты, и предоставляет статистику по игрокам.

Решение разработали за несколько дней на собственной платформе AI Assistant. Агент интегрирован с внутренними системами ФК «Динамо» Москва, поэтому получает актуальные данные в реальном времени и передаёт их в LLM модели для формирования ответа.

Для команды клуба мы также сделали административную панель. В ней можно настраивать сценарии, отслеживать работу ассистента и контролировать качество ответов.

Сейчас вместе с ФК «Динамо» Москва продолжаем расширять функциональность ассистента и добавлять новые точки его присутствия.

KTS × Selectel создали ИИ-поиск для компаний, где каждый ответ нужно подтвердить документом

В строительстве, производстве, добывающей отрасли и финансах сотрудники работают с большими массивами регламентов, ГОСТов и внутренних документов. При подготовке отчёта, прохождении проверки или аудита данные приходится искать в нескольких системах и сверять с первоисточниками. На это может уходить до нескольких часов в день.

Совместное решение KTS и Selectel помогает значительно сократить время поиска информации. Сотрудник задаёт вопрос на естественном языке и получает структурированный ответ со ссылкой на документ и конкретную страницу.

Также ассистент умеет:

— подключаться к wiki, СЭД, файловым хранилищам и нормативным источникам;
— суммаризировать длинные документы;
— выделять тезисы, обязательства и риски;
— экспортировать ответы в Word и PDF;
— учитывать права пользователей через системы управления доступом (IAM и SSO).

Безопасность заложена в архитектуру решения на нескольких уровнях. Система автоматически маскирует чувствительные данные, а встроенные механизмы контроля (guardrails) проверяют запросы и ответы ИИ на соответствие заданным политикам безопасности.

ИИ-ассистент может закрывать большинство рутинных типовых запросов. Благодаря готовой инфраструктуре KTS AI Platform пилот можно запустить за две недели.

Проверьте решение на собственных документах: загрузите их в настроенную базу знаний и оцените качество ответов.

Протестировать ИИ-ассистента

Как ИИ работает в девелопменте: 8 практических сценариев

Девелоперы накапливают огромные объёмы информации: регламенты, проектную документацию, BIM-отчёты, записи звонков и переписки в CRM. Эти данные находятся в разрозненных источниках, поэтому ручной поиск отнимает время. Сотрудники тонут в операционке, а решения принимаются медленнее.

Ускорить работу с данными и автоматизировать частотные операции, помогают AI-решения. Наш опыт показывает, что большинство прикладных сценариев внедрения строятся на двух механиках:

▫️ анализ базы знаний и контекстный поиск по корпоративным источникам;
▫️ генерация текстовых и визуальных материалов на основе реальных данных компании.

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

Например, AI-ассистент во время разговора подсказывает менеджеру ответы по ипотеке и юридическим нюансам. А помощник жителей составляет и регистрирует обращение в УК по короткому голосовому сообщению вроде: «В лифте нет света».

Для каждого решения разобрали требования к данным, сроки запуска проекта и ожидаемый бизнес-эффект.

💬 Заходите почитать

Nocode умер, да здравствует nocode

Всю дорогу разработчики пытались упрощать создание программ. Начинали с Assembler, с каждым новым языком программирования повышали уровень абстракции, создавали библиотеки / фреймворки для упрощения и ускорения разработки.

В итоге мы дошли от Assembler до Python, Go, TypeScript и других языков. Попытались пойти дальше и сделать инструменты nocode — ещё одну абстракцию, которая позволит создавать системы не программистам.

В итоге получали очень нишевый инструмент автоматизации или очередной язык программирования мышкой с проблемами версионируемости и наблюдаемости. Характерный пример — n8n. Кто на нём пытался собрать что-то больше прототипа, неизбежно сталкивался с множеством проблем, которые решались большими костылями.

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

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

Этот подход — Spec-Driven Development.

Давайте вспомним подход enterprise-компаний: есть бизнес аналитики, которые формируют требования и скоуп, есть системные аналитики и архитекторы — они придумывают, как система вписывается в текущий ландшафт и взаимодействует с другими системами. Программисту в таких компаниях остаётся транслировать проработанные требования в код, доработав детали, которые не учли на этапе проектирования.

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

В итоге мы получим новый уровень абстракции nocode в виде спецификации и детерминированную реализацию в формате кода и тестов, которая лишена минусов ноукод-систем. При этом полностью отходим от участия кодера (намеренно использовал эту формулировку вместо «разработчика») в создании кода.

Возникает справедливое возражение: агенты же нейрослоп кодовый генерируют. Через некоторое время это невозможно будет поддерживать.

Да, всё так. Поэтому нужно строить принципы-правила-навыки, по которым агент будет работать. То есть задача разработчика смещается от ручной трансляции требований из спецификации в код в создание конвейера для агентов, мониторинга качества «продукции» и оперативного реагирования на нарушение технологического процесса.

Как это реализовать, поделюсь в следующем посте. Чтобы сузить скоуп, расскажу про агентские автоматизации, а не системы общего назначения.

#александр_опрышко