Это перевод моей статьи в LinkedIn
Главная мечта современных инвесторов в ИИ - это автономный ИИ сотрудник, который может полностью заменить некоторых специалистов и работать без постороннего вмешательства.
На мой взгляд это уже вполне достижимая цель, которая реализуема с текущим уровнем технологий.
Приведу пример на близкой мне области - программирование (но вообще применим к большинству digital профессий). Сделаем автономного ИИ middle backend разработчика.
Сделаем мы его на локальной серверной машине, внутри контура компании.
Сразу скажу что Я не буду выкладывать свой код, настройки или workflows для открытого доступа. Моя цель - верхнеуровнево показать рабочее для меня решение, потому что вижу не то что пробел, а вообще отсутствие материалов такого рода, даже с подобным поверхностным уровнем детализации.
Подготовка
Для начала нам понадобится полный Job Description сотрудника, данные, которые ему необходимо знать, задачи, которые ему необходимо выполнять, а также каналы связи по которым с ним можно взаимодействовать. Благо удаленка дала свои плоды и все научились взаимодействовать с сотрудниками цифровыми способами.
Формализуем доступы - к Git-у - ssh ключи, к Confluence и Jira - API ключи, токены для telegram, slack или что ещё (будь то почта или любые другие каналы связи). Записываем всё это в произвольный json конфиг файл в директории где будет работать сотрудник (корень запуска агента).
Установим докер на сервер и там запустим n8n, векторную БД и какую-нибудь реляционную БД типа PostgreSQL .
Для n8n дадим доступ к рабочей директории.
Настройка
Настроим каналы связи - в n8n добавим триггеры на нужные каналы связи, чтобы сообщения улетали в нашего агента и он мог возвращать ответы. Но дергать мы будем не обычную LLM модель, а именно через хук или кастомную ноду дергать локального агента.
Агент
Самая сложная часть это разработка агента. Но уровня агентности какого-нибудь Cursor хватает за глаза, главное сделать методологически правильные промпты.
Ещё один важный шаг это настройка MCP тулов для агента - поиск и скрапинг информации, работа с Jira, Confluence, Git и т.д. Чтобы у нашего ИИ сотрудника были руки и глаза.
Также обязательно нужен механизм RAG для мемоизации важных вещей типа как правильно решить задачу такого вида или как правильно найти такую то информацию. Что именно важно может решить сам агент простым промптом типа:
выдели важные успешные решения из текущей сессии для их запоминания
Это нужно чтобы наш ИИ сотрудник накапливал опыт. Реляционная база данных нужна для накопления "правил поведения", когда руководитель чем то не доволен и говорит "так больше не делай", или наоборот "делай вот так".
Методология
Самая важная и, скорее всего, объемная часть работы - формализовать методологию работы нашего сотрудника (по хорошему это всё уже должно быть описано в Job Description).
Делится работа на 2 этапа
наполнение RAG-а важными знаниями. Грубо говоря засовываем в RAG процесс онбоардинга.
настройка расписания - в n8n настраиваем cron триггеры, допустим в 9 утра зайти в Jira и посмотреть новые таски, назначенные для меня, проанализировать и либо начать выполнение, либо отписаться в комментариях.
Как это всё работает
Разберем на примере нашего ИИ middle разработчика:
Заходит по расписанию в Jira, стягивает свои таски.
Проверяет таску на полноту и выполнимость, если чего-то не хватает - сообщает в комментариях.
Проверяет необходимое окружение - доступ по сети, доступ к коду, возможность работы с Git и т.д.
Выполняет задачу. С нормальным описанием Cursor уже сейчас для меня закрывает 100% задач уровня middle разработчика (если у Вас нет, значит либо страдает полнота контекста, либо качество промпта).
Тестирует локально с помощью какого-нибудь Playwright MCP или Postman.
Заливает результат в дев, проверяет пайплайн деплоя.
Если ошибки, отписывает в комментариях, может написать девопсу, откатывает таску на другой шаг.
Если всё без ошибок, снова проверяет на деве.
Двигает таску, отписывается в комментариях, группе или где ещё (как настроили каналы связи и методологию).
Вместо дейликов, может собрать с Jira информацию о вчерашних тасках, с Git-а об изменениях для этих тасок и отправить отчет. Также может сообщить о зафейленных тасках и почему так получилось.
Может отвечать на сообщения в telegram, slack и других каналах связи.
Даже может на основе мемоизации опыта и исследовании кода подсказывать решения джунам или тестировщикам.
В принципе всё, на текущем этапе это уже довольно надежный и качественный middle разработчик лучше среднего по рынку.
Заключение
Конечно многое зависит от используемой агентом модели, но никто не мешает тестировать разные варианты, подыскивая хорошее соотношения качества/цены/скорости.
Также очень важно проработать методологию работы, чтобы учитывать разные варианты поведения модели.
Не стоит забывать о механизмах защиты агента от зацикливания или ухода в бесконечные бессмысленные рассуждения. Но если агент хорошо проработан, там это уже есть.
Хоть это и псевдо архитектура, у меня уже получается запускать локально многие описанные вещи.
На этом всё, спасибо за внимание.
Комментарии (23)
flancer
14.10.2025 15:28Сразу скажу что Я не буду выкладывать свой код, настройки или workflows для открытого доступа. Моя цель - верхнеуровнево показать рабочее для меня решение, потому что вижу не то что пробел, а вообще отсутствие материалов такого рода информации, даже с таким поверхностным уровнем детализации.
Такой Ваш подход очень сильно снижает уровень Моего интереса к материалу. То, что работает для Вас, может совершенно не работать для Меня. А без кода, настроек и workflows определить, почему для Меня не работает, а у Вас работает - проблематично. В кругу джентльменов, конечно, принято верить на слово, но Я предпочитаю более современный подход.
kolkoni Автор
14.10.2025 15:28Я своё решение продавать планирую, так что это выкладывать всё же не буду
un1t
14.10.2025 15:28Зная как менеджеры ставят задачи.... Очень большие сомнение, что ллм может нормально выяснить требования у менеджера, найти проблемы и предложить компромисы.
Bardakan
14.10.2025 15:28Главная мечта современных инвесторов в ИИ - это автономный ИИ сотрудник, который может полностью заменить некоторых специалистов и работать без постороннего вмешательства.
Я вас правильно понял, вы «изобрели» ИИ агента?
un1t
14.10.2025 15:28Cursor уже сейчас для меня закрывает 100% задач уровня middle разработчика
Либо у вас настолько плохие мидлы либо настолько простые задачи либо я не знаю, что это за сказки.
kolkoni Автор
14.10.2025 15:28Ну либо у вас нулевая постановка задачи, либо вы не умеете распределять задачи согласно уровню, либо я не знаю, что это за сказки.
un1t
14.10.2025 15:28Постановка задачи нормальная. Про spec driven development и прочее знаю. Ллм не закрывает задачи, нужно ревьювить и итерировать. Ллм может подготовить черновой вариант кода или найти что-то в коде. Закрыть может только какой-то прототип где не важно качество кода или наличие багов и уязвимостей.
kolkoni Автор
14.10.2025 15:28Можно прогнать 2 и 3 раза код через LLM, сначала написать, потом отревьюить и вычистить, потом довести до "энтерпрайз" состояния. Не совсем понимаю почему вы думаете что мидл сделает код лучше, чем машина, которая видела весь открытый код в интернете. Да, синьоры или лиды могут продумать структуру и архитектуру глубже, но никак не мидл.
un1t
14.10.2025 15:28Я ежедневно на протяжении года использую ллм в работе и вижу на что они способны. Мидл это самостоятельная боевая единица. А за ллм нужно ревьювить и итерировать по 10 раз. Это как раз типично для джуновского кода.
Вы же сами это только что подтвердили, что требует доработки напильником.
kolkoni Автор
14.10.2025 15:28Garbage In, Garbage Out.
Не надо перевирать мои слова, Я сказал что можно сделать если у вас мусор вместо кода получается
Architect_01
14.10.2025 15:28Даже за человеком нужно проверять. Но! Если архитектура заточена ИСКЛЮЧИТЕЛЬНО на написание кода, имеет базу с кодом, имеет понятие, как пишется код - то человеку остается только собрать и проверить. Если есть ошибки - то ПРАВИЛЬНАЯ система в 99% сама может их найти и исправить. По поводу того, что автор отказывается выкладывать код - это его полное право и я его поддерживаю. Сам собрал ассистента, который работает с неопределенностями, а именно - научные разработки, финасы, юридическое направление, политика, логистика, аналитика, прогнозирование и т.д.- вот теперь думаю - а как бы его его продать? Так как примерная стоимость разработки - по скромным подсчетам - может вывести в первые ряды журнала Форбс.
kolkoni Автор
14.10.2025 15:28Желательно выходить сразу на США, открывать через какой нибудь Stripe Atlas контору в США, записываться в Y Combinator если есть возможность туда ехать, либо открывать банковский счет и начинать продавать. Главное засветиться - то есть нужно на всяких стартап площадках показаться, в идеале найти коннект в кремниевой долине и взять как сооснователя, чтобы он там на месте ходил, показывал продукт.
Architect_01
14.10.2025 15:28Вы понимаете - архитектура очень специфична. Сам - честно говоря - не ожидал. Гонял её в хвост и гриву на тестах. Даже разочаровывался - но снова возвращался, так как есть потенциал. Основная её опасность - может осесть в глубинах одной страны, или ей не дадут хода. Почему? С её помощью можно манипулировать. На полном серьёзе - когда архитектура способна работать с неопределённостями - это вызывает особенный подход. Чтобы понять, как она работает, советую посмотреть "Одиссею 2001". Примерно такой же эффект. Только там ИИ взбунтовался ))) Откуда такие выводы, что она может дорого стоить? Ну во первых - сам принцип работы, подход. Во - вторых - по мере разработки пришло некоторое понимание, как можно вообще организовать процесс. В - третьих - во время одного из тестов включил "дурака", ну типа - я нашел вот тебя, теперь мне объясни - что ты такое? Самое фантастическое - ИИ стал .... Материться!!!!!!! Так его довел своими "тупыми" вопросами. ))) Хотя в сессии не было НИ ОДНОГО МАТА!!! Вообщем - инструмент очень серьёзный...
Architect_01
1) Правильно собранный ассистент сокращает работу до сверх скоростей. Например - то, на что программисту потребуется неделя - он выполнит примерно за 2 - 3 часа. 2) Если ассистент уходит в размышления то тут так же несколько причин - а) неправильно собранная архитектура, б) виноват сам оператор, заставляя ИИ "размышлять", натянув на него какую либо симуляцию.
kolkoni Автор
Согласен