Наши аналитики почти перестали писать SQL руками и ходить к разработчикам с вопросом «а как работает эта фича». Сделал это инструмент, который мы строили для другого: он должен был сам закрывать задачи разработки. С исходной целью он провалился, и провалился интересно. Расскажу, где именно.
Почему вообще взялись
За полтора года команда ужалась почти вдвое. Задач меньше не стало. Бэклог при этом полон тикетов, которые выглядят механической работой: поправить текст ошибки, добавить поле в форму, изменить маппинг. План казался очевидным: собираем агенту максимум контекста о системе, отдаём ему простые задачи, люди занимаются сложными.
MVP я собрал в одиночку за 2 недели. Хотелось быстро проверить гипотезу, без замаха на платформу. Всё, что описано дальше, наросло на этот скелет уже по ходу.
Что построили
Чтобы агент писал код, он должен знать систему не хуже сеньора. Поэтому большую часть времени мы строили ему контекст:
забрали всю кодовую базу: ежедневный синк репозиториев плюс графы кода на tree-sitter (AST), чтобы агент ходил по коду точными переходами, без угадывания;
скормили схему БД и дали read-only доступ к базе;
перенесли знания из Confluence и переработали их в базу знаний, которая живёт от кода (об этом ниже, это отдельная история);
изменения из коммитов каждый день автоматически попадают в базу знаний, граф кода перестраивается каждые 2 часа.
Сверху веб-консоль: канбан задач, страница задачи с планом и диффом, просмотр и правка базы знаний, вкладка «спросить» с поиском по знаниям и коду в 4 фазы. Бонусом агент собирает еженедельные дайджесты изменений по каждому проекту прямо из коммитов.
База знаний, которая не протухает
У нас всегда была одна и та же болячка с Confluence: он не успевал за разработкой. Требования менялись быстрее, чем кто-то доносил их до вики, и любая статья по умолчанию требовала перепроверки. Классика: доке верить нельзя, поэтому всё равно идёшь к разработчику, а тот идёт в код.
Мы развернули это наоборот. Источником правды стал код, дисциплина документирования больше ни от кого не требуется. Каждый день агент прогоняет дневные коммиты и обновляет затронутые статьи базы знаний. Получились «нейростатьи»: доки, которые оперативно подтягиваются к реальному состоянию кода.
Важная деталь: то, что нейронка не может подтвердить по коду (договорённости с бизнесом, планы, устные решения), она не выдаёт за факт. Такие фрагменты подсвечены специальными блоками «не проверено по коду». Читатель сразу видит, где гарантия, а где память команды.
Итог этой части: от Confluence мы отказались полностью. Вики жила 5 лет, в ней накопилось 200+ статей: ТЗ, требования, ПМИ. Всё это переехало в базу знаний и теперь сверяется с кодом.
Где сломалось
Цель звучала как «агент закрывает простые задачи». Убил проект вопрос из пяти слов: а что такое простая задача?
Мы честно пытались ответить и не смогли. Один пример вместо теории. Задача: правки сторисов в нашем корпоративном мессенджере. Звучало как работа на вечер, агент даже справился. Правок по фиче было много, и мы отдавали их ему одну за другой. А потом открыли коммиты. За 6 итераций набралось около 2000 строк диффа там, где хватило бы трёхсот. Дешевле было переписать фичу с нуля, чем разобрать, что агент туда наслоил. «Простая задача» за несколько итераций превратилась в археологию.
Дальше включился второй слой: страх. Финтех, 1 млн+ пользователей, за каждой ошибкой реальные деньги. Каждый раз, когда мы почти решались отдать агенту боевой тикет, побеждало «а вдруг». В итоге агент, который умеет писать код, перестал получать настоящие задачи совсем.
Замечу: модель здесь ни при чём. Провал управленческий. Мы не смогли формализовать критерий доверия, и никакая LLM за нас это не сделает.
Пивот, который никто не планировал
Пока мы спорили о простых задачах, выяснилось неожиданное: инструментом вовсю пользуются аналитики. Сейчас он закрывает больше половины их запросов на исследования.
Раньше их путь выглядел так: вопрос «как работает эта фича» или просьба о выгрузке идёт к разработчику, и дальше ожидание. Могли ждать днями, пока у кого-то высвободится время на разбор логики или SQL-запрос.
Теперь аналитик задаёт вопрос во вкладке «спросить» и получает ответ, собранный по коду и базе знаний. Запросы тяжёлые, на сложном вопросе агент думает до 15 минут. Всё равно быстрее, чем ждать разработчика. Данные достаёт сам: у агента read-only доступ к БД. Разработчиков дёргают только там, где нужно что-то менять.
После четырёх фаз подключается отдельный агент-проверяющий. Если данных мало, он лезет в issues на GitHub и историю коммитов и проверяет, не менялось ли поведение. Пару раз именно это спасало от уверенного ответа по старой версии фичи.
Под капотом
Python 3.12 + FastAPI, SQLModel поверх SQLite с миграциями Alembic. Фронт SvelteKit + Tailwind, ответы стримятся через SSE. Графы кода строит tree-sitter: навигация по AST работает без LLM, модель подключается только там, где нужно понимание. Автоматизация держится на systemd-таймерах: пересборка графа, синк репозиториев, дайджесты. LLM подключена через провайдер-агностичный клиент, модель меняется конфигом. Через OpenRouter гоняем разные модели под разные работы: дешёвый Haiku делает разведку и собирает контекст, код пишет Opus. Платить дорогой моделью за grep смысла нет. Весь этот зоопарк обходится примерно в 200 долларов в месяц.
Про чувствительные данные: персональные данные наружу не уходят, перед отправкой во внешние API они маскируются, а ответ обогащается уже внутри контура. Как мы закрываем остальные риски работы агента с данными, тема отдельной статьи, она уже пишется.
Цифры
MVP: 1 человек, 2 недели.
Больше половины запросов аналитиков на исследования закрывается без разработчиков.
Ожидание ответа: было дни, стало до 15 минут.
Пользуются 3 аналитика, ~40 вопросов в неделю.
Расходы на LLM: ~200 $ в месяц.
У разработчиков высвободилось несколько дней в месяц.
Рутинное написание SQL-запросов руками: практически 0.
База знаний обновляется из коммитов ежедневно, Confluence выключен после 5 лет и 200+ статей.
Боевых задач разработки, закрытых агентом автономно: 0.
Что я понял про границы ИИ в разработке
«Простая задача» это свойство вашего знания о системе, а не свойство задачи. Пока знание размазано по головам, простых задач у вас нет.
Агент-разработчик упирается в доверие раньше, чем в качество кода. Кто ревьюит его дифф и кто отвечает за инцидент? Без ответа на эти вопросы неважно, насколько хороша модель.
Контекстная инфраструктура ценнее автоматизации. Базу знаний, графы кода и доступ к БД мы строили как фундамент для агента-разработчика. Фундамент оказался продуктом.
Начинать надо было с режима «спроси про систему»: он даёт пользу с первой недели и ничем не рискует. Режим «сделай за меня» требует зрелости процессов, которой у нас тогда не было.
Мы всё ещё хотим отдавать агенту задачи, следующий подход будет осторожнее. Когда дойдём, расскажу отдельно.
А пока вопрос к вам: у кого-нибудь получилось формализовать «простую задачу» так, чтобы не страшно было отдать её агенту? Расскажите в комментариях.
Про второй заход к агенту-разработчику, цену граблей и остальную кухню пишу в канале «Нейро CTO».
