Dmitry Zhdanov
67% тихих неудач очень похоже на то, что вижу у себя. У нас в разработке работают несколько ИИ-агентов, и самое частое «готово» без результата выглядит даже не как ошибка в данных, а как тест, который проходит при любом коде. Агент пишет тест, тест зелёный, отчёт честный, а если удалить саму правку, тест всё равно зелёный.
Помогло одно правило: каждую проверку сначала ломаем. Убираем исправление и смотрим, покраснеет ли тест. Не покраснел, значит «готово» не принимается. По сути то же, что у вас в выводах про проверку самой записи в базе, только применённое к проверкам.
Интересно, смотрели ли в ThinkingBox, меняется ли доля тихих неудач, если в инструкции прямо велеть агенту перечитать запись после изменения? Или раз 80% проблем в обработке вызовов инструментов, это почти не помогает?
Знакомая боль с переносом из чата в трекер. У нас доска задач плюс общий чат, и больше всего проблем было даже не с тем, что задачу забыли завести, а с тем, что решение приняли в переписке, а в карточке осталась старая постановка. Через неделю исполнитель честно делает по карточке, а все уже договорились иначе.
Помогло простое правило: кто принял решение в чате, тот одной строкой дописывает его в карточку. Не пересказ обсуждения, а только итог.
Интересно, как у вас с этим в Nubl: ответ на комментарий из Telegram попадает в задачу как комментарий или можно сразу поправить описание? И через MCP ИИ-инструмент может менять описание задачи или только комментировать?
Про код и рабочую систему выше уже сказали верно, добавлю то, на чём обычно спотыкаются именно с «ботом для записи клиентов за вечер». Сгенерировать его действительно можно за вечер, но перед тем как пускать туда настоящих клиентов, стоит проверить четыре вещи.
1. Где он живёт. Бот на ноутбуке работает, пока ноутбук открыт. Нужен сервер или хостинг с автоперезапуском, иначе ночная запись просто не дойдёт.
2. Где лежит ключ. Ключ API и токен бота — в отдельном файле настроек, а не в коде, и этот файл не должен попасть в публичный репозиторий. ИИ-помощники охотно вписывают ключ прямо в код.
3. Персональные данные. Имя и телефон клиента — это персональные данные. По 152-ФЗ их первичная запись должна идти в базу на территории РФ, а если вы отправляете их в промпт зарубежной модели — это уже трансграничная передача, о которой нужно уведомлять РКН. Тезис «всё остаётся на вашем ноутбуке» здесь не работает: запросы к DeepSeek уходят на его серверы.
4. Что будет при ошибке. Попросите отдельно: если бот упал или ответил ошибкой, клиент должен увидеть понятное сообщение и контакт, а вам — прийти уведомление. Без этого о поломке узнаете от недовольного клиента через неделю.
С этими четырьмя пунктами связка вполне годится для внутренних автоматизаций и прототипов, а вот с клиентскими данными я бы без них не запускал.
Для ботов это, кажется, важнее, чем для каналов. Сейчас, чтобы показать клиенту карточку объекта или выбор времени записи, приходится либо собирать всё из инлайн-кнопок (и каждое нажатие — новое сообщение или перерисовка), либо открывать мини-приложение, а это отдельный экран и отдельная вёрстка. Виджет прямо в сообщении закрыл бы середину: выбрать дату, переключить вариант, отправить — не выходя из чата.
Главный вопрос — дадут ли это ботам через Bot API или оставят под свои сценарии вроде ответов ИИ. И как ограничат JS: если пересланное сообщение сможет исполнять скрипт, обсуждать будут уже не удобство, а безопасность.
Из нашей практики: у нас небольшая студия, и бóльшую часть кода пишут ИИ-агенты. «Мясным прокси» себя чувствуешь, когда работа человека сводится к кнопке «принять».
Нам помогло отдать человеку то, что агент за него не сделает: проверять, что тест действительно ловит поломку. Ломаешь руками строку, которую правка якобы чинит, и смотришь, покраснеет ли тест. «Зелёные» тесты, которые ничего не проверяют, у агентов попадаются регулярно: то формулу переписали внутрь теста, то проверяют подпись на экране вместо значения, которое уходит на сервер.
Это уже инженерная работа, а не прокси, и выгорать от неё как-то меньше.
Ошибка контекста после переключения между тикетами, по-моему, самое коварное в ручной работе с продом. Тут никакая внимательность не спасает.
Кроме админки, нам сильно помог режим «сначала показать» у каждой опасной операции. Скрипт или кнопка сначала выводит, что именно изменится: какой клиент, сколько записей, что было и что станет. Применяется только второй командой. Пока сам не прочитал «удалю 1 аккаунт, ООО такое-то», ничего не происходит.
А как вы убедили руководство выделить время на внутренние инструменты? Обычно такие задачи проигрывают фичам, пока не случится свой инцидент.