ШІ-агент на власному сервері: що він уміє і чого йому не можна дозволяти ніколи

Агент, який читає ваш код, запускає тести й пропонує зміни, — чудовий колега. А ще це програма з доступом до командного рядка. Ось як ми отримуємо перше так, щоб друге не вийшло з-під контролю.

Чому власний сервер

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

• ваш код і тестові дані лишаються там, де вони вже є;
• агент працює за правилами, які можна прочитати у файлі, а не на чужій сторінці налаштувань;
• усе, що він робить, лишає слід: файли на диску, коміти в 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 і без секретів робочого середовища.
• Лише тестові дані: копія або анонімізований дамп.
• Кожне завдання — у гілці; зливає лише людина, і це забезпечує хостинг репозиторію.
• Тести, що запускаються однією командою.
• Короткий файл правил у репозиторії, який читають і агент, і люди.
• Людина, яка пише завдання й приймає результат.

Ми щодня так працюємо над власними проєктами. Якщо хочете так само на своєму сервері, надішліть нам запит.