ИИ-агент на своём сервере: что он умеет и чего ему нельзя позволять никогда

Агент, который читает ваш код, запускает тесты и предлагает изменения, — отличный коллега. А ещё это программа с доступом к командной строке. Вот как мы получаем первое так, чтобы второе не вышло из-под контроля.

Почему свой сервер

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

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

Сервер не обязан быть большим. Самое тяжёлое «мышление» происходит у поставщика модели; сервер запускает инструменты, тесты и Git. Небольшой виртуальной машины с несколькими гигабайтами памяти для одного проекта вполне достаточно.

Что он делает хорошо

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

Чего он не должен делать никогда

Правила ниже — не о том, что агент злонамерен. Они о том, что он уверен в себе и иногда ошибается, а это опасное сочетание рядом со всем, что работает вживую.

• Хранить секреты рабочей среды. Никаких паролей к рабочей базе данных, никаких платёжных ключей, никаких данных клиентов. Дайте ему тестовую копию и анонимизированный дамп.
• Пушить в основную ветку, выкатывать релизы или отправлять что-то клиенту. Его работа заканчивается веткой и pull request.
• Работать как root или как пользователь, под которым работает ваш рабочий сайт. Он получает своего пользователя и никакого sudo.
• Решать, что работа выполнена. Задание пишет человек, и результат принимает человек.

Агент предлагает. Человек читает изменение, запускает его и решает.

Настройка

Ничего экзотического: отдельный пользователь, папка проекта, Git как страховка.

# свой пользователь, без sudo
sudo useradd --create-home --shell /bin/bash agent

# проект — клон, который агент может менять
sudo -u agent git clone git@github.com:you/project.git ~agent/project

# каждое задание — в своей ветке
git switch -c agent/fix-invoice-rounding

На хостинге репозитория защитите основную ветку: изменения попадают туда только через pull request с одобренным ревью. Дайте ключу или токену агента право пушить ветки и открывать pull request — и ничего больше. Если он не может сливать изменения, неудачный день останется в ветке.

Файл правил, который он читает первым

Большинство агентов для программирования перед началом читают файл в репозитории: что это за проект, как запускать тесты, какие папки не трогать, как называть ветки. Держите его достаточно коротким, чтобы его читал и человек. Хороший файл помещается на один экран:

# Правила проекта
- PHP 8.5, без Composer. Тесты: `php tools/run-tests.php`.
- Никогда не редактируй `config/live.php` и ничего в `uploads/`.
- Одно задание — одна ветка — один pull request. Объясняй изменение простым языком.

Тесты, которые запускаются одной командой

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

Обычный день

1. Человек пишет задание: что есть, что должно измениться, как мы поймём, что оно работает. (Об этом у нас есть отдельная статья: Как написать техническое задание, которое разработчик не поймёт неправильно.)
2. Агент работает в своей ветке, запускает тесты и исправляет то, что они находят.
3. Он открывает pull request со сводкой простым языком: что изменилось, почему и в чём он не был уверен.
4. Человек читает diff, пробует изменение на тестовом сервере и сливает его или возвращает с комментарием.

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

Сколько это стоит, честно

Поставщик модели берёт плату за использование, так что насыщенная неделя стоит дороже спокойной. Сервер стоит столько, сколько стоит небольшой сервер. Настоящий расход — проверка: человек должен прочитать каждое изменение. Это не накладные расходы, которые надо оптимизировать. Это и есть работа.

Чек-лист

• Отдельный пользователь без sudo и без секретов рабочей среды.
• Только тестовые данные: копия или анонимизированный дамп.
• Каждое задание — в ветке; сливает только человек, и это обеспечивает хостинг репозитория.
• Тесты, которые запускаются одной командой.
• Короткий файл правил в репозитории, который читают и агент, и люди.
• Человек, который пишет задание и принимает результат.

Мы каждый день так работаем над собственными проектами. Если хотите так же на своём сервере, отправьте нам запрос.