Небольшая IT-компания, занимающаяся автоматизацией бизнес-процессов, однажды обнаружила, что автоматизирует чужие процессы, но не свои. Вся операционная нагрузка держалась на CEO: он отвечал на повторяющиеся вопросы, формулировал задачи разработчикам и следил за клиентами. Решением стал ИИ-ассистент прямо в рабочем Telegram-чате — не как эксперимент, а как рабочий инструмент.
Технически бот устроен без экзотики: Python-обработчик сообщений, фильтрация по упоминаниям и ключевым словам, сборщик контекста из последних сообщений ветки — и обычный API-вызов к Claude. Никакого файн-тюнинга, никаких собственных моделей. Авторы подчёркивают: 90% результата определяет не выбор модели, а то, какой контекст ей передаётся. Бот видит историю переписки, индексированную кодовую базу на PHP, базу клиентов через SQL-запросы и GitHub Issues. Это принципиально отличает решение от стандартных чат-ботов, которые работают только с заранее подготовленной документацией.
| Метрика | Значение |
|---|---|
| Сообщений от ИИ в чате | ~2500 |
| Задач создано на GitHub | ~120 |
| Вопросов менеджеров закрыто без CEO | ~60% |
| Среднее время ответа | 15-40 секунд |
| Критичных ошибок (hallucination -> инцидент) | 3 |
Самый частый сценарий — менеджер получает вопрос от клиента и раньше ждал ответа от разработчика часами. Теперь бот находит нужный контроллер в коде, проверяет валидацию и даёт конкретный ответ. В приведённом примере ИИ обнаружил, что TemplateController обрезает HTML-теги через strip_tags(), но принимает plain-text URL — и объяснил это менеджеру за 30 секунд. Команда оценивает экономию примерно в 30 человеко-часов в неделю только на таких вопросах.
Доступ к коду позволяет отвечать на вопросы клиентов напрямую: ИИ находит нужный контроллер и объясняет поведение за 30 секунд.
Второй сценарий оказался неожиданным даже для самой команды. Когда CEO написал в чат «Ром, выпиши задачу Диме», бот прочитал всю ветку обсуждения, нашёл в коде существующую реализацию хеширования фотографий, понял, что она изолирована от модуля анализа конкуренции, и сформулировал GitHub issue с конкретными алгоритмами — Hamming distance для сравнения хешей, метриками TP/FP/FN для валидации, предложением проверить 10 000+ пар. Задача такого уровня детализации обычно требует 30–40 минут работы техлида.
Третий сценарий — автоматический changelog после каждого деплоя. Бот пишет в чат не абстрактное «обновлён модуль», а конкретный список изменений: что именно поменялось в логике непрочитанных сообщений, какие элементы интерфейса убраны, что заблокировано на уровне mailbox. Команда оценивает это в 15 сэкономленных минут после каждого релиза плюс документированный след в истории чата.
Авторы честно перечисляют и провалы. Межсистемные баги, где проблема находится на стыке нескольких сервисов, бот диагностирует неточно — находит код каждого компонента, но не понимает их взаимодействие в runtime. Длинные обсуждения с перерывами теряются: контекстное окно большое, но за три дня активного чата в него не помещается всё. Главный риск — галлюцинации: в одном из случаев бот уверенно сообщил менеджеру, что функция импорта из Excel уже реализована, хотя её в продукте никогда не было. Бизнес-решения и эмоциональная поддержка сотрудников остаются за людьми.
