Разработка с ИИ-агентом: шесть правок за полчаса, кейс

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

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

TL;DR За один день ИИ-агент внёс шесть доработок во внутренний сервис. Каждая заняла от 2,5 до 10 минут, в сумме 30 минут 19 секунд. Время считал по журналу сессии: от моего сообщения до отчёта «работает, проверено». Так получилось, потому что сошлись шесть условий, а осторожность агента была записана в правилах заранее. Для продукта с выручкой и для кода, в котором работают другие люди, этот способ не годится. Условия, ограничения и сами правила — во второй половине текста.

Простыми словами ИИ-агент — программа, которой задачу ставят обычными словами. Она сама читает код, вносит изменения, запускает проверки и выкладывает результат на сервер. Я пользуюсь Claude Code; прошлый кейс с ним — аудит Директа за четыре часа.

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

Что за сервис

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

Размер — около 2 400 строк кода. Один сервер, пилот на живых операторах. Сервис собран тем же способом за один день, тремя неделями раньше. Я маркетолог, не разработчик: код в этом сервисе целиком написан агентом.

Как эта правка шла бы обычным путём

Поиск по списку — задача на полдня работы разработчика. Календарь у неё другой:

Завести тикет и описать, что нужно.
Дождаться уточняющих вопросов: «а русский ввод — это транслит или словарь?»
Получить оценку.
Попасть в планирование и встать в очередь за задачами, у которых есть выручка.
Разработка, проверка кода, тестирование, выкладка.

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

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

Хронометраж дня

Начало	Что просил	От сообщения до отчёта «работает»
10:35	Перенести сервис на нормальный адрес с сертификатом	23 мин, из них 17 ждали серверы доменных имён
11:25	Создание логинов для операторов в админке	4 мин 35 с
15:04	Поиск по брендам и моделям с русским вводом	9 мин 51 с
15:16	Один бренд в списке двумя пунктами	2 мин 28 с
15:20	Нижний порог цены и наценка на один из двух источников	3 мин 58 с
16:35	Галочка «Только Китай» и колонка «Страна бренда»	5 мин 58 с
16:47	Одна модель под двумя брендами	3 мин 29 с

Шесть правок сервиса — 30 минут 19 секунд и 122 действия агента: прочитать файл, выполнить команду, запустить проверку. Перерывы между строками таблицы — это я: смотрел результат, занимался другими делами, придумывал следующую правку.

Что помещается в девять минут

Расскажу про поиск, он самый длинный.

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

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

Я за это время читал короткие сообщения о ходе работы и ни разу не вмешался.

Где агент спорил со мной

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

У 43% строк первого источника минимум после наценки становился выше максимума: вилка, в которой «от» больше, чем «до». Он добавил правило, по которому максимум подтягивается к минимуму. Ещё у 29 позиций вся вилка лежала ниже порога. По моему правилу они стали показывать цену, которой в природе нет. Агент сделал буквально, как я сказал, и первым абзацем отчёта написал: вот два последствия, решение за вами. Второе я до сих пор не принял.

С дублем получилось похоже. Я попросил склеить модель, которая шла под двумя брендами. Агент проверил по открытым источникам, что это один и тот же производитель, и склеил. Потом сам прошёлся по всем данным в поисках таких же пар и нашёл ещё одну. Её не тронул: цены под двумя названиями расходились на 15–20%, и это похоже на разные каналы поставки. Написал: это вопрос не названия, а того, какую цену оператор назовёт клиенту, решайте сами.

Где агент ошибался

Как минимум четыре раза за день. Обо всех четырёх я знаю только потому, что он сам о них написал.

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

Замечание Три ошибки из четырёх поймала одна и та же привычка: прогнать на копии, сравнить «до» и «после», посмотреть глазами. Четвёртую агент нашёл, когда перепроверял вручную то, что должен был поймать сторож. Скорость держится на этих проверках. Я бы на шестой правке за день начал их пропускать, агент делает их каждый раз.

Почему здесь так можно

Сошлись шесть условий.

Один человек — заказчик, владелец и приёмщик. Согласовывать не с кем. Тикеты существуют в первую очередь для согласования, а тут оно не нужно.
Сервис маленький и стоит отдельно. 2 400 строк. От него не зависят другие системы, в его коде не работают другие люди.
Всё обратимо. Исходные данные правки не трогают, таблица для операторов пересобирается из них заново. Перед каждой выкладкой — резервная копия, откат — одна команда, и она записана.
Пилот. Пользователи переживут трёхсекундный перезапуск посреди дня.
Сервис не принимает деньги и не хранит данные клиентов. Он показывает цены.
Результат проверяется глазами за минуту. Открыл, набрал «сяоми», увидел.

