“Другие модели продолжали указывать на одно и то же снова и снова, даже после того, как мы это исправили. Когда мы попробовали Enter Pro, она разобралась, в чем была реальная причина”.

WhyVenv создала Kronos, автономного агента реагирования на инциденты для Quackathon, чтобы помочь инженерам быстрее переходить от ошибок в продакшене к первопричине.

Пейджер — это только начало

Когда в продакшене что-то ломается, само оповещение редко бывает самой сложной частью.

Grafana может сообщить вам, что что-то упало. Логи могут показать, что произошел сбой. Дашборд может мигать красным достаточно громко, чтобы разбудить кого-то в 2 часа ночи.

Но после этого начинается настоящая работа.

Инженеру все равно нужно открыть логи, понять ошибку, изучить кодовую базу, угадать, какая функция имеет значение, решить, является ли проблема срочной, и понять, что делать дальше: создавать GitHub issue, выпускать патч или запускать полную эскалацию.

Этот разрыв между знанием о том, что что-то сломалось, и пониманием того, что именно сломалось, — это то место, где реагирование на инциденты становится мучительным.

Именно в этом разрыве Dawood Khan нашел идею для Kronos.

Dawood изучал ИИ, но после университета переключился ближе к системной инженерии. Его интерес не был абстрактным. Он видел, как выходят из строя производственные системы, как реагируют команды и сколько ручного исследования все еще требуется между оповещением и исправлением.

На мероприятии Grafana в Хайдарабаде проблема стала еще более очевидной. Инженеры описывали один и тот же сценарий: система падает, кто-то получает звонок, а затем команда начинает привычную работу по ручному отслеживанию сбоя.

Quackathon стал моментом для создания чего-то другого. Разработанный WhyVenv, Kronos занял второе место на Quackathon, выделившись в категории Track 01: Software - The Sentient Workspace за превращение реагирования на инциденты в продакшене в агентный рабочий процесс.

Что создали WhyVenv

Проектом WhyVenv был Kronos, автономный агент реагирования на инциденты, созданный для трека Sentient Workspace на Quackathon.

Идея была простой, но амбициозной:

Kronos получает ошибки из продакшена, читает логи, извлекает соответствующий код, запрашивает у модели ИИ диагностику вероятной первопричины, а затем решает, что должно произойти дальше.

Иногда это означает создание GitHub issue.

Иногда, в зависимости от серьезности проблемы, это означает попытку исправления.

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

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

Kronos был создан для автоматизации этого промежуточного уровня.

Инженерное видение, стоящее за Kronos

“Частью, которой я больше всего гордился, был этап извлечения. Вместо того чтобы использовать только AST или эмбеддинги, мы работали с логами трассировки, потому что именно так инженеры обычно находят проблему”.

Частью, которой Dawood гордился больше всего, был не дашборд, не интеграция с GitHub и даже не диагностика ИИ.

Это был этап извлечения.

Многие ИИ-системы для работы с кодом пытаются понять кодовую базу через эмбеддинги, парсинг AST или загрузку широкого контекста. Kronos пошел по более привычному для инженеров пути: начать с логов трассировки и использовать их для сужения поиска.

Этот выбор имеет значение.

Когда инженеры отлаживают сбои в продакшене, они редко начинают с того, что просят модель ИИ прочитать весь репозиторий. Они смотрят на ошибку. Они идут по стек-трейсу. Они ищут через grep по коду. Они двигаются от симптома к источнику.

Kronos был разработан на основе этого же инстинкта.

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

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

Построение стека наблюдаемости с помощью Enter Pro

Kronos должен был работать с инструментами, которые команда ранее глубоко не использовала.

Grafana. Prometheus. Loki. Дашборды. Логи. Метрики. Оповещения.

Для команды хакатона это огромный объем инфраструктуры, в которой нужно разобраться еще до того, как сам продукт начнет работать.

Именно здесь Enter Pro оказался полезен для WhyVenv.

