Про агентов, которые «пишут код за вас», написано столько, что читать уже неловко. Почти всё это демки: todo-лист, тестовое, чистый репозиторий, автор рядом с рукой на мышке. Мне было интересно другое: что будет, если посадить агента на живой проект, где данные между сайтом и 1С ездят по расписанию, заказы принимают настоящие менеджеры, а сломанная цена доходит до тебя звонком от клиента.
Ниже двенадцать рабочих дней такого опыта: с 26 августа по 8 сентября 2026, один b2b-портал, четыре разобранные поломки и четыре места, где агент ошибается предсказуемо. Про поломки интереснее всего, как их вообще заметили: чинить их было обычной работой. Про ошибки наоборот: они повторяются, и под каждую пришлось ставить свою страховку.
Проект
Оптовый поставщик отделочных материалов: три бренда, около полутора тысяч позиций, тридцать человек в офисе. Закрытый портал для клиентов-юрлиц. Каталог, цены, остатки и заказы ходят между сайтом и 1С по расписанию, по штатному протоколу обмена.
До портала жизнь выглядела так: менеджер раз в день выгружал прайс в Excel, рассылал клиентам письмом, заказы забирал с почты и вбивал в 1С руками. Заказ, пришедший в шесть вечера, попадал в учёт следующим утром.
Обмен с 1С ломается ровно там, где стыкуются две чужие системы, и ломается тихо. Никто не звонит, ничего не падает, просто где-то не та цена. Вот эта тишина и была основной работой.
Что происходило эти двенадцать дней
За период набралось 456 рабочих заходов, примерно 38 в сутки: агент не ждёт утра понедельника. Из них 235 закрытых задач, 105 заявок на вливание кода, 28 выкатов на боевой сервер.
Цифры сами по себе ничего не доказывают: 456 заходов легко набить, если ходить кругами. Смотреть надо на то, что именно чинилось.
Ноль из 1С затирал настоящую цену
Симптом: на карточках вместо цены ноль, хотя вчера цена была.
У части номенклатуры базовая цена в 1С просто не заполнена: позицию заводят под заказ, цену ставит менеджер руками. В выгрузку такая позиция попадает всё равно и приезжает нулём. Код на стороне сайта честно записывал то, что приехало.
Тут важно, что агент не остановился на первом рабочем варианте. Первый час он держал заплатку if (price > 0). Она снимает симптом и ломается ровно тогда, когда у клиента появится товар за рубль или подарок за ноль. Разговор пошёл дальше: у каждого поля есть хозяин. Цена закупки, розничная цена, остаток, название приезжают из разных мест, часть полей редактирует менеджер на сайте. Как только это записано, поведение при пустом значении перестаёт быть вопросом вкуса: поле, чей источник 1С, пустым значением очищается, поле, чей источник сайт, пустым значением не трогается вовсе.
Дальше самое полезное. После выката он вместо «готово» пошёл считать результат на боевом: цена вернулась у семи карточек из восьми, у восьмой её нет и в самой 1С. Восьмая не недоделка, это ровно тот случай, ради которого правило и писалось.
Номер заказа с пробелом
Менеджер берёт номер из 1С, вбивает в поиск на портале и не находит ничего. Заказ при этом есть и открывается по прямой ссылке.
Номер лежал в базе с концевым пробелом, поиск на портале ищет по точному совпадению, и пробел, приехавший вместе с данными, превращает живой заказ в ненайденный, хотя глазами в таблице всё на месте. Из 1С регулярно приезжают концевые пробелы, неразрывный пробел вместо обычного, разный регистр в артикулах: поля заполняют люди в интерфейсе без валидации.
Такое живёт в бэклоге месяцами, потому что не горит: система работает, данные целы, всего-то пробел, и любой разработчик честно ставит задачу в конец очереди. А для человека, который ищет заказы двадцать раз в день, это отказ поиска.
Ночная выгрузка шла дважды
За ночь в учёте оказывалась вторая копия заказов, потому что крон запускал выгрузку два раза.
Причина скучная, но вывод из неё не про крон. Двойной запуск в принципе не должен приводить к дублям: протокол обмена сам требует повторов (ответ progress означает «пришли этот же запрос ещё раз»), 1С переспрашивает после таймаута, админ жмёт «обменяться сейчас» поверх расписания. Повтор сеанса тут норма, и идемпотентность из украшения превращается в условие работоспособности.
Проверка опять же по факту: в ночь на 8 сентября выгрузка стартовала один раз. Не «должна стартовать», а стартовала, по журналу запусков.
Витрина второго бренда не собралась
Сборка отменилась из-за занятой очереди, направления на главной не появились, и заявки от клиента про это не было вовсе: агент увидел пустую витрину сам, перезапустил сборку и дождался, пока все восемь направлений встанут на место.
Вот это, на мой взгляд, интереснее всего остального. Половину поломок ему никто не приносил.
Где агент ошибается и что с этим делать
Теперь неприятная часть. Ошибается он предсказуемо: у него несколько устойчивых режимов отказа, и каждый лечится устройством процесса, уговорами тут ничего не сделаешь.
«Кажется, работает». Самый частый и самый дорогой. Модель охотно объявляет задачу сделанной, когда код написан и выглядит правильным. Лечится только тем, что критерий готовности задан заранее и проверяется машиной или живым запросом: не «поправил обработку цены», а «на боевом было восемь карточек с нулём, стало ноль таких карточек, кроме одной, где цены нет в 1С». Формулировка критерия это работа человека, и это, пожалуй, главное, что от вас требуется.
Зелёные тесты вместо живой страницы. Агент смотрит в CI, а у витрины своя жизнь: очередь сборки, кеш, права роли. Правило, которое мы вывели болью: результат смотрится глазами того, кто им пользуется, и под его правами. У админа видно всё, у менеджера и клиента выборки разные. Под админом страница собиралась, под клиентом второго бренда нет.
Правка симптома вместо причины. История с if (price > 0) типовая. Модель отлично находит место, где значение перетирается, и отлично пишет проверку прямо там. Вопрос «а кто вообще хозяин этого поля» она сама себе не задаёт. Задавать приходится в постановке.
Правка, которую ночью перезапишет чужой процесс. Поправили значение руками, а утром оно вернулось: его пишет ночной обмен. Перед правкой поля надо найти всех, кто его читает и пишет: кроны, обмен, админку, миграции. Для агента это не инстинкт, это пункт в процедуре.
И отдельно про необратимое. Выкат на боевой и миграции боевой базы стоит держать за подтверждением человека, а переписку с заказчиком агенту лучше не отдавать вовсе: пусть готовит черновик, отправляет человек. Дело тут в цене ошибки: код можно откатить, письмо клиенту уже нет.
Чего это стоит по инфраструктуре
Если коротко: агент выгоден настолько, насколько у проекта уже есть механическая проверка. Ему нужны тесты, которые гоняются одной командой, заявки на вливание вместо коммитов в main, читаемый журнал выкатов и возможность посмотреть боевое своими глазами. На проекте, где всё это есть, агент закрывает поток мелочи, до которой у людей не доходят руки месяцами. На проекте, где проверить результат можно только руками старшего разработчика, он превращается в генератор заявок на ревью и становится дороже, чем польза.
Вторая вещь, которая оказалась важнее ожидаемого: контекст проекта должен где-то жить. Держать его надо в файлах рядом с кодом: кто хозяин каких полей, что нельзя трогать, чем проверяется готовность. Голову модели выкидывают каждую сессию. Это обычная документация, просто её теперь читает не только новый сотрудник.
Чего он не заменяет
Он не заменяет разговор с заказчиком. Не решает, что делать с позицией, у которой цены нет и в 1С. Не принимает решение «переводим клиентов на другую формулу цены». Он его исполняет после встречи.
Что он делает хорошо: держит поток задач, на который у человека не хватает внимания, и замечает поломки раньше менеджера. Для портала, который каждый день разговаривает с 1С, этого оказалось достаточно, чтобы менеджеры перестали перепечатывать заказы с почты.
Если у вас похожий обмен и вы ловили другие тихие поломки, расскажите в комментариях: мне интересно, какие ещё места ломаются молча.