Уберите любое из шести, и способ начинает ломаться.

Где так нельзя

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

Общий код Если в нём работают другие люди, очередь и планирование защищают их работу от вашей срочной правки.

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

Когда результат нельзя оценить самому. Поиск я проверил глазами. Устойчивость под нагрузкой или дыру в авторизации глазами не проверишь. Здесь я полагаюсь на проверки, которые агент пишет сам, и на те самые правила. Для пилота это приемлемо, для продукта нет.

Плохие идеи проходят так же быстро, как хорошие. Правило с порогом цены уехало в рабочий сервис через четыре минуты после того, как пришло мне в голову. На планировании кто-нибудь спросил бы: «А точно показывать цену, которой нет?» Агент тоже спросил, но уже после выкладки. Очередь раздражает, и она же работает как фильтр. Без неё паузу на «подумать» придётся ставить себе самому.

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

Знание живёт в одной голове Инструкцию по эксплуатации агент обновлял после каждой правки, она подробная. Кроме меня её никто не читал.

Моё внимание не бесплатно Тридцать минут — время агента. Мой день с этим сервисом шёл с 10:35 до 17:00: читал отчёты, проверял результат, принимал решения.

Как повторить у себя

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

У меня таких файлов шесть.

1. Правила безопасности: что нельзя никогда. Десять пунктов. Сервис не запускается с правами администратора. В интернет смотрит только веб-сервер, само приложение — нет. Вход закрыт по умолчанию. Всё, что ввёл пользователь, проверяется по белому списку. Пароли и ключи не попадают в переписку, код и журналы. В конце — список проверок, без которых выкладка запрещена. Файл написан после июньского взлома, и в разделе «как делать нельзя» перечислено ровно то, через что меня взломали.

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

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

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

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

6. Решения по продукту. Что сервис показывает и чего не показывает никогда, какие бизнес-правила приняты и кем. Без этого файла «мелкая правка» легко ломает договорённость, о которой агент не знал.

Лайфхак Каждая пойманная ошибка в тот же день становится строкой в правилах. Сегодня так появились три. «Проверка синтаксиса не замечает пропавших блоков: сравнивай файл до и после». «Правку логики данных сначала прогоняй на копии рабочей базы и смотри, какие строки изменились». «Прежде чем ставить диагноз, посмотри в сырых данных, откуда пришла строка». Следующая сессия начнёт уже с ними, и те же грабли агент обойдёт сам, без меня.

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

С чего начать:

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

Замечание Правила работают, пока вы сами понимаете, что в них написано. Свои десять пунктов безопасности я могу объяснить, поэтому замечу, если агент их нарушит. Правила, списанные у кого-то целиком и непрочитанные, защищают слабо: проверить их исполнение будет некому.

Краткие выводы

Шесть доработок внутреннего сервиса заняли 30 минут 19 секунд работы агента: от 2,5 до 10 минут каждая, включая проверку на копии, резервную копию, выкладку и запись в инструкцию.
Скорость дали шесть условий: один владелец, маленький отдельный сервис, обратимость, пилот, нет денег и клиентских данных, результат виден глазами.
Агент ошибся как минимум четыре раза за день. Три ошибки поймала проверка на копии со сравнением «до» и «после», четвёртую — ручная перепроверка. Проверки он делает каждый раз.
Осторожность агента записана заранее: правила безопасности, паспорт сервера, порядок выкладки, журнал действий, инструкция по эксплуатации, решения по продукту. Каждая пойманная ошибка в тот же день становится строкой в правилах.
Агент считает последствия на настоящих данных и пишет о них прямо, но решение оставляет человеку. Одно из двух таких решений я за день так и не принял.
Вместе с очередью исчезает пауза, в которой отсеиваются плохие идеи, а несохранённые изменения копятся так же быстро, как правки.

Откуда брали данные Журнал сессии ИИ-агента: время каждого моего сообщения и каждого ответа с точностью до секунды, число действий агента. Журнал действий на сервере и время резервных копий перед выкладками. Оценка «одна-три недели обычным путём» — моя прикидка, не замер.

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