Команда использовала Enter Pro на протяжении всего проекта для исследований, доработки идей и отладки. Dawood и его товарищи по команде использовали его, чтобы понять стек наблюдаемости, разобраться, как компоненты сочетаются друг с другом, и преодолеть проблемы интеграции, когда система вела себя не так, как ожидалось.

Один момент особенно запомнился.

Команда застряла на том, почему их оповещения о данных не приходили правильно. Они пробовали другие модели ИИ, но Dawood чувствовал, что некоторые из них продолжали ходить вокруг одной и той же точки, даже после того, как команда уже все исправила.

Когда они попробовали Enter Pro, это помогло им более прямо определить реальную причину.

Это именно тот момент, который имеет значение в спринте разработки. Не красивый ответ для демо. Не шаблонное предложение. А конкретный толчок для преодоления реального препятствия.

Для WhyVenv Enter Pro был не просто местом для генерации кода. Это был способ быстро разобраться в незнакомых системах, чтобы продолжать разработку.

Два дня концентрации

Dawood спланировал проект еще до того, как команда приступила к серьезной разработке.

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

Затем начался настоящий ритм хакатона.

Первый день состоял не только из кода. Команда проводила время вместе, общалась, шутила и осваивалась. Настоящая разработка началась после этого: концентрированный спринт, в котором они разделили работу, исследовали незнакомые части, реализовали основной процесс и дорабатывали продукт, пока он не стал единым целым.

Архитектура начиналась просто:

отчет о сбое -> релевантный код -> диагностика LLM -> тикет или исправление.

Затем каждая часть становилась более четкой по мере того, как команда вела разработку.

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

Что Kronos говорит об ИИ-агентах

Kronos — это не чат-бот, сидящий рядом с кодовой базой.

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

Это различие имеет значение.

Dawood чувствителен к вопросам стоимости и контроля в системах ИИ. В интервью он говорил об использовании токенов, дорогих вызовах моделей и важности того, чтобы не позволять агенту обрабатывать все подряд, когда детерминированная логика бэкенда может выполнять часть работы более эффективно.

Это зрелый подход для человека, создающего решения с использованием ИИ в 2026 году.

Будущее ИИ-агентов будет связано не только с использованием более мощных моделей. Оно также будет связано с пониманием того, когда их использовать не нужно. Какие части должны быть кодом? Какие части должны быть извлечением данных? Какие части должны быть рассуждениями модели? Какие части должны оставаться под контролем человека?

Kronos, даже будучи проектом для хакатона, указывает на этот вопрос.

Что дальше

Проекту все еще нужно ответить на несколько вопросов, прежде чем он станет готов к продакшену:

Насколько хорошо подход с извлечением масштабируется на более крупные кодовые базы?
Как следует калибровать уровень серьезности и автономности?
Когда агент должен создавать тикет вместо попытки исправления?
Какого объема контекста достаточно для модели, чтобы диагностировать реальный инцидент?
Что именно должны одобрять люди, прежде чем что-либо попадет в продакшен?

Это не мелкие вопросы. Это именно те вопросы, которые заставляют обратить внимание на Kronos.

Потому что инциденты в продакшене никуда не денутся. Единственный вопрос заключается в том, должно ли каждое реагирование начинаться с ручной паники.

Kronos предлагает другой первый шаг: шаг, при котором система, обнаружившая сбой, также может начать его понимать.

Это именно то, для поддержки чего существует Enter.

Не просто более быстрый код. Более быстрый переход от реальной болевой точки к работающему продукту.

И для WhyVenv этого движения было достаточно, чтобы превратить болезненный инженерный сценарий в один из победных проектов Quackathon.

Изучите Kronos.

Эта история является частью нашей серии публикаций Quackathon Builder Series, где мы подробно рассматриваем каждый проект, чтобы понять, что разработчики создали с помощью Enter Pro, почему они это сделали и что их работа говорит нам о будущем создания программного обеспечения на базе ИИ. Следите за обновлениями.