Проекты и кейсы · Константин Пестехин

Неделя → 4–5 часов

Агентный harness: от эпика до готового кода на ревью

AI agentsMulti-agent pipelineMCPYouTrackPostgreSQL

Задача: Нарезка эпика на задачи занимала у аналитика около недели, реализация — 1–2 недели разработки. Задачи получались неоднородными, подводные камни всплывали уже в коде.
Решение: Спроектировал пайплайн из нескольких агентов. Агент анализирует идею эпика, изучает кодовую базу и определяет, куда встраивать изменения; задаёт уточняющие вопросы по логике и модулям, находит подводные камни; проверяет гипотезы и структуру данных на тестовой БД. Затем нарезает задачи, анализирует и тестирует их и выдаёт готовыми для YouTrack — в формате, который ИИ-агент может взять и выполнить целиком. Реализацию делает агент, ревью — отдельный агент, человеку остаётся финальное ревью.
Результат: Подготовка задач по эпику — 4–5 часов вместо недели работы аналитика. Реализация вместе с ревью — 4–5 часов вместо 1–2 недель, на ревью нужен один разработчик.

Доставка 60% → 100%

Отказоустойчивая рассылка пушей: очередь в PostgreSQL

Java 21Spring Boot 3PostgreSQLVirtual threadsFCMKubernetesPrometheusGrafana

Задача: Рассылка жила в памяти одного HTTP-запроса внутри монолита: падение пода или деплой — и кампания терялась. Ни ретраев, ни дедупликации, ни метрик; адреса воркеров захардкожены. Доходило около 60% пушей.
Решение: Выделил отдельный сервис с очередью в PostgreSQL и явными машинами состояний. Диспетчер превращает кампанию в задания с идемпотентной вставкой; воркеры на всех подах параллельно забирают задания через FOR UPDATE SKIP LOCKED и шлют на виртуальных потоках. Ретраи с классификацией ошибок, fallback-канал, подбор зависших заданий, партиционирование таблицы по дням. Метрики, дашборды и алерты с первого дня.
Результат: Доставка выросла с 60% до 100%. Потеря узла больше не теряет пуши, скорость рассылки регулируется в рантайме, по каждой кампании видно, что дошло и почему не дошло.

Бесшовно, 2 команды

Переезд проекта: VM → Kubernetes, Ktor → Spring Boot

KubernetesGitLab CI/CDNginxSpring BootJavaTarantool ClusterGrafanaLokiPrometheus

Задача: Проект целиком нужно было перевезти в другую инфраструктуру: приложения на виртуальных машинах, монолит на Kotlin/Ktor, одиночный Tarantool, наблюдаемость почти отсутствовала.
Решение: Руководил двумя backend-командами. Перенёс приложения с VM в Kubernetes, переписал сервисы с Ktor на Spring Boot/Java с архитектурными изменениями. Настроил пайплайны в GitLab, сетевые доступы, DNS и роутинг, поднял все сервисы. Мигрировал standalone Tarantool на Tarantool Cluster. Настроил логи, метрики, трейсы, дашборды и алерты. Трафик переключал бесшовно через дополнительный слой Nginx.
Результат: Проект выведен в продакшн на новой платформе без остановки для пользователей: горизонтальное масштабирование, воспроизводимые деплои, полная наблюдаемость и алерты.