---
title: "Шесть правок за полчаса: как ИИ-агент меняет мелкую разработку и где так делать нельзя"
canonical_url: https://evstygney.ru/articles/pravki-za-polchasa-ai-agent/
date_published: 2026-09-17
date_modified: 2026-09-17
author: Егор (https://evstygney.ru/about/)
summary: "Обезличенный кейс: шесть доработок внутреннего сервиса за один день, от 2,5 до 10 минут каждая — от сообщения ИИ-агенту до работающего результата. Хронометраж по журналу, ошибки агента, шесть условий, при которых так можно, случаи, когда нельзя, и шесть файлов с правилами, которые агент должен знать заранее."
tags: ["ИИ и инструменты", "Подрядчики и команда"]
---

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

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

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

**Простыми словами.** ИИ-агент — программа, которой задачу ставят обычными словами. Она сама читает код, вносит изменения, запускает проверки и выкладывает результат на сервер. Я пользуюсь Claude Code; прошлый кейс с ним — [аудит Директа за четыре часа](/articles/direct-audit-case-ai-agent/).

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

## Что за сервис

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

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

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

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

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

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

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

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

| Начало | Что просил | От сообщения до отчёта «работает» |
|---|---|---|
| 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%, и это похоже на разные каналы поставки. Написал: это вопрос не названия, а того, какую цену оператор назовёт клиенту, решайте сами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---
Автор: Егор, маркетинг на языке денег. Telegram: https://t.me/evstygney_ru. Все цифры — модельные прикидки, если не сказано иное.