The post has been translated automatically. Original language: Russian
This is a translation of my LinkedIn article.
The main dream of modern AI investors is an autonomous AI employee who can completely replace some specialists and work without outside interference.
In my opinion, this is already a completely achievable goal, which is achievable with the current level of technology.
I'll give you an example in a field close to me - programming (but generally applicable to most digital professions). Let's make an autonomous AI middle backend developer.
We will do it on a local server machine, inside the company's contour.
Immediately I will say that I will not post my code, settings or workflows for open access. My goal is to show a top-level solution that works for me , because I see not just a gap, but a lack of materials of this kind, even with such a superficial level of detail.
Preparation
To begin with, we will need a complete Job Description of the employee, the data that he needs to know, the tasks that he needs to perform, as well as communication channels through which to interact with him. The benefit The removal has paid off and everyone has learned how to interact with employees in digital ways.
Formalizing accesses to Git - ssh keys, to Confluence and Jira API keys, tokens for telegram, slack or something else (be it mail or any other communication channels). We write all this into an arbitrary json config file in the directory where the employee will work (the root of the agent launch).
We'll install docker on the server and run n8n, a vector database, and some kind of relational database like PostgreSQL.
For n8n, we will give access to the working directory.
Customization
Let's set up communication channels - in n8n, we'll add triggers to the necessary communication channels so that messages fly to our agent and he can return responses. But we will not be pulling the usual LLM model, namely through a hook or a custom node to pull the local agent.
The Agent
The most difficult part is agent development. But the agency level of a Cursor is enough for the eyes, the main thing is to make methodologically correct promptings.
Another important step is setting up MCP tools for the agent - searching and scraping information, working with Jira, Confluence, Git , etc. So that our AI employee has hands and eyes.
You also need a RAG mechanism to memorize important things like it is correct to solve a problem of this kind or how to find such information correctly. What exactly is important can be decided by the agent himself with a simple prompt like:
Highlight important successful decisions from the current session to memorize them.
This is necessary for our AI employee to gain experience. A relational database is needed to accumulate "rules of conduct" when a supervisor is unhappy with something and says "don't do that anymore," or vice versa, "do it this way."
Methodology
The most important and, most likely, voluminous part of the work is to formalize the methodology of our employee's work (in a good way, all this should already be be described in the Job Description).
The work is divided into 2 stages
- filling the RAG with important knowledge. Roughly speaking, we are thrusting the onboarding process into the RAG.
- schedule setup - in n8n, we set up cron triggers, let's say at 9 a.m. go to Jira and see the new tasks assigned to me, analyze and either start execution or unsubscribe in the comments.
How it all works
Let's look at the example of our AI middle developer.:
- He logs into Jira on schedule, pulls off his tasks.
- Checks the task for completeness and feasibility, and if something is missing, reports it in the comments.
- Checks the necessary environment - network access, access to the code, the ability to work with Git, etc.
- Performs the task. With a normal description, Cursor already closes 100% of tasks at the middle developer level for me (if you don't have it, then either the completeness of the context or the quality of the product suffers).
- It tests locally using some kind of Playwright MCP or Postman.
- Uploads the result to dev, checks the pipeline deployment.
- If there are errors, he unsubscribes in the comments, can write to the developer, rolls back the task to another step.
- If everything is correct, it checks on virgo again.
- He moves the task, unsubscribes in the comments, group, or wherever else (as the communication channels and methodology have been set up).
- Instead of data, he can collect information from Jira about yesterday's tasks, and from Git about the changes for these tasks and send a report. They can also tell you about captured tasks and why this happened.
- Can respond to messages in telegram, slack and other communication channels.
- It can even suggest solutions to junos or testers based on memoization of experience and code research.
Basically, that's it, at the current stage it is already a fairly reliable and high-quality middle developer better than the average in the market.
Conclusion
Of course, a lot depends on the model used by the agent, but no one bothers to test different options, looking for a good ratio. quality/price/speed.
It is also very important to work out the methodology of the work in order to take into account the different behaviors of the model.
Do not forget about the mechanisms to protect the agent from looping or going into endless meaningless reasoning. But if the agent is well-developed, it's already there.
Although this is a pseudo architecture, I am already able to run many of the described things locally.
That's it, thanks for your attention.
Это перевод моей статьи в 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 разработчик лучше среднего по рынку.
Заключение
Конечно многое зависит от используемой агентом модели, но никто не мешает тестировать разные варианты, подыскивая хорошее соотношения качества/цены/скорости.
Также очень важно проработать методологию работы, чтобы учитывать разные варианты поведения модели.
Не стоит забывать о механизмах защиты агента от зацикливания или ухода в бесконечные бессмысленные рассуждения. Но если агент хорошо проработан, там это уже есть.
Хоть это и псевдо архитектура, у меня уже получается запускать локально многие описанные вещи.
На этом всё, спасибо за внимание.
Share
